On Wed, 11 Dec 2002, Jon Eaves wrote:
> Date: Wed, 11 Dec 2002 13:17:53 +1100 > From: Jon Eaves <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > http://www.eaves.org/jon/ > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
