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