Hi Dain...
Thanks for your feedback, I will look at it when I get to home.
On 2/28/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
On Feb 28, 2007, at 10:58 AM, Mohammad Nour El-Din wrote:
> On 2/28/07, Dain Sundstrom <[EMAIL PROTECTED]> 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.
>>
>> > Second is a completely trival issues. Seems the calling of equals
>> > on two properties instances isn't kosher. It complains "expected:<
>> > {key2=value2, key1=value1}> but was:<{key1=value1
>> > key2=value2}>", so obviously they are equal and something else
>> > going wrong.
>>
>> Are you sure that they the values are both plain old
>> java.lang.Strings?
>
>
> The value of the *expected* Properties object is provided to the
> PropertyEditors class as a plain old java.lang.String coded into
> the test
> case itself "key1=value1\r\nkey2=value2", but the value provided to
> the
> PropertyEditors class to create the *actual* Properties object is
> parsed
> from the ejb-jar.xml file and I access it from the env-entry
> references
> created with the EJB info object.
Are you sure that the property editor is getting exactally
"key1=value1\r\nkey2=value2"? My guess is the value is changed to
"key1=value1 key2=value2" by this declaration in the
org.apache.openejb.jee.package-info.java file:
@javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter
(value=javax.xml.bind.annotation.adapters.CollapsedStringAdapter.class,t
ype=String.class)
If my, guess is correct, it can be fixed by overriding the
@XmlJavaTypeAdapter annotation on the
org.apache.openejb.jee.EnvEntry.envEntryValue field. I'm not sure if
you can use the annotation to set the adapter back to null, and
unfortunately, there doesn't seem to be a do nothing adapter, so you
may have to write one.
-dain
--
Thanks
- Mohammad Nour
