> -----Ursprüngliche Nachricht-----
> Von: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
> Gesendet: Freitag, 17. August 2012 15:50
> An: Tomcat Users List
> Betreff: Re: hostConfigClass attribute
> 
> 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).

Hi,

yes you are right it is a hack. I had choosen this way because I was not sure 
if the hostConfigClass attribute was a supported feature and I was afraid it 
could be removed in future tomcat versions. Now that I know (thanks to your 
information) that it is a supported feature I will switch back using 
hostConfigClass again. From my perspective as a tomcat user I would appreciate 
if those attribute were mentioned in the docs. 

Would it be possible to remove the "SetPropertiesRule" warning in future 
versions? Because so far the only way to avoid this message is (as Mark 
suggested) to use a custom Host class which provides dummy getter and setter 
for hostConfigClass which is kind of a hack as well...

Best regards
Ole


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to