Hi Laird,
On 02/01/2011 09:31 PM, Laird Nelson wrote:
>
>
> OK. For now, it looks like I'll have to go with 3.
Thanks. In future we can give an option such that app does not have to
change (possibly a property something like
"eclipselink.weaving.enabled=false" to be set in the GlassFishProperties).
>
> this version, embedded does not make such assumption, but is
> capable of doing the weaving iff the entity classes are available
> only in the app' classloader.
>
> Case/soln (2) might solve the remote EJB issue as well, because
> the tester servlet will be able to access the @Remote EJB without
> any NamingException.
>
>
> You're referring to http://java.net/jira/browse/GLASSFISH-15775? But
> the root issue there is that it thinks that the bean's business
> interface has to extend java.rmi.Remote, which of course is not a
> requirement. I don't see how a classloader rearchitecture is going to
> help that.
I think the root cause is something else. I tried making the remote
interface explicitly extend java.rmi.Remote, but that didn't help.
However, when the embedded maven-plugin is used, it all works without
requiring to to extend java.rmi.Remote. The working test I am referring
to is this
<
http://java.net/projects/glassfish/sources/svn/show/trunk/v3/tests/embedded/maven-plugin/remoteejbs>
_Bhavani.
>
> Thanks for your pointers.
>
> Best,
> Laird