1 |
Renat Lumpau wrote: |
2 |
> On Thu, Jan 26, 2006 at 10:30:14AM +0100, Jose Gonzalez Gomez wrote: |
3 |
> |
4 |
>> Hi, |
5 |
>> |
6 |
> |
7 |
> Jose, |
8 |
> |
9 |
> Thanks a lot for your reply. As you observed, I'm not exactly a Java expert, so |
10 |
> it was exactly what I was looking for. |
11 |
> |
12 |
> |
13 |
>> I'm not sure this is the right way to go... The standard way to deploy |
14 |
>> a J2EE application (wether web or more than web, this is containing |
15 |
>> EJBs and other stuff) is using an enterprise application archive. This |
16 |
>> is basically a jar file with .ear extension and with its content |
17 |
>> arranged in a specified way. In the case of pure web applications |
18 |
>> (only servlets/JSPs) you may use directly a web archive, this is a jar |
19 |
>> file with .war extension and again with its contents arranged in a |
20 |
>> specified way. Some containers provide support for deploying an |
21 |
>> exploded (unzipped, unjarred, whatever you call it) application, but I |
22 |
>> think this is not dictated by the standard, so you can't count on |
23 |
>> this. Once you deploy the application, it's up to the server to do |
24 |
>> whatever it wants to run the application: it could unzip (unjar) the |
25 |
>> application to a working directory, or maybe just work from the |
26 |
>> provided file, as long as it publishes the web application as the |
27 |
>> standard dictates. |
28 |
>> |
29 |
> |
30 |
> Makes sense. I was under the impression (perhaps mistakenly) that we could |
31 |
> simply unjar those files and copy them over. Your explanation is much |
32 |
> appreciated. |
33 |
> |
34 |
> |
35 |
|
36 |
I had been exploded-ness recently. For war files, jar libraries are |
37 |
included in stuck into WEB-INF/lib. Because jars/wars/ears don't support |
38 |
symlinks, these would be copies of whatever jars were used to construct |
39 |
the jars. |
40 |
|
41 |
Following the spirit of not using bundled jars for building, this leads |
42 |
me to think that it would be better to explode the wars, and replace the |
43 |
jars contained within with symlinks to the jars on the system. |
44 |
|
45 |
We should be able to do this at merge time fairly easily, so it would |
46 |
just be a matter of figuring out where to stick the exploded jar |
47 |
(/usr/share/PN-SLOT/webapps is where war files get stuck currently). |
48 |
This exploded war could then be copied/symlink to wherever the container |
49 |
wants them. |
50 |
|
51 |
>> Moreover, I'm not sure you could create virtual hosting based only on |
52 |
>> J2EE servers, as I don't remember this to be included in the J2EE |
53 |
>> standard, and again you can't count on it. I think the best way to do |
54 |
>> this would be to provide virtual hosting using Apache and then use |
55 |
>> some connector to forward requests to the corresponding J2EE server. |
56 |
>> As far as I know this can be done with Tomcat, Jetty and JBoss fro |
57 |
>> your list. |
58 |
>> |
59 |
> |
60 |
> Noted. |
61 |
> |
62 |
> |
63 |
>> JBoss is thought as a microkernel to which you add containers and |
64 |
>> services as needed. In this case, each container (web, EJB) or service |
65 |
>> can be added or removed to create an instance of the server that suits |
66 |
>> your needs. JBoss comes with three configurations out of the box, one |
67 |
>> with all availables services activated, one as the default |
68 |
>> configuration used for most of the J2EE applications and one with a |
69 |
>> minimal set of services activated. Each of them has its own directory |
70 |
>> where all the necessary files for that configuration live. |
71 |
>> |
72 |
> |
73 |
> Thanks. |
74 |
> |
75 |
> |
76 |
>> I think the best bet would be to explore the API for J2EE application |
77 |
>> deployment (JSR 88) ([2]http://java.sun.com/j2ee/tools/deployment/, |
78 |
>> [3]http://www.jcp.org/en/jsr/detail?id=88&showPrint). This API intends |
79 |
>> to provide a common contract every J2EE application server should |
80 |
>> comply with, so you could create a generic deploy tool that would be |
81 |
>> independent from the server you would be deploying to. |
82 |
>> A quick googling of JSR 88 reports this link as something to take into |
83 |
>> account: [4]http://cargo.codehaus.org/. This tool is being actively |
84 |
>> developed by the Maven guys, and I'm pretty sure that could be used to |
85 |
>> deploy web and J2EE applications to any supported server. |
86 |
>> |
87 |
> |
88 |
> Thanks for the links, I'll go do my research. |
89 |
> |
90 |
> |
91 |
>> A final note: don't know if you know the difference between a java web |
92 |
>> application an a full blown J2EE application... reading your mail I |
93 |
>> get the feeling that you think that J2EE is similar in complexity to a |
94 |
>> PHP web application, and this isn't the case. Just in case, from the |
95 |
>> four servers you mention, three of them are just web containers, this |
96 |
>> is, they only support a small part of the full J2EE stack. Only JBoss |
97 |
>> is a full J2EE server. I think you should add to that list a few other |
98 |
>> servers that are full J2EE stacks, and quite popular, like Geronimo |
99 |
>> (from Apache, [5]http://geronimo.apache.org/) |
100 |
>> |
101 |
> |
102 |
> Noted. The reason I excluded Geronimo was because it's currently not in Portage. |
103 |
> |
104 |
> |
105 |
>> HTH, best regards |
106 |
>> Jose |
107 |
>> |
108 |
> |
109 |
> Thanks again for a very informative email. |
110 |
> |
111 |
|
112 |
- Josh |
113 |
-- |
114 |
gentoo-java@g.o mailing list |