tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Custom Valves and Administration Tool
Date Wed, 11 Dec 2002 06:30:30 GMT

"Jon Eaves" <> wrote in message
> 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....
> Now, if you don't mind, I've got just one more question ;-)....
> > 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

By implementing Lifecycle, you get well-defined states to allocate and
release any resources that your Valve may need.  Since the order of setting
attributes is undefined, it makes it much easier to determine resources that
depend on multiple attribute values.  It's pretty much independent of the

> 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.

It's purely because of the Valve definition in server.xml, when it can't
find the MBean to manage it.  Actually, the Valve should function fine even
with the error:  It's just noise in the log.

> 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 ?

With the MBean info, it is possible to use other JMX-enabled tools to manage
Tomcat (including your Valve).  The admin web-app is only one example of
such a tool.  It is also likely that JMX support will improve in Tomcat 5.x.

Of course, the simplest way to "get rid of the exception" is to disable (aka
comment out) the MBeans Listeners in server.xml.

> Cheers,
> -- jon
> --
> Jon Eaves <>

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

View raw message