On 3/27/06, Remy Maucherat <[EMAIL PROTECTED]> 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
