AKostylev wrote:
>Thank you a lot for your attention.
>I'll look forward for the update where this bug is fixed.
>
We've fixed it on the trunk. Try downloading the latest
build from :
http://download.java.net/javaee5/trunk/installer-nightly/
and let us know your results. I would recommend starting
with the explicit InitialContext(Hashtable) creation approach
rather than the Resin jndi-link to reduce the number of
variables.
>But I have another question though:
>is it normal that I need 5 jars -
>
>appserv-deployment-client.jar
>appserv-launch.jar
>appserv-rt.jar
>j2ee.jar
>javaee.jar
>
>to connect to Glassfish from standalone web container?
>Or is there another way to make this?
>
This is another difference between using a stand-alone java client
and an Application Client. When using an Application Client,
the burden of configuring the classpath to include all necessary
system code is on the container. We've tried to reduce the
number of .jars in the stand-alone client case but there are still
multiple needed.
In the simplest ejb access case you should only need appserv-rt.jar
and javaee.jar. j2ee.jar is the same thing as javaee.jar. We simply
renamed the .jar containing the Java EE API classes due to the
change of platform name between "J2EE" 1.4 and "Java EE" 5.
If your client accesses additional functionality beyond EJBs such
as persistence or JMS, there are some additional .jars needed in
the stand-alone case. We've listed these on the EJB FAQ.
--ken
>
>
>
>>AKostylev wrote:
>>
>>
>
>
>
>>>That's a pity but exception is stile the same when using Properties.
>>>
>>>
>>>
>>OK, thanks for trying that out. The fact that the behavior was
>>the same helps isolate the problem. This is looking like a bug in
>>a piece of our code that does its own internal lookup during
>>the EJB 3.0 reference processing on the client-side. It should be
>>using a context that matches the one on which the original lookup
>>was performed but instead it's internally creating its own
>>no-arg InitialContext(). Since Resin has overridden the default
>>naming provider for the JVM, the resulting internal lookup is not
>>successful.
>>
>>
>
>
>
>>I've filed an issue to track this bug :
>>
>>
>
>
>
>>https://glassfish.dev.java.net/issues/show_bug.cgi?id=920
>>
>>
>
>
>
>>We'll fix this in the trunk and backport it for the 9.0 UR1 release.
>>
>>
>
>
>
>>Note that it's possible there will be some other conflict with the
>>Resin environment even after this is fixed but we'll handle that
>>as necessary. One interim solution is to expose an adapted
>>2.x Home interface from your EJB and look that up instead.
>>The lookup for the 2.x Home involves a different path that will
>>not encounter the same bug.
>>
>>
>
>
>
>>Thanks for your patience.
>>
>>
>
>
>
>> --ken
>>
>>
>
>
>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>
>
>
>
>
>