tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Rossbach ...@objektpark.de>
Subject Re: [5.next] Progress
Date Wed, 30 Jun 2004 13:14:40 GMT
Hello,

I have start a Server saved implementation.

- Externalize configuration saving out of StandardServer

features:

*   splitt implementation from StandardServer class
*   refactor the current save methods to some helper classes
*   every save element from server.xml dialect has it own save factory
*   central Mbean that have a registry for save factories
*   save complete Server,Engine,Host or Context xml's
*   support cluster elements
*   implement with testcases

options:
*  configure the save factories from xml or properties files.
*  better backup handling / not only for server.xml, also for 
context.xmls :-)

I hope the first implementation is ready at this weekend.

==

see some comments directly at the 5.next topics.

regards
peter


Remy Maucherat schrieb:

> My upcoming change list:
> - Attempt to redo a bit the deployer:
>   * remove the CL code which is there to avoid JAR locking (or at least
> allow disabling this feature for non-Windows OSes); when enabling anti 
> locking
> code, move everything to a temp "deploy" folder where everything will be
> referenced from; controlled by a "development" flag on the Context to 
> allow
> disabling this on Windows

Good option.

>
>   * move processing of context.xml to StandardContext (at the expense of
> being able to specify the context class, which will move to an attribute
> on the Host), as I realize it is important to get context level
> configurability without adding too much complexity in the embedding
> application; this could also go in ContextConfig, but this should be 
> done in
> another event (START occurs too late)

see some change requests at my today proposal... HostConfig/Deployer

> - Use the webapp CL as the main CL (without the locking tricks it is 
> likely
> faster than the regular CL)
> - Default servlet refactoring and optimization (avoid ResourceInfo 
> class, MIME mapping matching)
> - Resolve DBCP -> Pool -> Collections dependency which exposes too 
> many JARs in the common classloader (using package renaming and some 
> repackaging)
> - Externalize configuration saving out of StandardServer

I can do that.
 

> - Remove anything useless (spring cleaning time), such as configuration
> options, container listeners (to be replaced with JMX notifications where
> it matters), etc

Very good.
I have a made a NotificationEmitter Inteface support for StandardContext 
an StandardWrapper,
but it exist some problems at current JSR 77 notification support. 
Please look at my proposal or the bugreport

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29869

> - BASIC auth optimization
> - clutering module refactoring, to extend the regular Catalina 
> objects, for
> easier future maintenance

I have a talk with Rainer Jung, and his changes to cluster 
implementation looks very good.

> - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX 
> and JMX
> remote, etc)

I have made prototype for mx4J JSR 160 support it looks very nice.
Can't we refactor the ServerLifecycleListener also?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29259

> - And the ongoing: allow all config/management/embedding through JMX; 
> note: I think this is almost there already (thanks Costin), so only a 
> little tweaking will likely be needed
>
YES!

> So there are still a number of big changes waiting to be implemented, 
> and these should have a bigger impact than my initial changes. I'll do 
> the deployer and classloader changes first, which is the biggest chunk.
>
> When I'm done with the "remove anything useless" item, I'll propose a 
> release plan. Any items to the list (anyone proposing something must 
> be willing to timely implement what he's proposing, I'm not running a 
> wish list ;) ) ?
>
> Rémy




---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message