Peter Rossbach wrote:
Tomcat 5.5 Proposal:
There's no Tomcat 5.5 ;)
Adding More Flexibility to Config Listener and Deployer
Peter Roßbach Frank Wegmann
Cool, you're not compliaining about the ex-Logger anymore :)
Overall, I think I like it some ideas from your email. I have
modifications planned to the deployer (see my previous), and this will I
think result in some code changes, so wait to send diffs until I'm done
with that. My changes are to modify how deployment is done once the
webapp is there, not to modify where the webapp comes from (since I
think the mechanism is good enough).
·Flexible ConfigListener configuration
·Configurable StandardHostDeployer
·More than one deployer or config Listener
·Faster war META-INF/context auto deployment after changing a
lot of war files
·JMX Notification at StandardContext und StandardWrapper
Some of it is quite obvious.
Currently, you can automatically deploy, delete or redeploy web
applications automatically using the classes HostConfig and
StandardHostDeployer. But this is tied to the single webapps directory.
However, customer scenarios would benefit from flexible mechanisms that
allow deployment of applications from different directories or even a
central HTTP repository. The necessity of a revised deployment
implementation is further stressed by the new undocumented FarmWar
Deployer facilitating an automatic cluster deployment. Here, with the
introduction of a StandardHostDeployer variant it gets clear that it
makes much sense to use different deployment sources at a single host in
a uniform manner
Cool, but:
- it's a bit more complex
- I think you can do that easily if you replace HostConfig, which is
pluggable
- overall, I don't care too much about the scanner (the current one is
good enough for me), and more about the deployer (which is the things
that gets called when TC is embedded, or is called by the scanner -
HostConfig - when running standalone); I think the deployer should be
simplified, while alternate scanners should be provided
In detail ...
a) The Config Listener can only be changed in server.xml:
Engine engineConfigClass=org.apache.catalina.startup.EngineConfig ...
Host hostConfigClass=org.apache.catalina.startup.HostConfig
configClass=org.apache.catalina.startup.ContextConfig
Context configClass=org.apache.catalina.startup.ContextConfig ...
See also the implementations for EngineRuleSet, HostRuleSet and
LifecycleListenerRule.
No. You can add more lifecycle listeners if you want to. There's just a
special one for configuration.
b)-d) Creating new container elements at runtime:
b) Create new host at runtime:
MBeanFactory.createStandardHost()(L. 943)
// add HostConfig for active reloading
HostConfig hostConfig = new HostConfig();
host.addLifecycleListener(hostConfig);
c) Create new context at runtime:
MBeanFactory createStandardContext() (L.826)
ContextConfig contextConfig = new ContextConfig();
context.addLifecycleListener(contextConfig);
d) Create new Service/Engine at runtime:
There is no correct setup for an EngineConfig. Currently the
EngineConfig implementation only prints out start/stop!
This is not the way to do it. Look at JMX embedding: either the tomcat
embedded distribution or the JBoss/Tomcat integration.
These old shortcuts are used by the admin webapp, and should be
considered deprecated. I'll propose removing them as part of the cleanup
step, actually.
e) Only StandardHost has a default for Context
This will be refactored, so you should wait a little. I see you're the
impatient type ;)
1.2) Change request:
...
Using the configListenerClass would free us from the special
MbeanFactory code and we could also drop the digester code in
Engine/Host/ContextRuleSet!
-1 at this point, since part of your statement is wrong, and that part
will be refactored (to summarize, the parsing of context.xml will likely
move to the context itself).
Of course, the current Deployer interface becomes inadequate when that
refactoring is done.
1.3) Enhancements
These enhancements realize a flexible deployment configuration per host.
Therefore we need to create a multi-valued configuration element
config for the container elements Engine/Host/Context in server.xml
which enables the user to configure a Host from more than one webapps or
descriptor directory.
Again, why not use additional lifecycle listener ? The config stuff
which is already there could be done in a Listener element, but since
it's needed to work, it's been hidden and automagically added (which
makes sense to me).
I think you can write listeners to do exactly what you propose.
While the attribute unpackWars can be set to true for one of these
directories, it may be false for others. So it is the decision of the
application
