You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Patrick Luby <pa...@sun.com> on 2002/08/08 18:19:45 UTC
[PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
All,
I have tested out some code in o.a.c.startup.Bootstrap.main() that finds
and loads the JDK tools (e.g. javac), loads the JSSE jars in
"jsse.home", turns on the Java security manager, determines and
catalina.home dynamically. These steps are currently done by the
catalina.[sh|bat] scripts.
My goal is to simplify the various Tomcat scripts to the point where all
they do is invoke a class. In other words, I would like to move all of
the construction of all sorts of optional system properties, etc. from
the scripts into Tomcat's main() method. Originally, I had proposed
using the commons-launcher to do this. However, commons-launcher is adds
another layer on top of the existing o.a.c.startup.Bootstrap class and
forks another JVM. This works, but is a bit heavyweight.
I am willing to move the script code into main(). However, there is one
problem: there are currently 2 sets of startup code. Current Bootstrap
and BootstrapService both do a lot of the same steps to start Tomcat.
Before I make any changes to Bootstrap, I would like to propose that we
separate out the common methods in Bootstrap and BootstrapService
(e.g. creating the classloaders, invoking Catalina.start(), etc.).
My hope would be that that Bootstrap.main() could be simplified to do
the following:
- Set up the shutdown port
- Invoke BootstrapService.start()
- Invoke BootstrapService.stop() when the shutdown port receives a
shutdown request
I would need Remy's and Pier's help to separate out the BootstrapService
methods so that they can compile without commons-daemons. I can them
move Bootstrap to use these methods and move the script code into these
methods so that both Bootstrap and BootstrapService share these features.
Is anyone interested in pursuing this? If so, let me know. If not (I
know everyone is busy), then I can leave things the way they are and
repropose this sometime in the future.
Thanks,
Patrick
--
________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by Patrick Luby <pa...@sun.com>.
Remy,
Remy Maucherat wrote:
>
> +1 from me.
>
> If we do that, that would mean commons-daemon is not going anywhere:
> - the interfaces will go away
> - the launcher code is supposed to end up in Ant
>
> If the launcher doesn't end up in Ant, then IMO we should create
> commons-launcher.
>
Since it will take a while to migrate all of the functionality in the
launcher to Ant, we should plan on the commons-launcher code being
around a while.
So, +1 for creating a separate "commons-launcher" repository.
Patrick
--
________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by Remy Maucherat <re...@apache.org>.
cmanolache@yahoo.com wrote:
> On Wed, 28 Aug 2002, jean-frederic clere wrote:
>
>
>>>Are you ok with a change for daemon to use introspection, and remove the
>>>dependency from tomcat to daemon plus consolidate all startups ?
>>
>>Sure ;-)
>
>
> Ok, then let me push a bit more: are you ok with merging the C code
> from daemon into jk2, and continuing the development on the C side
> in j-t-c/jk/native2 ?
>
> There is no point on having 2 codebases that launch the VM from C,
> or 2 service launchers. And there is a lot to benefits from both
> sides - I think.
>
> That should happen after jk2.0 is released ( eventually we can
> branch when 4.1 is released - and use the main branch ).
>
> ( one nice benefit may be getting back the ability to start
> and control the java process from apache, like jserv did ).
>
> I'm only talking about the C code here.
+1 from me.
If we do that, that would mean commons-daemon is not going anywhere:
- the interfaces will go away
- the launcher code is supposed to end up in Ant
If the launcher doesn't end up in Ant, then IMO we should create
commons-launcher.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by co...@covalent.net.
On Fri, 30 Aug 2002, jean-frederic clere wrote:
> I still see no good reasons to make a 'copy'...
Well, for the JNI invocation ( starting the VM inprocess ) - I just want
to make sure that jk is not missing any 'trick' - as you know this is
a very OS-specific and delicate problem. Right now it seems to work well,
but we require LD_LIBRARY_PATH to be set before with java .so in it -
if deamon can get around that on linux, than that's something to copy.
The other thing to copy is the service monitor and service starter - which
seems cool and cleaner than jk_nt_service.
I still want to keep the wrapper.properties, it gives a lot of control and
is easier to use ( IMO ) then using CLI.
Another reason - we'll have a single native build to worry about and
the user will have a more consistent behavior ( same logs, same config,
etc )
> Surely the code in daemon needs a cleaning and some changes to fit mod_jk needs.
> A "ant download" task could bring the needed source in the mod_jk directory to
> ease the release mechanism.
Well, it's a bit more than 'copy' - I would like to use the same logger
and same communication mechanism with the VM as jk is using ( i.e.
messages, invoke/get/setAttribute, etc).
> I will try to find time to get the JVM started under Apache as it was in
> mod_jserv using the code in daemon.
+1.
You may also 'copy' some code from jserv. I think it should also work
under IIS and the other servers - the Apache parent process will act as
the 'controller'.
One important thing is that the code in daemon just starts the JVM and
supports 'restart' ( using that 123 return code ). What we would need
and what jserv did is to keep it alive - i.e. unless a special
'stop me' return code is given, we should restart the process if it dies.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
cmanolache@yahoo.com wrote:
> On Thu, 29 Aug 2002, jean-frederic clere wrote:
>
>
>>I am +1 for merging the code but in daemon. I am using the daemon code for
>>projects not related with mod_jk and I would perfer to have it independant from
>>mod_jk.
>>An other point to be against moving it in mod_jk is that the code has been moved
>>recently in commons (sandbox) I do not thing that it is a good idea to move it
>>back in the Tomcat repos.
>>Also if we move it from daemon to mod_jk we have to ask it to the common dev
>>list before moving it.
>
>
> Ok, not 'move'. What about 'copy' :-) ?
>
> There is a lot of duplication, I just want to make sure that jk has all
> the features that it needs - starting the VM is one thing I want to review
> and 'copy', if there's something that we missed in jk. I would also like
> to 'copy' the service monitor and copy and modify the service
> registration ( I like the jk_nt_service properties file, but the code is
> a bit ugly right now ).
I still see no good reasons to make a 'copy'...
Surely the code in daemon needs a cleaning and some changes to fit mod_jk needs.
A "ant download" task could bring the needed source in the mod_jk directory to
ease the release mechanism.
I will try to find time to get the JVM started under Apache as it was in
mod_jserv using the code in daemon.
>
>
> Costin
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by "cmanolache@yahoo.com" <cm...@yahoo.com>.
On Thu, 29 Aug 2002, jean-frederic clere wrote:
> I am +1 for merging the code but in daemon. I am using the daemon code for
> projects not related with mod_jk and I would perfer to have it independant from
> mod_jk.
> An other point to be against moving it in mod_jk is that the code has been moved
> recently in commons (sandbox) I do not thing that it is a good idea to move it
> back in the Tomcat repos.
> Also if we move it from daemon to mod_jk we have to ask it to the common dev
> list before moving it.
Ok, not 'move'. What about 'copy' :-) ?
There is a lot of duplication, I just want to make sure that jk has all
the features that it needs - starting the VM is one thing I want to review
and 'copy', if there's something that we missed in jk. I would also like
to 'copy' the service monitor and copy and modify the service
registration ( I like the jk_nt_service properties file, but the code is
a bit ugly right now ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
cmanolache@yahoo.com wrote:
> On Wed, 28 Aug 2002, jean-frederic clere wrote:
>
>
>>>Are you ok with a change for daemon to use introspection, and remove the
>>>dependency from tomcat to daemon plus consolidate all startups ?
>>
>>Sure ;-)
>
>
> Ok, then let me push a bit more: are you ok with merging the C code
> from daemon into jk2, and continuing the development on the C side
> in j-t-c/jk/native2 ?
I am +1 for merging the code but in daemon. I am using the daemon code for
projects not related with mod_jk and I would perfer to have it independant from
mod_jk.
An other point to be against moving it in mod_jk is that the code has been moved
recently in commons (sandbox) I do not thing that it is a good idea to move it
back in the Tomcat repos.
Also if we move it from daemon to mod_jk we have to ask it to the common dev
list before moving it.
>
> There is no point on having 2 codebases that launch the VM from C,
> or 2 service launchers. And there is a lot to benefits from both
> sides - I think.
>
> That should happen after jk2.0 is released ( eventually we can
> branch when 4.1 is released - and use the main branch ).
>
> ( one nice benefit may be getting back the ability to start
> and control the java process from apache, like jserv did ).
That is a feature I need.
>
> I'm only talking about the C code here.
>
> Costin
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by cm...@yahoo.com.
On Wed, 28 Aug 2002, jean-frederic clere wrote:
> > Are you ok with a change for daemon to use introspection, and remove the
> > dependency from tomcat to daemon plus consolidate all startups ?
>
> Sure ;-)
Ok, then let me push a bit more: are you ok with merging the C code
from daemon into jk2, and continuing the development on the C side
in j-t-c/jk/native2 ?
There is no point on having 2 codebases that launch the VM from C,
or 2 service launchers. And there is a lot to benefits from both
sides - I think.
That should happen after jk2.0 is released ( eventually we can
branch when 4.1 is released - and use the main branch ).
( one nice benefit may be getting back the ability to start
and control the java process from apache, like jserv did ).
I'm only talking about the C code here.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
costinm@covalent.net wrote:
> On Thu, 8 Aug 2002, jean-frederic clere wrote:
>
>
>>I am using the jakarta-commons-sandbox/daemon to start/stop Tomcat in several
>>projects so I am +1 for using these things.
>>But I am going on holidays in the next minutes (till 28 august).
>
>
> Are you ok with a change for daemon to use introspection, and remove the
> dependency from tomcat to daemon plus consolidate all startups ?
Sure ;-)
>
> Costin
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by co...@covalent.net.
On Thu, 8 Aug 2002, jean-frederic clere wrote:
> I am using the jakarta-commons-sandbox/daemon to start/stop Tomcat in several
> projects so I am +1 for using these things.
> But I am going on holidays in the next minutes (till 28 august).
Are you ok with a change for daemon to use introspection, and remove the
dependency from tomcat to daemon plus consolidate all startups ?
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Patrick Luby wrote:
> All,
>
> I have tested out some code in o.a.c.startup.Bootstrap.main() that finds
> and loads the JDK tools (e.g. javac), loads the JSSE jars in
> "jsse.home", turns on the Java security manager, determines and
> catalina.home dynamically. These steps are currently done by the
> catalina.[sh|bat] scripts.
>
> My goal is to simplify the various Tomcat scripts to the point where all
> they do is invoke a class. In other words, I would like to move all of
> the construction of all sorts of optional system properties, etc. from
> the scripts into Tomcat's main() method. Originally, I had proposed
> using the commons-launcher to do this. However, commons-launcher is adds
> another layer on top of the existing o.a.c.startup.Bootstrap class and
> forks another JVM. This works, but is a bit heavyweight.
>
> I am willing to move the script code into main(). However, there is one
> problem: there are currently 2 sets of startup code. Current Bootstrap
> and BootstrapService both do a lot of the same steps to start Tomcat.
> Before I make any changes to Bootstrap, I would like to propose that we
> separate out the common methods in Bootstrap and BootstrapService (e.g.
> creating the classloaders, invoking Catalina.start(), etc.).
>
> My hope would be that that Bootstrap.main() could be simplified to do
> the following:
>
> - Set up the shutdown port
> - Invoke BootstrapService.start()
> - Invoke BootstrapService.stop() when the shutdown port receives a
> shutdown request
>
> I would need Remy's and Pier's help to separate out the BootstrapService
> methods so that they can compile without commons-daemons. I can them
> move Bootstrap to use these methods and move the script code into these
> methods so that both Bootstrap and BootstrapService share these features.
>
> Is anyone interested in pursuing this? If so, let me know. If not (I
> know everyone is busy), then I can leave things the way they are and
> repropose this sometime in the future.
I am using the jakarta-commons-sandbox/daemon to start/stop Tomcat in several
projects so I am +1 for using these things.
But I am going on holidays in the next minutes (till 28 august).
>
> Thanks,
>
> Patrick
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by Patrick Luby <pa...@sun.com>.
Remy,
Remy Maucherat wrote:
>
> No, I'd rather do something according to the pre-proposal put forward by
> Costin that would be a refactoring of the whole startup and
> configuration code, rather than an evolution of the current code. I
> don't have much interest in trying to improve that code, as I think it's
> good enough (ie, it gets the job done).
>
That makes sense. Trying to rework the startup stuff at the same time
before Costin's pre-proposal is implemented would probably cause a lot
more problems (or at least later rework) than waiting until after
Costin's pre-proposl is implemented.
Patrick
--
________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by Remy Maucherat <re...@apache.org>.
Patrick Luby wrote:
> All,
>
> I have tested out some code in o.a.c.startup.Bootstrap.main() that finds
> and loads the JDK tools (e.g. javac), loads the JSSE jars in
> "jsse.home", turns on the Java security manager, determines and
> catalina.home dynamically. These steps are currently done by the
> catalina.[sh|bat] scripts.
>
> My goal is to simplify the various Tomcat scripts to the point where all
> they do is invoke a class. In other words, I would like to move all of
> the construction of all sorts of optional system properties, etc. from
> the scripts into Tomcat's main() method. Originally, I had proposed
> using the commons-launcher to do this. However, commons-launcher is adds
> another layer on top of the existing o.a.c.startup.Bootstrap class and
> forks another JVM. This works, but is a bit heavyweight.
>
> I am willing to move the script code into main(). However, there is one
> problem: there are currently 2 sets of startup code. Current Bootstrap
> and BootstrapService both do a lot of the same steps to start Tomcat.
> Before I make any changes to Bootstrap, I would like to propose that we
> separate out the common methods in Bootstrap and BootstrapService (e.g.
> creating the classloaders, invoking Catalina.start(), etc.).
>
> My hope would be that that Bootstrap.main() could be simplified to do
> the following:
>
> - Set up the shutdown port
> - Invoke BootstrapService.start()
> - Invoke BootstrapService.stop() when the shutdown port receives a
> shutdown request
>
> I would need Remy's and Pier's help to separate out the BootstrapService
> methods so that they can compile without commons-daemons. I can them
> move Bootstrap to use these methods and move the script code into these
> methods so that both Bootstrap and BootstrapService share these features.
>
> Is anyone interested in pursuing this? If so, let me know. If not (I
> know everyone is busy), then I can leave things the way they are and
> repropose this sometime in the future.
No, I'd rather do something according to the pre-proposal put forward by
Costin that would be a refactoring of the whole startup and
configuration code, rather than an evolution of the current code. I
don't have much interest in trying to improve that code, as I think it's
good enough (ie, it gets the job done).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown code
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> BootstrapService never used a port.
You're right. I keep confusing the things - I now switched to
CatalinaService and it works.
BootstrapService depends on daemon - and I don't use daemon to
start. ( I hope deamon will switch to introspection )
> Sorry I missed something, but I had the impression that the bootstrap
> code was linked with the configuration code. I don't see how we can do
> all the changes and add JMX at the core level without doing a new JMX
> based launcher (JBoss style, I guess). Maybe I missed something (too
> much vacation, I suppose) ;-)
Ok. First, I don't think the bootstrap is 'linked' to configuration.
The role of bootstrap is to create 2 classloaders, load a class and
pass all the params. The only possible configuration would be the
location of the server/lib and common/lib - and that could be done
using the trick we discuss ( look in the classpath, find the dir ).
Having one class with start/stop/main/execute/setters and minimal
external deps ( commons-logging and introspection maybe ) should work.
The second step is Catalina/CatalinaService. Again,
having a single story would be really good. This is the real 'entry
point' and should have setters and execute for ant and JMX, as well
as main.
Regarding JMX - any application can use modeler ( or a similar tool )
and use Catalina.java as a JMX bean. With DynamicMBean it takes
one line of code. After that - no need to use any tomcat-specific
API, it's just a regular MBean.
The configuration is more of an issue after start() is called. If we
want to use JMX 'everywhere' ( JBoss style ) or not - that's a different
issue. I think it is a good idea, but it needs more discussion and
feedback. So far my 'pre-proposal' on configuration got some
nodding, but no real feedback or interest. If I'm the only one
who has this itch - we can leave server.xml, I won't spend the time
implementing something that nobody needs.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by Remy Maucherat <re...@apache.org>.
costinm@covalent.net wrote:
> On Thu, 8 Aug 2002, Patrick Luby wrote:
>
>
>>Wouldn't commons-daemon also want to use Bootstrap.java's classloader,
>>etc. setup? Right now, all of this is buried in main() instead of a
>>method that commons-daemon could access.
>
>
> Sure - split the main into several methods ( one called 'start' for
> commons-deamon to use ).
>
>
>
>>>Catalina.java will be useable as an ant task ( using execute()
>>>and the setters ) and will be useable as an MBean ( using modeler ).
>>>All things that can be specified via CLI will be setable via
>>>setters.
>>>
>>
>>Wouldn't we want to put execute() in Bootstrap.java since that is where
>>all of the classloader magic is happening?
>
>
> Bootstrap can mirror the methods of Catalina.java - using introspection
> to call them.
>
> But Catalina should have the logic - if you embed tomcat and have all
> the classes already available, or use ant with a defined <path>
> there is no need for Bootstrap.
>
> At least that's my experience with 3.3 launcher - it should
> only create the 'common' and 'server' loaders, create Catalina
> using the server loader, pass the common loader, then use
> introspection to call execute.
>
>
>
>>I agree. The BootstrapService does this very well. Hence, my proposal to
>>share common methods. By sharing start() and stop() logic,
>>Bootstrap.java would only need to have a command-line option (e.g.
>>-noshutdownport) that bypasses the creation of the shutdown port. Right
>>now, Bootstrap.main() has this shutdown port stuff really embedded in there.
>
>
> +1
>
> Each command-line options should have an equivalent setter, for JMX/ant
> use.
>
>
>
>>Also, my hope is that we can have the shutdown port logic, when it is
>>used, happen *before* the server is started so that you don't have to
>>wait for the server to fully start before you can shutdown Tomcat.
>
>
> My hope is that we'll remove the shutdown port and use ajp13 shutdown.
> One less open port. In addition JMX could be used ( or direct calls
> if tomcat is embeded ).
BootstrapService never used a port.
Sorry I missed something, but I had the impression that the bootstrap
code was linked with the configuration code. I don't see how we can do
all the changes and add JMX at the core level without doing a new JMX
based launcher (JBoss style, I guess). Maybe I missed something (too
much vacation, I suppose) ;-)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by co...@covalent.net.
On Thu, 8 Aug 2002, Patrick Luby wrote:
> Wouldn't commons-daemon also want to use Bootstrap.java's classloader,
> etc. setup? Right now, all of this is buried in main() instead of a
> method that commons-daemon could access.
Sure - split the main into several methods ( one called 'start' for
commons-deamon to use ).
> > Catalina.java will be useable as an ant task ( using execute()
> > and the setters ) and will be useable as an MBean ( using modeler ).
> > All things that can be specified via CLI will be setable via
> > setters.
> >
>
> Wouldn't we want to put execute() in Bootstrap.java since that is where
> all of the classloader magic is happening?
Bootstrap can mirror the methods of Catalina.java - using introspection
to call them.
But Catalina should have the logic - if you embed tomcat and have all
the classes already available, or use ant with a defined <path>
there is no need for Bootstrap.
At least that's my experience with 3.3 launcher - it should
only create the 'common' and 'server' loaders, create Catalina
using the server loader, pass the common loader, then use
introspection to call execute.
> I agree. The BootstrapService does this very well. Hence, my proposal to
> share common methods. By sharing start() and stop() logic,
> Bootstrap.java would only need to have a command-line option (e.g.
> -noshutdownport) that bypasses the creation of the shutdown port. Right
> now, Bootstrap.main() has this shutdown port stuff really embedded in there.
+1
Each command-line options should have an equivalent setter, for JMX/ant
use.
> Also, my hope is that we can have the shutdown port logic, when it is
> used, happen *before* the server is started so that you don't have to
> wait for the server to fully start before you can shutdown Tomcat.
My hope is that we'll remove the shutdown port and use ajp13 shutdown.
One less open port. In addition JMX could be used ( or direct calls
if tomcat is embeded ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by Patrick Luby <pa...@sun.com>.
Costin,
costinm@covalent.net wrote:
> On Thu, 8 Aug 2002, Patrick Luby wrote:
>
>
>
>
> The way I see it:
>
> Bootstrap.java -> creates the classpath for server, creates
> and load Catalina.java ( using Class.forName() ). No dependency on
> tomcat - except possibly introspection.
>
> Catalina.java -> main entry point into tomcat. It will have
> setXXX methods ( in addition to the CLI ), start(), stop(),
> execute(). That's where I would do all the endoresed, policy
> settings and most of the logic, that's what applications
> embeding tomcat will use
>
> All other classes should go to a compat/ directory and maintained
> for backward compat only. The commons-deamon can use introspection to
> call start()/stop().
Wouldn't commons-daemon also want to use Bootstrap.java's classloader,
etc. setup? Right now, all of this is buried in main() instead of a
method that commons-daemon could access.
>
> Catalina.java will be useable as an ant task ( using execute()
> and the setters ) and will be useable as an MBean ( using modeler ).
> All things that can be specified via CLI will be setable via
> setters.
>
Wouldn't we want to put execute() in Bootstrap.java since that is where
all of the classloader magic is happening?
> Regarding the shutdown port: it is essential for me to make it
> optional ( so that ant can start catalina in process and then _return_ ).
> Ajp13 already implements a shutdown procedure - and I would rather
> use that. In addition JMX can be used to call the stop operation.
>
I agree. The BootstrapService does this very well. Hence, my proposal to
share common methods. By sharing start() and stop() logic,
Bootstrap.java would only need to have a command-line option (e.g.
-noshutdownport) that bypasses the creation of the shutdown port. Right
now, Bootstrap.main() has this shutdown port stuff really embedded in there.
Also, my hope is that we can have the shutdown port logic, when it is
used, happen *before* the server is started so that you don't have to
wait for the server to fully start before you can shutdown Tomcat.
Patrick
--
________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown
code
Posted by co...@covalent.net.
On Thu, 8 Aug 2002, Patrick Luby wrote:
> I am willing to move the script code into main(). However, there is one
> problem: there are currently 2 sets of startup code. Current Bootstrap
> and BootstrapService both do a lot of the same steps to start Tomcat.
> Before I make any changes to Bootstrap, I would like to propose that we
> separate out the common methods in Bootstrap and BootstrapService
> (e.g. creating the classloaders, invoking Catalina.start(), etc.).
The way I see it:
Bootstrap.java -> creates the classpath for server, creates
and load Catalina.java ( using Class.forName() ). No dependency on
tomcat - except possibly introspection.
Catalina.java -> main entry point into tomcat. It will have
setXXX methods ( in addition to the CLI ), start(), stop(),
execute(). That's where I would do all the endoresed, policy
settings and most of the logic, that's what applications
embeding tomcat will use.
All other classes should go to a compat/ directory and maintained
for backward compat only. The commons-deamon can use introspection to
call start()/stop().
Catalina.java will be useable as an ant task ( using execute()
and the setters ) and will be useable as an MBean ( using modeler ).
All things that can be specified via CLI will be setable via
setters.
Regarding the shutdown port: it is essential for me to make it
optional ( so that ant can start catalina in process and then _return_ ).
Ajp13 already implements a shutdown procedure - and I would rather
use that. In addition JMX can be used to call the stop operation.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>