You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jeff Genender <jg...@apache.org> on 2007/07/14 01:04:17 UTC
Ideas on a rc.d kind of directory
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
Re: Ideas on a rc.d kind of directory
Posted by Jeff Genender <jg...@apache.org>.
How about bin/scripts ?
Jeff
Matt Hogstrom wrote:
>
> On Jul 16, 2007, at 3:17 AM, Jason Dillon wrote:
>
>> Why in bin/* ?
>>
>
> Only cause they are related to scripts.
Re: Ideas on a rc.d kind of directory
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Jul 16, 2007, at 3:17 AM, Jason Dillon wrote:
> Why in bin/* ?
>
Only cause they are related to scripts.
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@gmail.com>.
Why in bin/* ?
***
Btw my email box was full so I may have missed some discussion.
Should be happier now though.
--jason
On Jul 14, 2007, at 7:54 AM, Matt Hogstrom <ma...@hogstrom.org> wrote:
> I like the idea a lot. How would this work mechanically? Are you
> thinking of $G/bin/rc.d/ ?
>
> If so, the convention of prepending script names with a numbered
> prefix to help with ordering would useful to start with as well.
>
> Great idea.
>
> On Jul 13, 2007, at 7:04 PM, Jeff Genender wrote:
>
>> 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.
>
Re: Ideas on a rc.d kind of directory
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I like the idea a lot. How would this work mechanically? Are you
thinking of $G/bin/rc.d/ ?
If so, the convention of prepending script names with a numbered
prefix to help with ordering would useful to start with as well.
Great idea.
On Jul 13, 2007, at 7:04 PM, Jeff Genender wrote:
> 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.
Re: Ideas on a rc.d kind of directory
Posted by Jeff Genender <jg...@apache.org>.
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 :-)
Im am fine with it being in GShell or Groovy. If someone can have these
scripts set environment variable and/or preload the geronimo.sh with
ones set from these scripts, then I am totally fine with this.
Jeff
>
> -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
>>>>
>>>>
>>
>>
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@planet57.com>.
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
>>>>
>>>>
Re: Ideas on a rc.d kind of directory
Posted by Donald Woods <dw...@apache.org>.
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
>>>
>>>
>
>
Re: Ideas on a rc.d kind of directory
Posted by Jeff Genender <jg...@apache.org>.
Jason Dillon wrote:
> How does the script know to pick it up. Got a cli example of how the
> invoke would look?
Pseudo code for geronimo.sh:
scripts = read(bin/scripts);
for each script in scripts do
call script
endfor
Jeff
>
> --jason
>
>
> On Jul 16, 2007, at 9:45 PM, Jeff Genender wrote:
>
>> Use case needed now:
>>
>> Terracotta is developing a plugin. It needs to pass a setting to the
>> JVM (i.e. -xbootclasspath=). So when the Geronimo script is run, it
>> needs to pick up this "setting" from a script that is installed by the
>> plugin. The script would normally set a JAVA_OPTS and the geronimo.sh
>> script would then pick this up.
>>
>> These scripts would be installed by plugins (or created by someone), but
>> the great part is, when the plugin is uninstalled, the script goes away,
>> and the options are not set.
>>
>> Did this make sense?
>>
>> Jeff
>>
>>
>>
>> Jason Dillon wrote:
>>> Can you provide a wee bit detail on hat the use cases are you have in
>>> mind? I'm still a bit fuzzy what you are going for.
>>>
>>> --jason
>>>
>>>
>>> On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote:
>>>
>>>>
>>>>
>>>> Jason Dillon wrote:
>>>>> I still think that G could do with a tiny bootstrap JVM to handle
>>>>> all of
>>>>> the required flags and properties that are needed now for the
>>>>> server to
>>>>> opperate properly (and in a platform neutral manner). This could also
>>>>> be used to spawn clones or cluster nodes. As well as handling remote
>>>>> restarts and recovery from JVM crashes.
>>>>
>>>> Ok...cool...wanna help? ;-)
>>>>
>>>> If we can have a GShell, etc set an env property like JAVA_OPTS, please
>>>> how an example and I am all game ;-)
>>>>
>>>> Jeff
>>>>
>>>>>
>>>>> IMO this is critical for uber massive enterprise deployments as
>>>>> well as
>>>>> smaller scale cluster management.
>>>>>
>>>>> I also think that GShell would be ideal for the base platform for
>>>>> such a
>>>>> bootstrap JVM.
>>>>>
>>>>> I think it should be realativly easy to setup a POC if folks are
>>>>> interested.
>>>>>
>>>>> --jason
>>>>>
>>>>> P.S. Typed on my iPhone. Still not quite as fast as my blackberry...
>>>>> But I dropped in beer at the Giants/Doggers game. Ooops ;-)
>>>>>
>>>>>
>>>>> On Jul 14, 2007, at 6:41 AM, Jeff Genender <jg...@apache.org>
>>>>> 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.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -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
>>>>>>>>
>>>>>>>>
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@planet57.com>.
How does the script know to pick it up. Got a cli example of how the
invoke would look?
--jason
On Jul 16, 2007, at 9:45 PM, Jeff Genender wrote:
> Use case needed now:
>
> Terracotta is developing a plugin. It needs to pass a setting to the
> JVM (i.e. -xbootclasspath=). So when the Geronimo script is run, it
> needs to pick up this "setting" from a script that is installed by the
> plugin. The script would normally set a JAVA_OPTS and the geronimo.sh
> script would then pick this up.
>
> These scripts would be installed by plugins (or created by
> someone), but
> the great part is, when the plugin is uninstalled, the script goes
> away,
> and the options are not set.
>
> Did this make sense?
>
> Jeff
>
>
>
> Jason Dillon wrote:
>> Can you provide a wee bit detail on hat the use cases are you have in
>> mind? I'm still a bit fuzzy what you are going for.
>>
>> --jason
>>
>>
>> On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote:
>>
>>>
>>>
>>> Jason Dillon wrote:
>>>> I still think that G could do with a tiny bootstrap JVM to
>>>> handle all of
>>>> the required flags and properties that are needed now for the
>>>> server to
>>>> opperate properly (and in a platform neutral manner). This
>>>> could also
>>>> be used to spawn clones or cluster nodes. As well as handling
>>>> remote
>>>> restarts and recovery from JVM crashes.
>>>
>>> Ok...cool...wanna help? ;-)
>>>
>>> If we can have a GShell, etc set an env property like JAVA_OPTS,
>>> please
>>> how an example and I am all game ;-)
>>>
>>> Jeff
>>>
>>>>
>>>> IMO this is critical for uber massive enterprise deployments as
>>>> well as
>>>> smaller scale cluster management.
>>>>
>>>> I also think that GShell would be ideal for the base platform
>>>> for such a
>>>> bootstrap JVM.
>>>>
>>>> I think it should be realativly easy to setup a POC if folks are
>>>> interested.
>>>>
>>>> --jason
>>>>
>>>> P.S. Typed on my iPhone. Still not quite as fast as my
>>>> blackberry...
>>>> But I dropped in beer at the Giants/Doggers game. Ooops ;-)
>>>>
>>>>
>>>> On Jul 14, 2007, at 6:41 AM, Jeff Genender
>>>> <jg...@apache.org> 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.
>>>>>
>>>>>>
>>>>>>
>>>>>> -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
>>>>>>>
>>>>>>>
Re: Ideas on a rc.d kind of directory
Posted by Jeff Genender <jg...@apache.org>.
Use case needed now:
Terracotta is developing a plugin. It needs to pass a setting to the
JVM (i.e. -xbootclasspath=). So when the Geronimo script is run, it
needs to pick up this "setting" from a script that is installed by the
plugin. The script would normally set a JAVA_OPTS and the geronimo.sh
script would then pick this up.
These scripts would be installed by plugins (or created by someone), but
the great part is, when the plugin is uninstalled, the script goes away,
and the options are not set.
Did this make sense?
Jeff
Jason Dillon wrote:
> Can you provide a wee bit detail on hat the use cases are you have in
> mind? I'm still a bit fuzzy what you are going for.
>
> --jason
>
>
> On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote:
>
>>
>>
>> Jason Dillon wrote:
>>> I still think that G could do with a tiny bootstrap JVM to handle all of
>>> the required flags and properties that are needed now for the server to
>>> opperate properly (and in a platform neutral manner). This could also
>>> be used to spawn clones or cluster nodes. As well as handling remote
>>> restarts and recovery from JVM crashes.
>>
>> Ok...cool...wanna help? ;-)
>>
>> If we can have a GShell, etc set an env property like JAVA_OPTS, please
>> how an example and I am all game ;-)
>>
>> Jeff
>>
>>>
>>> IMO this is critical for uber massive enterprise deployments as well as
>>> smaller scale cluster management.
>>>
>>> I also think that GShell would be ideal for the base platform for such a
>>> bootstrap JVM.
>>>
>>> I think it should be realativly easy to setup a POC if folks are
>>> interested.
>>>
>>> --jason
>>>
>>> P.S. Typed on my iPhone. Still not quite as fast as my blackberry...
>>> But I dropped in beer at the Giants/Doggers game. Ooops ;-)
>>>
>>>
>>> On Jul 14, 2007, at 6:41 AM, Jeff Genender <jg...@apache.org> 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.
>>>>
>>>>>
>>>>>
>>>>> -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
>>>>>>
>>>>>>
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@planet57.com>.
Can you provide a wee bit detail on hat the use cases are you have in
mind? I'm still a bit fuzzy what you are going for.
--jason
On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote:
>
>
> Jason Dillon wrote:
>> I still think that G could do with a tiny bootstrap JVM to handle
>> all of
>> the required flags and properties that are needed now for the
>> server to
>> opperate properly (and in a platform neutral manner). This could
>> also
>> be used to spawn clones or cluster nodes. As well as handling remote
>> restarts and recovery from JVM crashes.
>
> Ok...cool...wanna help? ;-)
>
> If we can have a GShell, etc set an env property like JAVA_OPTS,
> please
> how an example and I am all game ;-)
>
> Jeff
>
>>
>> IMO this is critical for uber massive enterprise deployments as
>> well as
>> smaller scale cluster management.
>>
>> I also think that GShell would be ideal for the base platform for
>> such a
>> bootstrap JVM.
>>
>> I think it should be realativly easy to setup a POC if folks are
>> interested.
>>
>> --jason
>>
>> P.S. Typed on my iPhone. Still not quite as fast as my blackberry...
>> But I dropped in beer at the Giants/Doggers game. Ooops ;-)
>>
>>
>> On Jul 14, 2007, at 6:41 AM, Jeff Genender <jg...@apache.org>
>> 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.
>>>
>>>>
>>>>
>>>> -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
>>>>>
>>>>>
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@planet57.com>.
Don't make me open up a can of whoop-ass now...
--jason
On Sep 10, 2007, at 6:17 PM, Jeff Genender wrote:
> Hehehe...Jason...messing with you is like going to Disneyland...all
> fun ;-)
>
> Dude...you rock :-) Keep up the awesome work!
>
> Jefff
>
> Jason Dillon wrote:
>> I meant stop waiting for _more_ feedback :-P
>>
>> So far its all been good, but its a bigish change so I wanted to wait
>> for a bit before I did it.
>>
>> I've also been sexying up gshell... :-P
>>
>> --jason
>>
>>
>> On Sep 10, 2007, at 5:54 PM, Jeff Genender wrote:
>>
>>>
>>>
>>> Jason Dillon wrote:
>>>> Aighty... I'm gonna stop waiting for feedback and implement this
>>>> stuff
>>>> for all assemblies.
>>>
>>> Ummmm...what am I...chopped liver? ;-)
>>>
>>>
>>>>
>>>> --jason
>>>>
>>>>
>>>> On Sep 9, 2007, at 6:41 AM, Jeff Genender wrote:
>>>>
>>>>> No...no reasons...move forward ;-)
>>>>>
>>>>> Jeff
>>>>>
>>>>> Jason Dillon wrote:
>>>>>> Hey, have you played with the rc.d bits in the
>>>>>> assemblies/geronimo-jetty6-javaee5-gshell enough to know if
>>>>>> what I
>>>>>> whipped up will work for you?
>>>>>>
>>>>>> Any more comments or suggestions on how that stuff should work?
>>>>>>
>>>>>> I think this is done, quite powerful and flexible... though to
>>>>>> really
>>>>>> know for sure we'd need to have a few plugins actually using
>>>>>> it to
>>>>>> augment the Server's bootstrap configuration a?
>>>>>>
>>>>>> So... are there any reasons (significant or not) for not moving
>>>>>> forward
>>>>>> with this?
>>>>>>
>>>>>> --jason
>>>>>>
>>>>>>
>>>>>> On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jason Dillon wrote:
>>>>>>>> I still think that G could do with a tiny bootstrap JVM to
>>>>>>>> handle
>>>>>>>> all of
>>>>>>>> the required flags and properties that are needed now for the
>>>>>>>> server to
>>>>>>>> opperate properly (and in a platform neutral manner). This
>>>>>>>> could
>>>>>>>> also
>>>>>>>> be used to spawn clones or cluster nodes. As well as handling
>>>>>>>> remote
>>>>>>>> restarts and recovery from JVM crashes.
>>>>>>>
>>>>>>> Ok...cool...wanna help? ;-)
>>>>>>>
>>>>>>> If we can have a GShell, etc set an env property like JAVA_OPTS,
>>>>>>> please
>>>>>>> how an example and I am all game ;-)
>>>>>>>
>>>>>>> Jeff
>>>>>>>
>>>>>>>>
>>>>>>>> IMO this is critical for uber massive enterprise deployments as
>>>>>>>> well as
>>>>>>>> smaller scale cluster management.
>>>>>>>>
>>>>>>>> I also think that GShell would be ideal for the base
>>>>>>>> platform for
>>>>>>>> such a
>>>>>>>> bootstrap JVM.
>>>>>>>>
>>>>>>>> I think it should be realativly easy to setup a POC if folks
>>>>>>>> are
>>>>>>>> interested.
>>>>>>>>
>>>>>>>> --jason
>>>>>>>>
>>>>>>>> P.S. Typed on my iPhone. Still not quite as fast as my
>>>>>>>> blackberry...
>>>>>>>> But I dropped in beer at the Giants/Doggers game. Ooops ;-)
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jul 14, 2007, at 6:41 AM, Jeff Genender
>>>>>>>> <jg...@apache.org>
>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -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
>>>>>>>>>>>
>>>>>>>>>>>
Re: Ideas on a rc.d kind of directory
Posted by Jeff Genender <jg...@apache.org>.
Hehehe...Jason...messing with you is like going to Disneyland...all fun ;-)
Dude...you rock :-) Keep up the awesome work!
Jefff
Jason Dillon wrote:
> I meant stop waiting for _more_ feedback :-P
>
> So far its all been good, but its a bigish change so I wanted to wait
> for a bit before I did it.
>
> I've also been sexying up gshell... :-P
>
> --jason
>
>
> On Sep 10, 2007, at 5:54 PM, Jeff Genender wrote:
>
>>
>>
>> Jason Dillon wrote:
>>> Aighty... I'm gonna stop waiting for feedback and implement this stuff
>>> for all assemblies.
>>
>> Ummmm...what am I...chopped liver? ;-)
>>
>>
>>>
>>> --jason
>>>
>>>
>>> On Sep 9, 2007, at 6:41 AM, Jeff Genender wrote:
>>>
>>>> No...no reasons...move forward ;-)
>>>>
>>>> Jeff
>>>>
>>>> Jason Dillon wrote:
>>>>> Hey, have you played with the rc.d bits in the
>>>>> assemblies/geronimo-jetty6-javaee5-gshell enough to know if what I
>>>>> whipped up will work for you?
>>>>>
>>>>> Any more comments or suggestions on how that stuff should work?
>>>>>
>>>>> I think this is done, quite powerful and flexible... though to really
>>>>> know for sure we'd need to have a few plugins actually using it to
>>>>> augment the Server's bootstrap configuration a?
>>>>>
>>>>> So... are there any reasons (significant or not) for not moving
>>>>> forward
>>>>> with this?
>>>>>
>>>>> --jason
>>>>>
>>>>>
>>>>> On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Jason Dillon wrote:
>>>>>>> I still think that G could do with a tiny bootstrap JVM to handle
>>>>>>> all of
>>>>>>> the required flags and properties that are needed now for the
>>>>>>> server to
>>>>>>> opperate properly (and in a platform neutral manner). This could
>>>>>>> also
>>>>>>> be used to spawn clones or cluster nodes. As well as handling
>>>>>>> remote
>>>>>>> restarts and recovery from JVM crashes.
>>>>>>
>>>>>> Ok...cool...wanna help? ;-)
>>>>>>
>>>>>> If we can have a GShell, etc set an env property like JAVA_OPTS,
>>>>>> please
>>>>>> how an example and I am all game ;-)
>>>>>>
>>>>>> Jeff
>>>>>>
>>>>>>>
>>>>>>> IMO this is critical for uber massive enterprise deployments as
>>>>>>> well as
>>>>>>> smaller scale cluster management.
>>>>>>>
>>>>>>> I also think that GShell would be ideal for the base platform for
>>>>>>> such a
>>>>>>> bootstrap JVM.
>>>>>>>
>>>>>>> I think it should be realativly easy to setup a POC if folks are
>>>>>>> interested.
>>>>>>>
>>>>>>> --jason
>>>>>>>
>>>>>>> P.S. Typed on my iPhone. Still not quite as fast as my
>>>>>>> blackberry...
>>>>>>> But I dropped in beer at the Giants/Doggers game. Ooops ;-)
>>>>>>>
>>>>>>>
>>>>>>> On Jul 14, 2007, at 6:41 AM, Jeff Genender <jg...@apache.org>
>>>>>>> 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.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -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
>>>>>>>>>>
>>>>>>>>>>
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@planet57.com>.
I meant stop waiting for _more_ feedback :-P
So far its all been good, but its a bigish change so I wanted to wait
for a bit before I did it.
I've also been sexying up gshell... :-P
--jason
On Sep 10, 2007, at 5:54 PM, Jeff Genender wrote:
>
>
> Jason Dillon wrote:
>> Aighty... I'm gonna stop waiting for feedback and implement this
>> stuff
>> for all assemblies.
>
> Ummmm...what am I...chopped liver? ;-)
>
>
>>
>> --jason
>>
>>
>> On Sep 9, 2007, at 6:41 AM, Jeff Genender wrote:
>>
>>> No...no reasons...move forward ;-)
>>>
>>> Jeff
>>>
>>> Jason Dillon wrote:
>>>> Hey, have you played with the rc.d bits in the
>>>> assemblies/geronimo-jetty6-javaee5-gshell enough to know if what I
>>>> whipped up will work for you?
>>>>
>>>> Any more comments or suggestions on how that stuff should work?
>>>>
>>>> I think this is done, quite powerful and flexible... though to
>>>> really
>>>> know for sure we'd need to have a few plugins actually using it to
>>>> augment the Server's bootstrap configuration a?
>>>>
>>>> So... are there any reasons (significant or not) for not moving
>>>> forward
>>>> with this?
>>>>
>>>> --jason
>>>>
>>>>
>>>> On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote:
>>>>
>>>>>
>>>>>
>>>>> Jason Dillon wrote:
>>>>>> I still think that G could do with a tiny bootstrap JVM to handle
>>>>>> all of
>>>>>> the required flags and properties that are needed now for the
>>>>>> server to
>>>>>> opperate properly (and in a platform neutral manner). This
>>>>>> could also
>>>>>> be used to spawn clones or cluster nodes. As well as handling
>>>>>> remote
>>>>>> restarts and recovery from JVM crashes.
>>>>>
>>>>> Ok...cool...wanna help? ;-)
>>>>>
>>>>> If we can have a GShell, etc set an env property like
>>>>> JAVA_OPTS, please
>>>>> how an example and I am all game ;-)
>>>>>
>>>>> Jeff
>>>>>
>>>>>>
>>>>>> IMO this is critical for uber massive enterprise deployments as
>>>>>> well as
>>>>>> smaller scale cluster management.
>>>>>>
>>>>>> I also think that GShell would be ideal for the base platform for
>>>>>> such a
>>>>>> bootstrap JVM.
>>>>>>
>>>>>> I think it should be realativly easy to setup a POC if folks are
>>>>>> interested.
>>>>>>
>>>>>> --jason
>>>>>>
>>>>>> P.S. Typed on my iPhone. Still not quite as fast as my
>>>>>> blackberry...
>>>>>> But I dropped in beer at the Giants/Doggers game. Ooops ;-)
>>>>>>
>>>>>>
>>>>>> On Jul 14, 2007, at 6:41 AM, Jeff Genender <jg...@apache.org>
>>>>>> 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.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -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
>>>>>>>>>
>>>>>>>>>
Re: Ideas on a rc.d kind of directory
Posted by Jeff Genender <jg...@apache.org>.
Jason Dillon wrote:
> Aighty... I'm gonna stop waiting for feedback and implement this stuff
> for all assemblies.
Ummmm...what am I...chopped liver? ;-)
>
> --jason
>
>
> On Sep 9, 2007, at 6:41 AM, Jeff Genender wrote:
>
>> No...no reasons...move forward ;-)
>>
>> Jeff
>>
>> Jason Dillon wrote:
>>> Hey, have you played with the rc.d bits in the
>>> assemblies/geronimo-jetty6-javaee5-gshell enough to know if what I
>>> whipped up will work for you?
>>>
>>> Any more comments or suggestions on how that stuff should work?
>>>
>>> I think this is done, quite powerful and flexible... though to really
>>> know for sure we'd need to have a few plugins actually using it to
>>> augment the Server's bootstrap configuration a?
>>>
>>> So... are there any reasons (significant or not) for not moving forward
>>> with this?
>>>
>>> --jason
>>>
>>>
>>> On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote:
>>>
>>>>
>>>>
>>>> Jason Dillon wrote:
>>>>> I still think that G could do with a tiny bootstrap JVM to handle
>>>>> all of
>>>>> the required flags and properties that are needed now for the
>>>>> server to
>>>>> opperate properly (and in a platform neutral manner). This could also
>>>>> be used to spawn clones or cluster nodes. As well as handling remote
>>>>> restarts and recovery from JVM crashes.
>>>>
>>>> Ok...cool...wanna help? ;-)
>>>>
>>>> If we can have a GShell, etc set an env property like JAVA_OPTS, please
>>>> how an example and I am all game ;-)
>>>>
>>>> Jeff
>>>>
>>>>>
>>>>> IMO this is critical for uber massive enterprise deployments as
>>>>> well as
>>>>> smaller scale cluster management.
>>>>>
>>>>> I also think that GShell would be ideal for the base platform for
>>>>> such a
>>>>> bootstrap JVM.
>>>>>
>>>>> I think it should be realativly easy to setup a POC if folks are
>>>>> interested.
>>>>>
>>>>> --jason
>>>>>
>>>>> P.S. Typed on my iPhone. Still not quite as fast as my blackberry...
>>>>> But I dropped in beer at the Giants/Doggers game. Ooops ;-)
>>>>>
>>>>>
>>>>> On Jul 14, 2007, at 6:41 AM, Jeff Genender <jg...@apache.org>
>>>>> 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.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -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
>>>>>>>>
>>>>>>>>
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@planet57.com>.
Aighty... I'm gonna stop waiting for feedback and implement this
stuff for all assemblies.
--jason
On Sep 9, 2007, at 6:41 AM, Jeff Genender wrote:
> No...no reasons...move forward ;-)
>
> Jeff
>
> Jason Dillon wrote:
>> Hey, have you played with the rc.d bits in the
>> assemblies/geronimo-jetty6-javaee5-gshell enough to know if what I
>> whipped up will work for you?
>>
>> Any more comments or suggestions on how that stuff should work?
>>
>> I think this is done, quite powerful and flexible... though to really
>> know for sure we'd need to have a few plugins actually using it to
>> augment the Server's bootstrap configuration a?
>>
>> So... are there any reasons (significant or not) for not moving
>> forward
>> with this?
>>
>> --jason
>>
>>
>> On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote:
>>
>>>
>>>
>>> Jason Dillon wrote:
>>>> I still think that G could do with a tiny bootstrap JVM to
>>>> handle all of
>>>> the required flags and properties that are needed now for the
>>>> server to
>>>> opperate properly (and in a platform neutral manner). This
>>>> could also
>>>> be used to spawn clones or cluster nodes. As well as handling
>>>> remote
>>>> restarts and recovery from JVM crashes.
>>>
>>> Ok...cool...wanna help? ;-)
>>>
>>> If we can have a GShell, etc set an env property like JAVA_OPTS,
>>> please
>>> how an example and I am all game ;-)
>>>
>>> Jeff
>>>
>>>>
>>>> IMO this is critical for uber massive enterprise deployments as
>>>> well as
>>>> smaller scale cluster management.
>>>>
>>>> I also think that GShell would be ideal for the base platform
>>>> for such a
>>>> bootstrap JVM.
>>>>
>>>> I think it should be realativly easy to setup a POC if folks are
>>>> interested.
>>>>
>>>> --jason
>>>>
>>>> P.S. Typed on my iPhone. Still not quite as fast as my
>>>> blackberry...
>>>> But I dropped in beer at the Giants/Doggers game. Ooops ;-)
>>>>
>>>>
>>>> On Jul 14, 2007, at 6:41 AM, Jeff Genender
>>>> <jg...@apache.org> 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.
>>>>>
>>>>>>
>>>>>>
>>>>>> -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
>>>>>>>
>>>>>>>
Re: Ideas on a rc.d kind of directory
Posted by Jeff Genender <jg...@apache.org>.
No...no reasons...move forward ;-)
Jeff
Jason Dillon wrote:
> Hey, have you played with the rc.d bits in the
> assemblies/geronimo-jetty6-javaee5-gshell enough to know if what I
> whipped up will work for you?
>
> Any more comments or suggestions on how that stuff should work?
>
> I think this is done, quite powerful and flexible... though to really
> know for sure we'd need to have a few plugins actually using it to
> augment the Server's bootstrap configuration a?
>
> So... are there any reasons (significant or not) for not moving forward
> with this?
>
> --jason
>
>
> On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote:
>
>>
>>
>> Jason Dillon wrote:
>>> I still think that G could do with a tiny bootstrap JVM to handle all of
>>> the required flags and properties that are needed now for the server to
>>> opperate properly (and in a platform neutral manner). This could also
>>> be used to spawn clones or cluster nodes. As well as handling remote
>>> restarts and recovery from JVM crashes.
>>
>> Ok...cool...wanna help? ;-)
>>
>> If we can have a GShell, etc set an env property like JAVA_OPTS, please
>> how an example and I am all game ;-)
>>
>> Jeff
>>
>>>
>>> IMO this is critical for uber massive enterprise deployments as well as
>>> smaller scale cluster management.
>>>
>>> I also think that GShell would be ideal for the base platform for such a
>>> bootstrap JVM.
>>>
>>> I think it should be realativly easy to setup a POC if folks are
>>> interested.
>>>
>>> --jason
>>>
>>> P.S. Typed on my iPhone. Still not quite as fast as my blackberry...
>>> But I dropped in beer at the Giants/Doggers game. Ooops ;-)
>>>
>>>
>>> On Jul 14, 2007, at 6:41 AM, Jeff Genender <jg...@apache.org> 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.
>>>>
>>>>>
>>>>>
>>>>> -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
>>>>>>
>>>>>>
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@planet57.com>.
Hey, have you played with the rc.d bits in the assemblies/geronimo-
jetty6-javaee5-gshell enough to know if what I whipped up will work
for you?
Any more comments or suggestions on how that stuff should work?
I think this is done, quite powerful and flexible... though to really
know for sure we'd need to have a few plugins actually using it to
augment the Server's bootstrap configuration a?
So... are there any reasons (significant or not) for not moving
forward with this?
--jason
On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote:
>
>
> Jason Dillon wrote:
>> I still think that G could do with a tiny bootstrap JVM to handle
>> all of
>> the required flags and properties that are needed now for the
>> server to
>> opperate properly (and in a platform neutral manner). This could
>> also
>> be used to spawn clones or cluster nodes. As well as handling remote
>> restarts and recovery from JVM crashes.
>
> Ok...cool...wanna help? ;-)
>
> If we can have a GShell, etc set an env property like JAVA_OPTS,
> please
> how an example and I am all game ;-)
>
> Jeff
>
>>
>> IMO this is critical for uber massive enterprise deployments as
>> well as
>> smaller scale cluster management.
>>
>> I also think that GShell would be ideal for the base platform for
>> such a
>> bootstrap JVM.
>>
>> I think it should be realativly easy to setup a POC if folks are
>> interested.
>>
>> --jason
>>
>> P.S. Typed on my iPhone. Still not quite as fast as my blackberry...
>> But I dropped in beer at the Giants/Doggers game. Ooops ;-)
>>
>>
>> On Jul 14, 2007, at 6:41 AM, Jeff Genender <jg...@apache.org>
>> 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.
>>>
>>>>
>>>>
>>>> -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
>>>>>
>>>>>
Re: Ideas on a rc.d kind of directory
Posted by Nathaniel Harward <nh...@terracotta.org>.
Jeff Genender wrote:
> Jason Dillon wrote:
>
>> I still think that G could do with a tiny bootstrap JVM to handle all of
>> the required flags and properties that are needed now for the server to
>> opperate properly (and in a platform neutral manner). This could also
>> be used to spawn clones or cluster nodes. As well as handling remote
>> restarts and recovery from JVM crashes.
>>
I'm not sure in practice how it compares to having a [GShell] scripting
environment, but I'll throw this out there anyway: as a plugin developer
writing GBeans anyway, I would probably be happy with being able to
program against system-level concepts in a new plugin-lifecycle GBean.
A simplified example of my new GBean might look something like this:
public class MyPluginLifecycle implements
o.a.g.bootstrap.GeronimoPluginLifecycle {
private final o.a.g.bootstrap.BootstrapGBean bootStrap;
public MyPluginLifecycle(o.a.g.bootstrap.BootstrapGBean bootStrap) {
this.bootStrap = bootStrap;
}
public void onInstall() {
List<String> jvmArgs = bootStrap.getJVMArguments();
List<String> newJvmArgs = new LinkedList<String>(jvmArgs);
newJvmArgs.add("-Xbootclasspath/p:my-special-bootjar.jar");
bootStrap.setJVMArguments(newJvmArgs);
// Set system properties
bootStrap.setSystemProperty("my-special-name", "my-special-value");
// Other stuff...? bootStrap.getDependencies(),
bootStrap.getVarDir(), etc.?
...
}
public void onUninstall() {
// Remove the "-Xbootclasspath/p:my-special-bootjar.jar" argument
from the JVM arg list, etc.
...
}
// GBean glue
...
}
Having this would a) be consistent in interface for plugin developers
and b) let the Geronimo core "know" that it needs to be restarted for a
certain plugin to function properly if it altered something like the JVM
arguments or system properties, and let the user know accordingly. But
it, of course, lacks the good things about [GShell] scripting environments.
> Ok...cool...wanna help? ;-)
>
> If we can have a GShell, etc set an env property like JAVA_OPTS, please
> how an example and I am all game ;-)
>
> Jeff
I will do what I can since I represent the Terracotta use case Jeff
brought up. I believe I read earlier that GShell is in a sandbox (along
with the "portals" code I need to use for the GUI half of the plugin),
would it be possible to get a new sandbox project of these two projects
together, or otherwise make them work together?
In the meantime I will start experimenting with the portals code to
cover the first half of the Terracotta plugin, then as the scripting
half shakes out I can be a guinnea pig.
Nat
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@planet57.com>.
On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote:
> Jason Dillon wrote:
>> I still think that G could do with a tiny bootstrap JVM to handle
>> all of
>> the required flags and properties that are needed now for the
>> server to
>> opperate properly (and in a platform neutral manner). This could
>> also
>> be used to spawn clones or cluster nodes. As well as handling remote
>> restarts and recovery from JVM crashes.
>
> Ok...cool...wanna help? ;-)
Ya, of course... I need to get away from build tck automation crap
and work on some real software, cause my brain is starting to turn to
jelly :-P
> If we can have a GShell, etc set an env property like JAVA_OPTS,
> please
> how an example and I am all game ;-)
Well, it can't really do it now, but should be easy enough to whip it
up. Let me ponder for a wee bit and then I'll get back to you.
--jason
Re: Ideas on a rc.d kind of directory
Posted by Jeff Genender <jg...@apache.org>.
Jason Dillon wrote:
> I still think that G could do with a tiny bootstrap JVM to handle all of
> the required flags and properties that are needed now for the server to
> opperate properly (and in a platform neutral manner). This could also
> be used to spawn clones or cluster nodes. As well as handling remote
> restarts and recovery from JVM crashes.
Ok...cool...wanna help? ;-)
If we can have a GShell, etc set an env property like JAVA_OPTS, please
how an example and I am all game ;-)
Jeff
>
> IMO this is critical for uber massive enterprise deployments as well as
> smaller scale cluster management.
>
> I also think that GShell would be ideal for the base platform for such a
> bootstrap JVM.
>
> I think it should be realativly easy to setup a POC if folks are
> interested.
>
> --jason
>
> P.S. Typed on my iPhone. Still not quite as fast as my blackberry...
> But I dropped in beer at the Giants/Doggers game. Ooops ;-)
>
>
> On Jul 14, 2007, at 6:41 AM, Jeff Genender <jg...@apache.org> 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.
>>
>>>
>>>
>>> -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
>>>>
>>>>
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@planet57.com>.
On Jul 16, 2007, at 6:25 AM, Kevan Miller wrote:
>> I think it should be realativly easy to setup a POC if folks are
>> interested.
>
> Sounds great and agreed on the long-term direction. I could see a
> simple script-based change to enable in the short-term...
Before I got whip up some magic lemme get some more input on what
Jeffs use cases are... so I'm clear what we are talking about ;-)
>> P.S. Typed on my iPhone. Still not quite as fast as my
>> blackberry... But I dropped in beer at the Giants/Doggers game.
>> Ooops ;-)
>
> Heh. Simply your subconscious giving your id the necessary
> rationalization for getting an iPhone...
Heh, well it worked. I had been using my blackberry for days after I
got the iPhone and now I'm using the Jesus Phone much, much more.
Love it.... but...
> I need to work on a better way to filter mail getting down to my
> iPhone... There's too much ATM...
Ya, I need a mass delete. :-(
--jason
Re: Ideas on a rc.d kind of directory
Posted by Kevan Miller <ke...@gmail.com>.
On Jul 16, 2007, at 3:32 AM, Jason Dillon wrote:
> I still think that G could do with a tiny bootstrap JVM to handle
> all of the required flags and properties that are needed now for
> the server to opperate properly (and in a platform neutral
> manner). This could also be used to spawn clones or cluster
> nodes. As well as handling remote restarts and recovery from JVM
> crashes.
>
> IMO this is critical for uber massive enterprise deployments as
> well as smaller scale cluster management.
>
> I also think that GShell would be ideal for the base platform for
> such a bootstrap JVM.
>
> I think it should be realativly easy to setup a POC if folks are
> interested.
Sounds great and agreed on the long-term direction. I could see a
simple script-based change to enable in the short-term...
>
> --jason
>
> P.S. Typed on my iPhone. Still not quite as fast as my
> blackberry... But I dropped in beer at the Giants/Doggers game.
> Ooops ;-)
Heh. Simply your subconscious giving your id the necessary
rationalization for getting an iPhone...
I need to work on a better way to filter mail getting down to my
iPhone... There's too much ATM...
--kevan
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@gmail.com>.
I still think that G could do with a tiny bootstrap JVM to handle all
of the required flags and properties that are needed now for the
server to opperate properly (and in a platform neutral manner). This
could also be used to spawn clones or cluster nodes. As well as
handling remote restarts and recovery from JVM crashes.
IMO this is critical for uber massive enterprise deployments as well
as smaller scale cluster management.
I also think that GShell would be ideal for the base platform for such
a bootstrap JVM.
I think it should be realativly easy to setup a POC if folks are
interested.
--jason
P.S. Typed on my iPhone. Still not quite as fast as my blackberry...
But I dropped in beer at the Giants/Doggers game. Ooops ;-)
On Jul 14, 2007, at 6:41 AM, Jeff Genender <jg...@apache.org> 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.
>
>>
>>
>> -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
>>>
>>>
Re: Ideas on a rc.d kind of directory
Posted by Jeff Genender <jg...@apache.org>.
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.
>
>
> -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
>>
>>
Re: Ideas on a rc.d kind of directory
Posted by Donald Woods <dw...@apache.org>.
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.....
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.
-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
>
>
Re: Ideas on a rc.d kind of directory
Posted by Gianny Damour <gi...@optusnet.com.au>.
Hi,
I believe it is a great idea to have a kind of hook directory
defining scripts to be executed at specific stages.
It seems to me that the current .bat or .sh scripts will become
harder and harder to implement, maintain and *test* - AFAIK, there
are no tests. It seems to me that a move to a cross-platform
scripting language a la Groovy would give us a better mileage. As a
matter of fact, the Grails project has defined a very nice way to
integrate hook scripts provided by plugins into the runtime
configuration of a grails app - see http://grails.codehaus.org/Runtime
+Configuration+Plugins for more details.
What do you think about porting .bat and .sh scripts to groovy scripts?
Thanks,
Gianny
On 14/07/2007, at 9:04 AM, 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
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@planet57.com>.
On Jul 19, 2007, at 7:19 AM, Donald Woods wrote:
> Could we use Jakarta commons-launcher, which uses a subset of ANT?
Maybe...
> We'd probably have to make a few changes, so it would use the
> existing manifest settings in the server/client.jar and to handle
> our multiple server instance directory structure.....
Almost certainly...
--jason
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@planet57.com>.
Maybe a few more thoughts on this...
What I am thinking of is a relatively small JVM which is a process
controller. With some basic administration muck built into it to
start, stop, kill, list, fork, spawn, clone, blah, blah... server
processes... or if needed any support processes. IMO that is a bit
more than what the commons-launcher bits do, though probably whatever
the start bits do will most certainly end up re-using the ant-
launcher bits, as that code is already really solid for starting up
new JVM instances.
The controller process can also serve as a watchdog to make sure
processes are responsive and restart them if/when they barf, and if
supported periodically tickle them for basic health information etc.
This is kinda what I had always envisioned for the g-twiddle stuff
way, way, back. Gshell gets us much closer to making that actually
happen, though its still a work in progress, but I think that its put
together enough to try to implement an example so others might have a
better idea for the general vision.
Perhaps use of commons-launcher could do as a much shorter-term
implementation, though I would rather spend my time working on a few
GShell commands and massage the assembly to make it work, then work
on trimming down the GShell size, which is already kinda small, but
could be smaller if I tried. GShell already has the basic
underpinnings to handle most of what I'm thinking of, though the
telnet/ssh stuff is being a PITA right now. I may drop that for now
and just implement my own tiny shell client over ssl as a work around
until I can finally get the ssh support sorted.
--jason
On Jul 19, 2007, at 7:28 AM, Jeff Genender wrote:
> Lets let Jason chime in here as I think he volunteered to stitch a lot
> of this together.
>
> Jeff
>
> Donald Woods wrote:
>> Could we use Jakarta commons-launcher, which uses a subset of ANT?
>> We'd probably have to make a few changes, so it would use the
>> existing
>> manifest settings in the server/client.jar and to handle our multiple
>> server instance directory structure.....
>>
>>
>> -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
>>>
>>>
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@planet57.com>.
FYI, I've gotten my POC using GShell for this ready... I'm planning
on merging the changes into server/trunk today, though I'm not going
to hook it up to the default assemblies just yet. Instead I'm going
to create a new assembly to allow folks to play with it first and
then we can talk about making it the default. More email on how all
this stuff works in a wee bit.
Cheers,
--jason
On Jul 19, 2007, at 7:28 AM, Jeff Genender wrote:
> Lets let Jason chime in here as I think he volunteered to stitch a lot
> of this together.
>
> Jeff
>
> Donald Woods wrote:
>> Could we use Jakarta commons-launcher, which uses a subset of ANT?
>> We'd probably have to make a few changes, so it would use the
>> existing
>> manifest settings in the server/client.jar and to handle our multiple
>> server instance directory structure.....
>>
>>
>> -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
>>>
>>>
Re: Ideas on a rc.d kind of directory
Posted by Jeff Genender <jg...@apache.org>.
Lets let Jason chime in here as I think he volunteered to stitch a lot
of this together.
Jeff
Donald Woods wrote:
> Could we use Jakarta commons-launcher, which uses a subset of ANT?
> We'd probably have to make a few changes, so it would use the existing
> manifest settings in the server/client.jar and to handle our multiple
> server instance directory structure.....
>
>
> -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
>>
>>
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@planet57.com>.
On Jul 19, 2007, at 7:19 AM, Donald Woods wrote:
> Could we use Jakarta commons-launcher, which uses a subset of ANT?
Subset of ant? I just downloaded the 1.1. release, and it looks like
all of ant is in the lib/* Which totals up to 3m of stuff, in
addition to the ~76k in bin/. I'd imagine it might not need all that
ant fluff, wonder why they ship it like that though :-(
--jason
Re: Ideas on a rc.d kind of directory
Posted by Donald Woods <dw...@apache.org>.
Could we use Jakarta commons-launcher, which uses a subset of ANT?
We'd probably have to make a few changes, so it would use the existing
manifest settings in the server/client.jar and to handle our multiple server
instance directory structure.....
-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
>
>
Re: Ideas on a rc.d kind of directory
Posted by Jeff Genender <jg...@apache.org>.
David Jencks wrote:
>
> On Jul 13, 2007, at 7:04 PM, Jeff Genender wrote:
>> 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?
>
> How cross platform can we make this?
>
> I'm not sure I know what kinds of things you expect this to be used for,
> so if you can provide some more concrete examples I'd appreciate it.
> I'm wondering if this is the kind of stuff that we've been taking care
> of so far with e.g. the SystemPropertiesGbean and
> DirectoryInitializationGBean.
Sure...I'll give you an example and unfortunately the
SystemPropertiesGbean and DirectoryInitializationGBean won't work...
Terracotta is a great example. They need to set a Java option that sets
the boot classpath (-Xbootclasspath) Its something that has to be a
part of the command line in order for the JVM to correctly have its base
objects instrumented.
It would be cool to have their plugin drop a script in a directory that
gets picked up when running the app server. This is much better than
having it edit our own scripts directly. Hence, if the plugin gets
uninstalled, the script is removed and everything is back to the way it was.
As for cross platform, I think its up to the plugin developer who needs
this capability. Right now we support bat and sh scripts...which I
think is enough for us, so this seems like its reasonable to me. I
think this is a detail that can easily be handled. But from a Geronimo
perspective, we don't care because its our scripts that are firing the
subscripts. The impl is left up to the plugin/script developer...let
just recommend they offer a sh and bat script.
>
> thanks
> david jencks
>
>>
>> Jeff
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@planet57.com>.
On Jul 13, 2007, at 5:13 PM, Jeff Genender wrote:
> Jason Dillon wrote:
>> I was kinda against this kinda thingy way back in the days of the
>> boss-of-j, but I'm interested to hear more how you think it might
>> work... since I just wrote off anything Marc said as crap
>> automatically :-P
>>
>
> Does that make me Marc of geronimo? ;-)
No, you aren't a prick :-P
--jason
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@gmail.com>.
*giggle*
--jason
On Jul 14, 2007, at 7:50 AM, Matt Hogstrom <ma...@hogstrom.org> wrote:
>
> On Jul 13, 2007, at 8:13 PM, Jeff Genender wrote:
>
>> Does that make me Marc of geronimo? ;-)
>
> You mean because we automatically discount what you say? :)
Re: Ideas on a rc.d kind of directory
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Jul 13, 2007, at 8:13 PM, Jeff Genender wrote:
> Does that make me Marc of geronimo? ;-)
You mean because we automatically discount what you say? :)
Re: Ideas on a rc.d kind of directory
Posted by Jeff Genender <jg...@apache.org>.
Jason Dillon wrote:
> I was kinda against this kinda thingy way back in the days of the
> boss-of-j, but I'm interested to hear more how you think it might
> work... since I just wrote off anything Marc said as crap automatically :-P
>
Does that make me Marc of geronimo? ;-)
> --jason
>
>
> On Jul 13, 2007, at 4:17 PM, David Jencks wrote:
>
>>
>> On Jul 13, 2007, at 7:04 PM, 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?
>>
>> How cross platform can we make this?
>>
>> I'm not sure I know what kinds of things you expect this to be used
>> for, so if you can provide some more concrete examples I'd appreciate
>> it. I'm wondering if this is the kind of stuff that we've been taking
>> care of so far with e.g. the SystemPropertiesGbean and
>> DirectoryInitializationGBean.
>>
>> thanks
>> david jencks
>>
>>>
>>> Jeff
>>
Re: Ideas on a rc.d kind of directory
Posted by Jeff Genender <jg...@apache.org>.
Ok...maybe even not a script...maybe something that works similar to how
the sysconfig system on Unix works. A directory that contains "settings
files" or something that allows us to set environment variables. Like a
drop in text file:
JAVA_OPTS=-xbootclasspath-Xbootclasspath/p:var/terracotta/tc.jar
Although this is cool, at some point, someone is gonna want to run
something though and we may wish to go back to scripting ;-)
The positive on these text files is its automatically mostly cross
platform. Downside is we cant run anything...just an idea...
I would like to hear others' ideas.
Jeff
Jason Dillon wrote:
> I was kinda against this kinda thingy way back in the days of the
> boss-of-j, but I'm interested to hear more how you think it might
> work... since I just wrote off anything Marc said as crap automatically :-P
>
> --jason
>
>
> On Jul 13, 2007, at 4:17 PM, David Jencks wrote:
>
>>
>> On Jul 13, 2007, at 7:04 PM, 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?
>>
>> How cross platform can we make this?
>>
>> I'm not sure I know what kinds of things you expect this to be used
>> for, so if you can provide some more concrete examples I'd appreciate
>> it. I'm wondering if this is the kind of stuff that we've been taking
>> care of so far with e.g. the SystemPropertiesGbean and
>> DirectoryInitializationGBean.
>>
>> thanks
>> david jencks
>>
>>>
>>> Jeff
>>
Re: Ideas on a rc.d kind of directory
Posted by Jason Dillon <ja...@planet57.com>.
I was kinda against this kinda thingy way back in the days of the
boss-of-j, but I'm interested to hear more how you think it might
work... since I just wrote off anything Marc said as crap
automatically :-P
--jason
On Jul 13, 2007, at 4:17 PM, David Jencks wrote:
>
> On Jul 13, 2007, at 7:04 PM, 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?
>
> How cross platform can we make this?
>
> I'm not sure I know what kinds of things you expect this to be used
> for, so if you can provide some more concrete examples I'd
> appreciate it. I'm wondering if this is the kind of stuff that
> we've been taking care of so far with e.g. the
> SystemPropertiesGbean and DirectoryInitializationGBean.
>
> thanks
> david jencks
>
>>
>> Jeff
>
Re: Ideas on a rc.d kind of directory
Posted by David Jencks <da...@yahoo.com>.
On Jul 13, 2007, at 7:04 PM, 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?
How cross platform can we make this?
I'm not sure I know what kinds of things you expect this to be used
for, so if you can provide some more concrete examples I'd appreciate
it. I'm wondering if this is the kind of stuff that we've been
taking care of so far with e.g. the SystemPropertiesGbean and
DirectoryInitializationGBean.
thanks
david jencks
>
> Jeff