Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 89109 invoked from network); 16 Aug 2002 22:51:02 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 16 Aug 2002 22:51:02 -0000 Received: (qmail 23660 invoked by uid 97); 16 Aug 2002 22:51:28 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 23618 invoked by uid 97); 16 Aug 2002 22:51:27 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 23605 invoked by uid 98); 16 Aug 2002 22:51:27 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: costinm.sfo.covalent.net: costin owned process doing -bs Date: Fri, 16 Aug 2002 15:47:01 -0700 (PDT) From: costinm@covalent.net X-X-Sender: costin@costinm.sfo.covalent.net To: Tomcat Developers List Subject: Re: [5] [TODO] Config first task In-Reply-To: <3D5D55EA.90205@apache.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: