J2EE packaging mechanisms such as the War, Jar and EAR file are a basic yet very misunderstood feature of the J2EE development process. A new article by Tyler Jewell discusses some of the nuances associated with J2EE packaging and provides some hints to make you more productive.
- Posted by: Floyd Marinescu
- Posted on: June 28 2001 14:22 EDT
Read EJB 2 and J2EE Packaging.
- Making sense of J2EE packaging mechanisms by sharat nellutla on June 28 2001 15:49 EDT
- Making sense of J2EE packaging mechanisms by Rishi Tank on June 29 2001 17:15 EDT
- Making sense of J2EE packaging mechanisms by Tom Davies on June 30 2001 04:28 EDT
- Making sense of J2EE packaging mechanisms by Tyler Jewell on June 30 2001 09:20 EDT
Making sense of J2EE packaging mechanisms by nick pellow on July 01 2001 02:45 EDT
- Making sense of J2EE packaging mechanisms by kumar allamraju on July 01 2001 01:13 EDT
- Making sense of J2EE packaging mechanisms by timothy dennison on October 30 2001 05:58 EST
- Making sense of J2EE packaging mechanisms by nick pellow on July 01 2001 02:45 EDT
- Making sense of J2EE packaging mechanisms by Tyler Jewell on June 30 2001 09:20 EDT
- Making sense of J2EE packaging mechanisms by Gary Bisaga on December 10 2001 17:53 EST
Truly specking this where (packaging) J2EE is so poor. Some time packing makes life hell. There should be some mechanism to include Managed Beans in .ear files.
The problem of being able to refer common libraries from both web application & EJB modules has been troubling me for a while. I think J2EE has failed to cleanly address this basic need so far.
By common libraries I mean utility classes, object model components that are not web or EJB specific & are common to the suite of applications within an organization. To me it seems like these common libraries should be given a separate J2EE module identity like a web application module or an EJB module(let's call it a library module). That way a library module can be packaged & deployed just like any other J2EE web or EJB module as opposed to being packaged in a JAR file & manually added to classpath or Java 2 extension framework. Just like a web module can refer to an EJB module & EJB module can refer to another EJB module, both web & EJB modules could refer to this library module. No more classpath hassles & the library module is easily shared by any number of web and EJB modules.
For low level libraries(like JDBC drivers, LDAP service providers etc.) whose source code is not exposed, it's obviously okay to use classpath, but for libraries that are built in-house & whose source code can change, there is no clean way to package & deploy it in a J2EE-friendly way so that it can be shared by any web or EJB modules.
As a workaround, I am thinking of packaging those libraries in an EJB module by creating a dummy session bean. Web & EJB modules could then refer to that dummy bean in the EJB library module. Can anyone think of possible problems with this approach ? Any alternative approaches that could work out better ?
Nice to see someone answering this question -- it has been bothering me.
Does Weblogic 6.0SP2 support this?
This feature exists in WLS 6.1 for EAR and JAR files. It isn't needed for WAR files since you have WEB-INF\lib. When doing it for EAR files, the utility classes got into the \lib directory and your EJBs go into ejb\. When referring to the utility class in the manifest classpath, you use a relative path, but you leave off the lib\.
What is the best way to define the default webapp in an
EAR. By default webapp, I mean the webapp that is refrenced
with URI /. I have many webapps in one EAR on WLS6.0 and
/ returns a 303 Permission Denied or some such. However,
I can refrence each individual webapp as defined in application.xml.
AFAIK, Default webapp is at the webserver level, not per application.
A couple of questions regarding your article on J2EE Packaging and EJB2 (http://www.onjava.com/pub/a/onjava/2001/06/26/ejb.html?page=2)
In particular, you quote:
"The EJB 2.0 public final draft 2 (PFD2) specification is driving some projects to do this.
This new version of the specification mandates that entity EJBs participating in a relationship do so using local interfaces and requires both of the EJBs in the relationship to be packaged into the same JAR file."
Admittedly, I have not read the PDF2 cover to cover - but I have spent quite some time looking through it to evaluate the impact of the new changes. However, I cant find where the local interface / Jar file limitation is specified.
Could you possibly point me to the appropraite section?
The second question is regarding J2EE packaging:
The problem is how to set application-wide config settings in your deployed app.
Within the ejb-jar.xml file you can set individual bean-level, <env-entry> properties - which can be used to specify things that you dont want to hard-code.
However, this means that you have to specify (usually identical) settings in the DD for *each* bean.
If you are creating a generic baseclass - that your all EJbean implementations extend - in order to centalise management of such standard things as logging,
then you have no ability to centrally control your actual logging settings... (other than hard-coding them in the base class implementation!). You would prefer to control these settings in your DD...
What would be the best approach here? I cant see anything in EJB2 that helps here.
To answer my own questions (following some email discussion):
Entity beans participating in CMR relationships will need to exist in the same jar. This is not dictated by the spec directly (perhaps it should be for clarity) - but implied by the fact that CMR relationships can only be implemented via local interfaces.
Reference relationships do not require the beans to be in the same jar.
In any case, the advice is generally to group tightly coupled beans in the same jar.
Can you explain why the fact that container managed relationships are implemented using local interfaces implies that EJBs in these relationships must be packaged in the same jar? My understanding of local interfaces is that they can be used within the same JVM. Doesn't that mean that anything in the enterprise application can access the local interface and thus two EJBs can be packaged into separate jar files within the ear but still call each other through their local interfaces? If this is true, shouldn't I be able to have a CMR that spans jars?
Are you indicating that an ear file with an ejb-jar and war file referencing a common java library should be structured as follows?
(where the manifest file for myejb.jar and mywar.war use the classpath attribute of: lib/log4j.jar lib/struts.jar)?
I'm having a great deal of difficulty getting this to work with weblogic 6.1 sp1. I'd GREATLY appreciate your help.
The manifest.mf entry is always relative from the package. So, if you have a structure like:
The myejb.jar manifest.mf would have:
The myweb.war manifest.mf would have:
The anotherejb.jar manifest.mf would have:
There is a dependency example that has all of this at the developer.bea.com site in the EJB tech track.
Regarding, following ear content
and assuming ejb and web is dependent on common mylib jar and also myweb is an using ejb local interfaces as an ejb-client, Can you also specify what is the exact content of application.xml should be? I know it should have web and ejb module, but I am not sure about mylib.jar module, is it necessary to put /lib/mylib.jar in between <java>,</java> tags in application.xml? Also what about manifest files, I understood myejb.jar and myweb.war should have
Class-path: ../mylib.jar, but what about ear manifest file entries, it is not clear to me any thing to put ther too?
Also, regarding myweb.war myejb.jar dependency as a client, do I need to put anything in myweb.war's Manifest file regarding this ejb dependency? Thanks
I'm trying to figure out what's a sensible architecture for J2EE packaging of an appliation. (We're using weblogic 6.1 for what that matters, but it seems this should be mostly independent of which server we're using). We will be developing multiple applications that will be somewhat independent of each other; and my question is what the best practice is for packaging these into WAR/EAR files. By "somewhat independent" I mean:
1. There will be application modules that will contain different code; however they will use alot of common library classes
2. We will want to use a single-signon, meaning here simply that if you sign on to the system, your signon will be good in every web application on the system, or at least on more than one. This seems to me to imply sharing an HTTP session between more than one WAR file, but everything I can find seems to indicate this is not possible.
3. It would be nice to have at least some parts of the application independently loadable/unloadable.
Questions that come to mind include:
a. Based on (2) above are we doomed to having a single WAR file with everything in it, or at least everything that needs the same signon?
b. If there is some way to share sessions between WARs, is there any benefit of putting all the WARs into the same EAR file?
c. Is there any way of sharing class instances between EARs, e.g. for Singleton classes? From what I see in Tyler's articles etc. everything in a given EAR will use the same class loader, thus they will all get the same singleton. This does not seem to be the case between different EARs.
d. In general, is there a real-world example of packaging a J2EE application, especially if the tradeoffs of putting things into the same WAR, multiple WARs in the same EAR, or multiple EARs is discussed? The toy examples I've seen so far really don't answer this question.
Thanks in advance for any and all help,