glassfish_at_javadesktop.org wrote:
>>Your abstract EJB is not processed for injection, not
>>an abstract entity, right?
>
>
> I'm sorry; I had trouble parsing this sentence.
>
> I have an abstract class that concrete @Stateless EJBs extend from. It has within it a @PersistenceContext injection point like this:
>
> @PersistenceContext
> protected EntityManager em;
Right.
>
> It is in its own jar file (its own Maven project). It is not annotated with @Stateless, as I do not want it itself to be deployed as a stateless bean (it's abstract after all).
Which makes it a library in a JavaEE world.
>
> Next, I have a concrete EJB, in another Maven project, and hence another jar, that is annotated with @Stateless, and which extends my abstract EJB mentioned above.
>
> Lastly, I have various jars lying around with various @Entities in them.
Right. But here is the problem: embedded or not, it's still should be a JavaEE
artifact to deploy properly. In a regular server mode (i.e. non-embedded), you
would either package all your parts (minus may be the client class) into a
single EJB module or an ear file if you want to keep all parts separate.
>
> In my concrete EJB's project's testing phase, I invoke Glassfish in embedded mode. The classpath is the union of the abstract class jar I mentioned, the concrete EJB, and the entity jars.
>
> I hope that helps. I would pack this all up and ship it to you as is but it's proprietary. (I am beginning to think that I cannot avoid doing this anyway; it will take me several hours of dumb busywork to de-corporatize my code and send it off as a repeatable test case that will demonstrate this bug.)
>
I think I understand the problem, but there is a disagreement (between GlassFish
engineers) about the user expectations in this case, and the way to solve it (or
not) on the GlassFish side...
>
>
>>If this is correct,
>>persistence.xml won't help.... EJBContainer relies on
>>the existing deployment code to deploy EJB module
>>found on the classpath.
>
>
> Sure, OK.
>
>
>>The deployment code was
>>always under assumption that what you deploy, is a
>>complete module or application, and nothing outside
>>of it should be looked at.
>
>
> OK. {cue ominous music}
>
>
>>If there is more than 1 found, EJBContainer bootstrap
>>code creates a temp ear with the corresponding
>>modules, so that those modules can "see" each other.
>
>
> Oh, so you think that if I were to inject some other (stupid, dummy, not used) EJB module in here somewhere that that might cause an EAR to be created...would the EAR that is created on the fly like this also house my various entity jars?
Good question. No, the current code will look only at the EJBs and ejb-jar.xml.
And only persistence.xml and classes that are part of the same the EJB module
(or a library inside an ear) are being processed. So if you have 2 EJB jars that
need to share a PU, you are out of luck.
May be we should provide a "library" property for the createEJBContainer() call
so that you can tell us the exact list of the dependencies...
Regards,
-marina
>
> Best,
> Laird
> [Message sent by forum member 'ljnelson']
>
> http://forums.java.net/jive/thread.jspa?messageID=396977
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>