There is one problem with your approach:
What if your webapp uses different versions of
commonly used jars ?
I had this problem with one of my webapps, that
internally used an older version of the avalon
framework and some other jars incompatible to
my cocoon-2.0.4. I tried hard to get my webapp integrated
into cocoon and finally i gave up and came to following
solution:
1.) I set up a clean cocoon webapp
2.) I create a sitemap only for presentation
issues (the web frontend of my webapp)
and instrument what i need for this purpose
into a subdirectory within the cocoon app.
3.) I set up my "legacy" application completely
separated from cocoon
4.) I created an XML interface that consists
primarily of a bunch of jsp's that interact
with my legacy app and spill out XML to cocoon.
I could have used exis of course, but the interface
was not soo complex...
By this a could cleanly separate my legacy application
from my frontend. I had not to deal with compatibility
issues and i ended up in a very nice presentation layer.
What i liked most about this is the (almoust) total
separation of logic from presentation ;-)
There was only one caveat to master: My apps are under
authentification control. Therefore we implemented
a session aware protocol named "proxy:" that allows
under certain circumstances to transparently transfer
cookies between the browser and the legacyapplication.
Currently both apps must run in the same container and
the container must provide SSO. But i hope this limitation
can be eliminated in the near future...
regards, hussayn
Julian Klein wrote:
Robert,
I want all
the framework configs out of my way. I want all of
the options and jars and so on neatly tucked away
and where I can just drop them
in a directory and forget about them.
You can do one of two things with the jars.
1)The Cocoon war by default has all of them stored in
a certain lib directory. When you unpack the war in
Tomcat on startup the path would be as follows
(assuming the war is in the $TOMCAT_HOME/webapps
directory on startup):
$TOMCAT_HOME/webapps/cocoon/WEB-INF/lib. This way all
the jars are available to the servlet container that
is running the cocoon app and localized to this
directory.
2)You could move all these jars to $TOMCAT_HOME/lib or
if you are running a newer version of Tomcat
(e.g.4.1.12) then it would be $TOMCAT_HOME/common/lib.
If you put the jars here they will be available to
all webapps running in Tomcat and be localized.
Unlike the first option, this allows a more "public"
feel to your jars (the first is more like a
"protected" feel to the jars).
NOTE:All that was Tomcat specific deployment info, not
Cocoon. So the Cocoon developers have used the first
option to allow these jars to be localized and clean.
The jars can also be found at:
xml-cocoon/build/cocoon/webapp/WEB-INF/lib
Now Id like to have a war that is THAT small and
without having to have an intimate knowledge of
cocoon to accomplish it.
You would have to build Cocoon from the CVS source
code and modify the Ant build script to stop the
packaging of jars in the cocoon war. This requires a
minimal knowledge of Ant.
-->--> web.xml (NOT a 40 meg file)
Finally, the web.xml that comes with Cocoon in only a
few Ks. So it should never be more, unless you have
added A LOT of servlet mappings, but that must be
proprietary.
Hope this helps,
Julian
=====
Live simply so others may simply live.
-Ghandi
Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily"
-William of Occam
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
--
Dr. Hussayn Dabbous
SAXESS Software Design GmbH
Neuenhöfer Allee 125
50935 Köln
Telefon: +49-221-56011-0
Fax: +49-221-56011-20
E-Mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
