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