cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From SAXESS - Hussayn Dabbous <>
Subject Re: Cocoon. More Answers to your dilemma
Date Sat, 25 Jan 2003 21:09:20 GMT
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

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.
> ---------------------------------------------------------------------
> Please check that your question  has not already been answered in the
> FAQ before posting.     <>
> To unsubscribe, e-mail:     <>
> For additional commands, e-mail:   <>

Dr. Hussayn Dabbous
SAXESS Software Design GmbH
Neuenhöfer Allee 125
50935 Köln
Telefon: +49-221-56011-0
Fax:     +49-221-56011-20

Please check that your question  has not already been answered in the
FAQ before posting.     <>

To unsubscribe, e-mail:     <>
For additional commands, e-mail:   <>

View raw message