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 <steve(a)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/3df34efad32ceed9....
>>>
>>>
>>> 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(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> --
>>> steve(a)hibernate.org
>>>
http://hibernate.org
--
steve(a)hibernate.org
http://hibernate.org