[gentoo-java] webapp-config & Java

[gentoo-java] webapp-config & Java

[Renat Lumpau]

[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]

Hello,

I am looking into making webapp-config Java-aware. While there are quite a few
things that would need to happen from both the w-c and Java ends, it definitely
seems plausible.

The first step is to develop a directory structure for Java webapps that
supports virtual hosts and plays nice with GLEP 11. All four J2EE/servlet
engines currently in Portage (tomcat, jetty, resin, and jboss) implement this in
their own way:

- tomcat stores webapps in /var/lib/tomcat-5/{vhost}/webapps. There is
  one "default" vhost.
- jetty stores webapps in /opt/jetty/webapps. There is currently no
  vhost hierarchy, although I believe it should be easy to create one under
  /opt/jetty/webapps/{vhost}
- resin stores webapps in /opt/resin/webapps. There is currently no
  vhost hierarchy, although I believe it should be easy to create one under
  /opt/resin/webapps/{vhost}
- jboss is less straightforward. It appears that webapps go into
  /var/lib/jboss/{all,default,minimal}, but I'm not sure what the difference
  between those three directories is or how vhosts are handled.

I propose to add a Java-specific directory under /var/www/{vhost}, such as
/var/www/localhost/java (perhaps there is a better name than java?). This
directory could be symlinked from the tomcat/jetty/resin/jboss locations, much
like what tomcat already does. This would have the benefit of keeping everything
related to one vhost (statis HTML, servlets, CGI scripts, etc) in one location.

Comments and suggestions (esp. from Java folks) are welcome. I would
particularly like to figure out what to do with jboss.

-- 
Renat Lumpau
all things web-apps
GPG key id #C6A838DA on http://pgp.mit.edu
Key fingerprint = 04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-java] webapp-config & Java

[Jose Gonzalez Gomez]

[-- Attachment #1: Type: text/plain, Size: 5106 bytes --]

Hi,

2006/1/25, Renat Lumpau <rl03@gentoo.org>:
>
> Hello,
>
> I am looking into making webapp-config Java-aware. While there are quite a
> few
> things that would need to happen from both the w-c and Java ends, it
> definitely
> seems plausible.
>
> The first step is to develop a directory structure for Java webapps that
> supports virtual hosts and plays nice with GLEP 11.


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.

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.

All four J2EE/servlet
> engines currently in Portage (tomcat, jetty, resin, and jboss) implement
> this in
> their own way:
>
> - tomcat stores webapps in /var/lib/tomcat-5/{vhost}/webapps. There is
>   one "default" vhost.
> - jetty stores webapps in /opt/jetty/webapps. There is currently no
>   vhost hierarchy, although I believe it should be easy to create one
> under
>   /opt/jetty/webapps/{vhost}
> - resin stores webapps in /opt/resin/webapps. There is currently no
>   vhost hierarchy, although I believe it should be easy to create one
> under
>   /opt/resin/webapps/{vhost}
> - jboss is less straightforward. It appears that webapps go into
>   /var/lib/jboss/{all,default,minimal}, but I'm not sure what the
> difference
>   between those three directories is or how vhosts are handled.


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 propose to add a Java-specific directory under /var/www/{vhost}, such as
> /var/www/localhost/java (perhaps there is a better name than java?). This
> directory could be symlinked from the tomcat/jetty/resin/jboss locations,
> much
> like what tomcat already does. This would have the benefit of keeping
> everything
> related to one vhost (statis HTML, servlets, CGI scripts, etc) in one
> location.
>
> Comments and suggestions (esp. from Java folks) are welcome. I would
> particularly like to figure out what to do with jboss.
>

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.

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

HTH, best regards
Jose

(Sorry to post only to the java list, but I'm not subscribed to web-user)

[-- Attachment #2: Type: text/html, Size: 5928 bytes --]

Re: [gentoo-java] webapp-config & Java

[Renat Lumpau]

[-- Attachment #1: Type: text/plain, Size: 4260 bytes --]

On Thu, Jan 26, 2006 at 10:30:14AM +0100, Jose Gonzalez Gomez wrote:
>    Hi,

Jose,

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

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

Noted.

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

Thanks.

>    I think the best bet would be to explore the API for J2EE application
>    deployment (JSR 88) ([2]http://java.sun.com/j2ee/tools/deployment/,
>    [3]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: [4]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, [5]http://geronimo.apache.org/)

Noted. The reason I excluded Geronimo was because it's currently not in Portage.

>    HTH, best regards
>    Jose

Thanks again for a very informative email.
-- 
Renat Lumpau
all things web-apps
GPG key id #C6A838DA on http://pgp.mit.edu
Key fingerprint = 04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-java] webapp-config & Java

[Joshua Nichols]

Renat Lumpau wrote:
> On Thu, Jan 26, 2006 at 10:30:14AM +0100, Jose Gonzalez Gomez wrote:
>   
>>    Hi,
>>     
>
> Jose,
>
> 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
> appreciated.
>
>   

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 
the jars.

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 
wants them.

>>    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.
>>     
>
> Noted.
>
>   
>>    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.
>>     
>
> Thanks.
>
>   
>>    I think the best bet would be to explore the API for J2EE application
>>    deployment (JSR 88) ([2]http://java.sun.com/j2ee/tools/deployment/,
>>    [3]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: [4]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, [5]http://geronimo.apache.org/)
>>     
>
> Noted. The reason I excluded Geronimo was because it's currently not in Portage.
>
>   
>>    HTH, best regards
>>    Jose
>>     
>
> Thanks again for a very informative email.
>   

- Josh
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] webapp-config & Java

[Andrew Cowie]

On Thu, 2006-26-01 at 16:56 -0500, Joshua Nichols wrote:

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

Note that some app-servers can't/won't deal with an exploded war/ear.

AfC
Dunedin

-- 
gentoo-java@gentoo.org mailing list

Fwd: [gentoo-java] webapp-config & Java

[Jose Gonzalez Gomez]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

---------- Forwarded message ----------
From: Jose Gonzalez Gomez <jgonzalez.openinput@gmail.com>
Date: 27-ene-2006 12:54
Subject: Re: [gentoo-java] webapp-config & Java
To: Andrew Cowie <andrew@operationaldynamics.com>

2006/1/27, Andrew Cowie <andrew@operationaldynamics.com>:
>
> On Thu, 2006-26-01 at 16:56 -0500, Joshua Nichols wrote:
>
> > 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.
>
> Note that some app-servers can't/won't deal with an exploded war/ear.
>

I think this issue has more to do with solving the issues with java builds
based in ant or maven than finding bundled jars... currently almost every
Java package out there is built using either ant or maven (please, some Java
Gentoo developer correct me if I'm wrong). In the case of maven, jar
dependencies are not bundled with source files, they are specified as
dependencies in the project descriptors. In the case of web applications,
those dependencies are downloaded from binary repositories, and bundled in
the WEB-INF/lib directory of the war file at build time. The obvious
solution (don't know if easy to implement, I remember some discussion here
regarding this) is to intercept in some way the maven dependency resolution
mechanism and instead of downloading binary jars, take jars from the java
packages already installed by Gentoo.

In case you still want to go the explode/replace way, as Andrew tells, you
won't be able to use symlinks, as some app-servers can't deal with exploded
archives. You should replace those jars with jars present on the system, and
then repackage and deploy the archive. I see this more unnatural than the
previous solution, although maybe easier to do.

Best regads
Jose

Arghh... hadn't this list activated the reply-to-list option some time ago??

[-- Attachment #2: Type: text/html, Size: 2557 bytes --]

Re: Fwd: [gentoo-java] webapp-config & Java

[Andrew Cowie]

On Fri, 2006-27-01 at 12:55 +0100, Jose Gonzalez Gomez wrote:

> Arghh... hadn't this list activated the reply-to-list option some time
> ago??

Reply to list is a feature of your mail client, not mailing list
software.

In the situation you found yourself in {shrug, it happens}, most MUAs
allows you to "Edit and Send as New Message" if you right click on
something in the Sent folder.

AfC
Dunedin

-- 
Andrew Frederick Cowie
Operational Dynamics

Website: http://www.operationaldynamics.com/
Blog: http://research.operationaldynamics.com/blogs/andrew/
GPG key: 0945 9282 449C 0058 1FF5  2852 2D51 130C 57F6 E7BD

Sydney    +61 2 9977 6866
New York  +1 646 472 5054
Toronto   +1 416 848 6072
London    +44 207 1019201

-- 
gentoo-java@gentoo.org mailing list

Re: Fwd: [gentoo-java] webapp-config & Java

[Peter B. West]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

Andrew Cowie wrote:
> On Fri, 2006-27-01 at 12:55 +0100, Jose Gonzalez Gomez wrote:
> 
> 
>>Arghh... hadn't this list activated the reply-to-list option some time
>>ago??
> 
> 
> Reply to list is a feature of your mail client, not mailing list
> software.
> 
> In the situation you found yourself in {shrug, it happens}, most MUAs
> allows you to "Edit and Send as New Message" if you right click on
> something in the Sent folder.
> 
> AfC
> Dunedin
> 

It's a mailing list configuration option, which may not be present on 
all mailing list software. Most lists I subscribe to arrange for the 
reply to go to the list. Some don't, and that's a real pain in the bum.

Peter
-- 
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3232 bytes --]

Re: Fwd: [gentoo-java] webapp-config & Java

[Joshua Nichols]

Jose Gonzalez Gomez wrote:
> ---------- Forwarded message ----------
> From: *Jose Gonzalez Gomez* <jgonzalez.openinput@gmail.com 
> <mailto:jgonzalez.openinput@gmail.com>>
> Date: 27-ene-2006 12:54
> Subject: Re: [gentoo-java] webapp-config & Java
> To: Andrew Cowie <andrew@operationaldynamics.com 
> <mailto:andrew@operationaldynamics.com>>
>
> 2006/1/27, Andrew Cowie < andrew@operationaldynamics.com 
> <mailto:andrew@operationaldynamics.com>>:
>
>     On Thu, 2006-26-01 at 16:56 -0500, Joshua Nichols wrote:
>
>     > 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.
>
>     Note that some app-servers can't/won't deal with an exploded war/ear.
>
>
> I think this issue has more to do with solving the issues with java 
> builds based in ant or maven than finding bundled jars... currently 
> almost every Java package out there is built using either ant or maven 
> (please, some Java Gentoo developer correct me if I'm wrong). In the 
> case of maven, jar dependencies are not bundled with source files, 
> they are specified as dependencies in the project descriptors. In the 
> case of web applications, those dependencies are downloaded from 
> binary repositories, and bundled in the WEB-INF/lib directory of the 
> war file at build time. The obvious solution (don't know if easy to 
> implement, I remember some discussion here regarding this) is to 
> intercept in some way the maven dependency resolution mechanism and 
> instead of downloading binary jars, take jars from the java packages 
> already installed by Gentoo.
You are right that most things build using maven and/or ant. We don't 
currently build packages using maven due to the downloading-random-jars 
bit. But the solution to that isn't really relevant to this particular 
discussion, although feel free to revive the previous thread on that matter.
> In case you still want to go the explode/replace way, as Andrew tells, 
> you won't be able to use symlinks, as some app-servers can't deal with 
> exploded archives. You should replace those jars with jars present on 
> the system, and then repackage and deploy the archive. I see this more 
> unnatural than the previous solution, although maybe easier to do.
Perhaps we should first figure out which, if any, web containers / app 
servers don't support explodedness, before discounting this method.

There is a very good reason for going the 
exploded-war-with-symlinked-jars path: you'd always be using the most up 
to date versions of the jars that have been installed on your system. 
Case in point, I recall a security vulnerability recently with struts. 
Now, if you were deploying an unexploded webapp with a vulnerable 
version of struts, then you'd still have the vulnerability in your 
webapp even after updating to a non-vulnerable version of struts. This 
wouldn't happen if we went the exploded-war-with-symlinked-jars, and at 
most you may have to restart the webapp and / or web container.

- Josh
-- 
gentoo-java@gentoo.org mailing list

Re: Fwd: [gentoo-java] webapp-config & Java

[Greg Tassone]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

On Sat, 2006-01-28 at 20:45 -0500, Joshua Nichols wrote:
> Jose Gonzalez Gomez wrote:
...
> There is a very good reason for going the 
> exploded-war-with-symlinked-jars path: you'd always be using the most up 
> to date versions of the jars that have been installed on your system. 


Just a note:  Remember that not all applications are forward compatible
with the "newest" version of a particular JAR/library.  You'd have to
deal with this somehow in your linking scheme.

Greg


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-java] webapp-config & Java

[William L. Thomson Jr.]

Greetings,

On Thu, 2006-01-26 at 10:30 +0100, Jose Gonzalez Gomez wrote:
> 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. 

Keep in mind when using vhosts with Apache and Tomcat you must configure
Tomcat for the vhosts just the same as Apache. In fact many around
Tomcat say lose Apache. Seems static speed has improved with Tomcat.
Plus it can handle SSL, Perl, PHP, etc.

Not sure about the others, but that's the case with Tomcat at least.

-- 
Sincerely,
William L. Thomson Jr.
Obsidian-Studios, Inc.
http://www.obsidian-studios.com

-- 
gentoo-java@gentoo.org mailing list