1 |
Hi, |
2 |
|
3 |
2006/1/25, Renat Lumpau <rl03@g.o>: |
4 |
> |
5 |
> Hello, |
6 |
> |
7 |
> I am looking into making webapp-config Java-aware. While there are quite a |
8 |
> few |
9 |
> things that would need to happen from both the w-c and Java ends, it |
10 |
> definitely |
11 |
> seems plausible. |
12 |
> |
13 |
> The first step is to develop a directory structure for Java webapps that |
14 |
> supports virtual hosts and plays nice with GLEP 11. |
15 |
|
16 |
|
17 |
I'm not sure this is the right way to go... The standard way to deploy a |
18 |
J2EE application (wether web or more than web, this is containing EJBs and |
19 |
other stuff) is using an enterprise application archive. This is basically a |
20 |
jar file with .ear extension and with its content arranged in a specified |
21 |
way. In the case of pure web applications (only servlets/JSPs) you may use |
22 |
directly a web archive, this is a jar file with .war extension and again |
23 |
with its contents arranged in a specified way. Some containers provide |
24 |
support for deploying an exploded (unzipped, unjarred, whatever you call it) |
25 |
application, but I think this is not dictated by the standard, so you can't |
26 |
count on this. Once you deploy the application, it's up to the server to do |
27 |
whatever it wants to run the application: it could unzip (unjar) the |
28 |
application to a working directory, or maybe just work from the provided |
29 |
file, as long as it publishes the web application as the standard dictates. |
30 |
|
31 |
Moreover, I'm not sure you could create virtual hosting based only on J2EE |
32 |
servers, as I don't remember this to be included in the J2EE standard, and |
33 |
again you can't count on it. I think the best way to do this would be to |
34 |
provide virtual hosting using Apache and then use some connector to forward |
35 |
requests to the corresponding J2EE server. As far as I know this can be done |
36 |
with Tomcat, Jetty and JBoss fro your list. |
37 |
|
38 |
All four J2EE/servlet |
39 |
> engines currently in Portage (tomcat, jetty, resin, and jboss) implement |
40 |
> this in |
41 |
> their own way: |
42 |
> |
43 |
> - tomcat stores webapps in /var/lib/tomcat-5/{vhost}/webapps. There is |
44 |
> one "default" vhost. |
45 |
> - jetty stores webapps in /opt/jetty/webapps. There is currently no |
46 |
> vhost hierarchy, although I believe it should be easy to create one |
47 |
> under |
48 |
> /opt/jetty/webapps/{vhost} |
49 |
> - resin stores webapps in /opt/resin/webapps. There is currently no |
50 |
> vhost hierarchy, although I believe it should be easy to create one |
51 |
> under |
52 |
> /opt/resin/webapps/{vhost} |
53 |
> - jboss is less straightforward. It appears that webapps go into |
54 |
> /var/lib/jboss/{all,default,minimal}, but I'm not sure what the |
55 |
> difference |
56 |
> between those three directories is or how vhosts are handled. |
57 |
|
58 |
|
59 |
JBoss is thought as a microkernel to which you add containers and services |
60 |
as needed. In this case, each container (web, EJB) or service can be added |
61 |
or removed to create an instance of the server that suits your needs. JBoss |
62 |
comes with three configurations out of the box, one with all availables |
63 |
services activated, one as the default configuration used for most of the |
64 |
J2EE applications and one with a minimal set of services activated. Each of |
65 |
them has its own directory where all the necessary files for that |
66 |
configuration live. |
67 |
|
68 |
I propose to add a Java-specific directory under /var/www/{vhost}, such as |
69 |
> /var/www/localhost/java (perhaps there is a better name than java?). This |
70 |
> directory could be symlinked from the tomcat/jetty/resin/jboss locations, |
71 |
> much |
72 |
> like what tomcat already does. This would have the benefit of keeping |
73 |
> everything |
74 |
> related to one vhost (statis HTML, servlets, CGI scripts, etc) in one |
75 |
> location. |
76 |
> |
77 |
> Comments and suggestions (esp. from Java folks) are welcome. I would |
78 |
> particularly like to figure out what to do with jboss. |
79 |
> |
80 |
|
81 |
I think the best bet would be to explore the API for J2EE application |
82 |
deployment (JSR 88) (http://java.sun.com/j2ee/tools/deployment/, |
83 |
http://www.jcp.org/en/jsr/detail?id=88&showPrint). This API intends to |
84 |
provide a common contract every J2EE application server should comply with, |
85 |
so you could create a generic deploy tool that would be independent from the |
86 |
server you would be deploying to. |
87 |
|
88 |
A quick googling of JSR 88 reports this link as something to take into |
89 |
account: http://cargo.codehaus.org/. This tool is being actively developed |
90 |
by the Maven guys, and I'm pretty sure that could be used to deploy web and |
91 |
J2EE applications to any supported server. |
92 |
|
93 |
A final note: don't know if you know the difference between a java web |
94 |
application an a full blown J2EE application... reading your mail I get the |
95 |
feeling that you think that J2EE is similar in complexity to a PHP web |
96 |
application, and this isn't the case. Just in case, from the four servers |
97 |
you mention, three of them are just web containers, this is, they only |
98 |
support a small part of the full J2EE stack. Only JBoss is a full J2EE |
99 |
server. I think you should add to that list a few other servers that are |
100 |
full J2EE stacks, and quite popular, like Geronimo (from Apache, |
101 |
http://geronimo.apache.org/) |
102 |
|
103 |
HTH, best regards |
104 |
Jose |
105 |
|
106 |
(Sorry to post only to the java list, but I'm not subscribed to web-user) |