> yes your suggestion should work well. But now the
> deployer is forced to do redefining all my ejb
> definitions. This makes the usage a little bit
> uncomfortable. The declaration should be still an
> optional feature.
It's only optional when the ejb reference can be resolved unambiguously which was not the case in your old packaging :-)
>
> So now I will explain my new solution:
>
> I remove the EJBModule declaration from my
> application.xml for the "third-party-ejb". And the
> "third-party-ejb" will be simply added into the root
> of my EAR.
>
> ...
> <module>
> <ejb>jee-demo-ejb-0.0.2-SNAPSHOT.jar</ejb>
> </module>
> ...
>
> Next I change the MANIFEST.MF from my application
> specific EJB Module (jee-demo-ejb) like this:
>
> Manifest-Version: 1.0
> Class-Path: jee-demo-lib-0.0.2-SNAPSHOT.jar
>
> What happens now is, that all(!) my EJBs from my
> jee-demo-lib-0.0.2-SNAPSHOT.jar will be deployed
> successfully together with my application specific
> EJB Module.
> I can see this in the server.log output that all 3
> EJBs are in the same namespace of my only ejb
> module!
>
> java:global/jee-demo-ear-0.0.2-SNAPSHOT/jee-demo-ejb-0
> .0.2-SNAPSHOT/
>
> That is great! :-)
> So my final question is:
> Is this kind of packaging recommended? Adding
> ejb.jars to a ejb module by adding them to the
> classpath of the MANIFEST.MF. I have read before
> about this practice in deploying JPA entities
> together with an ejb module.
> So if this is JEE6 conform I should go this way?
Yes, this is good! In this new solution, the jee-demo-lib-0.0.2-SNAPSHOT.jar is a library jar instead of an independent ejb jar (so now only one bean will get instantiated for the bean class). And using Manifest to reference a library jar is spec conformed way to reference libraries.
I should've probably suggested this in the first place, but I was not too sure about the user scenario. If this packaging fits your need, it is a very good solution.
The difference of this packaging versus the way you did in the very beginning (putting the lib jar in the ear lib directory) is that in the current way the lib jar will only be included in the ejb jar and not other component jars (like the war file in the ear) so it would not cause any side effect that we were afraid of.
>
> By the way, what really missing in Glassfish V3 is
> the JNDI Browser Feature from V2.1 ... ;-)
I am not sure about this part. If this feature is missing, you could file an enhancement on this and we will try to include it in the next v3 release.
[Message sent by forum member 'hzhang_jn' (hong.zhang_at_sun.com)]
http://forums.java.net/jive/thread.jspa?messageID=383061