[JBoss JIRA] (JBTM-1665) Remove dependency on TAO
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1665?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1665:
--------------------------------
Assignee: Crispin Boylan (was: Amos Feng)
> Remove dependency on TAO
> ------------------------
>
> Key: JBTM-1665
> URL: https://issues.jboss.org/browse/JBTM-1665
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Tom Jenkinson
> Assignee: Crispin Boylan
> Fix For: 5.0.0.M5
>
>
> Part of the purpose of adding the socket server was to reduce the dependency on TAO, e.g.:
> ==6038== 20 bytes in 1 blocks are still reachable in loss record 7 of 54
> ==6038== at 0x4026011: calloc (vg_replace_malloc.c:593)
> ==6038== by 0x55C90A5: _dlerror_run (in /lib/libdl-2.12.so)
> ==6038== by 0x55C8B70: dlopen@(a)GLIBC_2.1 (in /lib/libdl-2.12.so)
> ==6038== by 0x40E2875: ACE_DLL_Handle::open(char const*, int, void*) (OS_NS_dlfcn.inl:124)
> ==6038== by 0x40E2D2B: ACE_DLL_Manager::open_dll(char const*, int, void*) (DLL_Manager.cpp:575)
> ==6038== by 0x40A3943: ACE_DLL::open_i(char const*, int, bool, void*) (DLL.cpp:167)
> ==6038== by 0x40A3AAA: ACE_DLL::open(char const*, int, bool) (DLL.cpp:127)
> ==6038== by 0x40A4C0A: ACE_Location_Node::open_dll(int&) (Parse_Node.cpp:479)
> ==6038== by 0x40A4D4B: ACE_Function_Node::symbol(ACE_Service_Gestalt*, int&, void (**)(void*)) (Parse_Node.cpp:657)
> ==6038== by 0x40A5627: ACE_Service_Type_Factory::make_service_type(ACE_Service_Gestalt*) const (Parse_Node.cpp:880)
> ==6038== by 0x40ACEA6: ACE_Service_Gestalt::initialize(ACE_Service_Type_Factory const*, char const*) (Service_Gestalt.cpp:552)
> ==6038== by 0x40A5555: ACE_Dynamic_Node::apply(ACE_Service_Gestalt*, int&) (Parse_Node.cpp:326)
> ==6038== by 0x40B3302: ace_yyparse(void*) (Svc_Conf_y.cpp:1440)
> ==6038== by 0x40AA5C7: ACE_Service_Gestalt::process_directives_i(ACE_Svc_Conf_Param*) (Service_Gestalt.cpp:800)
> ==6038== by 0x40AD407: ACE_Service_Gestalt::process_directive(char const*) (Service_Gestalt.cpp:940)
> ==6038== by 0x4287A65: TAO::ORB::open_global_services(int, char**) (Service_Config.inl:154)
> ==6038== by 0x4247EB3: CORBA::ORB_init(int&, char**, char const*) (ORB.cpp:1254)
> ==6038== by 0x49172F6: initOrb(char*) (OrbManagement.cxx:73)
> ==6038== by 0x4AB97C4: atmibroker::tx::OTSTxManager::OTSTxManager(char*) (OTSTxManager.cxx:39)
> ==6038== by 0x4ABA054: atmibroker::tx::OTSTxManager::create(char*) (OTSTxManager.cxx:57)
> ==6038== by 0x4AB0BDC: atmibroker::tx::TxManager::get_instance() (TxManager.cxx:63)
> ==6038== by 0x4AE7D06: txManager_open() (TxManagerAvoid.cxx:23)
> ==6038== by 0x4AD74D4: tx_open (TxAvoid.cxx:53)
> ==6038== by 0x804FF8D: TestXAStompConnection::test() (TestXAStompConnection.cxx:79)
> ==6038== by 0x805945B: CppUnit::TestCaller<TestXAStompConnection>::runTest() (TestCaller.h:166)
> ==6038== by 0xA5DC76: CppUnit::TestCaseMethodFunctor::operator()() const (TestCase.cpp:32)
> ==6038== by 0xA4F53D: CppUnit::DefaultProtector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (DefaultProtector.cpp:15)
> ==6038== by 0xA59812: CppUnit::ProtectorChain::ProtectFunctor::operator()() const (ProtectorChain.cpp:20)
> ==6038== by 0xA59544: CppUnit::ProtectorChain::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (ProtectorChain.cpp:77)
> ==6038== by 0xA65EF0: CppUnit::TestResult::protect(CppUnit::Functor const&, CppUnit::Test*, std::string const&) (TestResult.cpp:178)
> ==6038== by 0xA5D97C: CppUnit::TestCase::run(CppUnit::TestResult*) (TestCase.cpp:92)
> ==6038== by 0xA5E2DE: CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) (TestComposite.cpp:64)
> ==6038== by 0xA5E219: CppUnit::TestComposite::run(CppUnit::TestResult*) (TestComposite.cpp:23)
> ==6038== by 0xA5E2DE: CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) (TestComposite.cpp:64)
> ==6038== by 0xA5E219: CppUnit::TestComposite::run(CppUnit::TestResult*) (TestComposite.cpp:23)
> ==6038== by 0xA6850F: CppUnit::TestRunner::WrappingSuite::run(CppUnit::TestResult*) (TestRunner.cpp:47)
> ==6038== by 0xA65C89: CppUnit::TestResult::runTest(CppUnit::Test*) (TestResult.cpp:145)
> ==6038== by 0xA6834F: CppUnit::TestRunner::run(CppUnit::TestResult&, std::string const&) (TestRunner.cpp:96)
> ==6038== by 0xA6BA7A: CppUnit::TextTestRunner::run(CppUnit::TestResult&, std::string const&) (TextTestRunner.cpp:140)
> ==6038== by 0xA6BAF4: CppUnit::TextTestRunner::run(std::string, bool, bool, bool) (TextTestRunner.cpp:64)
--
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
12 years, 10 months
[JBoss JIRA] (JBTM-1855) No unit tests for queue with RTS transport
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1855?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1855:
-------------------------------------
[~gytis], [~zhfeng] mentioned that he had asked you to review: https://github.com/zhfeng/narayana/commit/b51faee71db0977898f471e806b5e88...
Have you had chance to do this yet?
> No unit tests for queue with RTS transport
> ------------------------------------------
>
> Key: JBTM-1855
> URL: https://issues.jboss.org/browse/JBTM-1855
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: BlackTie, REST, Testing
> Reporter: Crispin Boylan
> Assignee: Amos Feng
> Fix For: 5.0.0.M5
>
>
> There are currently no tests that use RTS for C++ queue tests. You can tell this as TXN_CFG is not specific in the btconfig.xml.
> When TXN_CFG is manually added to the btconfig.xml the tests actually fail with error:
> 15:15:44,584 ERROR [jacorb.orb] (StompConnect Transport: tcp:///127.0.0.1:49804) Exception while converting string to object: java.lang.IllegalArgumentException: Invalid or unreadable URL/IOR: <?xml version="1.0" encoding="UTF-8" standalone="yes"?><coordinator><status>TransactionActive</status><created>1970-01-01T01:00:00.060+01:00</created><timeout>300</timeout><txnURI>http://127.0.0.1:8080/rest-tx/tx/transaction-manager/0_ffff7f000001_107d7...</txnURI><terminatorURI>http://127.0.0.1:8080/rest-tx/tx/transaction-manager/0_ffff7f000001_107d7...</terminatorURI><durableParticipantEnlistmentURI>http://127.0.0.1:8080/rest-tx/tx/transaction-manager/0_ffff7f000001_107d7...</durableParticipantEnlistmentURI><volatileParticipantEnlistmentURI>http://127.0.0.1:8080/rest-tx/tx/transaction-manager/0_ffff7f000001_107d7...</volatileParticipantEnlistmentURI></coordinator>
> at org.jacorb.orb.ParsedIOR.parse(ParsedIOR.java:484) [jacorb-2.3.2.jbossorg-4.jar:]
> at org.jacorb.orb.ParsedIOR.parse(ParsedIOR.java:486) [jacorb-2.3.2.jbossorg-4.jar:]
> at org.jacorb.orb.ParsedIOR.<init>(ParsedIOR.java:225) [jacorb-2.3.2.jbossorg-4.jar:]
> at org.jacorb.orb.ORB.string_to_object(ORB.java:1961) [jacorb-2.3.2.jbossorg-4.jar:]
> at org.codehaus.stomp.jms.ProtocolConverter.createControlWrapper(ProtocolConverter.java:110) [blacktie-stompconnect-5.0.0.M4-SNAPSHOT.jar:]
> at org.codehaus.stomp.jms.ProtocolConverter.controlToTx(ProtocolConverter.java:98) [blacktie-stompconnect-5.0.0.M4-SNAPSHOT.jar:]
> at org.codehaus.stomp.jms.ProtocolConverter.onStompReceive(ProtocolConverter.java:310) [blacktie-stompconnect-5.0.0.M4-SNAPSHOT.jar:]
> at org.codehaus.stomp.jms.ProtocolConverter.onStompFrame(ProtocolConverter.java:172) [blacktie-stompconnect-5.0.0.M4-SNAPSHOT.jar:]
> at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:103) [blacktie-stompconnect-5.0.0.M4-SNAPSHOT.jar:]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_06-icedtea]
--
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
12 years, 10 months
[JBoss JIRA] (JBTM-1641) EAP 6.1 CNFE org.jboss.tm.TxManager (from Module org.jboss.jboss-transaction-spi:main)
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1641?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1641:
--------------------------------
Fix Version/s: 5.0.0.M5
(was: 5.0.0.Final)
> EAP 6.1 CNFE org.jboss.tm.TxManager (from Module org.jboss.jboss-transaction-spi:main)
> --------------------------------------------------------------------------------------
>
> Key: JBTM-1641
> URL: https://issues.jboss.org/browse/JBTM-1641
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Application Server Integration
> Affects Versions: 4.17.3
> Reporter: Darryl Miles
> Assignee: Michael Musgrove
> Priority: Minor
> Fix For: 5.0.0.M5
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> When enabling additional logging to system DEBUG on startup of standalone-full.xml it is possible to see:
> 07:15:40,780 DEBUG [org.jboss.tm.TransactionManagerLocator] (MSC service thread 1-2) Unable to lookup: java:/TransactionManager: javax.naming.NameNotFoundException: Error looking up TransactionManager, service service jboss.naming.context.java.TransactionManager is not started
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:132) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:80) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:197) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:120) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_17]
> at org.jboss.tm.TransactionManagerLocator.tryJNDI(TransactionManagerLocator.java:150) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locate(TransactionManagerLocator.java:131) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locateTransactionManager(TransactionManagerLocator.java:94) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<init>(ServerVMClientUserTransaction.java:93) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<clinit>(ServerVMClientUserTransaction.java:60) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:115) [jboss-as-transactions-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 07:15:40,786 DEBUG [org.jboss.tm.TransactionManagerLocator] (MSC service thread 1-2) Unable to instantiate legacy transaction manager: java.lang.ClassNotFoundException: org.jboss.tm.TxManager from [Module "org.jboss.jboss-transaction-spi:main" from local module loader @634f6b14 (finder: local module finder @72ff20fb (roots: F:\Devel\deps\jboss-eap-6.1\modules,F:\Devel\deps\jboss-eap-6.1\modules\system\layers\base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) [jboss-modules.jar:1.2.0.CR1]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_17]
> at java.lang.Class.forName(Class.java:188) [rt.jar:1.7.0_17]
> at org.jboss.tm.TransactionManagerLocator.usePrivateAPI(TransactionManagerLocator.java:172) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locate(TransactionManagerLocator.java:133) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locateTransactionManager(TransactionManagerLocator.java:94) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<init>(ServerVMClientUserTransaction.java:93) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<clinit>(ServerVMClientUserTransaction.java:60) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:115) [jboss-as-transactions-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
--
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
12 years, 10 months
[JBoss JIRA] (JBTM-1482) If a naughty afterCompletion sync throws an exception, log the exception call stack
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1482?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reassigned JBTM-1482:
-----------------------------------
Assignee: Tom Jenkinson (was: Gytis Trikleris)
> If a naughty afterCompletion sync throws an exception, log the exception call stack
> -----------------------------------------------------------------------------------
>
> Key: JBTM-1482
> URL: https://issues.jboss.org/browse/JBTM-1482
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Reporter: Scott Marlow
> Assignee: Tom Jenkinson
> Priority: Minor
> Fix For: 5.0.0.M5
>
> Original Estimate: 30 minutes
> Remaining Estimate: 30 minutes
>
> Currently, when this happens with AS, I see:
> {quote}
> 2013-02-18 16:24:43,837|WARN |[com.arjuna.ats.jta]|(ThreadId: Transaction Reaper Worker 221)|ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.jboss.as.jpa.transaction.TransactionUtil$SessionSynchronization@634ef5a7 with exception: java.lang.NullPointerException
> {quote}
> From a related email conversation:
> {quote}
> Here's our Logger code:
> @Message(id = 16029, value = "SynchronizationImple.afterCompletion - failed for {0} with exception", format = MESSAGE_FORMAT)
> @LogMessage(level = WARN)
> public void warn_resources_arjunacore_SynchronizationImple(String arg0, @Cause() Throwable arg1);
> Here is where we call our logger:
> jtaLogger.i18NLogger.warn_resources_arjunacore_SynchronizationImple(_theSynch.toString(), e);
> Maybe the message should have the {1} in it, i.e. it change it like so:
> "SynchronizationImple.afterCompletion - failed for {0} with exception {1}"
> {quote}
--
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
12 years, 10 months
[JBoss JIRA] (JBTM-1042) GC: No relationship between generic parameter and method argument (GC_UNRELATED_TYPES)
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1042?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1042:
--------------------------------
Priority: Major (was: Minor)
> GC: No relationship between generic parameter and method argument (GC_UNRELATED_TYPES)
> --------------------------------------------------------------------------------------
>
> Key: JBTM-1042
> URL: https://issues.jboss.org/browse/JBTM-1042
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Amos Feng
> Assignee: Amos Feng
> Fix For: 5.0.0.M5
>
>
> 1.XTS/recovery
> org.jboss.jbossts.xts.recovery.participant.at.XTSATRecoveryManagerImple Line 132
> com.arjuna.ats.arjuna.common.Uid is incompatible with expected argument type String in org.jboss.jbossts.xts.recovery.participant.at.XTSATRecoveryManagerImple.isParticipantPresent(Uid)
> 2.XTS/recovery
> org.jboss.jbossts.xts.recovery.participant.ba.XTSBARecoveryManagerImple Line 128
> com.arjuna.ats.arjuna.common.Uid is incompatible with expected argument type String in org.jboss.jbossts.xts.recovery.participant.ba.XTSBARecoveryManagerImple.isParticipantPresent(Uid)
--
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
12 years, 10 months
[JBoss JIRA] (JBTM-1042) GC: No relationship between generic parameter and method argument (GC_UNRELATED_TYPES)
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1042?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1042:
-------------------------------------
It does look like a bug to me, the uidMap in both cases is string -> uid but we are trying to call get with a uid, rather than an id.
It looks like it is used during recovery to work out if there is a particant alive, it will always return false so you will get more than one loaded. I think...
> GC: No relationship between generic parameter and method argument (GC_UNRELATED_TYPES)
> --------------------------------------------------------------------------------------
>
> Key: JBTM-1042
> URL: https://issues.jboss.org/browse/JBTM-1042
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 5.0.0.M5
>
>
> 1.XTS/recovery
> org.jboss.jbossts.xts.recovery.participant.at.XTSATRecoveryManagerImple Line 132
> com.arjuna.ats.arjuna.common.Uid is incompatible with expected argument type String in org.jboss.jbossts.xts.recovery.participant.at.XTSATRecoveryManagerImple.isParticipantPresent(Uid)
> 2.XTS/recovery
> org.jboss.jbossts.xts.recovery.participant.ba.XTSBARecoveryManagerImple Line 128
> com.arjuna.ats.arjuna.common.Uid is incompatible with expected argument type String in org.jboss.jbossts.xts.recovery.participant.ba.XTSBARecoveryManagerImple.isParticipantPresent(Uid)
--
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
12 years, 10 months
[JBoss JIRA] (JBTM-1802) Consider moving Arquillian profiles to root pom.xml
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1802?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1802:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 5.0.0.M5)
> Consider moving Arquillian profiles to root pom.xml
> ---------------------------------------------------
>
> Key: JBTM-1802
> URL: https://issues.jboss.org/browse/JBTM-1802
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Build System, Testing
> Reporter: Paul Robinson
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 6.0.0.Final
>
>
> We have three Arquillian profiles (for managed, remote and ipv6-managed) present in the pom of nearly every test that uses Arquillian. I suspect they can all be identical and thus placed int he root pom.xml. This should simplify maintenance and will ensure any fixes to this config are made throughout.
> The problem is that we may have legitimate reasons for this config to differ for some tests. Maybe we could use overrides in these cases.
> Assigning to Tom for his input.
--
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
12 years, 10 months