On 20/1/03 6:47 am, "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
>> Folks,
>>     I've been playing around lately with Jetty and Cocoon, and came out with
>> the idea of possibly distributing the two together...
> 
> Jetty is already in Cocoon CVS for some time now.
> Do "build run" to have jetty start up and serve on port 8888.

Beautiful. I'll dig out what version and stuff are there. I tested my stuff
against the latest "stable" (4.2.5???) and actually Greg had to patch a
little thing to make it work (so, right now it only works with Jetty "HEAD"
plus a small patch (attached)...

> Anyway, send in the patch, I'm interested to see it.

To Cocoon there is only one patch (to allow the CocoonServlet to load
configuration files outside of its servlet context) and that is attached.

There is also a different "jetty.xml" configuration file, which basically
encapsulates both the "server.xml" and "web.xml" for Tomcat. It would be
great if the CocoonServlet init parameters were moved off into the
"cocoon.xconf" file (leaving only the locations of cocoon.xconf and
logkit.xconf in there), but that means being _very_ picky on my side! :-)

I attached my "jetty.xml" file, check it out, I can't guarantee it works as
I've tested it only on my laptop and it might just depend on something I've
installed here (as well as the "server" shell script to make it start up).

> Just one question: what makes it better not to use web.xml with Jetty?
> Cocoon unfortunatley uses some config data from there still, and some
> features if that is not used are not available ATM.

Well, what I like are "clean and minimal" distributions. If you use the "web
inf" approach, some of your config files will end up in two different
directories: the "server" configuration files (server.xml, jetty.xml...) are
in a directory only used by the servlet container. While cocoon.xconf and
logkit.xconf are in "webapps/cocoon/WEB-INF"...

Why? Isn't it just easier to put everything in one place and tell users, "go
there, and edit the default values" ???

This is the "layout" I was able to get it to:

./bin
    this contains the "server" shell script to launch the whole thing

./classes
    exactly the same as "WEB-INF/classes", if you need one...

./etc
    ALL configuration files: jetty.xml, cocoon.xconf and logkit.xconf

./lib
    exactly the same as "WEB-INF/lib", and yes, you need it! :-)
    (note as Jetty relies on an XML parser to read its configuration
    files, the xml-*.jar are not here

./logs
    all log files, used both by Jetty and by Cocoon

./root
    all that stuff that usually ends up in your "webapps/cocoon" directory
    on Tomcat but without a "WEB-INF" subdirectory...
    
./server
    the Jetty jars and XML jars (basically this is what goes into the system
    class loader).

./work
./work/cocoon
./work/cache-dir
./work/upload-dir
./work/jetty
    the different "work" directories used (both) by jetty and cocoon

IMVHO such a layout is much more "clean" and "simple" than finding different
stuff into different places.

It also helps from a security point of view: if someone wants to be "tight"
the only places where the user owning the JVM process needs to write to are
./logs and ./work, nothing else, while with the "web-inf" approach, you have
to grant permissions to write in the "work" directory and in some of the
"WEB-INF" subdirectories.

There are just few dirs that I still wasn't able to move away from WEB-INF
(the db, deli and entities directories), but it's just a matter of time to
move them under ./work and ./etc respectively.

    Pier

Attachment: patch-xconf.txt
Description: Binary data

Attachment: patch-jetty.txt
Description: Binary data

Attachment: jetty.xml
Description: application/applefile

Attachment: jetty.xml
Description: Binary data

Attachment: server
Description: Binary data

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to