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