geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Ideas on a rc.d kind of directory
Date Sun, 15 Jul 2007 20:13:17 GMT
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
>>>>
>>>>


Mime
View raw message