Renat Lumpau wrote:
> On Thu, Jan 26, 2006 at 10:30:14AM +0100, Jose Gonzalez Gomez wrote:
> Thanks a lot for your reply. As you observed, I'm not exactly a Java expert, so
> it was exactly what I was looking for.
>> I'm not sure this is the right way to go... The standard way to deploy
>> a J2EE application (wether web or more than web, this is containing
>> EJBs and other stuff) is using an enterprise application archive. This
>> is basically a jar file with .ear extension and with its content
>> arranged in a specified way. In the case of pure web applications
>> (only servlets/JSPs) you may use directly a web archive, this is a jar
>> file with .war extension and again with its contents arranged in a
>> specified way. Some containers provide support for deploying an
>> exploded (unzipped, unjarred, whatever you call it) application, but I
>> think this is not dictated by the standard, so you can't count on
>> this. Once you deploy the application, it's up to the server to do
>> whatever it wants to run the application: it could unzip (unjar) the
>> application to a working directory, or maybe just work from the
>> provided file, as long as it publishes the web application as the
>> standard dictates.
> Makes sense. I was under the impression (perhaps mistakenly) that we could
> simply unjar those files and copy them over. Your explanation is much
I had been exploded-ness recently. For war files, jar libraries are
included in stuck into WEB-INF/lib. Because jars/wars/ears don't support
symlinks, these would be copies of whatever jars were used to construct
Following the spirit of not using bundled jars for building, this leads
me to think that it would be better to explode the wars, and replace the
jars contained within with symlinks to the jars on the system.
We should be able to do this at merge time fairly easily, so it would
just be a matter of figuring out where to stick the exploded jar
(/usr/share/PN-SLOT/webapps is where war files get stuck currently).
This exploded war could then be copied/symlink to wherever the container
>> Moreover, I'm not sure you could create virtual hosting based only on
>> J2EE servers, as I don't remember this to be included in the J2EE
>> standard, and again you can't count on it. I think the best way to do
>> this would be to provide virtual hosting using Apache and then use
>> some connector to forward requests to the corresponding J2EE server.
>> As far as I know this can be done with Tomcat, Jetty and JBoss fro
>> your list.
>> JBoss is thought as a microkernel to which you add containers and
>> services as needed. In this case, each container (web, EJB) or service
>> can be added or removed to create an instance of the server that suits
>> your needs. JBoss comes with three configurations out of the box, one
>> with all availables services activated, one as the default
>> configuration used for most of the J2EE applications and one with a
>> minimal set of services activated. Each of them has its own directory
>> where all the necessary files for that configuration live.
>> I think the best bet would be to explore the API for J2EE application
>> deployment (JSR 88) (http://java.sun.com/j2ee/tools/deployment/,
>> http://www.jcp.org/en/jsr/detail?id=88&showPrint). This API intends
>> to provide a common contract every J2EE application server should
>> comply with, so you could create a generic deploy tool that would be
>> independent from the server you would be deploying to.
>> A quick googling of JSR 88 reports this link as something to take into
>> account: http://cargo.codehaus.org/. This tool is being actively
>> developed by the Maven guys, and I'm pretty sure that could be used to
>> deploy web and J2EE applications to any supported server.
> Thanks for the links, I'll go do my research.
>> A final note: don't know if you know the difference between a java web
>> application an a full blown J2EE application... reading your mail I
>> get the feeling that you think that J2EE is similar in complexity to a
>> PHP web application, and this isn't the case. Just in case, from the
>> four servers you mention, three of them are just web containers, this
>> is, they only support a small part of the full J2EE stack. Only JBoss
>> is a full J2EE server. I think you should add to that list a few other
>> servers that are full J2EE stacks, and quite popular, like Geronimo
>> (from Apache, http://geronimo.apache.org/)
> Noted. The reason I excluded Geronimo was because it's currently not in Portage.
>> HTH, best regards
> Thanks again for a very informative email.
firstname.lastname@example.org mailing list