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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
