On 8/8/07, David Blevins <[EMAIL PROTECTED]> 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
