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 whether its war files should be unpacked and not that of the > host.
I think retrospectively the right decision would have been to unpack always (but I digress, here).
> Example: > > <Host > > <Config className="org.apache.catalina.deploy.DirectoryAutoDeployer" > deployOnStartup="true" > appBase="webapps" > unpackWars="true"/> > <Config className="org.apache.catalina.deploy.DirectoryAutoDeployer" > deployOnStartup="true" > appBase="adminapps" > unpackWars="false" > autoDeploy="false"/> > <Config className="org.apache.catalina.deploy.XMLContextAutoDeployer" > deployOnStartUp=true" > directory="context" /> <!--default conf/<engine>/<host> -->
Obviously, the HostConfig class is fairly focused at this functionality right now. The concerns should be separate between the scanner and the deployer. So if you "Config" thing is really the deployment scanner, then it should be called that way ;) (I strongly think this component should only care about scanning and monitoring, and have no deployment logic in it - this may not be the case right now, but will be part of my little deployer rework)
> Last but not least: These configuration changes should certainly be > accessible in the admin web app as well.
Sure ;) Personally, I'd still put that item in the "least" category (so it's "last and least").
> 2) HostDeployer > > 2.1) Status > Currently we can't change the default StandardHostDeployer in a clean > way. We would have to override the StandardHost class, but this leads to > some problems with the current runtime configuration via JMX. The > alternative would be to set with StandardHost.setDeployer() your own > Deployer at a special Listener class (start())
I disagree with this part of the proposal: there should be less than what there is now in the Deployer (I might actually remove it, and add the relevant method in the host), and there is only one reasonable default. To tweak further, I think it's acceptable to recommend extending StandardHost (or writing a custom Host).
> For clustering scenarios there is another deployer class FarmWarDeployer > (in org/apache/catalina/cluster/deploy) that handles cluster > applications as follows: > - You have your own directory > - Autodeployment takes place on all nodes in your cluster > - New cluster nodes will get all applications > (But please check your net for new illegal nodes J )
I want a FarmScanner instead (although I don't care about that feature). The idea is that you won't have "remote" WARs (although in theory you could do it with all my crazy resources stuff, it's way too complex and not robust enough - I got old, so I do like robustness more than faniness these days): the first thing the scanner should do is download (or expand) the remote WAR locally. This doesn't prevent scanning for updates, etc.
I'd like this scanner/deployer to be generic, consistent, and simple :)
> 2.2) Change request:
>
> Don't hardcode the parameter STANDARD_HOST_DEPLOYER. Instead use:
> <host deployerClass="org.apache.catalina.core.StandardHostDeployer">
>
> And add getter/setter methods to StandardHost.
I still believe we don't care about that. If we end up keeping the Deployer interface, then I'm +0 for adding that.
> 2.3) Enhancements > > These enhancements let the user define the deployment for a host or > cluster in a uniform and transparent manner and also allow customization > at deployment time. > > Therefore we need to create a multi-valued configuration element > <Deployer> for the elements Host and Cluster in server.xml. Any > deployment action can be customized by adding a call to a hook (before > or after deployment) to easily extend the StandardHostDeployer. > > Example: > A very interesting use case is adding security code > <Deployer className"org.apache.catalina.core.StandardHostDeployer"> > <Hook action="installRemote" > className="org.xxx.SecurityDeployerHook"/> > </Deployer>
Cool, but this is not too useful overall:
- you get JMX notifications
- we could keep some of the container events that you can use (addChild and others - more could be added) - or they could become more JMX notifications
So it's already there, and I'd have to disagree with adding more redundant stuff (the new branch is removing old useless stuff, not adding new redundant stuff ;) ).
> Actions are defined by the action attribute. Possible values are: > installRemote install a war (config and War URL) > installLocal install a directory or war > locally > remove undeploy existing apps > > The FarmWARDeployer needs refactoring to realize this enhancement. > Further necessary actions are: > - Fix Security issues (only deploy at auth nodes) > - Integrate a multi-deployer configuration at Host Level.
This should be a scanner if you want it ;)
Basically, I don't want to tell the deployer: deploy this WAR which is there using this and this (too complex), but rather tell the relevant scanner to do the job (and give a simple webapp to the deployer to deploy). Another facet of this change of concerns is that in embedded, we only need the deployer, which will be free of useless stuff (unlike right now), while the scanner will be removed (still unlike right now).
> 3) HostConfig > > 3.1) Status ... > See the return call after the call to deployDescriptors()! > Why stop the deployment cycle and wait 10 seconds for the next call? > Why do we not install only the single context.xml instead to loop over > the complete conf/<enginename>/<hostname> directory?
There could be a good reason why it's done this way, but I don't remember.
> The StandardContext has an attribute unpackWAR, but only the
> SetDocBaseRule class handles this attribute. StandardHostDeployer doesn't:
> See StandardHostDeployer method install(URL,URL) (L. 458):
> // Expand war file if host wants wars unpacked
> if (isWAR && host.isUnpackWARs()) {
> docBase = ExpandWar.expand(host, war);
> }
>
> Currently we can't use unpackWAR=false when deploying with
> META-INF/context.xml.
We'll see about that, but a bit later.
> 3.2) Change request: > > Don't return after deployDescriptors and the first WAR deployment will > be faster!
The impact of fixing this is quite small in the end, and we'll care about tweaking later.
> For War without a META-INF/context.xml, generate a default > context.xml > Also check the deployment of the ManagerServlet. > But also remove the ExpandWars and generate a default > conext.xml instead. > And check for special case ROOT app.
Sorry, but no for these: I don't see any reason for a default blank context.xml if there's none.
> 3.3) Enhancements > > Introduce directory deployment also for META-INF/context.xml
I have no idea what this means.
> Check META-INF/context.xml for missing or older > conf/<enginename>/<host>/app.xml. > Refactor the ManagerServlet code:
The manager servlet is not a priority, as we need to do the core first.
> 4) JMX Notification at StandardContext und StandardWrapper > > 4.1 Status > > StandardContext and StandardWrapper has a broadcastsupport object, but > nobody can register a NotificationListener.
Yeah, duh, this was never finished ;) I'll do it, and use it to remove a few hacks in context using that.
> Central JMX-based monitoring for all applications is a nice feature.
And this is not there right now ?
The rest of the "JMX changes" are tweaks to commons-modeler and the relevant TC stuff.
One small related note: I believe strongly in the MBean creation during init() if it's not there (and removal in destroy). (un)registration is a perfectly valid event for a MBean (and I use it exclusively right now, since regular notifications don't work).
About contributing, we don't know your code, and I don't trust you yet, so try submitting small patches first :) If you submit a large patch (say you implement all that is in this email in one big patch), it's hard to review, and we may not like parts of it, so likely noone will dare commit it. Also, try to write shorter, more focused proposals, it's easier.
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
