Please Recommend Monitoring/Management Tools

[pbdavey]

@Jason
FYI...jsvc was setup very similarly to how catalina.sh was setup. For Tomcat5.sh, I exported several env vars in my bash script, CATALINA_HOME/BASE, JAVA_OPTS, CATALINA_OPTS, etc the exact values I put in my .bash_profile so that catalina.sh would start properly. I could provide more environment details if it would help (listings of .bash_profile, Tomcat5.sh).

@Jen
No, all controllers are configured via xml. We use ant to configure xml for different application targets. However, I looked at different controllers, eg ParameterizedViewController vs. SimpleCommandControllers, and all are not reporting metrics. Tomcat is not devoid of metrics. The several internal MBeans are reporting and even some Spring MBeans that appear to be reporting some (View, Auth Provider). Of course, I may be unreliable as a source since I've not had a working AMS yet.

-Phil

[Jason Konicki]

Phil,

Looks like currently the process must be a java process in order to be discovered. There is a jira ticket opened for providing support for jsvc.

-Jason

[jencompgeek]

AMS will export an MBean for any implementation of org.springframework.web.servlet.Controller that it finds. However, it can only monitor the Controller implementations that have been woven by the monitoring aspect at build time - so the impl has to be in one of the instrumented Spring jars.

If you are looking to monitor your own Controller implementations, AMS automatically creates Spring AOP proxies to monitor any of your components that are marked with the @Controller annotation. Beyond that, we are also planning to publish the monitoring API in the near future so you can hook monitoring into your own components.

Does this seem to match what you are seeing?

[pbdavey]

Thanks for the follow ups!

I'll try in the next couple of days to rebuild, ensuring that build time has the right jars and then that run time has the right jars. I think they were correct before though, but I'll make sure as I suppose it's possible that I'm seeing a strange artifact that is the result of changing jars between compile and run. Other than that, is it necessary that @Controller is used? Can it not handle xml configured controllers? What about the Spring's Java config project?

[jencompgeek]

We can monitor and export any bean that is instantiated via an ApplicationContext, so you should be able to monitor beans configured in XML or Java Config. By default, any implementation of the Controller interface or any bean marked with @Controller is exported as a JMX MBean.

However, the controllers are woven with aspects for monitoring at compile time by SpringSource (except for @Controller which we use Spring AOP proxies for). org.springframework.web.servlet.mvc.AbstractContro ller's handleRequest method is woven, so any class extending that should get metrics updated unless it one of your own and overrides the handleRequest method (instead of handleRequestInternal). In that case, we can't weave it since it's yours and we don't have access to it at build time

[webkid90]

I was able to start my application with the instrumented jars. I was also able to deploy to Tomcat this application and view it through jconsole.
_________________
floatingtank
bodybuilding supplements