[JBoss JIRA] (JBTM-1981) Provide a quickstart that shows how to enlist a JDBC resource outside of the application server
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1981?page=com.atlassian.jira.plugin.... ]
Michael Musgrove resolved JBTM-1981.
------------------------------------
Resolution: Rejected
I added some tests in the linked JIRA that show how to use the transactional driver. However, I don't want to produce a quickstart that pulls out the essentials since we need to move to an embedded JCA solution and such a quickstart would encourage more legacy usages of the driver.
> Provide a quickstart that shows how to enlist a JDBC resource outside of the application server
> -----------------------------------------------------------------------------------------------
>
> Key: JBTM-1981
> URL: https://issues.jboss.org/browse/JBTM-1981
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Demonstrator
> Reporter: Tom Jenkinson
> Assignee: Michael Musgrove
> Priority: Minor
> Fix For: 6.0.0.Final
>
>
> It would be useful to see how to use a JDBC connection outside of the application server. The example should demonstrate recovery.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBTM-2081) Why do we mandate the property file?
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2081?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-2081:
-----------------------------------
I think your idea of requiring it for JTA or JTS is a good start. Beyond that I wonder if we could infer these default values (e.g., JTA implementation) by what's in your class path? Maybe a separate JIRA?
> Why do we mandate the property file?
> ------------------------------------
>
> Key: JBTM-2081
> URL: https://issues.jboss.org/browse/JBTM-2081
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 5.0.0.Final
> Reporter: Mark Little
> Assignee: Tom Jenkinson
>
> I noticed this originally when doing the Android port, but now again when doing vert.x: at some point over the years we appear to have moved to a model where the properties file must be present (e.g., in class path or CWD) or we exit. I'm not sure why we do this given that every property has a default value anyway.
> For example:
> java.lang.ExceptionInInitializerError: null
> at com.arjuna.common.util.propertyservice.PropertiesFactory.getPropertiesFromFile(PropertiesFactory.java:93)
> at com.arjuna.common.util.propertyservice.PropertiesFactory.initDefaultProperties(PropertiesFactory.java:236)
> at com.arjuna.common.util.propertyservice.PropertiesFactory.getDefaultProperties(PropertiesFactory.java:66)
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:77)
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:49)
> at com.arjuna.ats.txoj.common.txojPropertyManager.getTxojEnvironmentBean(txojPropertyManager.java:48)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBTM-2081) Why do we mandate the property file?
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2081?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2081:
-------------------------------------
Its set up for JTS mode: https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/narayana-jts-ja...
If you _didn't_ provide a config file, you would get a none-JTS transaction manager if you were using UserTransaction/TransactionManager (or arjunacore if you aren't) but with no recoveryModuleClassNames, xaResourceOrphanFilterClassNames.
> Why do we mandate the property file?
> ------------------------------------
>
> Key: JBTM-2081
> URL: https://issues.jboss.org/browse/JBTM-2081
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 5.0.0.Final
> Reporter: Mark Little
> Assignee: Tom Jenkinson
>
> I noticed this originally when doing the Android port, but now again when doing vert.x: at some point over the years we appear to have moved to a model where the properties file must be present (e.g., in class path or CWD) or we exit. I'm not sure why we do this given that every property has a default value anyway.
> For example:
> java.lang.ExceptionInInitializerError: null
> at com.arjuna.common.util.propertyservice.PropertiesFactory.getPropertiesFromFile(PropertiesFactory.java:93)
> at com.arjuna.common.util.propertyservice.PropertiesFactory.initDefaultProperties(PropertiesFactory.java:236)
> at com.arjuna.common.util.propertyservice.PropertiesFactory.getDefaultProperties(PropertiesFactory.java:66)
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:77)
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:49)
> at com.arjuna.ats.txoj.common.txojPropertyManager.getTxojEnvironmentBean(txojPropertyManager.java:48)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBTM-2081) Why do we mandate the property file?
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2081?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-2081:
-----------------------------------
What values are in the default properties file these days?
> Why do we mandate the property file?
> ------------------------------------
>
> Key: JBTM-2081
> URL: https://issues.jboss.org/browse/JBTM-2081
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 5.0.0.Final
> Reporter: Mark Little
> Assignee: Tom Jenkinson
>
> I noticed this originally when doing the Android port, but now again when doing vert.x: at some point over the years we appear to have moved to a model where the properties file must be present (e.g., in class path or CWD) or we exit. I'm not sure why we do this given that every property has a default value anyway.
> For example:
> java.lang.ExceptionInInitializerError: null
> at com.arjuna.common.util.propertyservice.PropertiesFactory.getPropertiesFromFile(PropertiesFactory.java:93)
> at com.arjuna.common.util.propertyservice.PropertiesFactory.initDefaultProperties(PropertiesFactory.java:236)
> at com.arjuna.common.util.propertyservice.PropertiesFactory.getDefaultProperties(PropertiesFactory.java:66)
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:77)
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:49)
> at com.arjuna.ats.txoj.common.txojPropertyManager.getTxojEnvironmentBean(txojPropertyManager.java:48)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBTM-2081) Why do we mandate the property file?
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2081?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2081:
-------------------------------------
Would the intention also be to no longer ship a default jbossts-properties.xml file in the jars, and to no longer be able to change the default name of the config file in the manifest.mf?
> Why do we mandate the property file?
> ------------------------------------
>
> Key: JBTM-2081
> URL: https://issues.jboss.org/browse/JBTM-2081
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 5.0.0.Final
> Reporter: Mark Little
> Assignee: Tom Jenkinson
>
> I noticed this originally when doing the Android port, but now again when doing vert.x: at some point over the years we appear to have moved to a model where the properties file must be present (e.g., in class path or CWD) or we exit. I'm not sure why we do this given that every property has a default value anyway.
> For example:
> java.lang.ExceptionInInitializerError: null
> at com.arjuna.common.util.propertyservice.PropertiesFactory.getPropertiesFromFile(PropertiesFactory.java:93)
> at com.arjuna.common.util.propertyservice.PropertiesFactory.initDefaultProperties(PropertiesFactory.java:236)
> at com.arjuna.common.util.propertyservice.PropertiesFactory.getDefaultProperties(PropertiesFactory.java:66)
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:77)
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:49)
> at com.arjuna.ats.txoj.common.txojPropertyManager.getTxojEnvironmentBean(txojPropertyManager.java:48)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBTM-1227) StAX is not available on Android
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1227?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris commented on JBTM-1227:
---------------------------------------
It wasn't merged. But I have actually started to work on android quickstart today. So I'll check if there is anything needing an update here and will merge it if everything is ok.
> StAX is not available on Android
> --------------------------------
>
> Key: JBTM-1227
> URL: https://issues.jboss.org/browse/JBTM-1227
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Common
> Affects Versions: 4.16.4, 5.0.0.M1
> Environment: Android 2.3.3
> Reporter: Mark Little
> Assignee: Gytis Trikleris
> Fix For: 6.0.0.Final
>
>
> StAX is not available. Since we use it for property configuration, the system fails to run unmodified. There is an equivalent implementation (XmlPullParser) but it is likely other JBoss projects will suffer from this issue.
> See http://www.ibm.com/developerworks/library/x-android/ for more details.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBTM-2081) Why do we mandate the property file?
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2081?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-2081:
-----------------------------------
Or if there's no property file default to JTA (or JTS)?
> Why do we mandate the property file?
> ------------------------------------
>
> Key: JBTM-2081
> URL: https://issues.jboss.org/browse/JBTM-2081
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 5.0.0.Final
> Reporter: Mark Little
> Assignee: Tom Jenkinson
>
> I noticed this originally when doing the Android port, but now again when doing vert.x: at some point over the years we appear to have moved to a model where the properties file must be present (e.g., in class path or CWD) or we exit. I'm not sure why we do this given that every property has a default value anyway.
> For example:
> java.lang.ExceptionInInitializerError: null
> at com.arjuna.common.util.propertyservice.PropertiesFactory.getPropertiesFromFile(PropertiesFactory.java:93)
> at com.arjuna.common.util.propertyservice.PropertiesFactory.initDefaultProperties(PropertiesFactory.java:236)
> at com.arjuna.common.util.propertyservice.PropertiesFactory.getDefaultProperties(PropertiesFactory.java:66)
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:77)
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:49)
> at com.arjuna.ats.txoj.common.txojPropertyManager.getTxojEnvironmentBean(txojPropertyManager.java:48)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBTM-2082) Upgrade Arquillian Core to 1.1.2.Final-wildfly-1
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-2082?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-2082:
----------------------------------
Status: Pull Request Sent (was: Reopened)
Git Pull Request: https://github.com/jbosstm/narayana/pull/585, https://github.com/jbosstm/narayana/pull/586 (was: https://github.com/jbosstm/narayana/pull/585)
> Upgrade Arquillian Core to 1.1.2.Final-wildfly-1
> ------------------------------------------------
>
> Key: JBTM-2082
> URL: https://issues.jboss.org/browse/JBTM-2082
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Fix For: 6.0.0.Alpha1
>
>
> Current version is incompatible with WildFly 8.0.0.Final-SNAPSHOT (Thu 30/1/2014)
> For example:
> {code}
> com.hp.mwtests.ts.jta.cdi.transactionScoped.TransactionScopedTest Time elapsed: 7.555 sec <<< ERROR!
> java.lang.NoSuchMethodError: org.jboss.arquillian.container.spi.client.deployment.Validate.isArchiveOfType(Ljava/lang/Class;Lorg/jboss/shrinkwrap/api/Archive;)Z
> at org.jboss.arquillian.testenricher.cdi.client.BeansXMLProtocolProcessor.process(BeansXMLProtocolProcessor.java:55)
> at org.jboss.arquillian.protocol.servlet.Processor.process(Processor.java:46)
> at org.jboss.arquillian.protocol.servlet.v_3.ServletProtocolDeploymentPackager.handleArchive(ServletProtocolDeploymentPackager.java:93)
> at org.jboss.arquillian.protocol.servlet.v_3.ServletProtocolDeploymentPackager.handleArchive(ServletProtocolDeploymentPackager.java:99)
> at org.jboss.arquillian.protocol.servlet.v_3.ServletProtocolDeploymentPackager.generateDeployment(ServletProtocolDeploymentPackager.java:75)
> at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.buildTestableDeployments(DeploymentGenerator.java:193)
> at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.createTestableDeployments(DeploymentGenerator.java:148)
> at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.generateDeployment(DeploymentGenerator.java:85)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:100)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months