tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cost...@covalent.net>
Subject RE: Connector compatibility between TC 4.0 and 4.1
Date Thu, 27 Dec 2001 00:04:21 GMT
On Fri, 21 Dec 2001, Craig R. McClanahan wrote:

> As appealing an idea as this sounds (packaging plug-in modules as
> webapps), it doesn't solve the underlying issue -- different containers
> have radically different internal architectures, and packaging the plug-in
> as webapp doesn't avoid having to deal with that.  You still have to
> bridge the architectural differences for "installing" the plug-in
> functionality in the container, using container-specific APIs.

Except that 'packaging' of the module doesn't even try to solve that
problem ( of different internal architectures, etc).

The problem it tries to solve is simplifing the live of the user, who will
use the ( hopefully ) simple pattern of deploying and configuring web
applications.

If a container's architecture allow certain functionality ( whatever that
is ) - we'll try to take advantage of it, and make the connector aware of
it. If not - then that feature will not be available on that container. We
don't try to create a common API or a meta architecture - just to take
advantage of the maximum set of APIs and features a container provides.


> To be successful at bridging this gap, you've really only got a couple of
> choices:

> * Create an external common API for things that are not architecture
>   dependent (like web connectors) that a container can choose to
>   support or not support, and don't bother trying to standardize
>   things that are radically different between architectures (for
>   example, RequestInterceptor vs. Valve, or the very different
>   concepts of how the core components of the container are organized).

That assumes the container should ( or should not ) support a particular
API or connector.

IMHO the connector is a module that should support different containers by
using their APIs.

It's unlikely IIS or iPlanet will start supporting jk. And I see no reason
for 3.3 ( for example ) to be changed to support whatever internal API the
connector will use on the java side.

On the other side, jk should try to use whatever API the web server ( on
one side ) and servlet container ( on the other ) provides. If certain
things are possible only with Apache2 ( like dynamic configuration of the
server using the cfgtree ) or a container - we should use them in that
particular case. If not - we can either try to provide a workaround or
just document that this feature is available only with a particular
configuration.


> * Create a meta-architecture (via a set of common APIs) that all
>   containers must support -- never mind that it might mandate doing
>   things in a totally different way than any existing container.

Again something that wouldn't make sense - the role of the module is to
augment the functionality, not to dicatate a particular API or model.


> IMHO, the latter option is not practical.  Packaging plug-in functionality
> as a web app does nothing to help resolve the basic issue that containers
> are different on the inside.  And, if you went to the effort to do this,
> you'd spend your time more efficiently by just creating a container
> conforming to those APIs and be done with it.

Packaging the plug-in as a webapp doesn't try to resolve that problem !
Containers and web server are different on the inside, and that's not even
something bad or a 'problem' that needs to be solved.

Packaging the plugin as a webapp is intended for the users deploying or
using plug-ins - if a particular plugin has support for a container, than
the user's experience will be consistent ( not the complete set of
features the plugin can provide - that depends on the container's
architecture - but the basic functionality and problem the plugin is
supposed to solve ).

> Oh wait ... we've already done that ... twice :-).  That seems entirely
> sufficient to me.

I think it have been done few dozen times - and there's still plenty of
space for improvements :-)

Costin


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message