1 |
Hello Eivind and Robin, |
2 |
|
3 |
Eivind Tagseth wrote: |
4 |
> |
5 |
> * Robin H. Johnson <robbat2@g.o> [2004-01-08 02:48:43 -0800]: |
6 |
> |
7 |
>> I'm working on implementing GLEP11 (just started a week ago since my |
8 |
>> school semester was over and I had some vacation time). I've got |
9 |
>> absolutely no experience or knowledge of servlets, so if you can explain |
10 |
>> how to incorporate them and how they fit together with everything, I'd |
11 |
>> be glad to see if they fit in with vhost-config and webapp-config, or |
12 |
>> java-config. |
13 |
> |
14 |
> I'll try to explain. |
15 |
> |
16 |
> Servlets |
17 |
> -------- |
18 |
> |
19 |
> Servlets, or rather, web applications, usually come in the form of a |
20 |
> WAR-file |
21 |
> (Web Archive). |
22 |
|
23 |
Just to clarify, what "usually means": You can provide a web application |
24 |
either as war file or as a complete directory tree. The war file just |
25 |
contains this tree for (installation) convenience, but may have to be |
26 |
extracted to adjust configuration files. |
27 |
|
28 |
> Everything needed to run the web application is contained |
29 |
> in this file (apart from the servlet engine itself), and installation of |
30 |
> the web application is a matter of deploying it into a servlet engine. |
31 |
> |
32 |
> As you can see, this is much like installing a "normal" web application |
33 |
> into apache, but in many ways much simpler. |
34 |
> |
35 |
> Servlet engines |
36 |
> --------------- |
37 |
> |
38 |
> Just as with web servers, there are several available servlet engines. |
39 |
> But unlike web servers, in theory, all web applications can be run by all |
40 |
> servlet engines. The process of deploying an application may be different |
41 |
> though, but many servlet engines lets you deploy a web application simply |
42 |
> by dropping the war file into a certain directory. |
43 |
> |
44 |
> The current problem |
45 |
> ------------------- |
46 |
> |
47 |
> The problem is that there is no standard way to install a web application |
48 |
> on a gentoo system, and there is no way to choose which servlet engine |
49 |
> one wants to use. |
50 |
> |
51 |
> Application Installation |
52 |
> - - - - - - - - - - - - |
53 |
> |
54 |
> For example, the before mentioned cocoon application requires tomcat. |
55 |
> Personally, I don't use tomcat, I rather use JBoss/Jetty for my |
56 |
> web applications. However, since I have installed cocoon, I automatically |
57 |
> got tomcat dragged in. And emerging cocoon gives me |
58 |
> |
59 |
> /opt/jakarta/tomcat/webapps/cocoon.war |
60 |
> |
61 |
> and documentation in |
62 |
> |
63 |
> /usr/share/doc/cocoon-2.0.2 |
64 |
> |
65 |
> So installing cocoon for me is: |
66 |
> |
67 |
> emerge cocoon |
68 |
> cp /opt/jakarta/tomcat/webapps/cocoon.war |
69 |
> /opt/jboss-3.2.1/server/default/deploy/ |
70 |
> |
71 |
> Which isn't very elegant. |
72 |
> |
73 |
> This is very much like the problem with apache applications, and you could |
74 |
> probably use the same system. Cocoon could be installed into |
75 |
> /usr/share/webapps/, just like the apache applications, e.g. like |
76 |
> /usr/share/webapps/${P}/war/cocoon.war. |
77 |
> |
78 |
> WAR files usually have the configuration files included into the WAR file |
79 |
> (not very practical IMO), so there is no need for a configuration |
80 |
> directory. |
81 |
|
82 |
Well, coming to frameworks like Cocoon the things get even more compilcated. |
83 |
Cocoon itself is a framework i.e. you either include it into your own web |
84 |
application or you adjust the Cocoon web application to your own needs for |
85 |
your application. The delivered Cocoon web application is basically just a |
86 |
demonstration, but not of much use as a real world app. This implies, that |
87 |
it is normally not really useful for normal users (i.e. not a developer) to |
88 |
install Cocoon at all in a servelt engine IMHO. Either it is included in |
89 |
another web application or it is used to build other (web) applications |
90 |
which implies no need for an installation in a servlet engine also. |
91 |
|
92 |
Additionally a developer might have the need to have multiple versions of |
93 |
Cocoon, since he could develop multiple applications using it or |
94 |
maintaining different versions of his application using different Cocoon |
95 |
versions also (and probably supporting diferent servlet engines). Both |
96 |
scenarios do not fit very well into the current portage characteristics. |
97 |
|
98 |
But there is more. Same situation applies for Enterprise Applications (EAR |
99 |
files), that should be running in any conforming J2EE server (jBoss, |
100 |
Enhydra, Jonas, Sun J2ee SDK, WebLogic, ...). Robert, don't get confused: a |
101 |
servlet engine is part of the J2EE spec. |
102 |
|
103 |
Robert, to increase your understanding: Imagine an servlet/JSP engine or a |
104 |
J2EE server to be an ordinary database and Cocoon would be a framework like |
105 |
unixODBC with an additional demo app. You'll understand that no plain user |
106 |
of unixODBC would like to have the demo app installed for all/one of his |
107 |
running databases ... |
108 |
|
109 |
While I think we should solve the basic problem installing real world web or |
110 |
enterprise applications, but Cocoon and other frameworks/toolkits should |
111 |
not be handled in the same way. |
112 |
|
113 |
> Virtual Host Support |
114 |
|
115 |
<snip/> |
116 |
|
117 |
Sorry, can't say to much vhosts also. |
118 |
|
119 |
Bottom line: I am not sure if portage can (and should) fulfill the need of a |
120 |
developer here. Especially in the Java world we have meanwhile interesting |
121 |
alternatives as shown with Maven to deal with this multi-version problem. |
122 |
|
123 |
Regards, |
124 |
Jörg |
125 |
|
126 |
|
127 |
|
128 |
-- |
129 |
gentoo-dev@g.o mailing list |