I would like to deploy multiple .har files and have them share the same SessionFactory. I have written a replacement for the org.jboss.hibernate.har.Hibernate MBean that allows this, but unfortunately HARDeployer requires that the MBean be of class org.jboss.hibernate.har.Hibernate to set the HarUrl attribute on it.

I have modified HARDeployer::isHibernateMBean() to return true for any MBean that has a HarUrl attribute. With this modified method in HARDeployer, I am able to use my replacement for org.jboss.hibernate.har.Hibernate, and share a single SessionFactory (and Configuration) for multiple .har files.

Below I provide my version of this method. I realize that it may not be adequate for future versions that may require additional attributes/operations on the target MBean, but at least its a start.

Will the Hibernate group please consider this change, and if applicable, adopt it or something else that will allow my to replace org.jboss.hibernate.har.Hibernate to manage SessionFactory instance they way I want/need to?

Sincerely,

Ralph Harnden

private boolean isHibernateMBean(ObjectName service)
{
try
{
MBeanInfo serviceInfo = server.getMBeanInfo( service );
//FIXME return Hibernate.class.getName().equals( serviceInfo.getClassName() );
MBeanAttributeInfo[] attributeInfos = serviceInfo.getAttributes();
int i;
for (i = 0; i < attributeInfos.length; i++)
{
if (attributeInfos[i].getName().equals("HarUrl"))
{
break;
}
}
return (i <= attributeInfos.length);
}
catch( Throwable t )
{
log.warn( "Unable to determine whether MBean [" + service + "] is Hibernate MBean" );
return false;
}
}

That sounds reasonable.

Note, however, that in the next generation of JBoss deployment there will not even be a HARDeployer, per-se. Its logic will simply be an interceptor/aspect which you could apply to any deployment.

Thanks for your reply.

If the HARDeplpyer as it exists today will be deprecated in the next generation of JBoss, then I can survive without this change until then. I can just keep reapplying my "fix" as new releases of the current generation of JBoss emerge. However, if others find this functionality useful, then you may want to consider putting it in the current JBoss.

Also, if anybody is intersted in my mechanism for sharing a single SessionFactory amongst multiple .har files, I am certainly willing to contribute it. I find it very useful, as in our application we will use Hibernate quite heavily in encapsulated components that are packaged in many distinct .har files. It would be very cumbersone to use a SessionFactory for each .har file. Sharing resources across those .har files makes things a lot simpler.

Finally, my mechanism also registers with JNDI the Configuration I use to constuct the SessionFactory (which of course is also registered with JNDI). I do this so that the multiple .har files can add themselves to the common Configuration, but I also find it useful to access the Configuration in the application (at least for testing purposes) once the deployment is complete.

Is there a specific reason why SessionFactory does not make the Configuration used to build it available?

Regards,

Ralph Harnden

Sure: a SessionFactory does not know about the Configuration used to build it. A Configuration is mutable without affecting any factories that it generated...

Thanks again.

That would be a fair answer if the Configuration could be reconstructed by the application using the SessionFactory. However, in the case of the HARDeployer, the Hibernate MBean constructs the Configuration based on the HarUrl, and then discards that Configuration. The application using the SessionFactory cannot access the Configuration used to build the SessionFactory to mutate it, or to do anything else with it for that matter.

My hybrid Hibernate MBean registers the Configuration with JNDI (in addition to the SessionFactory) so applications can get it.

May I be so bold as to suggest that the SessionFactory deep clone the Configuration used to build it, and to provide an accessor method to return a deep clone of that Configuration?

What if a Configuration used to build a SessionFactory is being modified by another thread while the SessionFactory being built is using it? After all, as you mention, it is mutable. Of course, that would probably never occur (yeah, right), but providing a synchronized deep clone method on Configuration would allow the SessionFactory to get a private and immutable copy of that Configuration.

Ralph Harnden