> I think the Resources stuff are at the right spot in the architecture :
> hidden behind the ServletContext, so that the data they abstract is
> availible to any servlet.
The Resource stuff is fine ( I would liked a JNDI Context more as an
abstraction, but it's just my taste, I like Resource too ).
The only question is if it have to be part of the container ( i.e. any
container that supports webdav must be based on this interfaces ) - and I
think that's a very limitting requirement.
Or it is part of webdav app ( what I did when I ported it to tomcat3 ),
and the container doesn't have to do nothing ( if using file-based
webapps, which is still the most common thing ) or provide some attributes
with the "base" and "repository type" - or something similar ( i.e. light
enough for any container to support it without changing it's architecture
to catalina )
> > You are the main author and you can of course decide if you want it to be
> > used only with catalina or if other servlet containers are allowed to use
> > it.
>
> Lol. How can I do that with the APL ?? Hey Craig, let's write a Catalina
> Public Licence to address that ;)
>
> Seriously, I encourage anyone to reuse the code, but I just wanted to expose
> here the few reasons why that particular component is "tied" to Catalina.
Then why all this noise and screams I hear when I just tried to take
Apache code, in my free time, and reuse it in tomcat3?
One hour after I do that everyone is flaming me and asks me to go to
sourceforge and stop using the name "tomcat" and so on and so on ??
> I guess we could vote on the subject, but if we leave it in, we'd have to
> provide support / fixes for that within the 3.x branch, which could be a
> problem since nobody's actually taking care of that right now (except
> Craig).
??????
I am working on the 3.x branch for about a year and made clear many times
that I'll continue to work on it for a while. At least until it's the
fastest and most secure servlet container ( we are close, but not there ).
I see there is a lot of interest in killing 3.x and making it "EOL", but
unless the Apache licence was changed overnight it will be difficult to do
that.
Tomcat3.2 was ready months ago, but everyone kept fixing non-critical bugs
that should have gone into 3.3 ( the development branch after the
rules). I started working on the 3.3 as soon as 3.2 was "freezed" and
Larry, Nacho and few other took care of checking in the patches and
waiting for a release. There are some issues that can't be resolve in a
"freezed" code, but only in the a development branch.
I'm working on few major things I announced, and my time is right now
_very_ limitted, I do have a job ( that is not "tomcat" ) and I have few
terrible deadlines, so forgive me for working on what I feel is more
important ( and again, 3.2 should have been released long ago and any
putback and non-critical fix is just delaying that even longer ! ).
With all this I take many hours of my free time and keep working on
tomcat3.3:
- performance improvements ( all the things that we couldn't put into 3.2
because they were too "dangerous" and we needed more time testing them )
( you can measure them )
- Using MessageBytes instead of Strings ( very important for performance,
but also to finally fix the "encoding bug )
- Fixing the class loader interceptor to support multiple operating modes
( including the one used in Catalina )
- remove all deprecated methods, finish cleaning up the core
- adding back JspInterceptor ( you can measure the improvement in jsp
execution )
- support "jikes" compiler ( you can measure the improvement in jsp
compilation time !)
- refactoring of connectors to have access to the full Interceptor API,
better configuration for interceptors ( no longer need "<property>" ).
- ( the recent ) webdav port, started support for resource caching ( will
be another performance and architecture enhancement for 3.x, reusing
apache code!)
- modularization, to allow people ( is it only me ???? ) to support
multiple facades. The servlet2.2 facade is in a bad shape and should be
rewritten, and we can do that while maintaining stability by following the
same evolutionary aproach - make it a module and replace it with something
better.
That also allows a nice "revolution" that will provide the 2.3 facade
without creating a new codebase or diverting from the 3.3 core, but as a
simple module.
Besides that, all the fixes from 3.2 must be integrated in, and some of
the good code from catalina should be ported ( http1.1, webdav, mod_warp
when ready ) - as long as they keep apache license and they are not glued
in. They are nice features and any user should benefit of them, without
having to change the container architecture.
Does it look like the 3.x branch is dead and nobody but Craig "is taking
care of it" ????
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
