maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Coy <st...@resolvesw.com>
Subject Re: Newbie trying to understand how to use some plugins
Date Wed, 12 Jun 2013 07:14:54 GMT
Richard,

When a Java EE server deploys an application EAR, its various components are categorised as
modules:
Each EJB jar is a separate module
Each WAR is a separate module - including all of the jars in it's WEB-INF/lib directory
All the jars in the EAR/lib directory are considered as a single module

Each module gets its own class loader. Contrary to popular belief, there is *no* EAR class
loader. (Consequently it's not normally possible to read resources from the EAR/META-INF directory,
which I've seen many developers attempt).

In the absence of any manifest class path settings, class loading works as follows:
Each EJB jar module has visibility of all classes contained in jars in the EAR/lib directory
EJB jar modules cannot see each other's classes, nor those in WAR modules
Each WAR module has visibility of all classes contained in jars in the EAR/lib directory and
all classes in each EJB module (this is optional in the spec, but in practice most app servers
support this)
WAR modules cannot see each other's classes

JBossAS/WildFly 7.x relaxes the EJB module visibility rule through default configuration so
that EJB modules *can* see each other's classes.
Aside from this, JBossAS/WildFly 7.x/8.x is highly spec compliant when it comes to class loading,
which has caused a lot of confusion because spec compliant class loading had to be *enabled*
through configuration in older versions of JBossAS.

In addition to the above, the containers provide access to the JavaSE classes and JavaEE classes*.
This means that you should *never* deploy these with your application. In maven terms, API
jars used to support builds should have a scope of "provided". This is particularly important
in WAR modules because (for historical reasons), classes are loaded from a WAR module *first*,
whereas everything else is parent first.

* Only WAR modules can see the servlet/jsp/jsf APIs. Some people get caught out by this.

As far as your separate EJB jar is concerned, just build it in to the EAR. Life will be easier!
Additionally, package your third party jar in the EAR/lib directory.

Another common mistake is to specify library jars as jar-modules in the EAR. jar-modules are
for EJB client jars (intended to be executed standalone) and are very rare in practice.

Hope this helps,

Steve C


On 12/06/2013, at 1:11 AM, RICHARD DOUST <rdoust@mac.com> 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 <waynefay@gmail.com> 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
not
>>> 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
have
>>> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message