Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 2.0M3
-
Fix Version/s: None
-
Component/s: project
-
Labels:None
-
Number of attachments :
Description
In order to expose its internals to management/monitoring, rather than use a load of custom code, WADI takes advantage of some fn-ality offered by Spring - look at the bottom of modules/webapp/src/webapp/WEB-INF/wadi-web.xml.
Basically, Spring will create an MBeanServer/JMX-Agent if one does not already exist (mbeanServer) and use the MBeanExporter to dynamically publish a list of beans to this agent.
This is done as WADI starts up. (There is also config to start up a JNDI registry so that you can attach e.g. mc4j and manage/monitor these mbeans - I think I describe how to do thi in the Getting Started doc in the wiki - if not, I should).
PROBLEM - as WADI shuts down, there is no equivalent process running backwards to deregister the MBeans. This is not generally a problem, until you use a container that is capable of Redeploying a war e.g. JBoss, Geronimo? or perhaps Jan's new Maven/Jetty plugin. Since nothing has been deregistered, on startup the second time, you get a load of name collisions, because the names that Spring chooses for its MBeans are the same as the last iteration. What is needed is a nice way of ensuring that at stop() time, all registered beans are deregistered - I have ideas on how this can be done simply - if anyone is interested.