Sorry for the late reply, I had no mail for few days. Jeanfrancois Arcand wrote:
>>1. Add a new plugins/ directory. All tomcat components will eventually >>be migrated from server/lib and common/lib into one of the plugins >>subdirectories. ( it can be called modules/ or something else ). >> > +1. For security reason, we should have a way to protect the module > (using Remy's catalina.property mechanism). We should have trusted > components as well as untrusted. I agree. Plugins should replace .jar files that are placed into server/lib and common/lib - and the same mechansims would apply. Each plugin should be able to define what goes into server/lib loader, what goes into common/lib loader, eventually and additional class loader to keep it's implementation isolated. And also set options on the class loaders - the module initialization ( in the mbean register callback ) can call tomcat APIs and set whatever it needs, register for hooks, etc ( similar with apache2 modules init() ). > What about Xerces? It's a kind of pluging but it is also and endorsed > lib. We need to keep the endorsed folder/mechanism I think this is a special case, and we'll have to keep it separated. Note that xerces itself is not a problem - the jaxp. classes are the ones needing endorsed. We could leave xerces as a module and have only xmlParserApis special. >>3. The format of a plugin. We should support at least .war ( tomcat >>already have all the code ). I don't see a need for a format that >>is very different, but we (may) need to add an additional XML file. >>We should also be able to support a .jar format ( maybe with an >>additional .xml descriptor in META-INF ) as well as .xml descriptors >>in the plugin directory. >> > I recommend keeping war file for web applications, and use jar as the > standard module/component. In module implements a common interface for > identifying themself, I recommend we don't add another xml file but use > introspection to discover the module functionalities etc. By using WAR I meant reusing the current infrastructure and possibly the layout.( for example reloading plugins may be very interesting :-). The standard manifest and the META-INF/services should be enough to identify the services - but we will need mbeans.xml ( for modeler ) and probably an mlet-style config to define the classloaders or options. I agree we shouldn't add ( if possible ) any new xml dtd, there are more then enough already :-) I think the existing ( standard or already used ) mlet, mbeans.xml, services provide all the meta info we need. >>6. Each classloader in tomcat will be ( or have ) a MBean. Different >>plugins can define new classloaders ( by using an mbean declaration ) >>or add jars to existing classloaders ( in particular the server, >>common and individual webapp loaders ). >> > We should define a contract between Tomcat and the plugins which force > the plugin-defined classloader to be "secure" (at least do the package > protection check). Maybe plugin-defined classloader should extend some > catalina classes in order to fullfill the contract. By defining the classloader - I meant more declarative definition. The plugin can instantiate a tomcat mbean for the loader ( we should have an mbean associated with the tomcat loader anyway ), or just use the <classpath> in the mlet. If the plugin decides to create its own loader - he probably knows what it's doing, but I hope that won't happen too often. > If a component doesn't have an MBean, we should have a mechanism to > generate, using introspection, that MBean. We doesn't need that soon, > but we you keep the idea in mind... We already have that. Modeler. Works very nice :-) >>8. Tomcat should work with no config file - using only JMX API calls >>to load it and configure a set of plugins ( profile ), using whatever >>class loader and layout the embeding application ( ant, etc ) wants. >> > Questions: Are we considering a Valve as a module/component? And it is > not clear in your proposal if we are keeping the server.xml file. I > recommend we keep it just to avoid confusion (IMBW...we should have a > pool to determine if users like server.xml :-) ). My proposal has nothing to do with server.xml or Valves or any other hook mechanism. It's about layout ( plugins/ or modules/ ) and how the modules are registered in tomcat ( using Mbean registration and nothing else ). How the modules are deployed ( using a dowload target or a full distribution and a command to remove some or anything else ) is also a separate issue. In general - I think server.xml should work ( backward compat at least), but we should also work on a different config file that is more friendly to editing and JMX config. I preffer using mlet-like style - it is very simple, standard ( or slightly extended :-), easy to generate. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
