tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <cos...@gmail.com>
Subject Re: Refactorings
Date Mon, 27 Mar 2006 22:07:30 GMT
On 3/27/06, Remy Maucherat <remm@apache.org> wrote:
>
> Costin Manolache wrote:
> >> I didn't try to extract a superclass on my branch (most likely, I
> >> won't), but I figured making the two implementations as close as
> >> possible in terms of functionality would be the best first step. So the
> >> attributes of the connectors are about the same, and the endpoints are
> >> similar.
> >
> > What would be your reason for not having a superclass for AprEndpoint
> and
> > non-AprEndpoint ???
> > They are already very similar - and your change will make them even more
> > similar,
> > the only difference is only in implementation details, etc.
>
> It's because I consider (in my branch) the java.io endpoint as
> deprecated, so I don't see the point of creating a superclass just to
> remove duplication on deprecated code.



Well, the problem is that tomcat is not your branch, and in tomcat the io
connectors
are not deprecated, and probably won't be any time soon ( I can't imagine
forcing people
to use jni and apr ) :-)

As I said - I don't care much about the APR connector either ( compiling or
using JNI for
a low performance server or development is not the best idea ), but  I'm
worried  we are going
down a wrong path ....



> Actually, my main concern is on removing the thread pool and ssl
> > abstractions ( keep
> > the TP as implementation for the endpoints that need it, but don't
> expose it
> > as an API and
> > not use it outside of endpoints ). If APR is a different class hierarchy
> - I
> > can just  ignore it
> >  :-), but the fundamental thing is to not expose details of the thread
> model
> > and SSL impl
> > ( APR and NIO don't fit with the SSL or thread model abstractions anyway
> ).
>
> I am not proposing this as is for Tomcat. There are issues anyway: for
> example, the AJP implementation would have to be modified, etc, while I
> don't have these sort of issues.


Jboss web server doesn't have those sort of issues - but tomcat does, in
part because
ajp ( and NIO ) don't match the current API.
And since tomcat goal is to be usefull to more than jboss - it would be good
to have
a better abstraction in place, so people who don't need APR but like to use
NIO can
do this in their trees.



> So if you can get rid of all calls and deps to ThreadPool and SSLSuport -
> > and move the methods
> > into the Endpoint(s) - I'm +1.
> >
> >
> >> - The Jasper sources for JSP 2.1 are also in that repository.
> >>>> - (from the get rid of dependencies department) Should PureTLS
> support
> >>>> stay ?
> >>>>
> >>>> - I will happily write the build script, which is going to be an
> order
> >>>> of magnitude simpler.
> >>> Let me know if you need help :-).
> >> You don't want to help on JSP 2.1 ? :D
> >
> >
> > I was talking about the ant script actually, don't want to start another
> > thread about jsp :-)
>
> I know you were talking about the Ant script.
>
> >> The script in sandbox can already build all the base tomcat, it's just
> not
> >>> packing it
> >>> in the old format ( since it's purpose is to avoid the jar and
> directory
> >>> mess :-)
> >> The question is: is the directory mess useful or not ? There are
> >> justifications for it (at least, most of it).
> >
> > Some justifications may no longer apply, some were proven to not matter,
> and
> > for some
> >  we know better alternatives :-)
> >
> > I'm not advocating single-jar by default - but something more like
> JBoss,
> > i.e. flatter and
> > oriented more towards modules rather than a particular class loader
> > hierarchy.
>
> The justifications I know about are:
> - the specification still recommends hiding the implementation classes
> (hence the hierarchy - is that the one proven to not matter ?)


Not matter + alternative implementations.
Hiding the implementation could be done at classloader / config level if
really needed.


- the "classes" folders allow patching (which of course may not be that
> useful)


Did we ever did such a patch in the last 5 years ? How would it interact
with
package sealing ? etc.


- I have no justification for the "shared" folder, except being able to
> share a JAR (aka, save memory and create leaking potential) without
> having it be exposed to the container implementation



If those justifications are good enough, then the "common" and "server"
> folders should remain.


I think the main 'justification' for the current structure was hiding the
jaxp
parser that the server used ( old crimson, different versions of xerces, etc
).

Well - I guess I don't mind it too much as long as there is a simpler
alternative ( like
the single-jar ) for people who don't need the extra complexity.

Costin
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message