2012/8/16 Schulz-Hildebrandt, Ole <ole.schulz-hildebra...@ppimedia.de>:
> Hi,
>
> I'm working with tomcat 7.0.29. In tomcat 5.x.x it was possible to use a
> custom HostConfig class by setting the hostConfigClass attribute at a <Host>
> element in the server.xml. This allowed to customize the order webapps were
> started, to avoid deploying of webapps at tomcat startup etc. Though this is
> still possible in tomcat 7.0.29 (internally still a LifecycleListenerRule for
> the hostConfigClass attribute is registered at the Digester) a warning is
> outputted (because the method setHostConfigClass was removed from the
> StandardHost):
>
> WARNUNG: [SetPropertiesRule]{Server/Service/Engine/Host} Setting property
> 'hostConfigClass' to 'de.ppimedia.tomcat.hostconfig.AppControllerHostConfig'
> did not find a matching property.
>
> Does anybody know why this method was removed? Is hostConfigClass only a
> "internal" attribute in tomcat 7.x.x? If so is there a "correct" way to use a
> custom HostConfig?
1. For reference: The "hostConfigClass" attribute on a <Host>,
"configClass" attribute on a <Context>, "engineConfigClass" on
<Engine> should already work as is.
The LifecycleListenerRule class that implements those attributes has
direct access to attributes on an XML element and so no setter is
actually needed.
The "SetPropertiesRule" warning can be ignored in this case. This
warning is a feature that was added in Tomcat 6 to catch common errors
when people misspell attribute names.
I think those attributes are a supported feature, but they are not
mentioned in documentation (update the docs?).
Does one need such properties on the StandardHost, StandardContext,
StandardEngine classes + expose them through JMX?
These attributes are used to configure those objects, but they would
have no effect if one tries to change them at runtime, so what purpose
would be to have such properties? One such purpose might be to be
able to inspect existing configuration through JMX.
2. Remembering one of commits,
http://svn.apache.org/viewvc?view=revision&revision=1030602
I think it is possible to add support for "hostConfigClass" property
on <Engine>, if anyone wants such feature.
3.
> I overwrote addLifecycleListener (replacing the default HostConfig by
> my custom HostConfig)
It sounds like a hack. It is better to create the correct class
instance when it is created.
Your approach will break if the default HostConfig object were somehow
configured before it is passed to addLifecycleListener(). It will also
break if another reference to the default instance were kept elsewhere
(accessing the default object, not knowing that you have replaced it).
Beat regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
