You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2002/08/16 21:43:38 UTC
[5] [TODO] Config first task
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] [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>