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
