It's one area I'm playing with, I want to make sure I'm not going in oposite direction :-)
BTW - another feature idea would be to extend the JMX configuration into the webapps, i.e. allow jmx apps to view and configure context and servlet params, and support servlets implementing MBean interfaces. The init(ServletConfig) model is pretty archaic :-)
Costin
Remy Maucherat wrote:
I've had a few more feature ideas (actually, it's more tweaks and simple things than big development for the most part), and I'm refining the way I'll be implementing the new deployer.
* Parse element Context (if context config file) in HostConfig, for className, path and docBase attributes.
* Parse remaining of element Context in ContextConfig (after defaultcontext).
* unpackWars in HostConfig (in most cases, it's done there already).
* Any resource removal when undeploy in HostConfig.
* anti-resource-locking (optional feature) in ContextConfig (by mutating the docBase, and copying the whole webapp elsewhere).
* Redo naming resources configuration using setAllProperties rule to make the XML less verbose.
Example:
<Resource name="bean/MyBeanFactory" auth="Container"
type="com.mycompany.MyBean" factory="org.apache.naming.factory.BeanFactory"
bar="23"/>
* Default global and per-host configurations:
- conf/<engine>/<host>/context.xml.default
- conf/<engine>/<host>/web.xml.default
- conf/context.xml
- conf/web.xml
This will lead to the removal of the DefaultContext interface, since this will fully replace the functionality (while being very simple to implement and actually complete functionality wise; I have no idea why I never thought of doing it this way, since the default web.xml is implemented like that). For the admin webapp support for DefaultContext, we would simply need to register a Context instance in JMX with the usual DefaultContext MBean name, and tweak a little.
* HTML host manager servlet (allows easily creating host and preconfiguring them - ex: with the manager webapp installed, and a default context file). I think this would be useful (?).
* The other features I mentioned earlier: startup time optimization, removal of stuff which isn't used (such as container listeners).
Note: I'll initially commit some of the updated deployer work as JDK 1.5 sources, and I'll change back to JDK 1.4 sources a bit later. It's very easy to do (although it hurts: I'm getting used to typing for collections way too fast ;) ), and I'm using this opportunity to really play with the new JDK.
How will this compile for people using JDK1.4 - or gump ?
I think I'm nearing the point where I'll submit a release plan for this branch (let's say at the end of next week), since I don't see much more to add for now besides more tweaking.
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
