You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Costin Manolache <cm...@yahoo.com> on 2003/01/14 19:38:41 UTC
PROPOSAL/VOTE: JMX hook mechanism
I don't know if we can get consensus or not - but IMO this is
the right solution, and I'm not going to look for another one.
I decided to make this proposal - to get this out of my
list.
Tomcat is composed of multiple components. We agreed that JMX is
the right way to configure and manage the components. The proposal
is to use JMX notifications to consolidate all callback and extension
mechanisms.
The only exception will be Valve - where the calling mechanism
just doesn't fit and the effort and changes will be too big. Valve
will remain unchanged - but for any new modules and as we optimize/enhance
existing modules we should switch to notifications.
Coyote ActionHook and JkHandler will be deprecated and replaced witht the
NotificationListener interface. The current parameters will be passed
in the Notification subclass ( we can reuse the same notification object -
one per Request object ). Small refactorings will be needed - but I don't
think it'll destabilize the code too much.
I don't expect this to destabilize the code too much - but if we decide to
do that, a branch may be a good idea.
Please post your opinion - and if you are interested to help doing it.
I posted some more notes on my weblog ( which I just started few days ago ),
and I'll update it with more details.
See http://www.webweavertech.com/costin/weblog/index.html
and http://www.webweavertech.com/costin/archives/000152.html
( I'm just getting started with the blogging :-).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL/VOTE: JMX hook mechanism
Posted by Jeanfrancois Arcand <jf...@apache.org>.
Costin Manolache wrote:
>I don't know if we can get consensus or not - but IMO this is
>the right solution, and I'm not going to look for another one.
>I decided to make this proposal - to get this out of my
>list.
>
Hope your list is not too big :-)
>
>Tomcat is composed of multiple components. We agreed that JMX is
>the right way to configure and manage the components. The proposal
>is to use JMX notifications to consolidate all callback and extension
>mechanisms.
>
+1
>
>
>
>The only exception will be Valve - where the calling mechanism
>just doesn't fit and the effort and changes will be too big. Valve
>will remain unchanged - but for any new modules and as we optimize/enhance
>existing modules we should switch to notifications.
>
I will give a try with the valve also. What we have to change is
StandardPipeline, ValveBase and ValveContext to use the
NotificationListener mechanism (simplification). Does I'm missing
something here? If not, I can make the change to see how it goes (on a
separate branch for sure).
>
>Coyote ActionHook and JkHandler will be deprecated and replaced witht the
>NotificationListener interface. The current parameters will be passed
>in the Notification subclass ( we can reuse the same notification object -
>one per Request object ). Small refactorings will be needed - but I don't
>think it'll destabilize the code too much.
>
>I don't expect this to destabilize the code too much - but if we decide to
>do that, a branch may be a good idea.
>
+1
>
>Please post your opinion - and if you are interested to help doing it.
>
Yes, I'm interested to help, but not as my first task.
>
>I posted some more notes on my weblog ( which I just started few days ago ),
>and I'll update it with more details.
>See http://www.webweavertech.com/costin/weblog/index.html
>and http://www.webweavertech.com/costin/archives/000152.html
>( I'm just getting started with the blogging :-).
>
I prefer the mailling list, and if I have to do one, I will do it in
french since most of us understand french (oups...againt the souveranist
Quebecois dream that come back :-) )
-- Jeanfrancois
>
>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/VOTE: JMX hook mechanism
Posted by Glenn Nielsen <gl...@mail.more.net>.
The book I have on JMX didn't mention anything about security.
Therefor my concern. I'll take a look at the JMX 1.2 spec & RI.
Yeah, the SecurityManager is definitely the right way to go.
Thanks,
Glenn
Costin Manolache wrote:
> Glenn Nielsen wrote:
>
>
>>I have one general comment. For security I would like to see two
>>different
>>MBeanServers used. One for config management the other for runtime
>>monitoring. This way you could implement diffrent access controls for
>>config management
>>from runtime monitoring.
>
>
> That's one concern I have with JMX - there is some protection using
> the Policy ( in JMX1.2 ), but if you don't run the sandbox you're
> on your own.
>
> All JMX implementations seem to support some "interceptors" and we can
> try to implement our own add-on scheme ( not sure if Sun RI extensions are
> documented or exist - but MX4J and Jboss provide that ).
>
> I'm afraid using 2 MBeanServers is not the best solution - if we put the
> mbean server in the parent loader, I'm pretty sure user code will be able
> to get it ( if it wants to ). And the code can become very complicated.
>
> You know my opinion on this - if you don't run the sandbox, user code can
> control the VM without problems ( with some JNI code - or introspection,
> or by overriding files ). If you run sandbox - the JMX1.2 policy-based
> access control should be good enough.
>
> Costin
>
>
>
>>Glenn
>>
>>Costin Manolache wrote:
>>
>>>Remy Maucherat wrote:
>>>
>>>
>>>
>>>>This looks fine. Do I get some sample code before voting, so I can see
>>>>the thing in action ?
>>>
>>>
>>>I'm working on converting Jk to Listeners.
>>>
>>>I want to first check in some changes to enable the "what is each thread
>>>doing" feature - but that would add the dependency to JMX.
>>>
>>>Time for a branch...
>>>
>>>Should I do the changes in a branch, or branch the current stable code
>>>and make changes in HEAD ?
>>>
>>>
>>>
>>>
>>>>>I posted some more notes on my weblog ( which I just started few days
>>>>>ago ), and I'll update it with more details.
>>>>>See http://www.webweavertech.com/costin/weblog/index.html
>>>>>and http://www.webweavertech.com/costin/archives/000152.html
>>>>>( I'm just getting started with the blogging :-).
>>>>
>>>>Arg, you fell for blogging ! ;-P
>>>>I'm not going to (although I do enjoy reading blogs): discussions should
>>>>stay on the mailing lists, which do have centralized archives. If lists
>>>>get more quiet because of blogging, then it's good (less emails to read
>>>>every day :-D ).
>>>
>>>
>>>I have a feeling the blogging is already affecting the lists. And it
>>>certainly helps organize yourself - that was the main argument for me.
>>>
>>>Are other tomcat developers blogging ? Should we keep a list - maybe in
>>>wiki ?
>>>
>>>It would be nice to be able to take all blogs about tomcat and feed them
>>>into the list ( I have a category for tocmat and one for ant - but I
>>>don't know too much about blogging yet ).
>>>
>>>
>>>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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL/VOTE: JMX hook mechanism
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Glenn Nielsen wrote:
>
>
>>I have one general comment. For security I would like to see two
>>different
>>MBeanServers used. One for config management the other for runtime
>>monitoring. This way you could implement diffrent access controls for
>>config management
>>from runtime monitoring.
>
>
> That's one concern I have with JMX - there is some protection using
> the Policy ( in JMX1.2 ), but if you don't run the sandbox you're
> on your own.
>
> All JMX implementations seem to support some "interceptors" and we can
> try to implement our own add-on scheme ( not sure if Sun RI extensions are
> documented or exist - but MX4J and Jboss provide that ).
>
> I'm afraid using 2 MBeanServers is not the best solution - if we put the
> mbean server in the parent loader, I'm pretty sure user code will be able
> to get it ( if it wants to ). And the code can become very complicated.
>
> You know my opinion on this - if you don't run the sandbox, user code can
> control the VM without problems ( with some JNI code - or introspection,
> or by overriding files ). If you run sandbox - the JMX1.2 policy-based
> access control should be good enough.
Great that they added those features. Having 2 MBean servers would be
quite complex, so I think Costin is right, and we should rely on the
security manager.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL/VOTE: JMX hook mechanism
Posted by Costin Manolache <cm...@yahoo.com>.
Glenn Nielsen wrote:
> I have one general comment. For security I would like to see two
> different
> MBeanServers used. One for config management the other for runtime
> monitoring. This way you could implement diffrent access controls for
> config management
> from runtime monitoring.
That's one concern I have with JMX - there is some protection using
the Policy ( in JMX1.2 ), but if you don't run the sandbox you're
on your own.
All JMX implementations seem to support some "interceptors" and we can
try to implement our own add-on scheme ( not sure if Sun RI extensions are
documented or exist - but MX4J and Jboss provide that ).
I'm afraid using 2 MBeanServers is not the best solution - if we put the
mbean server in the parent loader, I'm pretty sure user code will be able
to get it ( if it wants to ). And the code can become very complicated.
You know my opinion on this - if you don't run the sandbox, user code can
control the VM without problems ( with some JNI code - or introspection,
or by overriding files ). If you run sandbox - the JMX1.2 policy-based
access control should be good enough.
Costin
>
> Glenn
>
> Costin Manolache wrote:
>> Remy Maucherat wrote:
>>
>>
>>>This looks fine. Do I get some sample code before voting, so I can see
>>>the thing in action ?
>>
>>
>> I'm working on converting Jk to Listeners.
>>
>> I want to first check in some changes to enable the "what is each thread
>> doing" feature - but that would add the dependency to JMX.
>>
>> Time for a branch...
>>
>> Should I do the changes in a branch, or branch the current stable code
>> and make changes in HEAD ?
>>
>>
>>
>>>>I posted some more notes on my weblog ( which I just started few days
>>>>ago ), and I'll update it with more details.
>>>>See http://www.webweavertech.com/costin/weblog/index.html
>>>>and http://www.webweavertech.com/costin/archives/000152.html
>>>>( I'm just getting started with the blogging :-).
>>>
>>>Arg, you fell for blogging ! ;-P
>>>I'm not going to (although I do enjoy reading blogs): discussions should
>>>stay on the mailing lists, which do have centralized archives. If lists
>>>get more quiet because of blogging, then it's good (less emails to read
>>>every day :-D ).
>>
>>
>> I have a feeling the blogging is already affecting the lists. And it
>> certainly helps organize yourself - that was the main argument for me.
>>
>> Are other tomcat developers blogging ? Should we keep a list - maybe in
>> wiki ?
>>
>> It would be nice to be able to take all blogs about tomcat and feed them
>> into the list ( I have a category for tocmat and one for ant - but I
>> don't know too much about blogging yet ).
>>
>>
>> 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/VOTE: JMX hook mechanism
Posted by Glenn Nielsen <gl...@mail.more.net>.
I have one general comment. For security I would like to see two different
MBeanServers used. One for config management the other for runtime monitoring.
This way you could implement diffrent access controls for config management
from runtime monitoring.
Glenn
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>This looks fine. Do I get some sample code before voting, so I can see
>>the thing in action ?
>
>
> I'm working on converting Jk to Listeners.
>
> I want to first check in some changes to enable the "what is each thread
> doing" feature - but that would add the dependency to JMX.
>
> Time for a branch...
>
> Should I do the changes in a branch, or branch the current stable code and
> make changes in HEAD ?
>
>
>
>>>I posted some more notes on my weblog ( which I just started few days ago
>>>), and I'll update it with more details.
>>>See http://www.webweavertech.com/costin/weblog/index.html
>>>and http://www.webweavertech.com/costin/archives/000152.html
>>>( I'm just getting started with the blogging :-).
>>
>>Arg, you fell for blogging ! ;-P
>>I'm not going to (although I do enjoy reading blogs): discussions should
>>stay on the mailing lists, which do have centralized archives. If lists
>>get more quiet because of blogging, then it's good (less emails to read
>>every day :-D ).
>
>
> I have a feeling the blogging is already affecting the lists. And it
> certainly helps organize yourself - that was the main argument for me.
>
> Are other tomcat developers blogging ? Should we keep a list - maybe in
> wiki ?
>
> It would be nice to be able to take all blogs about tomcat and feed them
> into the list ( I have a category for tocmat and one for ant - but I don't
> know too much about blogging yet ).
>
>
> Costin
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL/VOTE: JMX hook mechanism
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>This looks fine. Do I get some sample code before voting, so I can see
>>the thing in action ?
>
>
> I'm working on converting Jk to Listeners.
>
> I want to first check in some changes to enable the "what is each thread
> doing" feature - but that would add the dependency to JMX.
>
> Time for a branch...
>
> Should I do the changes in a branch, or branch the current stable code and
> make changes in HEAD ?
The policy has been to make the changes in HEAD.
Tomcat 4.1.x will of course integrate the stable code in the branch.
I reread that part of the JMX API, and I think I am +1 (it does the same
as the current action mechanism).
>>>I posted some more notes on my weblog ( which I just started few days ago
>>>), and I'll update it with more details.
>>>See http://www.webweavertech.com/costin/weblog/index.html
>>>and http://www.webweavertech.com/costin/archives/000152.html
>>>( I'm just getting started with the blogging :-).
>>
>>Arg, you fell for blogging ! ;-P
>>I'm not going to (although I do enjoy reading blogs): discussions should
>>stay on the mailing lists, which do have centralized archives. If lists
>>get more quiet because of blogging, then it's good (less emails to read
>>every day :-D ).
>
>
> I have a feeling the blogging is already affecting the lists. And it
> certainly helps organize yourself - that was the main argument for me.
Ah, ok. Well, I *do* have some post its lying around somewhere (like
some random design ideas for the new mapper, most of which are bad, of
course ;-) ). Is there any use in making my post its public ?
> Are other tomcat developers blogging ? Should we keep a list - maybe in
> wiki ?
>
> It would be nice to be able to take all blogs about tomcat and feed them
> into the list ( I have a category for tocmat and one for ant - but I don't
> know too much about blogging yet ).
Nice way to force me to blog ;-)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL/VOTE: JMX hook mechanism
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> This looks fine. Do I get some sample code before voting, so I can see
> the thing in action ?
I'm working on converting Jk to Listeners.
I want to first check in some changes to enable the "what is each thread
doing" feature - but that would add the dependency to JMX.
Time for a branch...
Should I do the changes in a branch, or branch the current stable code and
make changes in HEAD ?
>> I posted some more notes on my weblog ( which I just started few days ago
>> ), and I'll update it with more details.
>> See http://www.webweavertech.com/costin/weblog/index.html
>> and http://www.webweavertech.com/costin/archives/000152.html
>> ( I'm just getting started with the blogging :-).
>
> Arg, you fell for blogging ! ;-P
> I'm not going to (although I do enjoy reading blogs): discussions should
> stay on the mailing lists, which do have centralized archives. If lists
> get more quiet because of blogging, then it's good (less emails to read
> every day :-D ).
I have a feeling the blogging is already affecting the lists. And it
certainly helps organize yourself - that was the main argument for me.
Are other tomcat developers blogging ? Should we keep a list - maybe in
wiki ?
It would be nice to be able to take all blogs about tomcat and feed them
into the list ( I have a category for tocmat and one for ant - but I don't
know too much about blogging yet ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL/VOTE: JMX hook mechanism
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> I don't know if we can get consensus or not - but IMO this is
> the right solution, and I'm not going to look for another one.
> I decided to make this proposal - to get this out of my
> list.
>
> Tomcat is composed of multiple components. We agreed that JMX is
> the right way to configure and manage the components. The proposal
> is to use JMX notifications to consolidate all callback and extension
> mechanisms.
>
> The only exception will be Valve - where the calling mechanism
> just doesn't fit and the effort and changes will be too big. Valve
> will remain unchanged - but for any new modules and as we optimize/enhance
> existing modules we should switch to notifications.
>
> Coyote ActionHook and JkHandler will be deprecated and replaced witht the
> NotificationListener interface. The current parameters will be passed
> in the Notification subclass ( we can reuse the same notification object -
> one per Request object ). Small refactorings will be needed - but I don't
> think it'll destabilize the code too much.
>
> I don't expect this to destabilize the code too much - but if we decide to
> do that, a branch may be a good idea.
>
> Please post your opinion - and if you are interested to help doing it.
This looks fine. Do I get some sample code before voting, so I can see
the thing in action ?
I think this should lead to a branch (where we put the current code in a
"COYOTE_1" branch) and Coyote 2.0.
> I posted some more notes on my weblog ( which I just started few days ago ),
> and I'll update it with more details.
> See http://www.webweavertech.com/costin/weblog/index.html
> and http://www.webweavertech.com/costin/archives/000152.html
> ( I'm just getting started with the blogging :-).
Arg, you fell for blogging ! ;-P
I'm not going to (although I do enjoy reading blogs): discussions should
stay on the mailing lists, which do have centralized archives. If lists
get more quiet because of blogging, then it's good (less emails to read
every day :-D ).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>