The behavior has nothing to do with EclipseLink. It is how "Application
Class Loader" in GlassFish works for non-OSGi application. A Class
Loader for any non-OSGi J2EE application in GlassFish can see packages
exported by any OSGi bundle. So, the EJB application's class loader is
able to see A.class in your case. If you want A.class to be not visible
to the whole world, then while exporting the corresponding package,
specify a mandatory attribute.
I once wanted to change the behavior of Application Class Loader to not
be able to see an exported package by default, but there were resistance
to the change, so I did not pursue it further.
Having said that, I would also like to know why you packaged A.class in
an OSGi bundle to start with. Are you interested in developing OSGi
enabled applications in GlassFish?
Thanks,
Sahoo
glassfish_at_javadesktop.org wrote:
> I've made the following steps:
>
> 1. An JPA annotated entity class A was written;
> 2. The class had been wrapped as an OSGi bundle (or hk2-jar);
> 3. A stand-alone EJB jar had been made with only a "META-INF/persistence.xml" resource inside. The class A had been referenced from "META-INF/persistence.xml" but it wasn't placed into the EJB;
> 4. The bundle (OSGi or hk2-jar - it doesn't matter) had been deployed to GlassFish v3 b55 environment;
> 5. The EJB module had been deployed to the same running instance of GlassFish Application Server.
>
> Now, we can get the entities A (as a part of OSGi/hk2 bundle) from any running J2EE application with using of EclipseLink JPA.
>
> The question is:
> Could we classify this behaviour of EclipseLink JPA as a bug or as a feature? Could we rely on such behaviour of EclipseLink JPA in future?
> [Message sent by forum member 'vektor79' (vektor79)]
>
> http://forums.java.net/jive/thread.jspa?messageID=358585
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>