[hibernate-dev] exposing statistics easier (HHH-3593 solution)

[Emmanuel Bernard]

On  Nov 20, 2008, at 11:47, John Mazzitelli wrote:

> 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.

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

>
>
>> 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.

I understand. But we can raise a config exception and fail fast. With  
your approach, if I name my bean server *platform* and want to deploy  
the Hibernate beans on it, I got screwed.