Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
To: tomcat-dev@jakarta.apache.org
Path: not-for-mail
From: Costin Manolache <cmanolache@yahoo.com>
Subject: Re: [PROPOSAL][TOMCAT5] plugins directory
Date: Mon, 16 Dec 2002 21:30:42 -0800
Lines: 107
Message-ID: <atmd5r$22h$1@main.gmane.org>
References: <atdlvt$lm7$1@main.gmane.org> <3DFDE943.4080204@apache.org>
NNTP-Posting-Host: ca-thoaks-docsis-cmtsc-b-203.vnnyca.adelphia.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
NNTP-Posting-Date: Tue, 17 Dec 2002 05:36:59 +0000 (UTC)
User-Agent: KNode/0.7.1
Sender: news <news@main.gmane.org>

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:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>