> glassfish_at_javadesktop.org wrote:
> > 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.
Yes, absolutely. I would (and do) package this in a "real" deployment scenario in an ear's lib directory.
> > 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.
Yep. But in the very common case of automated unit testing, you're just going to have a big horking classpath that--during automated testing--should be considered to be the contents of a hypothetical (or real, but just-in-time) .ear file. Obviously there's more on this classpath than would be deployed in a [i]bona fide[/i] production scenario, but man, I can tell you that if you don't offer this ability, OpenEJB (which DOES offer this ability) is looking pretty good about now. :-) Now if only they could get their OpenJPA 2.0 story straight.... :-)
> 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...
Would you kindly clarify? I am happy to represent the users. I also have a pretty deep understanding of how containers "think" in this respect as well, so might be able to help mediate.
> 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.
Well...crap. :-)
> So
> if you have 2 EJB jars that
> need to share a PU, you are out of luck.
Double crap.
> May be we should provide a "library" property for the
> createEJBContainer() call
> so that you can tell us the exact list of the
> dependencies...
Yes! Yes! Please! Keep thinking along these lines. And quickly, since the lack of ability to do this sort of thing is making me lean back towards other (non-optimal) solutions.
OpenEJB, as I stated before, does exactly this sort of thing. I would switch (back) to them in a [i]heartbeat[/i] if their JPA 2.0 support were better, which it will be in a matter of weeks. They [i]really[/i] get the embedded testing thing in a way that neither Glassfish nor JBoss does today, or ever has. Essentially, things "just work". Temporary .ear files are created, persistence units are discovered, unit tests are treated as pseudo-application clients--it's a beautiful thing. The end result is a unit test that can grab a reference to an EJB with little or no annoying boilerplate deployment silliness. Have a look at how they use their (proprietary) @LocalClient annotation in unit tests to get an idea of the use cases that (IMHO) all application servers need to support if EJBContainer is going to be a meaningful concept.
Best,
Laird
[Message sent by forum member 'ljnelson']
http://forums.java.net/jive/thread.jspa?messageID=397030