[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 edited comment on JBTM-2877 at 3/30/17 9:22 PM:
----------------------------------------------------------
What's the version of the g++ on Fedora 25 ?
was (Author: zhfeng):
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
[JBoss JIRA] (JBTM-2874) WildFly to GlassFish interop: Add a quickstart that shows transaction propagation
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2874?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Michael Musgrove created pull request #189 in GitHub
----------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> 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
[JBoss JIRA] (JBTM-2877) Linkage errors whilst building BlackTie Admin CLI tool on Fedora 25
by Michael Musgrove (JIRA)
Michael Musgrove created JBTM-2877:
--------------------------------------
Summary: 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
[JBoss JIRA] (JBTM-2876) Change the default service context id for the transaction propagation context
by Michael Musgrove (JIRA)
Michael Musgrove created JBTM-2876:
--------------------------------------
Summary: Change the default service context id for the transaction propagation context
Key: JBTM-2876
URL: https://issues.jboss.org/browse/JBTM-2876
Project: JBoss Transaction Manager
Issue Type: Sub-task
Components: JTS
Affects Versions: 5.5.5.Final
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Fix For: 6.later
On a CORBA invocation we pass the transaction data using a request service context. We use a non standard id for this context but for interoperability with other TMs we need to use the value zero (corresponding to the one used for OSI TP interop).
This change would mean that we will not be able to interop with earlier versions of WildFly so we are targeting the next major release (namely version 12).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[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.... ]
Issue was automatically transitioned when Michael Musgrove created pull request #1159 in GitHub
-----------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> 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
[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:
-----------------------------------
Fix Version/s: 5.next
> 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
[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:
-----------------------------------
Summary: WildFly to GlassFish interop: Check that transaction propagation works (was: Check Glassfish-to-Narayana interoperability (via JTS).)
> 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
>
> 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