1 |
On Thu, Jan 26, 2006 at 10:30:14AM +0100, Jose Gonzalez Gomez wrote: |
2 |
> Hi, |
3 |
|
4 |
Jose, |
5 |
|
6 |
Thanks a lot for your reply. As you observed, I'm not exactly a Java expert, so |
7 |
it was exactly what I was looking for. |
8 |
|
9 |
> I'm not sure this is the right way to go... The standard way to deploy |
10 |
> a J2EE application (wether web or more than web, this is containing |
11 |
> EJBs and other stuff) is using an enterprise application archive. This |
12 |
> is basically a jar file with .ear extension and with its content |
13 |
> arranged in a specified way. In the case of pure web applications |
14 |
> (only servlets/JSPs) you may use directly a web archive, this is a jar |
15 |
> file with .war extension and again with its contents arranged in a |
16 |
> specified way. Some containers provide support for deploying an |
17 |
> exploded (unzipped, unjarred, whatever you call it) application, but I |
18 |
> think this is not dictated by the standard, so you can't count on |
19 |
> this. Once you deploy the application, it's up to the server to do |
20 |
> whatever it wants to run the application: it could unzip (unjar) the |
21 |
> application to a working directory, or maybe just work from the |
22 |
> provided file, as long as it publishes the web application as the |
23 |
> standard dictates. |
24 |
|
25 |
Makes sense. I was under the impression (perhaps mistakenly) that we could |
26 |
simply unjar those files and copy them over. Your explanation is much |
27 |
appreciated. |
28 |
|
29 |
> Moreover, I'm not sure you could create virtual hosting based only on |
30 |
> J2EE servers, as I don't remember this to be included in the J2EE |
31 |
> standard, and again you can't count on it. I think the best way to do |
32 |
> this would be to provide virtual hosting using Apache and then use |
33 |
> some connector to forward requests to the corresponding J2EE server. |
34 |
> As far as I know this can be done with Tomcat, Jetty and JBoss fro |
35 |
> your list. |
36 |
|
37 |
Noted. |
38 |
|
39 |
> JBoss is thought as a microkernel to which you add containers and |
40 |
> services as needed. In this case, each container (web, EJB) or service |
41 |
> can be added or removed to create an instance of the server that suits |
42 |
> your needs. JBoss comes with three configurations out of the box, one |
43 |
> with all availables services activated, one as the default |
44 |
> configuration used for most of the J2EE applications and one with a |
45 |
> minimal set of services activated. Each of them has its own directory |
46 |
> where all the necessary files for that configuration live. |
47 |
|
48 |
Thanks. |
49 |
|
50 |
> I think the best bet would be to explore the API for J2EE application |
51 |
> deployment (JSR 88) ([2]http://java.sun.com/j2ee/tools/deployment/, |
52 |
> [3]http://www.jcp.org/en/jsr/detail?id=88&showPrint). This API intends |
53 |
> to provide a common contract every J2EE application server should |
54 |
> comply with, so you could create a generic deploy tool that would be |
55 |
> independent from the server you would be deploying to. |
56 |
> A quick googling of JSR 88 reports this link as something to take into |
57 |
> account: [4]http://cargo.codehaus.org/. This tool is being actively |
58 |
> developed by the Maven guys, and I'm pretty sure that could be used to |
59 |
> deploy web and J2EE applications to any supported server. |
60 |
|
61 |
Thanks for the links, I'll go do my research. |
62 |
|
63 |
> A final note: don't know if you know the difference between a java web |
64 |
> application an a full blown J2EE application... reading your mail I |
65 |
> get the feeling that you think that J2EE is similar in complexity to a |
66 |
> PHP web application, and this isn't the case. Just in case, from the |
67 |
> four servers you mention, three of them are just web containers, this |
68 |
> is, they only support a small part of the full J2EE stack. Only JBoss |
69 |
> is a full J2EE server. I think you should add to that list a few other |
70 |
> servers that are full J2EE stacks, and quite popular, like Geronimo |
71 |
> (from Apache, [5]http://geronimo.apache.org/) |
72 |
|
73 |
Noted. The reason I excluded Geronimo was because it's currently not in Portage. |
74 |
|
75 |
> HTH, best regards |
76 |
> Jose |
77 |
|
78 |
Thanks again for a very informative email. |
79 |
-- |
80 |
Renat Lumpau |
81 |
all things web-apps |
82 |
GPG key id #C6A838DA on http://pgp.mit.edu |
83 |
Key fingerprint = 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA |