I recently added support to Jopr, The JBoss management platform project ( http://www.jboss.org/jopr ) to be able to monitor Hibernate via the Hibernate Statistics MBean. For background, see my blog entry: http://management-platform.blogspot.com/2008/11/monitoring-hibernate.html and more specifically, see the demo flash: https://docs.jbosson.redhat.com/confluence/display/JON2/Demo-MonitoringHi... If you watch that demo, you can see how useful the Hibernate Statistics data can be (e.g. when used by external management tools like Jopr you can track the performance of Hibernate over time, send alerts based on that performance data, etc. etc.). But for users to be able to monitor their Hibernate applications from an external management tool, it isn't enough for them to specify the "hibernate.generate_statistics" configuration setting. They must expose those statistics via JMX; however, that puts a burden on the Hibernate developer to write special code to do this (as the example code in the blog illustrates - see Max's comments on my blog and my responses also). Out of that, I submitted this JIRA: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3593 Last night I wrote the code that implements this enhancement request and attached the patch to that JIRA. The short of it is, the Hibernate developer no longer has to write any Java code to expose the statistics via JMX, all you have to do is set these configuration settings: hibernate.generate_statistics.jmx=true hibernate .generate_statistics .jmx.object_name=hibernate:type=statistics,application=foo hibernate.generate_statistics.jmx.mbeanserver=*platform* If you set those, statistics generation will be turned on, the Hibernate Statistics MBean will be exposed via JMX and if you enabled the VM for remote JMX, you can immediately begin to monitor Hibernate (you'll even see the Hibernate MBean via jconsole, though things like Jopr will provide better functionality like viewing historical stat data, alerting and the like). As the JIRA mentions, this patch does NOT introduce any JMX compile- time dependencies (due to the requirement that Hibernate be able to support JDK 1.4). Therefore, you will not see any "javax.management.*" imports or classes being used directly (they are used via reflection). However, if you enable this JMX statistics feature, obviously, you must run in JRE 5+ or JRE 1.4 + JMX libraries - if you do not, this code will log error messages saying what the problem is and simply disable the JMX stats capability (but otherwise, hibernate works normally). Any suggestions how I might further this along to get it merged? Or is this patch good enough for some Hibernate developer to merge it in and take it over? John Mazz _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

To be sure, hibernate.generate_statistics is usually not enough if you want to use a monitoring tool (since it is generally not the case that your monitoring tool is running in the same VM as the hibernate app and can access the statistics object directly). > The main problem is that it feels odd for Hibernate to be responsible > for the Bean Server startup. I thought the opposite - I don't like having to ask developers to write special code in their apps to be able to peek at their hibernate stats. I should be able to take any hibernate application, add a couple configuration settings to enable stats and be able to peek at the stats from an external monitoring tool. As it is right now, given a hibernate app without this special code built in somewhere, there is no way for me to monitor it. > If we nevertheless go that path, we need to enhance a few things: > - sessionFactory.close() should release the Bean Server if it started > one initially (good citizen) > - sessionFactory.close() should release the MBean good points. > - it would be nice to find a better way than the *platform* hack ( > maybe hibernate.generate_statistics.jmx.mbeanserver.plaform = true ) I didn't go this route because I didn't want two properties setting the same thing, and possibly saying two different things. For example, I don't want the possibility of someone accidentally doing this: ...jmx.mbeanserver = my_mbean_server ...jmx.mbeanserver.plaform = true That's saying "use the platform MBeanServer" *and* "use the MBeanServer with a default domain name of "my_mbean_server". Which takes effect? I didn't want someone to do something confusing like this. _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

I don't know the MBean security model. How do I ensure that an given MBean is restricted in view / write access?

Spring and a lot of other containers like JBoss's Microcontainer make it pretty easy to deploy the statistics MBean. E.g. in Spring: <bean id="hibernateStatisticsService" class="org.hibernate.jmx.StatisticsService"> <property name="sessionFactory"> <bean factory-bean="entityManagerFactory" factory-method="getSessionFactory"/> </property> </bean> <bean id="jmxBeanExporter" class="org.springframework.jmx.export.MBeanExporter"> <property name="beans"> <map> <entry key=":type=HibernateStatisticsService" value-ref="hibernateStatisticsService"/> </map> </property> <property name="server" ref="platformMBeanServer"/> </bean> Probably it's more of a documentation issue to explain to users how to do this than to provide a configuration facility. I don't see this as hard as a user.

But even under JSE it's trivial to publish an MBean in a few lines of Java code as well:

Let's instead burn some calories in Hibernate 3.3 getting natural ID key caching working properly, okay? :-)

John, follow Steve's lead and put it in hibernate-jmx module. These statistics have been hidden all too long for users of Hibernate IMO. This setting will make it available. IMO it is not a security issue since its not enabled by default and similar to users of AS can go enable jmx console without a password or the standard password. Wether we have a simple setting for this or users put mutations of different ways of setting up JMX doesn't make much of a difference does it ? /max >> But even under JSE it's >> trivial to publish an MBean in a few lines of Java code as well: > > Well, that's my whole point in this exercise. We shouldn't require > people to introduce this code (albeit trivial) in their app just so it > can be monitored (after all, how many app developers actually take it > upon themselves to write code whose sole purpose is monitoring?). And > once you put it in, you probably will want additional code to > introduce a way to disable it if you need to - see Emmanuel's point > about security. It should be configurable directly from the framework > itself. > >> Let's instead burn some calories in Hibernate 3.3 getting natural ID >> key caching working properly, okay? :-) > > I've already burned the calories myself (it is working with the patch > I attached to the JIRA). And since I don't work on other parts of > Hibernate, I'm not diverting resources from it. But, if this work > isn't deemed contributable or highly useful, let me know and I'll stop > working on it. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

Next major release of Hibernate will be much more modularized than earlier. It's in trunk, so not something that is going to show up in 3.2.x. -max > hibernate-jmx is actually news to me - I didn't realize there was such a > module. > > Is it easy for someone with an existing app to plop this hibernate-jmx > module (.jar?) in their app deployment and have it "just work"? > > I'm curious if this is going to be shipped with, say, JBossAS, so its > already available to people without downloading it separately. > > I'll see if I can read up some more on that module. > > Max Rydahl Andersen wrote: >> John, follow Steve's lead and put it in hibernate-jmx module. >> These statistics have been hidden all too long for users of Hibernate >> IMO. >> This setting will make it available. >> IMO it is not a security issue since its not enabled by default and >> similar >> to users of AS can go enable jmx console without a password or the >> standard password. >> Wether we have a simple setting for this or users put mutations of >> different ways of >> setting up JMX doesn't make much of a difference does it ? >> /max >> >>>> But even under JSE it's >>>> trivial to publish an MBean in a few lines of Java code as well: >>> >>> Well, that's my whole point in this exercise. We shouldn't require >>> people to introduce this code (albeit trivial) in their app just so it >>> can be monitored (after all, how many app developers actually take it >>> upon themselves to write code whose sole purpose is monitoring?). And >>> once you put it in, you probably will want additional code to >>> introduce a way to disable it if you need to - see Emmanuel's point >>> about security. It should be configurable directly from the framework >>> itself. >>> >>>> Let's instead burn some calories in Hibernate 3.3 getting natural ID >>>> key caching working properly, okay? :-) >>> >>> I've already burned the calories myself (it is working with the patch >>> I attached to the JIRA). And since I don't work on other parts of >>> Hibernate, I'm not diverting resources from it. But, if this work >>> isn't deemed contributable or highly useful, let me know and I'll stop >>> working on it. >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev