Good evening, I've been working with 3.1.2, and was in love with the concept of transparently persisting "hibernatable" domain objects within a process. There is a slight, what I would call counterintuitive problem with the default variable mapping config file related to this though... objects that are Serializable even though they are "hibernatable" will be, by default, persisted in the process via serialization rather than hibernate. This is due to the sequence of matcher/converter declarations in the default config file. As the engine is trying to figure out how to save a process variable to the DB, it will encounter the serializable converter PRIOR to the HibernateLongVariableInstance... (as they're checked sequentially) so when a user attempts to utilize the default behavior with their domain object (and it happens to be serializable), they'll be in for a big surprise as it won't actually utilize the hibernate variable instances OOTB. This can be fixed by providing your own config file in the root of the classpath - blah blah blah. As far as I'm concerned though the default behavior should be a bit more intuitive and attempt to use the hibernate variable instances prior to the serializable variable instance. simply changing the ordering in the default file makes things work as one would expect (IMHO). Also on this subject - there's a bit of code in the match() (name?) method of the hibernateLongID variable instance impl that is a bit odd - the class metadata for an object's class is fetched (if possible). If it exists, the identifier type's class is compared == to LongType.class... this caused me no end of problem. The question is - why is it comparing the identifier's class == rather than using instanceof or assignable from to determine if the object can use that particular variableInstance implementation. Please pardon the ramblingness of this post - it's late and I've been wrestling with this, trying to get the most intuitive behavior in our app all day. Thanks. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967680#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...