maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <>
Subject Re: Newbie trying to understand how to use some plugins
Date Tue, 11 Jun 2013 15:49:09 GMT

Re: "Local" access crossing different EAR files:

That isn't Maven related, but I happened to be discussing this with some
folks in my company just this morning.  Basically it's a classloading
issue.  An Enterprise Application (ear file) has its own classloader. 
So the client in ear file B, trying to make a local access to
"" in ear file A is actually looking at a completely
different class from the "" that is defined in ear
file A, even though the name appears to be the same.  The same byte code
loaded by two different class loaders makes two different classes.

The application server _may_ have a way to define a common library that
spans the two applications  I think Websphere does, but I'm not sure
about JBoss.  The EJB spec allows it but doesn't require it, and makes
clear that such an arrangement is not portable.

So if you put your web and ejb modules in separate enterprise
applications, you most likely need to use the remote interface.  Calls
don't necessarily go out over the network, as the local ORB might
optimize it, but parameters and return values will be serialized, so you
won't have call-by reference semantics.

I wonder, though, if you could repeat the original question?  I recall
something about "the library jar isn't on the server", and I'm not sure
if you meant "it isn't in Maven Central" or something else.



On Tue, 2013-06-11 at 11:11, RICHARD DOUST wrote:
> Wayne,
> Thanks for your response.
> I don't really need to make the EJB jar work standalone. I was trying to divide and conquer.
In 4.2.2 I deployed the EJB jar as part of an EAR with 2 WARs. I think that I'd like to deploy
to JBoss AS 7 with an EAR containing the EJB jar, and two separate wars that use the services
of the beans packaged in the EAR. I'm a little concerned though because I read that if I go
this route, the web tier will be forced to use the remote interfaces while they currently
use local interfaces. Do you know if this is correct?  
> Thanks,
> Richard
> On Jun 10, 2013, at 1:05 PM, Wayne Fay <> wrote:
> >> Anyway, I'm running into issues at deployment time (just starting with the EJB
jar as a
> >> standalone deployment) because the EJB jar depends on a 3rd party jar that is
> >> available on the server.
> > 
> > If you **really** need to make the EJB jar work in standalone
> > deployment (which is not especially common IME), you could make this
> > work with the shade plugin (or other similar plugins) by packaging the
> > contents of your dependencies in alongside your own project files in
> > an "uberjar" or "onejar."
> > 
> >> I'd like to avoid that this time, so I'm thinking, much like WAR and EAR files
> >> META-INF/lib directories, a jar file might have something similar. Does this
fall outside
> >> the definition of a jar? Is there no way to package a 3rd party jar upon which
one's code
> >> depends with one's jar, so that at runtime the dependencies can be resolved
by the
> >> classloader?
> > 
> > The Java Jar file specification does not allow Jar files to contain
> > other Jar files so this is not possible (unless you are using a
> > special classloader which does not conform to the spec like
> > Classworlds).
> > 
> > Instead, you should be using dependencies in your WAR and EAR pom
> > files to declare "this project depends on these libraries" and Maven
> > will automatically pull those Jar files in and include them in the WAR
> > or EAR packages when they are constructed.
> > 
> > Are you sure that you need this EJB jar to work in standalone
> > deployment? Or is this just something you're trying for something to
> > do, and you will generally deploy the EJB in a WAR/EAR? If the latter,
> > I would ignore this "problem" for now and continue working to make the
> > WAR/EAR function as you require.
> > 
> > Wayne
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> > 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
Greg Trasuk.  
Stream Lead - Open Source Technologies
Ph: 905-315-9509
Cell: 905-921-6464

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message