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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
