Why did you decide to check jar names, rather than perform a known class lookup? 1) Jar names can be changed. 2) System.getProperty( "java.class.path" ) is only going to work in very specific environments (and unfortunately often not the environments that you want to do JTA). 3) Class path scanning for files like this is assuming the environment is set up a certain way (worried about something like JBoss's Virtual File System here)
On Tue 07 Aug 2012 02:19:58 PM CDT, Łukasz Antoniak wrote: > > Hello all, > > I have implemented basic proof of concept regarding JTA platform > recognition. You can find the initial suggestion here: > https://github.com/lukasz-antoniak/hibernate-core/commit/3df34efad32ceed98a98d2af2c831119b4261773. > > Implementation notes: > > 1) Defining JAR archives in classes extending AbstractJtaPlatform > might not be the best option, but I did not want to double each > platform class by introducing something like: > public interface EnterprisePlatform { > public JtaPlatform getJtaPlatform(); > public Collection<Pattern> getCharacteristicJarArchivePatterns(); > } > public class WeblogicEnterprisePlatform implements EnterprisePlatform { > // obvious goes here... > } > Any thoughts? > > 2) Decided to match JAR archive names with regular expressions instead > of strict names because of JAR versioning (case of Bitronix). > > As for now, automatic recognition has been tested on WebLogic 12 and > it seems to work fine. > > I wanted to know your opinion before testing against other application > servers. > > Best Regards, > Lukasz > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- > st...@hibernate.org > http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
