You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/01/07 01:12:17 UTC
Catalina interface/impl separations
Folks,
Back in a thread that ended on the 16th October we talked of some fixes
to the code that makes the interface abstractions ( interfaces & classes
in org.apache.catalina package ) no longer dependant on implementation
of Catalina.
The reason we needed this is that it will make Catalina more mountable
in other applications. Interface/Impl separation allows classloader
hiding of impl from potentially hostile code.
I guess many issues that were identified were fixed immediately. Here
is my view of what is left:
org.apache.catalina.Cluster -> dependant on classes from
org.apache.catalina.cluster package
org.apache.catalina.Connector -> dependant on
org.apache.catalina.net.ServerSocketFactory
org.apache.catalina.Context -> dependant on many classes from
org.apache.catalina.deploy
org.apache.catalina.DefaultContext -> ditto
org.apache.catalina.Server -> ditto
The consensus of opinion was to do nothing at that stage that might
break the API.
What is the feeling nearly three months on? Are we still aiming at full
separation in terms both of dependancy and Jar? Are these five fixable?
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Catalina interface/impl separations
Posted by Paul Hammant <Pa...@yahoo.com>.
Tom, Folks,
Thanks for that. I can't comment really either as I am not a committer.
Bip's last revision to Cluster is from July.
I think there are a couple more classes in org.apache.catalina.startup
that should have interfaces extracted from them and placed in
org.apache.catalina. These are:
* Embedded
* EmbeddedManager
Interface extraction should be easy and not break any backwards
compatability. Changing over return types might.
Regards,
- Paul H
>I'm not a tomcat developer (yet), but, I've been writing code that provides
>fail-over capability by providing distributed (cluster) session managment.
>
>My review of the catalina code indicates that org.apache.catalina.Cluster is
>not currently useful. The distributed session store does not 'work' and has
>some design issues that must be addressed before it can be made to work.
>
>Tom
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Catalina interface/impl separations
Posted by Tom Drake <rt...@pobox.com>.
Paul:
I'm not a tomcat developer (yet), but, I've been writing code that provides
fail-over capability by providing distributed (cluster) session managment.
My review of the catalina code indicates that org.apache.catalina.Cluster is
not currently useful. The distributed session store does not 'work' and has
some design issues that must be addressed before it can be made to work.
Tom
----- Original Message -----
From: "Paul Hammant" <Pa...@yahoo.com>
To: <to...@jakarta.apache.org>
Sent: Sunday, January 06, 2002 4:12 PM
Subject: Catalina interface/impl separations
| Folks,
|
| Back in a thread that ended on the 16th October we talked of some fixes
| to the code that makes the interface abstractions ( interfaces & classes
| in org.apache.catalina package ) no longer dependant on implementation
| of Catalina.
|
| The reason we needed this is that it will make Catalina more mountable
| in other applications. Interface/Impl separation allows classloader
| hiding of impl from potentially hostile code.
|
| I guess many issues that were identified were fixed immediately. Here
| is my view of what is left:
|
| org.apache.catalina.Cluster -> dependant on classes from
| org.apache.catalina.cluster package
| org.apache.catalina.Connector -> dependant on
| org.apache.catalina.net.ServerSocketFactory
| org.apache.catalina.Context -> dependant on many classes from
| org.apache.catalina.deploy
| org.apache.catalina.DefaultContext -> ditto
| org.apache.catalina.Server -> ditto
|
| The consensus of opinion was to do nothing at that stage that might
| break the API.
|
| What is the feeling nearly three months on? Are we still aiming at full
| separation in terms both of dependancy and Jar? Are these five fixable?
|
| Regards,
|
| - Paul H
|
|
|
| --
| To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
| For additional commands, e-mail:
<ma...@jakarta.apache.org>
|
|
|
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Catalina interface/impl separations
Posted by Paul Hammant <Pa...@yahoo.com>.
Thanks Remy,
This is really great news.
>>What is the feeling nearly three months on? Are we still aiming at full
>>separation in terms both of dependancy and Jar? Are these five fixable?
>>
>
>No. Just package your JARs differently.
>cluster, deploy and net are self-contained packages, so just integrate them
>in the base package.
>
Could we change the relevant <jar> line in build.xml from....
<!-- Catalina Main JAR File -->
<jar jarfile="${catalina.deploy}/server/lib/catalina.jar">
<fileset dir="${catalina.build}/server/classes">
<exclude name="org/apache/naming/**" />
<exclude name="**/connector/warp/**" />
<exclude name="org/apache/catalina/startup/Bootstrap.class" />
<exclude
name="org/apache/catalina/startup/BootstrapService.class" />
<exclude
name="org/apache/catalina/startup/ClassLoaderFactory.class" />
<exclude name="org/apache/catalina/startup/Tool.class" />
<exclude
name="org/apache/catalina/loader/StandardClassLoader*.class" />
<exclude name="org/apache/catalina/loader/Extension.class" />
<exclude name="org/apache/catalina/loader/Reloader.class" />
<exclude
name="org/apache/catalina/startup/SecurityClassLoad.class" />
<exclude name="org/apache/catalina/servlets/**" />
<exclude name="org/apache/catalina/util/ssi/**" />
</fileset>
</jar>
... to ...
<!-- Catalina Interfaces JAR File -->
<jar jarfile="${catalina.deploy}/server/lib/catalina-interfaces.jar">
<fileset dir="${catalina.build}/server/classes"
<include name="org/apache/catalina/*" />
<include name="org/apache/catalina/net/**" />
<include name="org/apache/catalina/cluster/**" />
<include name="org/apache/catalina/deploy/**" /
</fileset>
</jar>
<!-- Catalina Main Impl JAR File -->
<jar jarfile="${catalina.deploy}/server/lib/catalina-impl.jar">
<fileset dir="${catalina.build}/server/classes"
<exclude name="org/apache/naming/**" />
<exclude name="**/connector/warp/**" />
<exclude name="org/apache/catalina/*" />
<exclude name="org/apache/catalina/net/**" />
<exclude name="org/apache/catalina/cluster/**" />
<exclude name="org/apache/catalina/deploy/**" />
<exclude name="org/apache/catalina/startup/Bootstrap.class" />
<exclude
name="org/apache/catalina/startup/BootstrapService.class" />
<exclude
name="org/apache/catalina/startup/ClassLoaderFactory.class" />
<exclude name="org/apache/catalina/startup/Tool.class" />
<exclude
name="org/apache/catalina/loader/StandardClassLoader*.class" />
<exclude name="org/apache/catalina/loader/Extension.class" />
<exclude name="org/apache/catalina/loader/Reloader.class" />
<exclude
name="org/apache/catalina/startup/SecurityClassLoad.class" />
<exclude name="org/apache/catalina/servlets/**" />
<exclude name="org/apache/catalina/util/ssi/**" />
</fileset>
</jar>
It would be a great help. In the lifetime of Catalina following the
first 4.x releases there have been some jar name changes so it is not
without precident.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Catalina interface/impl separations
Posted by Remy Maucherat <re...@apache.org>.
> Folks,
>
> Back in a thread that ended on the 16th October we talked of some fixes
> to the code that makes the interface abstractions ( interfaces & classes
> in org.apache.catalina package ) no longer dependant on implementation
> of Catalina.
>
> The reason we needed this is that it will make Catalina more mountable
> in other applications. Interface/Impl separation allows classloader
> hiding of impl from potentially hostile code.
>
> I guess many issues that were identified were fixed immediately. Here
> is my view of what is left:
>
> org.apache.catalina.Cluster -> dependant on classes from
> org.apache.catalina.cluster package
> org.apache.catalina.Connector -> dependant on
> org.apache.catalina.net.ServerSocketFactory
> org.apache.catalina.Context -> dependant on many classes from
> org.apache.catalina.deploy
> org.apache.catalina.DefaultContext -> ditto
> org.apache.catalina.Server -> ditto
>
> The consensus of opinion was to do nothing at that stage that might
> break the API.
We tried (for some of the items), but it created lots of problems. We chose
not to break the API, so none of the above will be "fixed" (although I don't
consider any as a problem).
> What is the feeling nearly three months on? Are we still aiming at full
> separation in terms both of dependancy and Jar? Are these five fixable?
No. Just package your JARs differently.
cluster, deploy and net are self-contained packages, so just integrate them
in the base package.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>