-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 29 Dec 2005, Carsten Ziegeler wrote:
Date: Thu, 29 Dec 2005 14:25:48 +0100
From: Carsten Ziegeler <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: [2.2] Unable to start Cocoon with Win
Giacomo Pati schrieb:
Reading you mail again I think I now got what you try to say :-)
A java class that simulates the cocoon.sh/cocoon.bat stuff, right? And a
cocoon.sh/cocoon.bat combo to just start that java class without the
hassle of the different toolset and env variable handlings those OS
have.
Yepp, that's what I meant :) (Yes, I was in a hurry...)
I have to think about it whether the jetty-start.jar can do that as
well. Give my some time to check it out.
Ok, I've checked whether the jetty-start.jar can help simplify the
cocoon.sh/cocoon.bat combo. I've come to the conclution that either the
jetty-start.jar nor our Loader class will be able to overcome the pain
to maintain 2 separate start scripts for the two main OS platforms. the
reason is simple.
There are some properties that NEED to be specified on the command
line anyway to be active:
- -Djava.endorsed.dirs...
- -Dcom.sun.management.jmxremote...
- -Xdebug...
and some others, too.
So, simplifying with the help of the jetty-start.jar/Loader will only
able to cover properties specifyable during the run of a JXM. Sure one
can write a java class that spawns a new JVM thread/process but IMHO
that would not be very smart (2 JVM running just to configure one).
Ok, great - I just tried the m2 plugin for jetty and it does not help us
as it
seems to use the projects classpath and not the jars from web-inf/lib.
Yes.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDtAA4LNdJvZjjVZARAiY2AKDcW6myKjTAWw+RkwOH7VMUipjqrQCeJrls
qhG76Zt9vmkqGBWApWGJ+GU=
=1xgS
-----END PGP SIGNATURE-----
