[javaee-spec users] [jsr342-experts] Re: Simple "war" files

From: Antonio Goncalves <>
Date: Mon, 13 Feb 2012 09:15:02 +0100

I've always found it weird to think of the packaging I need. A jar file is
fine, but if I add a servlet I then need to change it to a war. And if I
need nested jars, then I need to change it to an ear. Why do I have to
bother ? As David says, the container dismantles the archives and looks at
what inside anyway. So why do I have to tell the container that this is a
web archive ? It can guess by checking @WebServlet or web.xml.

If in the future we aim at having a single container with multiple
services, a single packaging will fit this perfectly. But as Bill mentions,
I'm also not conviced at the moment... knowing that modules will arrive


On Sat, Feb 11, 2012 at 01:30, Bill Shannon <> wrote:

> I agree, if we were to do it all over again, I'd look at turning
> web applications inside out and packaging them in jar files.
> But at this point I'm not at all convinced that the advantages
> justify the costs.
> Lots of people complain about the complexity of Java EE. Every
> time we come up with a better way to do the same thing, a bunch
> of people just look at it as a different way to do the same thing,
> which makes the platform seem more complex. Stuff like this really
> has to have a big payoff to make it worthwhile, which I don't see
> in this case.
> In any event, any discussion of this particular issue really needs
> to start in the Servlet expert group.
> David Blevins wrote on 02/08/12 20:05:
>> While I'm not sure how I feel about the concept of remaking EAR files for
>> EJBs, I have wondered the exact opposite about .war files.
>> Specifically, I have often longed for plain-java "war" file packaging
>> that didn't involve nested jars. Basically, the exact opposite of what we
>> have now.
>> Instead of:
>> archive/WEB-INF/classes/<the-**code>
>> archive/<the-content>
>> Perhaps something like this:
>> archive/<the-code>
>> archive/WEB-INF/content/<the-**content>
>> There are various names we might choose instead of "/WEB-INF/content",
>> such as maybe "/META-INF/web/", but you get the idea.
>> Being able to test servlets on a plain classpath the way we can currently
>> test EJBs would be stellar. We don't have the standard concept of an
>> Embedded Servlet container, but they do exist. Having to create war files
>> only for the purpose of handing them to a container which will simply
>> dismantle them is a bit of work that would be nice to avoid. We all know
>> how big of a performance hit this can be disk-wise. This kind of thing
>> would also be nice for more OSGi-friendly usage which is always a
>> non-nested kind of environment with dependencies handled elsewhere.
>> Having a single-jar deployable version of a "webapp" is very useful.
>> These days you can get quite far with a single jar that contains CDI, JPA,
>> EJBs, EJB @WebServices, and EJB JAX-RS components, etc.. The day you want
>> to add a servlet, though, you suddenly have to change all your packaging.
>> Ironically, this used to be one of the complaints about EJB till we added
>> the EJBs in .wars feature.
>> I can see tremendous value in saying "if you want to put your entire app
>> in one jar, that's ok." Allowing for multi-archive archives is certainly
>> useful, but at this point I don't see a reason for forcing it.
>> A thought at least.
>> -David
>> On Feb 8, 2012, at 5:14 PM, Marina Vatkina wrote:
>> Experts,
>>> As you know, while it's easy to package a library into a .war file or a
>>> .ear archive, there is no easy way to do the same for a stand-alone EJB
>>> module in a portable way. The only current option is to use a reference by
>>> adding a Class-Path attribute to the Manifest file of the EJB .jar file (or
>>> another referenced archive) but this is not portable as it requires to
>>> place referenced library in the specific location of the application server
>>> file system (in case that .jar file is not used from its original location).
>>> Do you thing the EJB spec should allow an EJB .jar file to have a lib/
>>> directory inside it? If yes, will there be any restrictions that we will
>>> need to address?
>>> Thank you,
>>> -marina

Antonio Goncalves
Software architect and Java Champion
Web site <> |
Blog <> |
LinkedIn<>| Paris
JUG <>