On 3/27/06, Remy Maucherat <[EMAIL PROTECTED]> wrote: > > 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.
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. 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 ). 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 :-) > 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. > 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). Not an option for your tree you mean :-) Well, I would not like it either, there is value in having an API for logging - and java.util.logging is not really an API, but an implementation with some hooks. If c-l 2.0 changes in a backward incompatible way ( as is the habbit with many other apache products ) - then probably the best choice is to drop it, or just -1 the changes in c-l and ask for a different package ( like o.a.c.logging2 ). Costin
