Ok guys, so it's going to be work. No 'magic' solution :-(
Oh well... thanks for trying. The static initializer is ugly and has big comments above it "remove before production release" but its in a central place and will always get called. I'll have to check if a war even gets deployed. This is the most paranoid - ah.. sorry 'security concious' :-) - environment I have ever worked in. Koens suggestion is what I was going for with the version number (not the hibernate version number) in the processDefinition. Only if its not in the processDefintion itself I'll have to store version numbers in an own DB table :-( I'll try out both approaches, but I like the 'dummy' Node approach best. @Johan Shit happens. What I'm going for is a fail safe process. (I randomly sprinkle Exceptions at a 60% rate and still expect everything to workout fine.) I haven't checked the possible szenarios but anything that relies on hibernate version numbers is critical as I have no way of knowing the current hibernate version number when packaging the ear. Thanks again Rainer View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3916862#3916862 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3916862 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
