I may well be wrong here but what if you wanted two datasources - we shouldn't really optimize for a 1PC TX in this particular area IMO.
1 of 1 people found this helpful
Changing PropertyFileDynamicClass to also search the classpath seems reasonable, though since DynamicClass is itself an integration point it's also possible to define a new implementation instead, so that existing users don't get surprised by behavior changes. Guess it depends if you want it in a major release or in a maintenance branch. IIRC the only reason it doesn't currently do that, is nobody asked for it. Embedded IronJacamar, or a minimal Wildfly-swarm, are probably more heavily used that tx-driver.
Sure, there is no optimization for 1PC TX in this change.
This is really a small change and contains chage of way how the information about XADataSource is loaded from. The user can define multiple arjuna prefixed datasources, each one will have its own properties file and standard 2PC will be run.
Thank jhalliday. It's a good point about the backward compatibility. I haven't thought about it.
Just I think this behaviour is not kind of removing any functionality. It just adds "one" more way how to load the properties file. Loading from the abs/relative path is retained as default way and if not found then it tries the classpath too. Is not that change (adding functionality) which does not break the compatibility?
I created a JBTM issue on this: [JBTM-2985] Make jdbc transaction driver dynamic properties file being loaded from classpath - JBoss Issue Tracker