RE: Connector compatibility between TC 4.0 and 4.1

[costinm]

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:   
For additional commands, e-mail: 

RE: Connector compatibility between TC 4.0 and 4.1

[Craig R. McClanahan]

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.

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).

* 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.

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.

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

Craig




On Fri, 21 Dec 2001 [EMAIL PROTECTED] wrote:

> Date: Fri, 21 Dec 2001 11:34:57 -0800 (PST)
> From: [EMAIL PROTECTED]
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: RE: Connector compatibility between TC 4.0 and 4.1
>
> On Fri, 21 Dec 2001, Kevin Seguin wrote:
>
> > > My thinking ( for 4.1/3.3 ) was to have j-t-c built as a
> > > 'standalone module', a trusted/priviledged webapp that can be
> > > deployed and
> > > is self-contained.
> > >
> >
> > can you provide some more detail?  i'm quite interested in learning more.
>
> It's quite simple - the idea is to 'package' tomcat modules ( i.e.
> anything providing additional functionality ) as 'plain' WAR files.
>
> Why ? Many good reasons:
>
> - reuse - all the infrastructure for webapps will apply to modules as
> well. With a bit of work we can get dynamic module loading/reloading,
> deployment ( including 'hot' ) etc. Even setting module properties will
> benefit from the UI for web.xml admin ( i.e. most config can be done
> using Context attributes in web.xml ).
>
> - self-contained and well defined environment for modules. We'll know
> that the directory structure on deployment will be clear, we can call
> getRealPath(/) and know where all our files are located. That's container
> independent, etc.
> ( I assume modules will be 'expanded' - that's a requirement, as we'll
> use the directory structure to generate configs, etc)
>
> - a lot of the module can be implemented as plain servlet/jsp. Like
> 'seeing' jk status, logs, etc. Again, everything is self-contained and
> have a defined structure ( like in a webapp )
>
> - the original reason for doing that ( in 3.3 ) was simplifying the code.
> We wanted 3.3 to be as simple as possible, with a minimal core providing
> the 'referenece implementation' part and nothing else, and have all the
> 'features' implemented as optional modules. That's what the 'modules/'
> directory is for. 3.3 does have all the features from 3.2.x, but we tried
> to not add anything else - any feature should be provided as a module.
>
> - of course, the build environment and everything else becomes more
> 'faimiliar' for people. It's a webapp that happens to implement and use
> one extra API ( or few APIs ) to interface with the container.
> It's no different from a webapp that is using diferent parsers or
> databases. The only 'special' thing is that our webapp can affect the
> container behavior ( exacly like /admin or /manager ).
>
> The only problem is making the 'webapp' usable on multiple containers (
> that support the concept ). This is quite painfull for 4.x ( including 4.1
> ), because in order to access the internals you need to implement an
> interface on a servlet ( and that will not load in 3.3 ). But I think
> there are some ( maybe ugly ) ways to get around this.
>
> Again, in a webapp that does database access or xml you want to be able to
> support multiple 'drivers' - a module doing authentication will also have
> 'drivers' for different servlet containers, same for jk.
>
> Costin
>
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Connector compatibility between TC 4.0 and 4.1

[costinm]

On Fri, 21 Dec 2001, Kevin Seguin wrote:

> > My thinking ( for 4.1/3.3 ) was to have j-t-c built as a
> > 'standalone module', a trusted/priviledged webapp that can be
> > deployed and
> > is self-contained.
> >
>
> can you provide some more detail?  i'm quite interested in learning more.

It's quite simple - the idea is to 'package' tomcat modules ( i.e.
anything providing additional functionality ) as 'plain' WAR files.

Why ? Many good reasons:

- reuse - all the infrastructure for webapps will apply to modules as
well. With a bit of work we can get dynamic module loading/reloading,
deployment ( including 'hot' ) etc. Even setting module properties will
benefit from the UI for web.xml admin ( i.e. most config can be done
using Context attributes in web.xml ).

- self-contained and well defined environment for modules. We'll know
that the directory structure on deployment will be clear, we can call
getRealPath(/) and know where all our files are located. That's container
independent, etc.
( I assume modules will be 'expanded' - that's a requirement, as we'll
use the directory structure to generate configs, etc)

- a lot of the module can be implemented as plain servlet/jsp. Like
'seeing' jk status, logs, etc. Again, everything is self-contained and
have a defined structure ( like in a webapp )

- the original reason for doing that ( in 3.3 ) was simplifying the code.
We wanted 3.3 to be as simple as possible, with a minimal core providing
the 'referenece implementation' part and nothing else, and have all the
'features' implemented as optional modules. That's what the 'modules/'
directory is for. 3.3 does have all the features from 3.2.x, but we tried
to not add anything else - any feature should be provided as a module.

- of course, the build environment and everything else becomes more
'faimiliar' for people. It's a webapp that happens to implement and use
one extra API ( or few APIs ) to interface with the container.
It's no different from a webapp that is using diferent parsers or
databases. The only 'special' thing is that our webapp can affect the
container behavior ( exacly like /admin or /manager ).

The only problem is making the 'webapp' usable on multiple containers (
that support the concept ). This is quite painfull for 4.x ( including 4.1
), because in order to access the internals you need to implement an
interface on a servlet ( and that will not load in 3.3 ). But I think
there are some ( maybe ugly ) ways to get around this.

Again, in a webapp that does database access or xml you want to be able to
support multiple 'drivers' - a module doing authentication will also have
'drivers' for different servlet containers, same for jk.

Costin




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Connector compatibility between TC 4.0 and 4.1

[Kevin Seguin]

> My thinking ( for 4.1/3.3 ) was to have j-t-c built as a
> 'standalone module', a trusted/priviledged webapp that can be 
> deployed and
> is self-contained.
> 

can you provide some more detail?  i'm quite interested in learning more.

thanks,
-kevin.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Connector compatibility between TC 4.0 and 4.1

[GOMEZ Henri]

>The standalone connector (at least the future version of it) 
>for TC 4.x is
>also in j-t-c, 

Do you speak of coyote or jk2 ?

>and I'd like it to work with both versions of 
>TC with only
>one codebase. Why ? It saves time, and that also avoid mistakes (like
>forgetting to apply a patch on one of the versions).
>
>This connector would then be optional with TC 4.0.x (use it if you need
>better performance), and would be the default in the next 4.x 
>release (if of
>course, it turns out it's better than the current one).


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Connector compatibility between TC 4.0 and 4.1

[costinm]

On Thu, 20 Dec 2001, Paul Speed wrote:

> > My thinking ( for 4.1/3.3 ) was to have j-t-c built as a
> > 'standalone module', a trusted/priviledged webapp that can be deployed and
> > is self-contained.
> >
> > Keeping all container adapters in j-t-c has the extra benefit that we can
> > share more code among them.
>
> It still feels wierd to me.  Imagine if JNDI did things this way...
> we'd have to have every provider installed just to build it. :)

JNDI is an API.

j-t-c is a provider - it implements the 'connection' between web server
and servlet container.

It has a 'common' part, and pieces that are specific to the different
containers and servers it supports.

Those 'adapters' are supposed to be small and simple. They are not, and
one of the things I'm trying to do in jk2 is to fix that. I'm talking
about both the java and the c side.


> I think if the layer of abstraction is at the right point you can
> get a compromise between code reuse and modularity.  Otherwise, since
> the container adapters are in a different module than the containers
> themselves, there are always going to be cases where container
> improvements break the connector build.  This is because they are
> tagged differently, etc..

Tomcat3.3 and 4.0 are supposed to be frozen at API level. If a documented
API no longer works, that's a bug in the container.

BTW, we have container adapters but also server adapters - I see no reason
to treat them differently ( and I doubt the IIS adapter will be included
in iis sources :-).

Moving the adapters would require a stable API for jk - wich I don't
think we'll have until jk2 is completed. Using the jk1 API will be a
mistake IMHO ( if you consider the Ajp13 and Ajp13Packet as an API ).



> Right now it seems to be structured that j-t-c is the application
> and the containers are its libraries.  It seems like it should

j-t-c is structured ( at least try to do ) as a provider ( or driver,
add-on, whatever) for each container. It supports multiple servers,
multiple containers - and I think it's normal for it to depend on them,
and not the other way around.

> > For the current release - I don't think we should move the code.
> > For jk2 - I also think we should wait until it's in a more concrete shape.
>
> So are you saying that the dependencies should be restructured as
> discussed above, but just not yet?

I think we should keep the current model until things are stable.

I see no problem with some containers having the 'jk adapter' built-in,
or with jk having a container adapter.

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Connector compatibility between TC 4.0 and 4.1

[Remy Maucherat]

> On Thu, 20 Dec 2001, Remy Maucherat wrote:
>
> > Hi,
> >
> > After a lot of efforts, it turns out the connectors (in j-t-c) still
can't
> > be compiled against both the 4.0 branch and the HEAD branch of the
Tomcat
> > CVS.
> >
> > There are a few solutions to this:
> >
> > 1) Force the connectors to be built against the HEAD branch. They should
run
> > fine on Tomcat 4.0 (although that needs some testing).
>
> If we add void setFactory(org.apache.catalina.ServerSocketFactory $1),
> then it'll be impossible to build it against 4.0.
>
> If we don't - it's impossible to build against 4.1.
>
> > 2) The main problem is the move of the ServerSocketFactory interface
from
> > o.a.c.net to o.a.c. We could revert that change, and fixing the rest is
> > extremely simple.
>
> That's the only solution AFAIK.

The proposal was heavily weigthed towards 2), since I think it's the only
acceptable solution.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Connector compatibility between TC 4.0 and 4.1

[Remy Maucherat]

> [EMAIL PROTECTED] wrote:
> >
> > Keeping all container adapters in j-t-c has the extra benefit that we
can
> > share more code among them.
>
> It still feels wierd to me.  Imagine if JNDI did things this way...
> we'd have to have every provider installed just to build it. :)
>
> I think if the layer of abstraction is at the right point you can
> get a compromise between code reuse and modularity.  Otherwise, since
> the container adapters are in a different module than the containers
> themselves, there are always going to be cases where container
> improvements break the connector build.  This is because they are
> tagged differently, etc..
>
> Right now it seems to be structured that j-t-c is the application
> and the containers are its libraries.  It seems like it should
> really be the other way around.  But that's just my non-committer
> $0.02.  And I run Tomcat stand-alone anyway... the engineer in me
> just had to say something. :)

The standalone connector (at least the future version of it) for TC 4.x is
also in j-t-c, and I'd like it to work with both versions of TC with only
one codebase. Why ? It saves time, and that also avoid mistakes (like
forgetting to apply a patch on one of the versions).

This connector would then be optional with TC 4.0.x (use it if you need
better performance), and would be the default in the next 4.x release (if of
course, it turns out it's better than the current one).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Connector compatibility between TC 4.0 and 4.1

[Paul Speed]

[EMAIL PROTECTED] wrote:
> 
> On Thu, 20 Dec 2001, Kevin Seguin wrote:
> 
> > perhaps now is the time to do some rethinking of where the connectors for
> > each serlvet container live.
> >
> > today, in j-t-c, there is the framework (for lack of a better word) for
> > connectors plus the individual connectors or adapters for tomcat 3 and
> > tomcat 4.
> >
> > personally, i think it would be better to have the individual
> > connectors/adapters live with the servlet container itself.  i.e. put the
> > ajp13 connector for tomcat 4 in the jakarta-tomcat-4.0 source tree.  this
> > way, j-t-c can build without having dependencies on any servlet containers,
> > and servlet containers that want to provide connectors that make use of
> > j-t-c can (optionally) depend on j-t-c.
> 
> My thinking ( for 4.1/3.3 ) was to have j-t-c built as a
> 'standalone module', a trusted/priviledged webapp that can be deployed and
> is self-contained.
> 
> Keeping all container adapters in j-t-c has the extra benefit that we can
> share more code among them. 

It still feels wierd to me.  Imagine if JNDI did things this way...
we'd have to have every provider installed just to build it. :)

I think if the layer of abstraction is at the right point you can
get a compromise between code reuse and modularity.  Otherwise, since
the container adapters are in a different module than the containers
themselves, there are always going to be cases where container 
improvements break the connector build.  This is because they are
tagged differently, etc..

Right now it seems to be structured that j-t-c is the application
and the containers are its libraries.  It seems like it should
really be the other way around.  But that's just my non-committer
$0.02.  And I run Tomcat stand-alone anyway... the engineer in me
just had to say something. :)

> And the build changes I'm trying to make
> should simplify building for all or just individual containers.
> 
> For the current release - I don't think we should move the code.
> For jk2 - I also think we should wait until it's in a more concrete shape.

So are you saying that the dependencies should be restructured as
discussed above, but just not yet?

-Paul

> 
> Costin
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Connector compatibility between TC 4.0 and 4.1

[costinm]

On Thu, 20 Dec 2001, Remy Maucherat wrote:

> Hi,
>
> After a lot of efforts, it turns out the connectors (in j-t-c) still can't
> be compiled against both the 4.0 branch and the HEAD branch of the Tomcat
> CVS.
>
> There are a few solutions to this:
>
> 1) Force the connectors to be built against the HEAD branch. They should run
> fine on Tomcat 4.0 (although that needs some testing).

If we add void setFactory(org.apache.catalina.ServerSocketFactory $1),
then it'll be impossible to build it against 4.0.

If we don't - it's impossible to build against 4.1.

> 2) The main problem is the move of the ServerSocketFactory interface from
> o.a.c.net to o.a.c. We could revert that change, and fixing the rest is
> extremely simple.

That's the only solution AFAIK.

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Connector compatibility between TC 4.0 and 4.1

[costinm]

On Thu, 20 Dec 2001, Kevin Seguin wrote:

> perhaps now is the time to do some rethinking of where the connectors for
> each serlvet container live.
>
> today, in j-t-c, there is the framework (for lack of a better word) for
> connectors plus the individual connectors or adapters for tomcat 3 and
> tomcat 4.
>
> personally, i think it would be better to have the individual
> connectors/adapters live with the servlet container itself.  i.e. put the
> ajp13 connector for tomcat 4 in the jakarta-tomcat-4.0 source tree.  this
> way, j-t-c can build without having dependencies on any servlet containers,
> and servlet containers that want to provide connectors that make use of
> j-t-c can (optionally) depend on j-t-c.

My thinking ( for 4.1/3.3 ) was to have j-t-c built as a
'standalone module', a trusted/priviledged webapp that can be deployed and
is self-contained.

Keeping all container adapters in j-t-c has the extra benefit that we can
share more code among them. And the build changes I'm trying to make
should simplify building for all or just individual containers.

For the current release - I don't think we should move the code.
For jk2 - I also think we should wait until it's in a more concrete shape.

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Connector compatibility between TC 4.0 and 4.1

[Kevin Seguin]

> 
> Hi,
> 
> After a lot of efforts, it turns out the connectors (in 
> j-t-c) still can't
> be compiled against both the 4.0 branch and the HEAD branch 
> of the Tomcat
> CVS.
> 
> There are a few solutions to this:
> 
> 1) Force the connectors to be built against the HEAD branch. 
> They should run
> fine on Tomcat 4.0 (although that needs some testing).
> 
> 2) The main problem is the move of the ServerSocketFactory 
> interface from
> o.a.c.net to o.a.c. We could revert that change, and fixing 
> the rest is
> extremely simple.
> 
> Which one do you think is best ?
> 

perhaps now is the time to do some rethinking of where the connectors for
each serlvet container live.

today, in j-t-c, there is the framework (for lack of a better word) for
connectors plus the individual connectors or adapters for tomcat 3 and
tomcat 4.

personally, i think it would be better to have the individual
connectors/adapters live with the servlet container itself.  i.e. put the
ajp13 connector for tomcat 4 in the jakarta-tomcat-4.0 source tree.  this
way, j-t-c can build without having dependencies on any servlet containers,
and servlet containers that want to provide connectors that make use of
j-t-c can (optionally) depend on j-t-c.

just my $0.02.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Connector compatibility between TC 4.0 and 4.1

[Remy Maucherat]

Hi,

After a lot of efforts, it turns out the connectors (in j-t-c) still can't
be compiled against both the 4.0 branch and the HEAD branch of the Tomcat
CVS.

There are a few solutions to this:

1) Force the connectors to be built against the HEAD branch. They should run
fine on Tomcat 4.0 (although that needs some testing).

2) The main problem is the move of the ServerSocketFactory interface from
o.a.c.net to o.a.c. We could revert that change, and fixing the rest is
extremely simple.

Which one do you think is best ?

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: