You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jon Eaves <jo...@eaves.org> on 2002/12/10 23:38:48 UTC
Custom Valves and Administration Tool
Hi all,
Thanks to Bill Barker, my custom valves now are installed happily
within Tomcat and are valving away nicely without spewing MBean
exceptions into the log.
I was hoping to manage the valves via the Administration tool.
Q1. Is this possible ?
Q2. Do I have to modify the Admin tool ?
Q3. How do I configure it ? (what needs to be in server.xml ?)
I would have thought it was possible, as the Admin tool appears
to parse the server.xml and generate stuff based on that, and my
Valves have implemented the LifecycleListener interfaces so I'm
a tad confused about where to go from here.
Cheers,
-- jon
PS: I've said it before, and I'll say it again, the documentation
in Tomcat for general users/administrators is first rate. This
stuff is a bit thin, but what they heck, most people don't need
or want to do this.
--
Jon Eaves <jo...@eaves.org>
http://www.eaves.org/jon/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Custom Valves and Administration Tool
Posted by Bill Barker <wb...@wilshire.com>.
"Jon Eaves" <jo...@eaves.org> wrote in message
news:3DF6DF09.3070307@eaves.org...
> Hi again Bill,
>
> >> 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 MBeans.
> >
>
> Excellent, so the Valves can then conform to an defined
> servlet/applet/midlet like behaviour. I noticed the use of the
> start() etc methods in the Valve and guessed that was something to
> do with it, but also guessed wrong that it was relating to the MBeans.
>
> > 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.
>
> Yup. My Valves were all working just fine with the errors, but I wanted
> to be neat and tidy ;-)
>
> >
> >> 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.
>
> OK. I'll have a play around with that. I think I tried that originally,
> and when I did, the Administration application stopped working, but that
> may just have been co-incidence.
Well, yeah, that's a side affect. ;-)
>
> Thanks very much Bill and Craig for your patience.
I feel honored to be mentioned in the same sentence with Craig on this
thread :-).
>
> Cheers,
> -- jon
>
> --
> Jon Eaves <jo...@eaves.org>
> http://www.eaves.org/jon/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Custom Valves and Administration Tool
Posted by Jon Eaves <jo...@eaves.org>.
Hi again Bill,
>> 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 MBeans.
>
Excellent, so the Valves can then conform to an defined
servlet/applet/midlet like behaviour. I noticed the use of the
start() etc methods in the Valve and guessed that was something to
do with it, but also guessed wrong that it was relating to the MBeans.
> 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.
Yup. My Valves were all working just fine with the errors, but I wanted
to be neat and tidy ;-)
>
>> 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.
OK. I'll have a play around with that. I think I tried that originally,
and when I did, the Administration application stopped working, but that
may just have been co-incidence.
Thanks very much Bill and Craig for your patience.
Cheers,
-- jon
--
Jon Eaves <jo...@eaves.org>
http://www.eaves.org/jon/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Custom Valves and Administration Tool
Posted by Bill Barker <wb...@wilshire.com>.
"Jon Eaves" <jo...@eaves.org> wrote in message
news:3DF6A051.4070000@eaves.org...
> 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 (www.bouncycastle.org)
> 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
MBeans.
>
> 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 <jo...@eaves.org>
> http://www.eaves.org/jon/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Custom Valves and Administration Tool
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 11 Dec 2002, Jon Eaves wrote:
> Date: Wed, 11 Dec 2002 13:17:53 +1100
> From: Jon Eaves <jo...@eaves.org>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> 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 (www.bouncycastle.org)
> 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
Craig
>
> --
> Jon Eaves <jo...@eaves.org>
> http://www.eaves.org/jon/
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Custom Valves and Administration Tool
Posted by Jon Eaves <jo...@eaves.org>.
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 (www.bouncycastle.org)
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
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.
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 ?
Cheers,
-- jon
--
Jon Eaves <jo...@eaves.org>
http://www.eaves.org/jon/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Custom Valves and Administration Tool
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 11 Dec 2002, Jon Eaves wrote:
> Date: Wed, 11 Dec 2002 09:38:48 +1100
> From: Jon Eaves <jo...@eaves.org>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Custom Valves and Administration Tool
>
> Hi all,
>
> Thanks to Bill Barker, my custom valves now are installed happily
> within Tomcat and are valving away nicely without spewing MBean
> exceptions into the log.
>
> I was hoping to manage the valves via the Administration tool.
>
> Q1. Is this possible ?
Yes, with some work.
> Q2. Do I have to modify the Admin tool ?
Yes. You'll need to add JSP pages, a form bean, and the appropriate set
of Actions (the admin webapp is based on Struts) for your custom Valve's
properties, plus tweak the generic code for things like "add valve" to
make your type of valve an option on the list.
> Q3. How do I configure it ? (what needs to be in server.xml ?)
>
It's not really a matter of configuration -- the admin tool has specific
logic for each specific type of component that it supports. The only
reasonably generic part is building the initial tree from the components
actually running inside Tomcat (which was in turn based on the original
contents of server.xml), and saving the updated set of components actually
running back to the server.xml file.
> I would have thought it was possible, as the Admin tool appears
> to parse the server.xml and generate stuff based on that, and my
> Valves have implemented the LifecycleListener interfaces so I'm
> a tad confused about where to go from here.
>
Ideally, the admin tool would be completely generic -- you could add your
custom components (perhaps along with a description of how they fit in in
some sort of XML file), and the admin tool would automatically build the
required screens and functionality. IMHO, implementing this ideal in a
completely generic way is somewhere between very difficult and not
feasible if you want to end up with a high quality UI, but assistance in
doing this would be welcomed.
> Cheers,
> -- jon
>
> PS: I've said it before, and I'll say it again, the documentation
> in Tomcat for general users/administrators is first rate. This
> stuff is a bit thin, but what they heck, most people don't need
> or want to do this.
>
> --
> Jon Eaves <jo...@eaves.org>
> http://www.eaves.org/jon/
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>