-
15. Re: ObjectStoreDir location
"bill.burke@jboss.com" wrote:
And the config file location System Property is? (Thanks for being my manual)
I suppose you're just lucky Adrian isn't watching ;-)com.arjuna.ats.arjuna.common.propertiesFile
is used to set the file name. If not passed an absolute filename (starting with the string abs://), then the system searches for the file in the order:
* current working directory
* in the directory specified by the system property user.dir
* in the directory specified by the system property user.home
* in the directory specified by the system property java.home
* using the getResource() method
Hope that helps. -
16. Re: ObjectStoreDir location
"Kevin.Conner@jboss.com" wrote:
"dimitris@jboss.org" wrote:
If you can just introduce property substitution that would be great.
JBossTS is a standalone transaction manager and does not currently support this. Overriding the default value in the integration layer would, however, allow you to configure it via the mbean and therefore take advantage of the substitution support in the app server.
Kev
You mean add it to the com.arjuna.ats.jbossatx.jta.TransactionManagerService mbean?
Maybe this integrating mbean should live in the jboss codebase, that would make thinks a lot easier when applying small changes like this. -
17. Re: ObjectStoreDir location
There's a separate integration module in the TS code, where integration code for application servers exists. These days it only has AS code in there, but over the years the amount of code there has grown and shrunk. I prefer the current approach because then there's a single location for all integration code related to TS and supported platforms.
Kev will know for sure, but I suspect this code lives in its own jar. If that's the case then rebuilding that shouldn't ever require a re-QA of the stand-alone TS: just re-QA for the integration. -
18. Re: ObjectStoreDir location
"mark.little@jboss.com" wrote:
There's a separate integration module in the TS code, where integration code for application servers exists. These days it only has AS code in there, but over the years the amount of code there has grown and shrunk. I prefer the current approach because then there's a single location for all integration code related to TS and supported platforms.
This would also be my preference as we would normally only change it if there was a change in the associated core libraries."mark.little@jboss.com" wrote:
Kev will know for sure, but I suspect this code lives in its own jar. If that's the case then rebuilding that shouldn't ever require a re-QA of the stand-alone TS: just re-QA for the integration.
Yes, that is correct. This has no bearing on our standalone QA run and is tested using the AS testsuite.
Kev