You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by cm...@yahoo.com on 2002/08/16 00:50:00 UTC
[5] Config
After a lot of thinking and searching, I found a solution that
I think will work well. If you like it - I'll need some help from
Remy to implement it. If you don't like it - I'm waiting for
a better one...
There are 3 major parts:
1. Config storage. Currently that's server.xml.
2. Configuring various components ( runtime config, init, etc ).
That's done using digester/introspection in 4.x ( init ) and JMX ( at
runtime )
3. Saving config. That's done via introspecting life objects
and generating server.xml in 4.x
What I'm proposing is a pluggable config storage, using JNDI API
for storage and JMX ( and introspection ) for runtime changes.
For API - my initial approach was to create a clone of 1.4 prefs.
I think a much better solution is to use JNDI as API.
We already depend on JNDI, and JNDI is available to all VMs -
including in GCJ, kaffe. The interface is mature, flexible and
well known. In addition it is very easy to create wrappers to
jdk1.4 prefs and back - so both 'flavors' can be used.
The data will be organized to follow the JMX naming hierarchy
( after reorganizing the naming schema ): each tomcat component
that is configurable will have a JMX name and associated attributes,
and those will be stored in the directory. An ObjectName will be
a jndi Name.
We'll automatically gain access to all 'stores' that jndi supports -
ldap, directory servers, etc. There are also file providers implementing
standard xml formats ( or ldif ?). An additional format to support
may be the jboss-style <mbean> - which may be syntactically closer
to the jmx-based runtime.
The second layer will be a wrapper that can use either introspection
or JMX, possibly an extension of modeler.
We'll have a clear distinction between 'persistent' config and
'runtime' config. JMX was not designed for storage ( even if it
has the optional load/store methods ), and it is useful to be
able to choose between making changes in the running server
( some may be temporary ) and making changes in the persistent
store.
Using notifications it is possible to propagate any change via
JMX to the store - but that should be optional ( i.e. you could
choose to not change the store, but only the runtime ).
Any operation ( reload, etc ) will be done via JMX - only
setting attributes is important for config.
It is possible to also use DirContext to represent 'life'
objects - and use the same API to set attributes on the
persistent and life sub-trees. ( with JMX or introspection
underneath ).
There are few (major) issues with JMX - I don't know how
well it will scale, giving the huge number of objects it involves.
One way to solve this is to use mx4j internals - for example
to delay some of the introspection, optimize some
lookups, etc. Right now the JNDI model seems better
suited for a large number of objects ( if we start
representing each servlet as an mbean - for example
to collect time information ). But overall JMX is
the right way to go about configuring and operating
on live objects, and JNDI is (IMO) the right way to
go about storing hierarchical and config data.
What do you think ?
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [TODO] Config first task
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> I don't understand why you think it's the same.
>
> For the ENC, you do something like:
> (new InitialContext()).lookup("java:/comp/env/maxExemptions");
>
> So you need the thread or CL binding to retrive the JNDI Context where
> maxExemptions is.
>
> For the config, you can for example give StandardContext a reference to
> the DirContext which contains the webapp configuration data. So no
> thread binding needed.
I think we're talking about different things.
Say I want to read WEB-INF/web.xml for application /examples.
Right now it seems what I have to do requires the use of the thread
or cl binding to locate the jndi context representing the war/files.
What I would like to do from inside tomcat is:
globalContext.lookup("host=localhost:8080, path=/examples,
file=/WEB-INF/web.xml")
( or some / based name: FILES:/localhost:8080/examples/WEB-INF/web.xml ).
I couldn't find any way to do that.
For the java:/comp/env - yes, the Context must be bound so that
the app can locate it using the InitialContext(). But it can
also be bound in the 'globalContext' - so that an admin app or
some listeners can see/alter the webapp bindings.
What I'm trying to say is that thread/classloader binding is
required in some cases, but it can be avoided in many other cases. And
in general there are a lot of 'tricky' things about it ( like if you
create a new thread and the binding no longer works ).
>> Sure. Just trying to get feedback and maybe get other people interested.
>> So far only 2 people seem interested in 'common-discovery'.
>
> I didn't look at it at all, sorry :-(
It's about using META-INF/services, and in general about supporting a
pattern where each .jar includes some resource with a fixed name
and you want to manipulate it.
Examples:
- locate Listeners/Valves/Interceptors that are installed, so that the
admin can display all available modules
- locate and automatically load any META-INF/mbeans.xml so that each module
can register his own description transparently
- possibly META-INF/ant.tasks ( or just
META-INF/services/org.apache.tools.ant.ProjectComponent ) - and have the
tasks automatically declared
- declare some interface for tomcat configurator ( like ant's ProjectHelper)
and have it loaded automatically. ( or different configurators that are
available, each getting a chance to configure )
- declare the JNDI providers or JDBC drivers so you don't need to
explicitely declare them
- support multiple parsers - and have a way to choose which one to use
( instead of 'select first' )
And so on.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [TODO] Config first task
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>>And internals and 'priviledged' application will get access to the
>>>root of this tree, and look up anything configurable or runtime
>>>using the 'normal' API - with no tricks with classloader/thread binding.
>>
>>That's different from the ENC, since here, you can give the component a
>>reference to the right context.
>
>
> That's something I don't understand.
>
> Each app is supposed to get it's own DirContext, using the same name.
> And that's done by binding it per thread or class loader.
>
> However this DirContext may also be binded in the 'big tree' - and
> internal code could access all those 'enc' contexts.
I don't understand why you think it's the same.
For the ENC, you do something like:
(new InitialContext()).lookup("java:/comp/env/maxExemptions");
So you need the thread or CL binding to retrive the JNDI Context where
maxExemptions is.
For the config, you can for example give StandardContext a reference to
the DirContext which contains the webapp configuration data. So no
thread binding needed.
Did I get it right ? (maybe not)
>>>I am thinking to propose use of commons-discovery and a
>>>META-INF/mbeans.xml in modeler - so a jar containing tomcat modules will
>>>include it's onw description, and an easy mechanism to find it.
>>
>>Ok, since you have ideas, feel free to experiment ;-)
>
>
> Sure. Just trying to get feedback and maybe get other people interested.
> So far only 2 people seem interested in 'common-discovery'.
I didn't look at it at all, sorry :-(
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [TODO] Config first task
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Costin Manolache wrote:
...
> Sure. Just trying to get feedback and maybe get other people interested.
> So far only 2 people seem interested in 'common-discovery'.
> I want to use it for an antlib 'experiment', but it would also help
> for tomcat. Something like ant's ProjectHelper hook to plug in
> different jndi config drivers ?
OT: I am. I may use it to make Morphers available to apps. *And* if you
tell me about your Antlib 'experiment', I'd be more than happy :-)
-> switching conversation to private or ant-dev
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [TODO] Config first task
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
>> And internals and 'priviledged' application will get access to the
>> root of this tree, and look up anything configurable or runtime
>> using the 'normal' API - with no tricks with classloader/thread binding.
>
> That's different from the ENC, since here, you can give the component a
> reference to the right context.
That's something I don't understand.
Each app is supposed to get it's own DirContext, using the same name.
And that's done by binding it per thread or class loader.
However this DirContext may also be binded in the 'big tree' - and
internal code could access all those 'enc' contexts.
>> I am thinking to propose use of commons-discovery and a
>> META-INF/mbeans.xml in modeler - so a jar containing tomcat modules will
>> include it's onw description, and an easy mechanism to find it.
>
> Ok, since you have ideas, feel free to experiment ;-)
Sure. Just trying to get feedback and maybe get other people interested.
So far only 2 people seem interested in 'common-discovery'.
I want to use it for an antlib 'experiment', but it would also help
for tomcat. Something like ant's ProjectHelper hook to plug in
different jndi config drivers ?
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [TODO] Config first task
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>>The way I see it, we'll have 2 JNDI 'trees':
>>> - one for 'config data' ( the new one ).
>>> - one for 'runtime data' - including the VFS, various java:env, etc.
>>
>>Yes.
>>
>>I suppose you can take advantage of federation to make a giant big tree.
>
>
> And internals and 'priviledged' application will get access to the
> root of this tree, and look up anything configurable or runtime
> using the 'normal' API - with no tricks with classloader/thread binding.
That's different from the ENC, since here, you can give the component a
reference to the right context.
> One way or another, we need each internal object to be aware of its
> name - and it can cache the DirContexts it needs ( to avoid duplicating
> lookups, etc ).
Obvioulsy. Each component should keep local values also (you can't do a
lookup on each variable access).
>>As I see it, we'll have the JNDI config which will be used by the
>>Catalina objects (like StandardContext) to store their config. The
>>question is do we make those objects the MBeans. I think we can use the
>>modeler to do that easily, instead of having the MBeans be another set
>>of separate objects.
>
>
> I don't think they need to be registered by default, but it is indeed very
> easy to turn them into MBeans via modeler. Probably the same listener
> mechanism can be used ( jndi also has some events to notify of new objects
> and attribute changes - similar with the Lifecyecle and catalina-specific
> events used to registrate the mbeans in the current code ).
>
> We need to have each configurable object into the mbean.xml descriptor,
> which may eventually turn with some magic into an ldap schema.
>
> I am thinking to propose use of commons-discovery and a META-INF/mbeans.xml
> in modeler - so a jar containing tomcat modules will include it's onw
> description, and an easy mechanism to find it.
Ok, since you have ideas, feel free to experiment ;-)
>>>We still need to 'bind' the initial context for each webapp so that
>>>webapps can see their separated envs. But internal code
>>>should have access to the root of the tree, for example stored in
>>>some top-level objects - and be able to access anything with a simple
>>>lookup.
>>
>>For the J2EE ENC, you have to do the binding:
>>- for security reasons, otherwise the webapp could find a way to access
>>another context
>>- because the lookup call is "static" (it's not, but it would be exactly
>>the same if it was), you have no way otherwise to do the lookup in the
>>right context
>
>
> I know ( for webapps ). I was talking about internal and 'priviledged'
> apps, who don't need that. They should be able to access the 'root',
> and shouldn't use the thread binding ( which sometimes is confusing
> and even dangerous )
For the ENC, you still need to return the right context.
Or were you talking about the configuration context (in which case, it's
probably not needed).
> BTW, another idea: what about trying to create a jndi context
> for web.xml ? Then same kind of code that manages server.xml will be able
> to manage web.xml for apps.
Yes, we can also try to reuse it. One thing at a time, please ;-)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [TODO] Config first task
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
>> The way I see it, we'll have 2 JNDI 'trees':
>> - one for 'config data' ( the new one ).
>> - one for 'runtime data' - including the VFS, various java:env, etc.
>
> Yes.
>
> I suppose you can take advantage of federation to make a giant big tree.
And internals and 'priviledged' application will get access to the
root of this tree, and look up anything configurable or runtime
using the 'normal' API - with no tricks with classloader/thread binding.
One way or another, we need each internal object to be aware of its
name - and it can cache the DirContexts it needs ( to avoid duplicating
lookups, etc ).
> As I see it, we'll have the JNDI config which will be used by the
> Catalina objects (like StandardContext) to store their config. The
> question is do we make those objects the MBeans. I think we can use the
> modeler to do that easily, instead of having the MBeans be another set
> of separate objects.
I don't think they need to be registered by default, but it is indeed very
easy to turn them into MBeans via modeler. Probably the same listener
mechanism can be used ( jndi also has some events to notify of new objects
and attribute changes - similar with the Lifecyecle and catalina-specific
events used to registrate the mbeans in the current code ).
We need to have each configurable object into the mbean.xml descriptor,
which may eventually turn with some magic into an ldap schema.
I am thinking to propose use of commons-discovery and a META-INF/mbeans.xml
in modeler - so a jar containing tomcat modules will include it's onw
description, and an easy mechanism to find it.
>> We still need to 'bind' the initial context for each webapp so that
>> webapps can see their separated envs. But internal code
>> should have access to the root of the tree, for example stored in
>> some top-level objects - and be able to access anything with a simple
>> lookup.
>
> For the J2EE ENC, you have to do the binding:
> - for security reasons, otherwise the webapp could find a way to access
> another context
> - because the lookup call is "static" (it's not, but it would be exactly
> the same if it was), you have no way otherwise to do the lookup in the
> right context
I know ( for webapps ). I was talking about internal and 'priviledged'
apps, who don't need that. They should be able to access the 'root',
and shouldn't use the thread binding ( which sometimes is confusing
and even dangerous )
BTW, another idea: what about trying to create a jndi context
for web.xml ? Then same kind of code that manages server.xml will be able
to manage web.xml for apps.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [TODO] Config first task
Posted by Remy Maucherat <re...@apache.org>.
costinm@covalent.net wrote:
> On second tought, it would be excelent if you can map server.xml. The
> only issue I have is the naming hierarcy - but we can address that later.
Ok, I'll do it.
> One thing I hate in the current JNDI code is the binding on thread/class
> loader, etc. I understand what it is supposed to do, but we shouldn't
> have to do that internally.
>
> The way I see it, we'll have 2 JNDI 'trees':
> - one for 'config data' ( the new one ).
> - one for 'runtime data' - including the VFS, various java:env, etc.
Yes.
I suppose you can take advantage of federation to make a giant big tree.
As I see it, we'll have the JNDI config which will be used by the
Catalina objects (like StandardContext) to store their config. The
question is do we make those objects the MBeans. I think we can use the
modeler to do that easily, instead of having the MBeans be another set
of separate objects.
> We still need to 'bind' the initial context for each webapp so that
> webapps can see their separated envs. But internal code
> should have access to the root of the tree, for example stored in
> some top-level objects - and be able to access anything with a simple
> lookup.
For the J2EE ENC, you have to do the binding:
- for security reasons, otherwise the webapp could find a way to access
another context
- because the lookup call is "static" (it's not, but it would be exactly
the same if it was), you have no way otherwise to do the lookup in the
right context
> If we are going to go with the JNDI-based config, than I think it may
> be worth to first clean up and add some more docs to the jndi code
> we have. I know you knows the code very well - but for those with
> less JNDI experience it would help a lot. The binding seems the
> trickiest part, and I can't understand why it is actually needed from
> inside.
Ok.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [TODO] Config first task
Posted by co...@covalent.net.
On second tought, it would be excelent if you can map server.xml. The
only issue I have is the naming hierarcy - but we can address that later.
One thing I hate in the current JNDI code is the binding on thread/class
loader, etc. I understand what it is supposed to do, but we shouldn't
have to do that internally.
The way I see it, we'll have 2 JNDI 'trees':
- one for 'config data' ( the new one ).
- one for 'runtime data' - including the VFS, various java:env, etc.
We still need to 'bind' the initial context for each webapp so that
webapps can see their separated envs. But internal code
should have access to the root of the tree, for example stored in
some top-level objects - and be able to access anything with a simple
lookup.
If we are going to go with the JNDI-based config, than I think it may
be worth to first clean up and add some more docs to the jndi code
we have. I know you knows the code very well - but for those with
less JNDI experience it would help a lot. The binding seems the
trickiest part, and I can't understand why it is actually needed from
inside.
Costin
On Fri, 16 Aug 2002, Remy Maucherat wrote:
> I will bootstrap the new configuration code by writing a DOM based JNDI
> directory context to provide some compatibility with the current server.xml.
>
> I'll start experimenting with the JNDI naming conventions we'll be using
> as I implement the context (obviously, that will happen in the test
> program I'll write).
>
> I'd like to advocate mirroring all changes to the configuration to the
> backend immediately (without the need for a commit as it is done now).
>
> The initial experimental implementation will use:
> - a DOM tree to mirror the XML, and that easily maps to the structure
> - algorithms wise, it is likely to look like the WARDirContext
> - I may use JDOM, as some DOM to XML serialization is needed, and isn't
> provided by JAXP
>
> Note: The only reason why I want to use something like JDOM is for the
> serialization. If someone has ideas about how to do it without JDOM (I'm
> fine with using straight DOM), let me know (I'd like to avoid writing my
> own serialization code if possible, although it could be useful to do so
> for performance reasons).
>
> Remy
>
>
> --
> 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: [5] [TODO] Config first task
Posted by co...@covalent.net.
On Fri, 16 Aug 2002, Remy Maucherat wrote:
> I will bootstrap the new configuration code by writing a DOM based JNDI
> directory context to provide some compatibility with the current server.xml.
Great.
I am not very sure if we should spend too much time preserving the current
server.xml. If it can be done without too many restrictions in the naming
structure - great.
I was thinking to look at one of the existing file-based stores ( XML,
etc).
What's important is to have a well-organised naming hierarchy - the one
used for mbeans is a bit confusing.
> I'll start experimenting with the JNDI naming conventions we'll be using
> as I implement the context (obviously, that will happen in the test
> program I'll write).
The naming convenitons are the critical part. Good luck :-)
> I'd like to advocate mirroring all changes to the configuration to the
> backend immediately (without the need for a commit as it is done now).
>
> The initial experimental implementation will use:
> - a DOM tree to mirror the XML, and that easily maps to the structure
> - algorithms wise, it is likely to look like the WARDirContext
> - I may use JDOM, as some DOM to XML serialization is needed, and isn't
> provided by JAXP
>
> Note: The only reason why I want to use something like JDOM is for the
> serialization. If someone has ideas about how to do it without JDOM (I'm
> fine with using straight DOM), let me know (I'd like to avoid writing my
> own serialization code if possible, although it could be useful to do so
> for performance reasons).
Yes, just use an identity Transformer. It's quite easy - you make a
trasnformation between a DOMSource and a FileDestination.
( make sure you turn on indentation !)
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[5] [TODO] Config first task
Posted by Remy Maucherat <re...@apache.org>.
I will bootstrap the new configuration code by writing a DOM based JNDI
directory context to provide some compatibility with the current server.xml.
I'll start experimenting with the JNDI naming conventions we'll be using
as I implement the context (obviously, that will happen in the test
program I'll write).
I'd like to advocate mirroring all changes to the configuration to the
backend immediately (without the need for a commit as it is done now).
The initial experimental implementation will use:
- a DOM tree to mirror the XML, and that easily maps to the structure
- algorithms wise, it is likely to look like the WARDirContext
- I may use JDOM, as some DOM to XML serialization is needed, and isn't
provided by JAXP
Note: The only reason why I want to use something like JDOM is for the
serialization. If someone has ideas about how to do it without JDOM (I'm
fine with using straight DOM), let me know (I'd like to avoid writing my
own serialization code if possible, although it could be useful to do so
for performance reasons).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] Config
Posted by co...@covalent.net.
On Fri, 16 Aug 2002, Steve Downey wrote:
> > This really seems to pick the best APIs for the job.
> > It's a good idea to use JNDI for configuration storing indeed, as it
> > allows enterprise scale deployments, and seems generally better suited
> > than JMX.
> >
> > Remy
> >
> >
> To the extent that JNDI and JMX do the jobs they were designed for, it
> makes perfect sense. JNDI is all about locating and retrieving data by
> name. JMX is mostly a runtime mechanism for component management.
JMX has almost no support for storing the data ( the load/store are not
even close to a real API like JNDI or prefs ).
The real question for storage was JNDI or prefs - with prefs beeing a bit
simpler. But I think as an API JNDI is far more powerfull and not
that complex ( for simple tasks it is simple ). And it works in any
VM ( including 1.1 ), is mature, etc.
Both JMX and JNDI are about names and attributes. But JMX is very
specialized to runtime.
We could use JNDI for runtime API - it does have this flexibility -
either as a wrapper on top of JMX or doing direct introspection.
It is already used to store 'life' objects ( the java:env ), and
it's not hard to extend it to support setAttribute() and operate
like any DirContext on runtime objects.
But it has no support for operations, and JMX has
various unique features ( like SNMP, the HTTP adapter, etc ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] Config
Posted by Steve Downey <st...@netfolio.com>.
>
>
>> <SNIP/>
>>
>> What do you think ?
>
>
> I love it :)
>
> This really seems to pick the best APIs for the job.
> It's a good idea to use JNDI for configuration storing indeed, as it
> allows enterprise scale deployments, and seems generally better suited
> than JMX.
>
> Remy
>
>
To the extent that JNDI and JMX do the jobs they were designed for, it
makes perfect sense. JNDI is all about locating and retrieving data by
name. JMX is mostly a runtime mechanism for component management.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] Config
Posted by Remy Maucherat <re...@apache.org>.
cmanolache@yahoo.com wrote:
> After a lot of thinking and searching, I found a solution that
> I think will work well. If you like it - I'll need some help from
> Remy to implement it. If you don't like it - I'm waiting for
> a better one...
>
> There are 3 major parts:
> 1. Config storage. Currently that's server.xml.
> 2. Configuring various components ( runtime config, init, etc ).
> That's done using digester/introspection in 4.x ( init ) and JMX ( at
> runtime )
> 3. Saving config. That's done via introspecting life objects
> and generating server.xml in 4.x
>
> What I'm proposing is a pluggable config storage, using JNDI API
> for storage and JMX ( and introspection ) for runtime changes.
>
> For API - my initial approach was to create a clone of 1.4 prefs.
> I think a much better solution is to use JNDI as API.
>
> We already depend on JNDI, and JNDI is available to all VMs -
> including in GCJ, kaffe. The interface is mature, flexible and
> well known. In addition it is very easy to create wrappers to
> jdk1.4 prefs and back - so both 'flavors' can be used.
>
> The data will be organized to follow the JMX naming hierarchy
> ( after reorganizing the naming schema ): each tomcat component
> that is configurable will have a JMX name and associated attributes,
> and those will be stored in the directory. An ObjectName will be
> a jndi Name.
>
> We'll automatically gain access to all 'stores' that jndi supports -
> ldap, directory servers, etc. There are also file providers implementing
> standard xml formats ( or ldif ?). An additional format to support
> may be the jboss-style <mbean> - which may be syntactically closer
> to the jmx-based runtime.
>
> The second layer will be a wrapper that can use either introspection
> or JMX, possibly an extension of modeler.
>
> We'll have a clear distinction between 'persistent' config and
> 'runtime' config. JMX was not designed for storage ( even if it
> has the optional load/store methods ), and it is useful to be
> able to choose between making changes in the running server
> ( some may be temporary ) and making changes in the persistent
> store.
> Using notifications it is possible to propagate any change via
> JMX to the store - but that should be optional ( i.e. you could
> choose to not change the store, but only the runtime ).
>
> Any operation ( reload, etc ) will be done via JMX - only
> setting attributes is important for config.
>
> It is possible to also use DirContext to represent 'life'
> objects - and use the same API to set attributes on the
> persistent and life sub-trees. ( with JMX or introspection
> underneath ).
>
> There are few (major) issues with JMX - I don't know how
> well it will scale, giving the huge number of objects it involves.
> One way to solve this is to use mx4j internals - for example
> to delay some of the introspection, optimize some
> lookups, etc. Right now the JNDI model seems better
> suited for a large number of objects ( if we start
> representing each servlet as an mbean - for example
> to collect time information ). But overall JMX is
> the right way to go about configuring and operating
> on live objects, and JNDI is (IMO) the right way to
> go about storing hierarchical and config data.
>
>
> What do you think ?
I love it :)
This really seems to pick the best APIs for the job.
It's a good idea to use JNDI for configuration storing indeed, as it
allows enterprise scale deployments, and seems generally better suited
than JMX.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] Config
Posted by Costin Manolache <cm...@yahoo.com>.
Craig R. McClanahan wrote:
> (Breathing a sigh of relief that I don't actually have to *implement* this
> stuff, but hoping to contribute a little anyway :-)
Well, the fact that I don't have to implement much is a relief for me too...
Both the API and a lot of drivers ( including xml file ) are already
written, we have a lot of support ( caching, etc ) already and Remy is an
expert.
>> For API - my initial approach was to create a clone of 1.4 prefs.
>
> Thinking outside the box a little, what would be the implications of
> prereq'ing JDK 1.4 as the minimum for Tomcat 5? Then, we could consider
> using prefs directly instead of via wrappers.
The reason I prefer JNDI over prefs have nothing to do with the VM.
JNDI is much more mature, more widely used, more powerfull, we
already have a lot of support and knowledge, there are many drivers.
And it supports the 'distributed / high-end' use case ( directory
server ) out-of-box.
I don't mind having prefs used by default if 1.4 is detected -
i.e. registry on windows and .xml files on unix. It is quite
easy to write a JNDI context that uses prefs underneath.
I don't mind using 1.4 features - but using 1.4 as a minimm is
a bit too much. Even 1.3 may be questionable.
For me the baseline is what GCJ supports ( i.e. the classpath project ).
I still believe in 'java everywhere' :-)
> Using DirContext instead of just Context would also let us think about a
> storage format with fewer objects in it -- one per managed object instead
> of one per property -- because we could use JNDI attributes for the
> individual properties themselves. Such an entry maps pretty directly to
> *being* an MBean as well ... it might be possible to kill two birds with
> one stone here.
Exactly ! And one nice thing in JNDI is that we can do a lot of 'lazy'
evaluation. If nobody is going to configure an object, there is no
point introspecting it. Just bind it to a context and when someone
asks for attributes we do the introspection. And you can also
construct objects dynamically - which is even better.
JMX will require you to register each object and most implementations
will do a full introspection when you register. And that involves a lot
of objects and overhead.
> Some utility methods that perform direct conversion between the structured
> name types would be well worth it performance-wise. We don't want to be
> dealing with the String versions of these names any more than we'd have
> to.
+1
The jndi Name is not bad. And it maps well into JMX ObjectName.
>> Using notifications it is possible to propagate any change via
>> JMX to the store - but that should be optional ( i.e. you could
>> choose to not change the store, but only the runtime ).
>>
>
> Note that this would need to include configuration changes the component
> does for itself (i.e. calculate the work directory path if one hasn't been
> explicitly configured), not just those performed by external management
> tools.
I don't agree. The configuration is what the user specifies. What the
component determines by itself shouldn't slip into the config file.
Only user-initiated config must be stored ( exactly like if the user would
edit the file directly and restart ).
>> Any operation ( reload, etc ) will be done via JMX - only
>> setting attributes is important for config.
>>
>
> While on that topic, it would be useful for some managed objects to
> support two "instances" of a component in memory simultaneously -- for
> example, when upgrading a webapp you often want to leave the old version
> running (and accepting requests) until the new version has been fully
> initialized and is ready to start accepting requests.
Probably a 'ver' component in the name ?
We really need to reorganize the JMX names.
> Part of the motivation for JMX in the first place was to support the
> ability to have external management apps be able to talk with it. If we
> didn't need that, we wouldn't really need it -- we could just use JNDI to
> represent the internal component hierarchy (extending the way Catalina
> already represents a webapp's static resources as a JNDI context).
I know. JMX is also necesary to support 'operations' ( reload, start, etc ).
But the nice thing about using JNDI as the 'first line' is that JMX can
be used with less performance impact. For example we can have a 'master'
jmx object that would register other on demand - using the information
in the JNDI hierarchy.
> One avenue to consider if the number of MBeans becomes an issue (I'm not
> sure that it really is -- we've got an instance of the real component
> class per component anyway) is to make MBeans only for coarse grained
> things, and represent fine-grained things as attributes of the coarse
> grained MBeans. Conceptually, this is the same sort of design choice you
> make with entity EJBs about how fine grained you get. It's not
> necessarily an all-or-nothing decision.
Well, on MBean per servlet is important if you want statistical data
( times, number of request, etc). And that's quite usefull.
One MBean per user is unacceptable if you are a big organization ( with
thousands of users)
Again, JNDI was designed to deal with this kind of situations - a directory
server may store/manipulate large ammounts of data. And we would only
'bind it' - i.e. store the real object in a hashtable, and create the MBeans
only on demand. Probably that would require special attention to the master
MBean that would find and dynamically create other mbeans.
As a note, representing the 'user' as just a DirContext with some attributes
we care about can also simplify the user management and make the code more
generic and flexible.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] Config
Posted by "Craig R. McClanahan" <cr...@apache.org>.
(Breathing a sigh of relief that I don't actually have to *implement* this
stuff, but hoping to contribute a little anyway :-)
On Thu, 15 Aug 2002 cmanolache@yahoo.com wrote:
> Date: Thu, 15 Aug 2002 15:50:00 -0700 (PDT)
> From: cmanolache@yahoo.com
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: List Tomcat-Dev <to...@jakarta.apache.org>
> Subject: [5] Config
>
> After a lot of thinking and searching, I found a solution that
> I think will work well. If you like it - I'll need some help from
> Remy to implement it. If you don't like it - I'm waiting for
> a better one...
>
> There are 3 major parts:
> 1. Config storage. Currently that's server.xml.
> 2. Configuring various components ( runtime config, init, etc ).
> That's done using digester/introspection in 4.x ( init ) and JMX ( at
> runtime )
> 3. Saving config. That's done via introspecting life objects
> and generating server.xml in 4.x
>
> What I'm proposing is a pluggable config storage, using JNDI API
> for storage and JMX ( and introspection ) for runtime changes.
>
> For API - my initial approach was to create a clone of 1.4 prefs.
Thinking outside the box a little, what would be the implications of
prereq'ing JDK 1.4 as the minimum for Tomcat 5? Then, we could consider
using prefs directly instead of via wrappers.
> I think a much better solution is to use JNDI as API.
>
> We already depend on JNDI, and JNDI is available to all VMs -
> including in GCJ, kaffe. The interface is mature, flexible and
> well known. In addition it is very easy to create wrappers to
> jdk1.4 prefs and back - so both 'flavors' can be used.
>
Using DirContext instead of just Context would also let us think about a
storage format with fewer objects in it -- one per managed object instead
of one per property -- because we could use JNDI attributes for the
individual properties themselves. Such an entry maps pretty directly to
*being* an MBean as well ... it might be possible to kill two birds with
one stone here.
> The data will be organized to follow the JMX naming hierarchy
> ( after reorganizing the naming schema ): each tomcat component
> that is configurable will have a JMX name and associated attributes,
> and those will be stored in the directory. An ObjectName will be
> a jndi Name.
Some utility methods that perform direct conversion between the structured
name types would be well worth it performance-wise. We don't want to be
dealing with the String versions of these names any more than we'd have
to.
>
> We'll automatically gain access to all 'stores' that jndi supports -
> ldap, directory servers, etc. There are also file providers implementing
> standard xml formats ( or ldif ?). An additional format to support
> may be the jboss-style <mbean> - which may be syntactically closer
> to the jmx-based runtime.
>
> The second layer will be a wrapper that can use either introspection
> or JMX, possibly an extension of modeler.
>
> We'll have a clear distinction between 'persistent' config and
> 'runtime' config. JMX was not designed for storage ( even if it
> has the optional load/store methods ), and it is useful to be
> able to choose between making changes in the running server
> ( some may be temporary ) and making changes in the persistent
> store.
> Using notifications it is possible to propagate any change via
> JMX to the store - but that should be optional ( i.e. you could
> choose to not change the store, but only the runtime ).
>
Note that this would need to include configuration changes the component
does for itself (i.e. calculate the work directory path if one hasn't been
explicitly configured), not just those performed by external management
tools.
> Any operation ( reload, etc ) will be done via JMX - only
> setting attributes is important for config.
>
While on that topic, it would be useful for some managed objects to
support two "instances" of a component in memory simultaneously -- for
example, when upgrading a webapp you often want to leave the old version
running (and accepting requests) until the new version has been fully
initialized and is ready to start accepting requests.
> It is possible to also use DirContext to represent 'life'
> objects - and use the same API to set attributes on the
> persistent and life sub-trees. ( with JMX or introspection
> underneath ).
>
Yep :-)
> There are few (major) issues with JMX - I don't know how
> well it will scale, giving the huge number of objects it involves.
> One way to solve this is to use mx4j internals - for example
> to delay some of the introspection, optimize some
> lookups, etc. Right now the JNDI model seems better
> suited for a large number of objects ( if we start
> representing each servlet as an mbean - for example
> to collect time information ). But overall JMX is
> the right way to go about configuring and operating
> on live objects, and JNDI is (IMO) the right way to
> go about storing hierarchical and config data.
>
Part of the motivation for JMX in the first place was to support the
ability to have external management apps be able to talk with it. If we
didn't need that, we wouldn't really need it -- we could just use JNDI to
represent the internal component hierarchy (extending the way Catalina
already represents a webapp's static resources as a JNDI context).
One avenue to consider if the number of MBeans becomes an issue (I'm not
sure that it really is -- we've got an instance of the real component
class per component anyway) is to make MBeans only for coarse grained
things, and represent fine-grained things as attributes of the coarse
grained MBeans. Conceptually, this is the same sort of design choice you
make with entity EJBs about how fine grained you get. It's not
necessarily an all-or-nothing decision.
>
> What do you think ?
>
> Costin
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>