IMO, the less native platform scripts we have the better. I'm defs
against adding new ones... and really interested in removing the ones
we currently have.
If only Microsoft would ship a /bin/sh then I'd be happy to keep
around a single set of scripts... but ya, thats not gonna happen :-(
--jason
On Jul 15, 2007, at 11:29 AM, Donald Woods wrote:
Jeff Genender wrote:
Donald Woods wrote:
Is this a scenario that would be better handled by the gshell
code in
sandbox or some daemon code that also handles the multiple server
instance support?
Thought here, would be gshell could read a standard Java
properties file
for JVM args and then launch the server with them.....
As long as one JVM launches, the other (ie. gshell or groovy can
start
another instance of a JVM) then this is doable. Otherwise, this
won't
work...with my Terracotta example being a reason.
In my eyes, scripts are a no-go, unless you can make them platform
neutral and not require users to install a third-party solution like
Perl (on Windows) to make it work.
We already ship sh and bat code...why would this be a no-go? If
this is
the case, then we shouldn't be shipping startup scripts in bat and sh
format.
I know Jason would be in favor of dropping the complicated .sh/.bat
files we have now, as we have seen several breakages between them
this release (between the openjpa agent, handling spaces in paths
on Windows, file separators, ...)
My point, was that having to provide 2 scripts per extension (Unix
and Windows) would be troublesome for some, like all you Mac users
who hate Windows :-)
-Donald
-Donald
Jeff Genender wrote:
Hi,
As we move forward and we integrate with more and more 3rd party
products, we will need the ability to be able to change an
environment
variable through a plugin, or add a commandline JAVA_OPTS, etc.
Currently our startup scripts call the setjavaenv.sh to set
environment
properties. It would really be nice to have the ability to have a
"scripts" directory, where all of the scripts get executed before
Geronimo is launched. Why do we want this?
As we grow in our plugins, they will need to set environment or
java
options set before running G. They may also have a need to
start or run
other outside processes that are not a part of G.
It would be great to allow plugins to install an rc script that
gets
executed to do activities before and perhaps after G is run?
I would propose we create a scripts directory under bin or under
var
that could be similar to init.d, and have it called with start/
stop,
etc. This way plugins can install specific scripts in these
directories
for execution.
Thoughts?
Jeff
