[JBoss JIRA] (JBTM-2874) WildFly to GlassFish interop: Add a quickstart that shows transaction propagation
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2874?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2874:
--------------------------------
Fix Version/s: 5.next
(was: 5.5.6.Final)
> WildFly to GlassFish interop: Add a quickstart that shows transaction propagation
> ---------------------------------------------------------------------------------
>
> Key: JBTM-2874
> URL: https://issues.jboss.org/browse/JBTM-2874
> Project: JBoss Transaction Manager
> Issue Type: Sub-task
> Components: Demonstrator
> Affects Versions: 5.5.5.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.next
>
>
> Currently both app servers need patching. The quickstart will demonstrate:
> # how to patch the servers;
> # link to the WidFly and GlassFish JIRAs that stop interop from working;
> # show how to configure and run transactional ejb calls between the two servers
> A follow up quickstart will demonstrate recovery
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2865) Cache store can get an NPE as work is written to outside of _workList lock
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2865?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2865:
--------------------------------
Fix Version/s: 5.next
(was: 5.5.6.Final)
> Cache store can get an NPE as work is written to outside of _workList lock
> --------------------------------------------------------------------------
>
> Key: JBTM-2865
> URL: https://issues.jboss.org/browse/JBTM-2865
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.next
>
>
> {code}
> java.lang.NullPointerException
> at com.arjuna.ats.internal.arjuna.objectstore.AsyncStore.getState(CacheStore.java:579)
> at com.arjuna.ats.internal.arjuna.objectstore.CacheStore.read_state(CacheStore.java:130)
> at com.arjuna.ats.internal.arjuna.objectstore.FileSystemStore.read_state_internal(FileSystemStore.java:331)
> at com.arjuna.ats.internal.arjuna.objectstore.FileSystemStore.read_committed(FileSystemStore.java:103)
> at com.hp.mwtests.ts.arjuna.objectstore.ThreadWriter.run(CachedTest.java:69)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2869) Deprecate SPI transaction event notifications
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2869?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-2869.
-------------------------------
> Deprecate SPI transaction event notifications
> ---------------------------------------------
>
> Key: JBTM-2869
> URL: https://issues.jboss.org/browse/JBTM-2869
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: SPI
> Affects Versions: 5.5.5.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Optional
> Fix For: 5.5.6.Final
>
>
> The SPI API for monitoring thread to transaction association changes needs deprecating. It was introduced in JBTM-2343 (Interface for tracking thread/transaction association changes) and WFLY-4923.
> The ability to listen for such changes has been re implemented by WFTC (see WFLY commit 7ef53b800:- Updated EJB client integration: Fixes to start bringing Transactions, EJB, and Discovery together) so we should stop generating these events.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2623) WildFly to GlassFish interop: Check that transaction propagation works
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2623?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-2623.
-------------------------------
> WildFly to GlassFish interop: Check that transaction propagation works
> ----------------------------------------------------------------------
>
> Key: JBTM-2623
> URL: https://issues.jboss.org/browse/JBTM-2623
> Project: JBoss Transaction Manager
> Issue Type: Sub-task
> Components: JTS
> Affects Versions: 5.2.13.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Minor
> Fix For: 5.5.6.Final
>
>
> This subtask is for testing transaction propagation only, JBTM-2873 is for the recovery part of this issue.
> This task facilitates the resolution of JBTM-223 Check WL-to-JBossTS interoperability (via JTS).
> Whilst developing a test for recovery with WebLogic I was unable to make progress due to issue \[1\] (basically registering resources for recovery fails). Checking recovery using glassfish may be easier since the source code is readily available and may help with figuring out the correct solution with WL.
> \[1\] According to [https://docs.oracle.com/cd/E12839_01/web.1111/e13731/jtatxexp.htm#WLJTA279]
> XA resources can be registered for recovery via a singleton bean that runs at start up and registers them with the WL transaction manager. When I do this I get the exception as shown:
> {quote}
> javax.transaction.SystemException: Resource 'Dummy'can be registered only in a server process
> at org.glassfish.transaction.TransactionManagerImplCommon.registerStaticResource(TransactionManagerImplCommon.java:695)
> at org.jboss.narayana.RecoveryBean.register(RecoveryBean.java:61)
> at org.jboss.narayana.RecoveryBean.init(RecoveryBean.java:30)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethod(Jsr250Metadata.java:377)
> at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethods(Jsr250Metadata.java:352)
> at com.oracle.pitchfork.intercept.InterceptionMetadata.invokeLifecycleMethods(InterceptionMetadata.java:399)
> at weblogic.ejb.container.injection.EjbComponentCreatorImpl.invokePostConstruct(EjbComponentCreatorImpl.java:55)
> at weblogic.ejb.container.manager.SingletonSessionManager.constructAndInitBean(SingletonSessionManager.java:330)
> at weblogic.ejb.container.manager.SingletonSessionManager.access$300(SingletonSessionManager.java:62)
> at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.doActualInit(SingletonSessionManager.java:753)
> at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.initInternal(SingletonSessionManager.java:701)
> at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.init(SingletonSessionManager.java:588)
> at weblogic.ejb.container.manager.SingletonSessionManager.init(SingletonSessionManager.java:255)
> at weblogic.ejb.container.manager.SingletonSessionManager.perhapsInit(SingletonSessionManager.java:251)
> at weblogic.ejb.container.deployer.EJBDeployer.start(EJBDeployer.java:968)
> at weblogic.ejb.container.deployer.EJBModule.start(EJBModule.java:597)
> at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:360)
> at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:356)
> at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
> at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:138)
> at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124)
> at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:216)
> at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:211)
> at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
> at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:73)
> at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:24)
> at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729)
> at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
> at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258)
> at weblogic.application.internal.SingleModuleDeployment.activate(SingleModuleDeployment.java:48)
> at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165)
> at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
> at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:226)
> at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:418)
> at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51)
> at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:200)
> at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30)
> at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:240)
> at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169)
> at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123)
> at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:210)
> at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:118)
> at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78)
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017)
> at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388)
> at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430)
> at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
> at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)
> at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)
> at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)
> at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)
> at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:606)
> at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
> at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:231)
> at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:254)
> at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:413)
> at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
> at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)
> at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)
> at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)
> at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)
> at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
> at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
> at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)
> at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548)
> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)
> at weblogic.work.ExecuteThread.run(ExecuteThread.java:263)
> {quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2623) WildFly to GlassFish interop: Check that transaction propagation works
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2623?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2623:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> WildFly to GlassFish interop: Check that transaction propagation works
> ----------------------------------------------------------------------
>
> Key: JBTM-2623
> URL: https://issues.jboss.org/browse/JBTM-2623
> Project: JBoss Transaction Manager
> Issue Type: Sub-task
> Components: JTS
> Affects Versions: 5.2.13.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Minor
> Fix For: 5.next
>
>
> This subtask is for testing transaction propagation only, JBTM-2873 is for the recovery part of this issue.
> This task facilitates the resolution of JBTM-223 Check WL-to-JBossTS interoperability (via JTS).
> Whilst developing a test for recovery with WebLogic I was unable to make progress due to issue \[1\] (basically registering resources for recovery fails). Checking recovery using glassfish may be easier since the source code is readily available and may help with figuring out the correct solution with WL.
> \[1\] According to [https://docs.oracle.com/cd/E12839_01/web.1111/e13731/jtatxexp.htm#WLJTA279]
> XA resources can be registered for recovery via a singleton bean that runs at start up and registers them with the WL transaction manager. When I do this I get the exception as shown:
> {quote}
> javax.transaction.SystemException: Resource 'Dummy'can be registered only in a server process
> at org.glassfish.transaction.TransactionManagerImplCommon.registerStaticResource(TransactionManagerImplCommon.java:695)
> at org.jboss.narayana.RecoveryBean.register(RecoveryBean.java:61)
> at org.jboss.narayana.RecoveryBean.init(RecoveryBean.java:30)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethod(Jsr250Metadata.java:377)
> at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethods(Jsr250Metadata.java:352)
> at com.oracle.pitchfork.intercept.InterceptionMetadata.invokeLifecycleMethods(InterceptionMetadata.java:399)
> at weblogic.ejb.container.injection.EjbComponentCreatorImpl.invokePostConstruct(EjbComponentCreatorImpl.java:55)
> at weblogic.ejb.container.manager.SingletonSessionManager.constructAndInitBean(SingletonSessionManager.java:330)
> at weblogic.ejb.container.manager.SingletonSessionManager.access$300(SingletonSessionManager.java:62)
> at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.doActualInit(SingletonSessionManager.java:753)
> at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.initInternal(SingletonSessionManager.java:701)
> at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.init(SingletonSessionManager.java:588)
> at weblogic.ejb.container.manager.SingletonSessionManager.init(SingletonSessionManager.java:255)
> at weblogic.ejb.container.manager.SingletonSessionManager.perhapsInit(SingletonSessionManager.java:251)
> at weblogic.ejb.container.deployer.EJBDeployer.start(EJBDeployer.java:968)
> at weblogic.ejb.container.deployer.EJBModule.start(EJBModule.java:597)
> at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:360)
> at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:356)
> at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
> at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:138)
> at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124)
> at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:216)
> at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:211)
> at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
> at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:73)
> at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:24)
> at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729)
> at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
> at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258)
> at weblogic.application.internal.SingleModuleDeployment.activate(SingleModuleDeployment.java:48)
> at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165)
> at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
> at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:226)
> at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:418)
> at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51)
> at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:200)
> at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30)
> at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:240)
> at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169)
> at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123)
> at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:210)
> at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:118)
> at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78)
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017)
> at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388)
> at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430)
> at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
> at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)
> at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)
> at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)
> at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)
> at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:606)
> at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
> at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:231)
> at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:254)
> at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:413)
> at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
> at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)
> at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)
> at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)
> at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)
> at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
> at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
> at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)
> at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548)
> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)
> at weblogic.work.ExecuteThread.run(ExecuteThread.java:263)
> {quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2653) Make the service context id for JTS coordinator propagation configurable
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2653?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2653:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Make the service context id for JTS coordinator propagation configurable
> ------------------------------------------------------------------------
>
> Key: JBTM-2653
> URL: https://issues.jboss.org/browse/JBTM-2653
> Project: JBoss Transaction Manager
> Issue Type: Sub-task
> Components: JTS
> Affects Versions: 5.3.2.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Optional
> Fix For: 5.next
>
>
> JTS transaction propagation uses a CORBA service context to transmit the coordinator object reference. We use a proprietary id to identify this context but if we want to interoperate with foreign transaction managers we need to use the standard value of zero.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2871) BlackTie core does not compile on Fedora 25
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2871?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2871:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> BlackTie core does not compile on Fedora 25
> -------------------------------------------
>
> Key: JBTM-2871
> URL: https://issues.jboss.org/browse/JBTM-2871
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: BlackTie
> Affects Versions: 5.5.5.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.next
>
>
> BlackTie core no longer compiles after upgrading to Fedora 25 (from Fedora 23). The error is in the STL:
> {code}
> [cc] /home/mmusgrov/work/source/forks/narayana/master/blacktie/core/src/main/cpp/ThreadLocalStorage.cxx:52:87: error: no matching function for call to 'make_pair(apr_os_thread_t&, apr_pool_t*&)'
> [cc] tls_pools.insert(std::make_pair<apr_os_thread_t, apr_pool_t*>(os_th,tls_pool));
> {code}
> The fix is to let the library infer the types of the pair being inserted, ie:
> {code}
> tls_pools.insert(std::make_pair(os_th,tls_pool));
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2877) Linkage errors whilst building BlackTie Admin CLI tool on Fedora 25
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-2877?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on JBTM-2877:
---------------------------------
What the version of the g++ on Fedora 25 ?
> Linkage errors whilst building BlackTie Admin CLI tool on Fedora 25
> -------------------------------------------------------------------
>
> Key: JBTM-2877
> URL: https://issues.jboss.org/browse/JBTM-2877
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: BlackTie
> Affects Versions: 5.5.5.Final
> Reporter: Michael Musgrove
> Assignee: Amos Feng
>
> I get linkage errors when building the admin tool on Fedora 25. Note that I have log4cxx-902683-fc18x64.jar in my local repo. The linker errors are:
> [cc] Starting link
> [cc] cxx/test/lib/libblacktie-codec.so: undefined reference to `log4cxx::helpers::MessageBuffer::str[abi:cxx11](log4cxx::helpers::CharMessageBuffer&)'
> [cc] cxx/test/lib/libblacktie-core.so: undefined reference to `log4cxx::helpers::CharMessageBuffer::str[abi:cxx11](log4cxx::helpers::CharMessageBuffer&)'
> [cc] cxx/test/lib/libblacktie-codec.so: undefined reference to `log4cxx::helpers::MessageBuffer::str[abi:cxx11](std::ostream&)'
> [cc] cxx/test/lib/libblacktie-hybrid.so: undefined reference to `log4cxx::helpers::CharMessageBuffer::operator<<(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
> [cc] cxx/test/lib/libblacktie-codec.so: undefined reference to `log4cxx::Logger::forcedLog(log4cxx::helpers::ObjectPtrT<log4cxx::Level> const&, std::__cxx11::basic_string<char, std::char_traits<char>, std
> ::allocator<char> > const&, log4cxx::spi::LocationInfo const&) const'
> [cc] collect2: error: ld returned 1 exit status
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months