jsr342-experts@javaee-spec.java.net

[jsr342-experts] Re: Simple "war" files

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Fri, 10 Feb 2012 16:30:11 -0800

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
>>
>>
>>
>