tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Custom Valves and Administration Tool
Date Wed, 11 Dec 2002 22:44:35 GMT

On Wed, 11 Dec 2002, Jon Eaves wrote:

> Date: Wed, 11 Dec 2002 13:17:53 +1100
> From: Jon Eaves <>
> Reply-To: Tomcat Users List <>
> To: Tomcat Users List <>
> Subject: Re: Custom Valves and Administration Tool
> Craig R. McClanahan wrote:
> >
> First of all as there's been so much beating on the Tomcat developers
> I'd like to offer my whole-hearted congratulations to each and every
> one of you.  You've done a great job, and what's more, in spite of
> the (unwarranted) vitriol that is spewed in your direction, you keep
> coming back for more.  You guys and gals are legends.
> Secondly, the community here is fantastic and the way that users came
> to the "defense" of the Tomcat team was phenomenal.  Good work one and
> all.  As an author involved in a similar effort (
> there are very few people who take the time to say "Thanks", but the
> effect on the developers morale is worth it.
> Remember everybody on the list, that's all they get paid in, and it
> doesn't cost anything to say it....

You're welcome :-).

> Now, if you don't mind, I've got just one more question ;-)....

Looks like more than one more to me :-)

> > On Wed, 11 Dec 2002, Jon Eaves wrote:
> >>
> >>I was hoping to manage the valves via the Administration tool.
> >>
> >>Q1. Is this possible ?
> >
> >
> > Yes, with some work.
> Aha.  I was hoping this wasn't going to be the answer.  Oh well.
> [ snip ]
> If this is the case, why does the code for the Valve recommend
> implementing the Lifecycle interface ? What was the design reason
> for that ?h

In many cases you want to do some initialization and finalization in your
valve classes.  Implementing the Lifecycle interface gives your Valves the
equivalent of the init() and destroy() methods on a Servlet, which are
called at the beginning and ending of its lifecycle.

If you don't need this, there's no reason to implement Lifecycle in your
Valves.  If you peruse the standard ones, you'll see a mixture of those
that do and those that don't depending upon the detailed requirements.

> Additionally, why does the MBeans server barf when loading custom
> beans without the mbeans-descriptor.xml file ? Is this due to the
> Lifecycle interface being implemented, or just purely because of
> the Valve definition in server.xml it is expecting to find a bean
> that it can manage.

When Tomcat starts up, one of the functions of the ServerLifecycleListener
gadget that is declared in server.xml is to walk through all the
components of Catalina that were actually configured (including your
custom valve) and create a corresponding MBean.  In order to construct the
metadata information associated with each MBean (i.e. the MBeanInfo data
structure), Tomcat requires that an <mbean-descriptor> element for your
custom Valve class must have been defined, so it knows what attributes
(in JMX terms -- properties in JavaBeans terms) and operations (i.e.
methods) to be exposed to JMX clients.

It has nothing to do with implementing Lifecycle or not.  It has
everything to do with requiring that the metadata information be available
for your fully qualified class name.

> The reason I ask is because it seems bit of dicking around just to
> implement a new Valve.  Writing the code took about 2 hours, it
> then took 2 days to get the exception stuff sorted out.
> What is the additional information used for ? And was there a better
> (read simpler and less mucking around) way to solve my "get rid of
> the exception" than addition of the descriptor, or is that required
> for all additional components in Tomcat ?

The set of attributes actually displayed for a given Valve implementation
(in the admin tool) is currently hard coded with special logic for each
recognized class.  It would not be hard to extend this to a "generic"
Valve configuration screen that would consult the JMX metadata in order to
know what fields to display.

A more aggressive goal would be to have a completely generic JMX client
that constructed its entire UI based on the JMX metadata.  That's also
possible using some existing JMX technologies.

> Cheers,
> 	-- jon


> --
> Jon Eaves <>
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message