[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-…
[View More]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
[View Less]
11 years
[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, …
[View More]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
[View Less]
11 years
[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 …
[View More]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
[View Less]
11 years
[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
> …
[View More] 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
[View Less]
11 years
[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:…
[View More] 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
[View Less]
11 years
[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
> ------------------------------------------------
>
> …
[View More] 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
[View Less]
11 years