Just a heads up to check the changes on master in how JtaPlatformInitiator works now.
On Thu 09 Aug 2012 09:10:18 AM CDT, Steve Ebersole wrote: > Yes this is exactly what I meant. > > By renaming, what I mean is that a user could very well rename the jar > file themselves and things would generally continue to work because > java is based on classloading and the names of jars are irrelevant to > classloading (other than feeding class path). > > I also wanted to make sure this process is extensible by the user. So > either making this a service, or allowing specification (somehow) of > additional resolution keys. > > On Wed 08 Aug 2012 02:17:19 AM CDT, Łukasz Antoniak wrote: >> Hello Steve, >> >> Thank you for the quick response. To be honest I don't know why I have >> decided to implement it this way. Probably I have focused more on >> design and implementation than recognition of runtime environment >> itself :(. >> By performing known class lookup do you mean something like >> "registry.getService( ClassLoaderService.class ).classForName( >> "weblogic.Server" )" and check for ClassLoadingException? >> "weblogic.Server" is the main application server class. >> >> BTW, actually for WebLogic main class has changed between versions 11 >> and 12 so I will have to think of another "known class" or interpret >> collection as alternatives :). >> >> Regards, >> Lukasz >> >> 2012/8/7 Steve Ebersole <st...@hibernate.org>: >>> 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 > > -- > st...@hibernate.org > http://hibernate.org -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
