Re: Expanded types for env-entries (was: Re: Test errors)

[David Blevins <da...@visi.com>]

On Feb 28, 2007, at 10:29 AM, Dain Sundstrom wrote:

> On Feb 28, 2007, at 12:38 AM, David Blevins wrote:
>
>> First, it seems like a bug in xbean-reflect's File property editor  
>> (haven't looked too hard yet).  We're supplying the string "C:/ 
>> temp" and it's giving back "/private/tmp/openejb3/container/ 
>> openejb-core/C:/temp".  So clearly it's calling new File 
>> (string).getAbsoulteFile() and returning that.  Something to look  
>> into fixing as I don't think it's xbean reflect's place to be  
>> resolving relative paths.
>
> I wrote that code, but I think you are correct.  If the receiving  
> bean wants an absolute path, it can make the calls itself.

I just ran into this again.  Fixed it in xbean-reflect and checked it  
in.  We just did an xbean-reflect release so we might want to create  
a build of that and throw it in our repo for our 3.0 release.

-David

Re: Expanded types for env-entries (was: Re: Test errors)

[Mohammad Nour El-Din <no...@gmail.com>]

On 8/8/07, David Blevins <da...@visi.com> wrote:
>
>
> On Aug 8, 2007, at 3:52 AM, Mohammad Nour El-Din wrote:
>
> > Hi David...
> >
> > Thanks a lot :), I am busy right now, but during free times I have I
> > investigate a related problem to this JIRA, the problem of the
> > Properties
> > env-entry, I am reading about JAXB2 to gain more info.
>
> I bet that properties problem is fixed now.  One of the issues we
> found in certification is that it's not legal to trim white space
> from the <env-entry-value> tags, which if i recall correctly was what
> was preventing the Properties thing from working.


I am worming myself up again to get back more active :). I didn't understand
why trimming the value of the env-entry-value causes the Properties
env-entry-type not to work ???

In general, I wonder if we shouldn't consider this issue solved.  I
> mean we do have extended env entry type support in that if the type
> in the declaration is java.lang.String and your bean actually has say
> java.util.Date, then xbean-reflect will convert it.  So the
> functionality is there, strictly speaking.  The downsides are:
>
>   1. the value in jndi is still java.util.String
>   2. it has to be reconverted on each bean creation
>
> The upsides I guess are:
>
>   1. the env-entry-value is still a legal type (illegal values might
> be an issue for 3rd party tooling)
>   2. who wants to have to specify the type anyway
>
> Course the opposite of #2 could also be considered a positive, maybe
> some people want to use their env-entry-type[s] and their bean field/
> setter types to strictly match.
>
> Don't know.  Thoughts?
>
> > BTW, the new
> > xbean-reflect release is on the remote maven repo ?
>
> Yes.  It's up on in ibiblio, just this change came afterwards.
>
> -David
>
>
>
>


-- 
Thanks
- Mohammad Nour

Re: Expanded types for env-entries (was: Re: Test errors)

[David Blevins <da...@visi.com>]

On Aug 8, 2007, at 3:52 AM, Mohammad Nour El-Din wrote:

> Hi David...
>
> Thanks a lot :), I am busy right now, but during free times I have I
> investigate a related problem to this JIRA, the problem of the  
> Properties
> env-entry, I am reading about JAXB2 to gain more info.

I bet that properties problem is fixed now.  One of the issues we  
found in certification is that it's not legal to trim white space  
from the <env-entry-value> tags, which if i recall correctly was what  
was preventing the Properties thing from working.

In general, I wonder if we shouldn't consider this issue solved.  I  
mean we do have extended env entry type support in that if the type  
in the declaration is java.lang.String and your bean actually has say  
java.util.Date, then xbean-reflect will convert it.  So the  
functionality is there, strictly speaking.  The downsides are:

  1. the value in jndi is still java.util.String
  2. it has to be reconverted on each bean creation

The upsides I guess are:

  1. the env-entry-value is still a legal type (illegal values might  
be an issue for 3rd party tooling)
  2. who wants to have to specify the type anyway

Course the opposite of #2 could also be considered a positive, maybe  
some people want to use their env-entry-type[s] and their bean field/ 
setter types to strictly match.

Don't know.  Thoughts?

> BTW, the new
> xbean-reflect release is on the remote maven repo ?

Yes.  It's up on in ibiblio, just this change came afterwards.

-David

Re: Expanded types for env-entries (was: Re: Test errors)

[Mohammad Nour El-Din <no...@gmail.com>]

Hi David...

Thanks a lot :), I am busy right now, but during free times I have I
investigate a related problem to this JIRA, the problem of the Properties
env-entry, I am reading about JAXB2 to gain more info. BTW, the new
xbean-reflect release is on the remote maven repo ?

On 8/8/07, David Blevins <da...@visi.com> wrote:
>
>
> On Feb 28, 2007, at 10:29 AM, Dain Sundstrom wrote:
>
> > On Feb 28, 2007, at 12:38 AM, David Blevins wrote:
> >
> >> First, it seems like a bug in xbean-reflect's File property editor
> >> (haven't looked too hard yet).  We're supplying the string "C:/
> >> temp" and it's giving back "/private/tmp/openejb3/container/
> >> openejb-core/C:/temp".  So clearly it's calling new File
> >> (string).getAbsoulteFile() and returning that.  Something to look
> >> into fixing as I don't think it's xbean reflect's place to be
> >> resolving relative paths.
> >
> > I wrote that code, but I think you are correct.  If the receiving
> > bean wants an absolute path, it can make the calls itself.
>
> I just ran into this again.  Fixed it in xbean-reflect and checked it
> in.  We just did an xbean-reflect release so we might want to create
> a build of that and throw it in our repo for our 3.0 release.
>
> -David
>
>


-- 
Thanks
- Mohammad Nour