Costin Manolache wrote:
- I did my own connector refactorings very recently, and the result can
be seen here (I removed SSL support in that code, but it could be left
in easily) for the java.io endpoint:
http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/src/share/classes/org/apache/tomcat/util/net/JIoEndpoint.java
This increases the commonality between the two endpoints, and IMO is the
right first step to start code sharing. Since it is Java 5, I will also
see if I can add ways to specify an Executor for use by the endpoint for
its worker threads (I expect so-so performance, but it could allow
things like a single thread pool for the whole server).
+1 on increasing the commonality between endpoints, and +1 on removing
pure tls and the entire SSL-support from the base connector - if anyone
needs different SSL stack it can be added back, but with a different
abstraction.
I'll compare your refactoring with mine ( in sandbox ), I have no problem
with
droping my code, but since we have 2 implementations it's good to compare
and see
if maybe there are good things in both :-)
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.
- 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
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).
If you don't mind, I think we should have the single-jar option in the main
build file,
even if we won't release it this way.
Any comment on the 'direct' commons-logging ?
The direct c-l means the c-l hardcoded for java.util.logging ? Is so,
I'm not that happy: the API is going to change in c-l 2.0, so I would
prefer switching to java.util.logging (the only issue is that I think my
boss would not like it, so it's probably not an option).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
