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
soon.
Antonio
On Sat, Feb 11, 2012 at 01:30, Bill Shannon <bill.shannon_at_oracle.com> 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 <http://www.antoniogoncalves.org> |
Twitter<http://twitter.com/agoncal>|
Blog <http://feeds.feedburner.com/AntonioGoncalves> |
LinkedIn<http://www.linkedin.com/in/agoncal>| Paris
JUG <http://www.parisjug.org>