Gentoo Archives: gentoo-dev

From: "Jörg Schaible" <joerg.schaible@×××.de>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Re: [gentoo-java] Help with new Cocoon ebuild
Date: Thu, 08 Jan 2004 22:26:03
Message-Id: btkl9s$em2$1@sea.gmane.org
In Reply to: Re: [gentoo-dev] Re: [gentoo-java] Help with new Cocoon ebuild by Eivind Tagseth
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

Replies

Subject Author
Re: [gentoo-dev] Re: Re: [gentoo-java] Help with new Cocoon ebuild Eivind Tagseth <eivindt-gentoo@××××××××.no>