Hibernate deployer not flexible enough to keep up with Hibernate config changes

The mechanism for parsing and deploying a hibernate.cfg.xml file is overly fragile and prone to falling out of date with respect to configuration options that Hibernate supports. See http://stackoverflow.com/questions/1443192/jbosscache-as-a-second-level-cache-for-hibernate-in-jboss-5/ for an example of how this has broken.

There's a deployer that parses a hibernate.cfg.xml into a metadata object, which includes the set of configuration properties stored as a key/value pairs. But the property names you use have to map to properties on the org.jboss.hibernate.jmx.Hibernate class, because the deployer uses JBoss MC property injection to populate the o.j.h.jmx.Hibernate object. So you can't use the regular Hibernate property names, which include '.' and such. Plus it breaks when Hibernate adds a new property, a la what this user is seeing.

In its start() method the org.jboss.hibernate.jmx.Hibernate class then builds a Hibernate Configuration object, by mapping it's property values back to the standard Hibernate configuration property names.

More sensible IMHO is to inject into the o.j.h.jmx.Hibernate object the original set of parsed key/value pairs via a new setProperties(Set<BaseNamedElement>) method. The start() method would then build the Configuration from that set of properties. This would allow any valid Hibernate property to be used and would remove the need to use AS-specific property names. The Hibernate MBean interface would then just expose whatever properties we've chosen to map.

We should of course also support the legacy AS-specific property names.