Hi, Jim.
In GlassFish it does not matter how you plan to launch the app client
- either using the appclient script or using Java Web Start. The
packaging considerations are the same. In both cases GlassFish will
make sure that the correct JARs are available to the client.
The key part is what are the "correct" JARs.
GlassFish does not do a detailed analysis of the client JAR and the
JARs it refers to in order to decide itself what JARs to make
available to the client. The Java EE 6 spec prescribes how those
decisions are to be made. Any JAR in the EAR's /lib directory must be
available to every EE module in the EAR. Further, all JARs listed in
the Class-Path entry of a module JAR's manifest must also be available.
With this in mind, the general approach we recommend is that
developers package the interfaces to EJBs - along with other things
that really will be needed by the client - into a separate JAR
library. In this design there is no need - and this is good - for the
client to refer directly to the EJB module, so this design tends to
nicely decouple the client from the EJB implementations, including
lots of classes that the EJB module needs for its server-side work
that have no business also being on the client side.
So, you could either package this library JAR into the EAR's /lib
directory or make sure the client and the EJB modules both refer to
the library JAR from their manifest Class-Path entries.
In either case, GlassFish will make the library JAR available to both
the EJB module and the app client module.
I'm not familiar with the specific Maven issue you mentioned, but you
are correct in the sense that it's a good idea to create the third,
library JAR on which the EJB and the client modules then depend.
I hope that helps.
- Tim
On Mar 15, 2012, at 11:53 AM, forums_at_java.net wrote:
> When an ACC client is bundled into an ear along with the server-side
> ejb jars
> and wars, do I need to include an ejb-client jar containing the remote
> interfaces and server side classes the client needs (such as Enums,
> Entities,
> Utility classes, etc.) or is that supposed to be handled by the ACC
> (launching via jnlp)?
>
> Currently it seems to me that I need to build this jar because
> without it the
> client can't see the classes it needs. I'm buildilng the client jar
> with
> maven inside the ejb jar's pom. The problem with this is that Maven's
> default way of building that jar includes some classes that cause
> problems on
> the server side, seemingly due to classloader issues due to having
> duplicate
> copies of classes available. Two specific cases:
>
> One:
>
> * session bean had a section with a case statement on an enum, the
> compiler
> creates a SessionBean$1.class for this
> * the $1 class is included in the client jar by maven's default rules
> (excludes things ending in "*Bean.class" for example)
> * hitting that line of code in the session bean causes
> IllegalAccessError
> * excluding that class explicitly from the client jar works around the
> problem
>
> Two:
>
> * session bean uses a utility class that exists in the same package
> * utility class has package private methods
> * utility class is not used by the client, but again, default rules
> include
> it in the client jar, because of its name
> * when the session bean creates the utility class, no errors
> * when the session bean accesses the package private methods of the
> utility
> class, it gets IllegalAccessError
>
> I can provide an example project that duplicates these problems. At
> this
> point I don't think of them as glassfish problems, but more as build
> problems
> that I can work around. But I want to know if I'm just going about
> this the
> wrong way, because it keeps biting me as new code is written and new
> situations come in where a class that doesn't need to be in the
> client jar
> shows up there.
>
> Thanks,
>
> Jim
>
>
> --
>
> [Message sent by forum member 'culli']
>
> View Post: http://forums.java.net/node/884308
>
>