Re: Custom Valves and Administration Tool
Jon Eaves [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... 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 [EMAIL PROTECTED] http://www.eaves.org/jon/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Custom Valves and Administration Tool
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]
Re: Custom Valves and Administration Tool
On Wed, 11 Dec 2002, Jon Eaves wrote: Date: Wed, 11 Dec 2002 09:38:48 +1100 From: Jon Eaves [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.eaves.org/jon/ Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 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 [EMAIL PROTECTED] http://www.eaves.org/jon/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Custom Valves and Administration Tool
Jon Eaves [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... 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 [EMAIL PROTECTED] http://www.eaves.org/jon/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Custom Valves and Administration Tool
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 [EMAIL PROTECTED] http://www.eaves.org/jon/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
