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.
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.
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 ?)
- the "classes" folders allow patching (which of course may not be that
useful)
- 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.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
