You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Mladen Turk <mt...@mappingsoft.com> on 2002/06/15 18:43:34 UTC
TomcatMonitor
Hi,
As a maker of ApacheMonitor I _know_ that the support for the Tomcat's
start/stop/monitor would be trivial.
The question is can we (Apache2 and Tomcat) agree to coexist, or make
two different try buttons.
MT.
Re: TomcatMonitor
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
William A. Rowe, Jr. wrote:
> At 01:58 AM 6/16/2002, Mladen Turk wrote:
>
>> > Finally, we need a service-specific way (probably as a subkey
>> > of the service within HKLM/CurrentControlSet/Services) to
>> > define what "Extra" user-defined ControlService codes are
>> > supported. Win32 today supports 128 as Restart. Could add
>> > new ones later on to distinguish that Graceful from a Hard
>> > restart. Tomcat doesn't support any, but could in the future.
>> >
>>
>> I think that the extension dll would be better solution.
>> Using registry would be simpler, but more restrictive.
>
>
> No... it's really not restrictive at all, it's a well defined API. I
> believe the
> status codes are extensible as well, although I have to look at the API
> to be certain. But let's not reinvent wheels ;-)
>
> We've gotta remember that folks don't compile for Apache, and we really
> want to place as much configuration/control in the hands of the users as
> we possibly can. So I'd put user configuration over custom APIs any day.
>
> I really hate the idea of building a new extension API when one exists,
> so...
>
> we should be able to host the service control dialog extension. 'Should'
> is the operative word, I started hacking but coding to undocumented
> interfaces gets rough. But my point is this; if someone codes an extended
> dialog for the Apache service, for example, it would be available from both
> ApacheMonitor and the Services MMC view under properties.
>
> What I don't want to do is start investing a bunch of time at 9x pseudo
> services when XP home [finally] really melds together the 'home' OS with
> what we need in terms of real NT service control. That bit might be harder
> to define to everyone's satisfaction, but I bet it can be done.
>
> Bill
>
>
In jakarta-commons-sandbox/daemon there is already pieces of this httpd logic.
The problem is jakarta-commons-sandbox/daemon needs cygwin in win32 plaform.
(I do not want to use something else that a gnu compiler and that was the
fastest way to get it working)
The jakarta-commons-sandbox/daemon idea is to run services written in Java.
I use it to run Tomcat on Port 80 as user nobody
That is for Java the configuration information should be stored in a property
file (and not in the registry).
Chers
Jean-frederic
Re: TomcatMonitor
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
William A. Rowe, Jr. wrote:
> At 01:58 AM 6/16/2002, Mladen Turk wrote:
>
>> > Finally, we need a service-specific way (probably as a subkey
>> > of the service within HKLM/CurrentControlSet/Services) to
>> > define what "Extra" user-defined ControlService codes are
>> > supported. Win32 today supports 128 as Restart. Could add
>> > new ones later on to distinguish that Graceful from a Hard
>> > restart. Tomcat doesn't support any, but could in the future.
>> >
>>
>> I think that the extension dll would be better solution.
>> Using registry would be simpler, but more restrictive.
>
>
> No... it's really not restrictive at all, it's a well defined API. I
> believe the
> status codes are extensible as well, although I have to look at the API
> to be certain. But let's not reinvent wheels ;-)
>
> We've gotta remember that folks don't compile for Apache, and we really
> want to place as much configuration/control in the hands of the users as
> we possibly can. So I'd put user configuration over custom APIs any day.
>
> I really hate the idea of building a new extension API when one exists,
> so...
>
> we should be able to host the service control dialog extension. 'Should'
> is the operative word, I started hacking but coding to undocumented
> interfaces gets rough. But my point is this; if someone codes an extended
> dialog for the Apache service, for example, it would be available from both
> ApacheMonitor and the Services MMC view under properties.
>
> What I don't want to do is start investing a bunch of time at 9x pseudo
> services when XP home [finally] really melds together the 'home' OS with
> what we need in terms of real NT service control. That bit might be harder
> to define to everyone's satisfaction, but I bet it can be done.
>
> Bill
>
>
In jakarta-commons-sandbox/daemon there is already pieces of this httpd logic.
The problem is jakarta-commons-sandbox/daemon needs cygwin in win32 plaform.
(I do not want to use something else that a gnu compiler and that was the
fastest way to get it working)
The jakarta-commons-sandbox/daemon idea is to run services written in Java.
I use it to run Tomcat on Port 80 as user nobody
That is for Java the configuration information should be stored in a property
file (and not in the registry).
Chers
Jean-frederic
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: TomcatMonitor
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: 16. lipanj 2002 18:55
> To: dev@httpd.apache.org
> Cc: dev@httpd.apache.org; William A. Rowe, Jr.;
> tomcat-dev@jakarta.apache.org
> Subject: RE: TomcatMonitor
>
>
> I really hate the idea of building a new extension API when
> one exists, so...
>
Me to, especially commenting that :)
> we should be able to host the service control dialog
> extension. 'Should' is the operative word, I started hacking
> but coding to undocumented interfaces gets rough. But my
> point is this; if someone codes an extended dialog for the
> Apache service, for example, it would be available from both
> ApacheMonitor and the Services MMC view under properties.
>
+++1, I love the idea. If you remember I even posted the AM that works
like a CPL.
The only problem is the 8.3 filename restiction, if that's problem at
all.
MT.
RE: TomcatMonitor
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:58 AM 6/16/2002, Mladen Turk wrote:
> > Finally, we need a service-specific way (probably as a subkey
> > of the service within HKLM/CurrentControlSet/Services) to
> > define what "Extra" user-defined ControlService codes are
> > supported. Win32 today supports 128 as Restart. Could add
> > new ones later on to distinguish that Graceful from a Hard
> > restart. Tomcat doesn't support any, but could in the future.
> >
>
>I think that the extension dll would be better solution.
>Using registry would be simpler, but more restrictive.
No... it's really not restrictive at all, it's a well defined API. I
believe the
status codes are extensible as well, although I have to look at the API
to be certain. But let's not reinvent wheels ;-)
We've gotta remember that folks don't compile for Apache, and we really
want to place as much configuration/control in the hands of the users as
we possibly can. So I'd put user configuration over custom APIs any day.
I really hate the idea of building a new extension API when one exists, so...
we should be able to host the service control dialog extension. 'Should'
is the operative word, I started hacking but coding to undocumented
interfaces gets rough. But my point is this; if someone codes an extended
dialog for the Apache service, for example, it would be available from both
ApacheMonitor and the Services MMC view under properties.
What I don't want to do is start investing a bunch of time at 9x pseudo
services when XP home [finally] really melds together the 'home' OS with
what we need in terms of real NT service control. That bit might be harder
to define to everyone's satisfaction, but I bet it can be done.
Bill
RE: TomcatMonitor
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:58 AM 6/16/2002, Mladen Turk wrote:
> > Finally, we need a service-specific way (probably as a subkey
> > of the service within HKLM/CurrentControlSet/Services) to
> > define what "Extra" user-defined ControlService codes are
> > supported. Win32 today supports 128 as Restart. Could add
> > new ones later on to distinguish that Graceful from a Hard
> > restart. Tomcat doesn't support any, but could in the future.
> >
>
>I think that the extension dll would be better solution.
>Using registry would be simpler, but more restrictive.
No... it's really not restrictive at all, it's a well defined API. I
believe the
status codes are extensible as well, although I have to look at the API
to be certain. But let's not reinvent wheels ;-)
We've gotta remember that folks don't compile for Apache, and we really
want to place as much configuration/control in the hands of the users as
we possibly can. So I'd put user configuration over custom APIs any day.
I really hate the idea of building a new extension API when one exists, so...
we should be able to host the service control dialog extension. 'Should'
is the operative word, I started hacking but coding to undocumented
interfaces gets rough. But my point is this; if someone codes an extended
dialog for the Apache service, for example, it would be available from both
ApacheMonitor and the Services MMC view under properties.
What I don't want to do is start investing a bunch of time at 9x pseudo
services when XP home [finally] really melds together the 'home' OS with
what we need in terms of real NT service control. That bit might be harder
to define to everyone's satisfaction, but I bet it can be done.
Bill
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: TomcatMonitor
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: 16. lipanj 2002 5:03
> To: dev@httpd.apache.org
> Subject: Re: TomcatMonitor
>
> >
> >I wouldn't have a problem with that. No sense reinventing the wheel
> >for one or the other of us... +1.
>
> and a ++1 here.
>
> Requirements ...
>
> 1. keep running a single binary. Don't care if it displays
> one or twenty
> taskbar
> icons, but the overhead of the binary itself (polling the list of
> services) is just
> too intense to waste with multiple invocations running at
> the same time.
>
> Suggestions and Observations
>
> 1. the name, "Apache Monitor" is generic enough for any ASF project.
Agreed!
>
> So we could create a registry of apps, under
>
> HLKM\SOFTWARE\Apache Software Foundation\ApacheMonitor\
>
> And even define groups that would consitute one 'Icon'. That
> way a given server's tomcat and apache instances could both
> be tracked under a single icon, while another server's tomcat
> and apache instances could be tracked under another icon?
>
Excellent. I was thinking the same, even before the xxx service
monitoring.
The reason is to be able to save the connected computers, and perhaps
the
Disconnect button will 'pass' this time (It's already in the code).
Further more to keep the things simple :-), I was thinking of something
like
'User button', for specific group of services, that is invoked through
extension dll.
This extension dll should have two callbacks (ApacheMonitorInitialize,
ApacheMonitorManage and ApacheMonitorService).
So if found in the registry, the AM will try to load those dll's at
startup and query the
ApacheMonitorInitialize for icons, the 'User button' name, "Extra"
user-defined codes, etc...
ApacheMonitorManage will be called when the user clicks on that 'User
button' with the name
Of the selected service, the AM's window handle, and service registry
key.
If the ApacheMonitorService callback is present it will be called upon
the start/stop/restart events instead of the default ones in the AM
itself. This will enable to do whatever extra is needed to be done prior
to those events, and depending on the returned value, the standard
service management will be skipped or called.
> Finally, we need a service-specific way (probably as a subkey
> of the service within HKLM/CurrentControlSet/Services) to
> define what "Extra" user-defined ControlService codes are
> supported. Win32 today supports 128 as Restart. Could add
> new ones later on to distinguish that Graceful from a Hard
> restart. Tomcat doesn't support any, but could in the future.
>
I think that the extension dll would be better solution.
Using registry would be simpler, but more restrictive.
MT.
RE: TomcatMonitor
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: 16. lipanj 2002 5:03
> To: dev@httpd.apache.org
> Subject: Re: TomcatMonitor
>
> >
> >I wouldn't have a problem with that. No sense reinventing the wheel
> >for one or the other of us... +1.
>
> and a ++1 here.
>
> Requirements ...
>
> 1. keep running a single binary. Don't care if it displays
> one or twenty
> taskbar
> icons, but the overhead of the binary itself (polling the list of
> services) is just
> too intense to waste with multiple invocations running at
> the same time.
>
> Suggestions and Observations
>
> 1. the name, "Apache Monitor" is generic enough for any ASF project.
Agreed!
>
> So we could create a registry of apps, under
>
> HLKM\SOFTWARE\Apache Software Foundation\ApacheMonitor\
>
> And even define groups that would consitute one 'Icon'. That
> way a given server's tomcat and apache instances could both
> be tracked under a single icon, while another server's tomcat
> and apache instances could be tracked under another icon?
>
Excellent. I was thinking the same, even before the xxx service
monitoring.
The reason is to be able to save the connected computers, and perhaps
the
Disconnect button will 'pass' this time (It's already in the code).
Further more to keep the things simple :-), I was thinking of something
like
'User button', for specific group of services, that is invoked through
extension dll.
This extension dll should have two callbacks (ApacheMonitorInitialize,
ApacheMonitorManage and ApacheMonitorService).
So if found in the registry, the AM will try to load those dll's at
startup and query the
ApacheMonitorInitialize for icons, the 'User button' name, "Extra"
user-defined codes, etc...
ApacheMonitorManage will be called when the user clicks on that 'User
button' with the name
Of the selected service, the AM's window handle, and service registry
key.
If the ApacheMonitorService callback is present it will be called upon
the start/stop/restart events instead of the default ones in the AM
itself. This will enable to do whatever extra is needed to be done prior
to those events, and depending on the returned value, the standard
service management will be skipped or called.
> Finally, we need a service-specific way (probably as a subkey
> of the service within HKLM/CurrentControlSet/Services) to
> define what "Extra" user-defined ControlService codes are
> supported. Win32 today supports 128 as Restart. Could add
> new ones later on to distinguish that Graceful from a Hard
> restart. Tomcat doesn't support any, but could in the future.
>
I think that the extension dll would be better solution.
Using registry would be simpler, but more restrictive.
MT.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TomcatMonitor
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:45 AM 6/15/2002, you wrote:
>On Sat, 15 Jun 2002, Mladen Turk wrote:
>
> > As a maker of ApacheMonitor I _know_ that the support for the Tomcat's
> > start/stop/monitor would be trivial.
> > The question is can we (Apache2 and Tomcat) agree to coexist, or make
> > two different try buttons.
>
>I wouldn't have a problem with that. No sense reinventing the wheel for
>one or the other of us... +1.
and a ++1 here.
Requirements ...
1. keep running a single binary. Don't care if it displays one or twenty
taskbar
icons, but the overhead of the binary itself (polling the list of
services) is just
too intense to waste with multiple invocations running at the same time.
Suggestions and Observations
1. the name, "Apache Monitor" is generic enough for any ASF project.
2. we name the service (as does Tomcat) in an intelligent way, so we simply
continue to display the 'display' name of the service in any prompts.
No confusion.
3. we aught to have some 'registry' of services that the monitor will handle.
No reason the user couldn't extend the monitor to any service. Why don't
we continue to key on the ImagePath name, perhaps using regexes, so we
can even pattern match for things like hostsvc.exe -k NetworkService?
So we could create a registry of apps, under
HLKM\SOFTWARE\Apache Software Foundation\ApacheMonitor\
And even define groups that would consitute one 'Icon'. That way a given
server's tomcat and apache instances could both be tracked under a single
icon, while another server's tomcat and apache instances could be tracked
under another icon?
Finally, we need a service-specific way (probably as a subkey of the service
within HKLM/CurrentControlSet/Services) to define what "Extra" user-defined
ControlService codes are supported. Win32 today supports 128 as Restart.
Could add new ones later on to distinguish that Graceful from a Hard restart.
Tomcat doesn't support any, but could in the future.
Foods for thought, I hope to have time to finish the async hacks soon so the
taskbar is more responsive to the user (and includes the starting and stopping
states as well.)
Bill
Re: TomcatMonitor
Posted by jlwpc1 <jl...@earthlink.net>.
:: The question is can we (Apache2 and Tomcat) agree to coexist, or
make
:: two different try buttons.
::
>From the Online ( and downloadable )
System Administration Scripting Guide
Services
http://www.microsoft.com/technet/scriptcenter/services/default.asp
And for Win9x ( and others NT up )
Processes
http://www.microsoft.com/technet/scriptcenter/process/default.asp
Use the above in the command line or
for graphic type buttons, list boxes, and
etc., try a HTA.
Introduction to HTML Applications (HTAs)
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/hta
/overview/htaoverview.asp
JLW
Re: TomcatMonitor
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sat, 15 Jun 2002, Mladen Turk wrote:
> As a maker of ApacheMonitor I _know_ that the support for the Tomcat's
> start/stop/monitor would be trivial.
> The question is can we (Apache2 and Tomcat) agree to coexist, or make
> two different try buttons.
I wouldn't have a problem with that. No sense reinventing the wheel for
one or the other of us... +1.
--Cliff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TomcatMonitor
Posted by co...@covalent.net.
On Sat, 15 Jun 2002, Mladen Turk wrote:
> Hi,
>
> As a maker of ApacheMonitor I _know_ that the support for the Tomcat's
> start/stop/monitor would be trivial.
I can't wait to see it implemented...
Costin
> The question is can we (Apache2 and Tomcat) agree to coexist, or make
> two different try buttons.
Re: TomcatMonitor
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sat, 15 Jun 2002, Mladen Turk wrote:
> As a maker of ApacheMonitor I _know_ that the support for the Tomcat's
> start/stop/monitor would be trivial.
> The question is can we (Apache2 and Tomcat) agree to coexist, or make
> two different try buttons.
I wouldn't have a problem with that. No sense reinventing the wheel for
one or the other of us... +1.
--Cliff
Re: TomcatMonitor
Posted by co...@covalent.net.
On Sat, 15 Jun 2002, Mladen Turk wrote:
> Hi,
>
> As a maker of ApacheMonitor I _know_ that the support for the Tomcat's
> start/stop/monitor would be trivial.
I can't wait to see it implemented...
Costin
> The question is can we (Apache2 and Tomcat) agree to coexist, or make
> two different try buttons.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>