[JBoss JIRA] (WFLY-10200) WARN on presence of -jmx.xml file if embedded broker is not present, instead of doing invalid wiring
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-10200:
---------------------------------------
Summary: WARN on presence of -jmx.xml file if embedded broker is not present, instead of doing invalid wiring
Key: WFLY-10200
URL: https://issues.jboss.org/browse/WFLY-10200
Project: WildFly
Issue Type: Enhancement
Components: JMS
Reporter: Brian Stansberry
Assignee: Jeff Mesnil
Priority: Minor
This is largely a topic for discussion.
If the messaging subsystem is present but no 'server' child resource is installed, there's a DUP that will try and create services for destinations in any discovered xxx-jmx.xml. These will fail due to missing dependencies on broker services.
Perhaps the DUP could just log a WARN in this case. Of course if the app depends on the destinations configured in the -jmx.xml and they are not provided otherwise (i.e. separately configured on an external broker) then the app will fail anyway, and the WARN would just help explain why. But if the destinations are available, then the -jms.xml could be regarded as just ignorable cruft left in the deployment.
For example, the app at https://github.com/jboss-openshift/openshift-quickstarts/tree/master/jta-... could benefit from this, by being able to work when deployed 1) with an embedded broker or 2) with an external broker and just an empty subsystem-messaging-activemq.
An assumption I'm making here is a subsystem=messaging-activemq is or will be useful even without a child 'server' resource. That's what our current openshift images configure when we configure for an external broker.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-10199) Using jboss-modules loading outside WildFly 12 is broken
by Martin Perina (JIRA)
[ https://issues.jboss.org/browse/WFLY-10199?page=com.atlassian.jira.plugin... ]
Martin Perina commented on WFLY-10199:
--------------------------------------
Yes, the NPE was fixed, but as mentioned above when I use the latest 1.7 manual build, I've got module not found exception
> Using jboss-modules loading outside WildFly 12 is broken
> --------------------------------------------------------
>
> Key: WFLY-10199
> URL: https://issues.jboss.org/browse/WFLY-10199
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 12.0.0.Final
> Reporter: Martin Perina
> Assignee: David Lloyd
>
> oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11:
> export JAVA_MODULEPATH="<PATH TO OUR MODULES>"
> exec "${JAVA_HOME}/bin/java" \
> -jar "${JBOSS_HOME}/jboss-modules.jar" \
> -dependencies org.ovirt.engine.core.tools \
> -class org.ovirt.engine.core.cryptotool.Main \
> "$@"
> where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool.
> When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception:
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:460)
> at java.util.Properties.setProperty(Properties.java:166)
> at java.lang.System.setProperty(System.java:796)
> at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40)
> at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.modules.Main.main(Main.java:390)
> When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error:
> org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools
> at org.jboss.modules.Module.addPaths(Module.java:1221)
> at org.jboss.modules.Module.link(Module.java:1577)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
> at org.jboss.modules.Main.main(Main.java:426)
> I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions?
> Thanks
> Martin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-10199) Using jboss-modules loading outside WildFly 12 is broken
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-10199?page=com.atlassian.jira.plugin... ]
David Lloyd commented on WFLY-10199:
------------------------------------
This is fixed upstream in the jboss-modules 1.7 and 1.8 branches.
> Using jboss-modules loading outside WildFly 12 is broken
> --------------------------------------------------------
>
> Key: WFLY-10199
> URL: https://issues.jboss.org/browse/WFLY-10199
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 12.0.0.Final
> Reporter: Martin Perina
> Assignee: David Lloyd
>
> oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11:
> export JAVA_MODULEPATH="<PATH TO OUR MODULES>"
> exec "${JAVA_HOME}/bin/java" \
> -jar "${JBOSS_HOME}/jboss-modules.jar" \
> -dependencies org.ovirt.engine.core.tools \
> -class org.ovirt.engine.core.cryptotool.Main \
> "$@"
> where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool.
> When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception:
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:460)
> at java.util.Properties.setProperty(Properties.java:166)
> at java.lang.System.setProperty(System.java:796)
> at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40)
> at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.modules.Main.main(Main.java:390)
> When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error:
> org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools
> at org.jboss.modules.Module.addPaths(Module.java:1221)
> at org.jboss.modules.Module.link(Module.java:1577)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
> at org.jboss.modules.Main.main(Main.java:426)
> I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions?
> Thanks
> Martin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-10199) Using jboss-modules loading outside WildFly 12 is broken
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-10199?page=com.atlassian.jira.plugin... ]
David Lloyd reassigned WFLY-10199:
----------------------------------
Assignee: David Lloyd (was: Jason Greene)
> Using jboss-modules loading outside WildFly 12 is broken
> --------------------------------------------------------
>
> Key: WFLY-10199
> URL: https://issues.jboss.org/browse/WFLY-10199
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 12.0.0.Final
> Reporter: Martin Perina
> Assignee: David Lloyd
>
> oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11:
> export JAVA_MODULEPATH="<PATH TO OUR MODULES>"
> exec "${JAVA_HOME}/bin/java" \
> -jar "${JBOSS_HOME}/jboss-modules.jar" \
> -dependencies org.ovirt.engine.core.tools \
> -class org.ovirt.engine.core.cryptotool.Main \
> "$@"
> where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool.
> When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception:
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:460)
> at java.util.Properties.setProperty(Properties.java:166)
> at java.lang.System.setProperty(System.java:796)
> at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40)
> at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.modules.Main.main(Main.java:390)
> When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error:
> org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools
> at org.jboss.modules.Module.addPaths(Module.java:1221)
> at org.jboss.modules.Module.link(Module.java:1577)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
> at org.jboss.modules.Main.main(Main.java:426)
> I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions?
> Thanks
> Martin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-10195) HibernateSearchJPATestCase fails under security manager
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-10195?page=com.atlassian.jira.plugin... ]
David Lloyd edited comment on WFLY-10195 at 4/6/18 11:54 AM:
-------------------------------------------------------------
Either the underlying problem needs to be fixed, or the tests disabled under security manager. In addition, the corresponding subsystem(s) (if any) should warn about the situation when a security manager is present.
> HibernateSearchJPATestCase fails under security manager
> -------------------------------------------------------
>
> Key: WFLY-10195
> URL: https://issues.jboss.org/browse/WFLY-10195
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: David Lloyd
> Labels: lucene, security-manager
>
> It looks like Lucene is performing reflection from a class initializer without a privileged block.
> {noformat}
> javax.ejb.EJBException: WFLYEJB0442: Unexpected Error
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:183)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:330)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:238)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:72)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81)
> at org.jboss.as.test.integration.hibernate.search.SearchBean$$$view618.findByKeyword(Unknown Source)
> at org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase.testFullTextQuery(HibernateSearchJPATestCase.java:54)
> 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:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.GeneratedMethodAccessor199.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> at sun.reflect.GeneratedMethodAccessor198.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.GeneratedMethodAccessor185.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.GeneratedMethodAccessor184.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.GeneratedMethodAccessor183.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:372)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:246)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:431)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:55)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:260)
> at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:324)
> at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> at sun.reflect.GeneratedMethodAccessor186.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.GeneratedMethodAccessor185.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.GeneratedMethodAccessor184.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.GeneratedMethodAccessor183.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:317)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:205)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:431)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:55)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:219)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:167)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176)
> at sun.reflect.GeneratedMethodAccessor188.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1475)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ExceptionInInitializerError
> at org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:341)
> at org.apache.lucene.index.SegmentCoreReaders.<init>(SegmentCoreReaders.java:104)
> at org.apache.lucene.index.SegmentReader.<init>(SegmentReader.java:65)
> at org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:171)
> at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:326)
> at org.apache.lucene.index.StandardDirectoryReader$2.doBody(StandardDirectoryReader.java:320)
> at org.apache.lucene.index.StandardDirectoryReader$2.doBody(StandardDirectoryReader.java:316)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:731)
> at org.apache.lucene.index.StandardDirectoryReader.doOpenFromCommit(StandardDirectoryReader.java:316)
> at org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:312)
> at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:263)
> at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:251)
> at org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:123)
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:239)
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider.openIndexReader(SharingBufferReaderProvider.java:73)
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider.openIndexReader(SharingBufferReaderProvider.java:35)
> at org.hibernate.search.reader.impl.ManagedMultiReader.createInstance(ManagedMultiReader.java:68)
> at org.hibernate.search.reader.impl.MultiReaderFactory.openReader(MultiReaderFactory.java:42)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:633)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:524)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.queryEntityInfos(HSQueryImpl.java:265)
> at org.hibernate.search.query.hibernate.impl.FullTextQueryImpl.list(FullTextQueryImpl.java:199)
> at org.hibernate.search.jpa.impl.FullTextQueryImpl.getResultList(FullTextQueryImpl.java:153)
> at org.jboss.as.test.integration.hibernate.search.SearchBean.findByKeyword(SearchBean.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:498)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:135)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
> ... 169 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/hibernate4native_search_test.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.hibernate4native_search_test.jar" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192)
> at java.lang.Class.checkMemberAccess(Class.java:2348)
> at java.lang.Class.getDeclaredFields(Class.java:1915)
> at org.apache.lucene.util.RamUsageEstimator.shallowSizeOfInstance(RamUsageEstimator.java:293)
> at org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.<clinit>(PerFieldPostingsFormat.java:216)
> ... 222 more
> {noformat}
> CC [~sannegrinovero], [~pferraro]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-10199) Using jboss-modules loading outside WildFly 12 is broken
by Martin Perina (JIRA)
[ https://issues.jboss.org/browse/WFLY-10199?page=com.atlassian.jira.plugin... ]
Martin Perina updated WFLY-10199:
---------------------------------
Description:
oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11:
export JAVA_MODULEPATH="<PATH TO OUR MODULES>"
exec "${JAVA_HOME}/bin/java" \
-jar "${JBOSS_HOME}/jboss-modules.jar" \
-dependencies org.ovirt.engine.core.tools \
-class org.ovirt.engine.core.cryptotool.Main \
"$@"
where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool.
When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception:
Exception in thread "main" java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:460)
at java.util.Properties.setProperty(Properties.java:166)
at java.lang.System.setProperty(System.java:796)
at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40)
at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.modules.Main.main(Main.java:390)
When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error:
org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools
at org.jboss.modules.Module.addPaths(Module.java:1221)
at org.jboss.modules.Module.link(Module.java:1577)
at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
at org.jboss.modules.Main.main(Main.java:426)
I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions?
Thanks
Martin
was:
oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11:
{{export JAVA_MODULEPATH="<PATH TO OUR MODULES>"
exec "${JAVA_HOME}/bin/java" \
-jar "${JBOSS_HOME}/jboss-modules.jar" \
-dependencies org.ovirt.engine.core.tools \
-class org.ovirt.engine.core.cryptotool.Main \
"$@"
}}
where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool.
When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception:
{{Exception in thread "main" java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:460)
at java.util.Properties.setProperty(Properties.java:166)
at java.lang.System.setProperty(System.java:796)
at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40)
at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.modules.Main.main(Main.java:390)}}
When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error:
{{org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools
at org.jboss.modules.Module.addPaths(Module.java:1221)
at org.jboss.modules.Module.link(Module.java:1577)
at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
at org.jboss.modules.Main.main(Main.java:426)}}
I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions?
Thanks
Martin
> Using jboss-modules loading outside WildFly 12 is broken
> --------------------------------------------------------
>
> Key: WFLY-10199
> URL: https://issues.jboss.org/browse/WFLY-10199
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 12.0.0.Final
> Reporter: Martin Perina
> Assignee: Jason Greene
>
> oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11:
> export JAVA_MODULEPATH="<PATH TO OUR MODULES>"
> exec "${JAVA_HOME}/bin/java" \
> -jar "${JBOSS_HOME}/jboss-modules.jar" \
> -dependencies org.ovirt.engine.core.tools \
> -class org.ovirt.engine.core.cryptotool.Main \
> "$@"
> where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool.
> When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception:
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:460)
> at java.util.Properties.setProperty(Properties.java:166)
> at java.lang.System.setProperty(System.java:796)
> at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40)
> at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.modules.Main.main(Main.java:390)
> When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error:
> org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools
> at org.jboss.modules.Module.addPaths(Module.java:1221)
> at org.jboss.modules.Module.link(Module.java:1577)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
> at org.jboss.modules.Main.main(Main.java:426)
> I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions?
> Thanks
> Martin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-10199) Using jboss-modules loading outside WildFly 12 is broken
by Martin Perina (JIRA)
[ https://issues.jboss.org/browse/WFLY-10199?page=com.atlassian.jira.plugin... ]
Martin Perina updated WFLY-10199:
---------------------------------
Description:
oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11:
{{export JAVA_MODULEPATH="<PATH TO OUR MODULES>"
exec "${JAVA_HOME}/bin/java" \
-jar "${JBOSS_HOME}/jboss-modules.jar" \
-dependencies org.ovirt.engine.core.tools \
-class org.ovirt.engine.core.cryptotool.Main \
"$@"
}}
where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool.
When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception:
{{Exception in thread "main" java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:460)
at java.util.Properties.setProperty(Properties.java:166)
at java.lang.System.setProperty(System.java:796)
at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40)
at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.modules.Main.main(Main.java:390)}}
When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error:
{{org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools
at org.jboss.modules.Module.addPaths(Module.java:1221)
at org.jboss.modules.Module.link(Module.java:1577)
at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
at org.jboss.modules.Main.main(Main.java:426)}}
I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions?
Thanks
Martin
was:
oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11:
export JAVA_MODULEPATH="<PATH TO OUR MODULES>"
exec "${JAVA_HOME}/bin/java" \
-jar "${JBOSS_HOME}/jboss-modules.jar" \
-dependencies org.ovirt.engine.core.tools \
-class org.ovirt.engine.core.cryptotool.Main \
"$@"
where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool.
When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception:
Exception in thread "main" java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:460)
at java.util.Properties.setProperty(Properties.java:166)
at java.lang.System.setProperty(System.java:796)
at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40)
at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.modules.Main.main(Main.java:390)
When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error:
org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools
at org.jboss.modules.Module.addPaths(Module.java:1221)
at org.jboss.modules.Module.link(Module.java:1577)
at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
at org.jboss.modules.Main.main(Main.java:426)
I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions?
Thanks
Martin
> Using jboss-modules loading outside WildFly 12 is broken
> --------------------------------------------------------
>
> Key: WFLY-10199
> URL: https://issues.jboss.org/browse/WFLY-10199
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 12.0.0.Final
> Reporter: Martin Perina
> Assignee: Jason Greene
>
> oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11:
> {{export JAVA_MODULEPATH="<PATH TO OUR MODULES>"
> exec "${JAVA_HOME}/bin/java" \
> -jar "${JBOSS_HOME}/jboss-modules.jar" \
> -dependencies org.ovirt.engine.core.tools \
> -class org.ovirt.engine.core.cryptotool.Main \
> "$@"
> }}
> where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool.
> When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception:
> {{Exception in thread "main" java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:460)
> at java.util.Properties.setProperty(Properties.java:166)
> at java.lang.System.setProperty(System.java:796)
> at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40)
> at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.modules.Main.main(Main.java:390)}}
> When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error:
> {{org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools
> at org.jboss.modules.Module.addPaths(Module.java:1221)
> at org.jboss.modules.Module.link(Module.java:1577)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
> at org.jboss.modules.Main.main(Main.java:426)}}
> I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions?
> Thanks
> Martin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-10199) Using jboss-modules loading outside WildFly 12 is broken
by Martin Perina (JIRA)
Martin Perina created WFLY-10199:
------------------------------------
Summary: Using jboss-modules loading outside WildFly 12 is broken
Key: WFLY-10199
URL: https://issues.jboss.org/browse/WFLY-10199
Project: WildFly
Issue Type: Bug
Affects Versions: 12.0.0.Final
Reporter: Martin Perina
Assignee: Jason Greene
oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11:
export JAVA_MODULEPATH="<PATH TO OUR MODULES>"
exec "${JAVA_HOME}/bin/java" \
-jar "${JBOSS_HOME}/jboss-modules.jar" \
-dependencies org.ovirt.engine.core.tools \
-class org.ovirt.engine.core.cryptotool.Main \
"$@"
where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool.
When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception:
Exception in thread "main" java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:460)
at java.util.Properties.setProperty(Properties.java:166)
at java.lang.System.setProperty(System.java:796)
at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40)
at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.modules.Main.main(Main.java:390)
When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error:
org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools
at org.jboss.modules.Module.addPaths(Module.java:1221)
at org.jboss.modules.Module.link(Module.java:1577)
at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
at org.jboss.modules.Main.main(Main.java:426)
I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions?
Thanks
Martin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-10053) TM is not forward compatible
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10053?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka edited comment on WFLY-10053 at 4/6/18 11:32 AM:
-----------------------------------------------------------------
I successfully run the test like this (I downloaded the eap and wildfly zip instances):
{{mvn test -Dts.eap1.version=7.0.9 -Dts.eap1.dist.path=/home/ochaloup/jboss/jboss-eap-7.0.9 -Dts.eap2.dist.path=/home/ochaloup/jboss/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT -Dts.eap2.version=7.2.0 -Dts.tx.impl=JTA -Dts.log.arjuna.all -Dtest=FirstCallSecondTests#jvmCrashEntryCommitSecondServer -DfailIfNoTests=false}}
when the test finishes in my case is possible to run just those two servers and try to debug the first server
{code}
cd tests-transactions-propagation/manu-unit-eap-transactions-propagation/out/EAP1_7.0.9/workspace/jboss-eap-7.0.9
./bin/standalone.sh -c standalone-full.xml
cd tests-transactions-propagation/manu-unit-eap-transactions-propagation/out/EAP2_7.2.0/workspace/wildfly-13.0.0.Alpha1-SNAPSHOT
./bin/standalone.sh -c standalone-full.xml -Djboss.socket.binding.port-offset=100
{code}
I got to the point where the {{receiverContexts}} is {{null}} (https://github.com/wildfly/jboss-ejb-client/blob/2.1.8.Final/src/main/jav...), just I don't know the reason.
During investigation I found it sounds a bit similar to this one https://bugzilla.redhat.com/show_bug.cgi?id=952746 where the connection to the remote server was not available until there was some different successful ejb call from server1 to server2.
>From that I tried to add the call {{int retCode = beanInvoker.invoke();}} just after the line https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/tests-transactions-p..., added a bit tuning for not changing db value again and but unfortunately it haven't fixed the issue for me and it's probably not the same issue.
[~istraka] what is your results on running the test with {{7.0.9 -> 7.0.9}}, please?
was (Author: ochaloup):
I successfully run the test like this (I downloaded the eap and wildfly zip instances):
{{mvn test -Dts.eap1.version=7.0.9 -Dts.eap1.dist.path=/home/ochaloup/jboss/jboss-eap-7.0.9 -Dts.eap2.dist.path=/home/ochaloup/jboss/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT -Dts.eap2.version=7.2.0 -Dts.tx.impl=JTA -Dts.log.arjuna.all -Dtest=FirstCallSecondTests#jvmCrashEntryCommitSecondServer -DfailIfNoTests=false}}
when the test finishes in my case is possible to run just those two servers and try to debug the first server
{code}
cd tests-transactions-propagation/manu-unit-eap-transactions-propagation/out/EAP1_7.0.9/workspace/jboss-eap-7.0.9
./bin/standalone.sh -c standalone-full.xml
cd tests-transactions-propagation/manu-unit-eap-transactions-propagation/out/EAP2_7.2.0/workspace/wildfly-13.0.0.Alpha1-SNAPSHOT
./bin/standalone.sh -c standalone-full.xml -Djboss.socket.binding.port-offset=100
{code}
I got to the point where the {{receiverContexts}} is {{null}} (https://github.com/wildfly/jboss-ejb-client/blob/2.1.8.Final/src/main/jav...), just I don't know the reason.
During investigation I found it sounds a bit similar to this one https://bugzilla.redhat.com/show_bug.cgi?id=952746 where the connection to the remote server was not available until there was some different successful ejb call from server1 to server2.
>From that I tried to add the call {{int retCode = beanInvoker.invoke();}} just after the line https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/tests-transactions-p..., added a bit tuning for not changing db value again and but it seems it's not connected.
[~istraka] what is your results on running the test with {{7.0.9 -> 7.0.9}}, please?
> TM is not forward compatible
> -----------------------------
>
> Key: WFLY-10053
> URL: https://issues.jboss.org/browse/WFLY-10053
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 12.0.0.Final
> Reporter: Ivan Straka
> Assignee: Tom Jenkinson
> Attachments: EAP7.0.9.log, WF12.log
>
>
> TM is unable to recover transaction after one of the nodes crash during commit phase of a resource.
> Scenario:
> # EAP 7.0.9 enlists dummy XA resource, update db value (XADatasource) and call WildFly 12
> # WildFly 12 enlists dummy XA resource, update other db value
> # At entry of commit phase of dummy XA resource on WildFly12 byteman crash the server
> # WildFly 12 is started
> # Recovery process should recover the transaction
> Following exception is seen in EAP 7.0.9 log
> {code:java}
> 2018-03-20 12:42:35,171 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016036: commit on < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff7f000001:643452d5:5ab0f37d:f, node_name=eap1, branch_uid=0:ffff7f000001:643452d5:5ab0f37d:1e, subordinatenodename=null, eis_name=unknown eis name > (RecoveryOnlySerializedEJBXAResource{ejbReceiverNodeName='eap2'}) failed with exception $XAException.XA_RETRY: javax.transaction.xa.XAException
> at org.jboss.ejb.client.RecoveryOnlySerializedEJBXAResource.commit(RecoveryOnlySerializedEJBXAResource.java:56)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:477)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2869)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2785)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1853)
> at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> {code}
> Result is that resources on EAP7.0.9 are commited and resources on WF12 are not:
> {code:java}
> [INFO] there is (are) 1 transaction(s) in tx obj store /home/istraka/manu-units/tests-transactions-propagation/manu-unit-eap-transactions-propagation/out/EAP2_7.2.0/workspace/wildfly-12.0.0.Final/standalone/data/tx-object-store
> [INFO] Transaction
> Xid:< formatId=131077, gtrid_length=32, bqual_length=40, tx_uid=0:ffff7f000001:-174ad8d9:5ab0fb3b:f, node_name=eap1, branch_uid=0:ffff7f000001:-174ad8d9:5ab0fb3b:1e, subordinatenodename=eap2, eis_name=0 >
> Type:StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA
> ParentNodeName:eap1
> Participant:false
> CreationTime:Tue, 20 Mar 2018 13:15:18 +0100
> AgeInSeconds:269
> Id:0:ffff7f000001:39e6900e:5ab0fb4a:13
> Participant
> HeuristicValue:-1
> Status:PREPARED
> JndiName:java:/TestXAResource
> GlobalTransactionId:[B@5753c786
> HeuristicStatus:UNKNOWN
> NodeName:null
> Timeout:0
> FormatId:-1
> BranchQualifier:[B@1874640
> Type:/StateManager/AbstractRecord/XAResourceRecord
> Participant:true
> EisProductVersion:EAP Test
> ClassName:com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> EisProductName:Crash Recovery Test
> Id:0:ffff7f000001:39e6900e:5ab0fb4a:1d
> Participant
> HeuristicValue:-1
> Status:PREPARED
> JndiName:java:jboss/eap2-ds-jndi
> GlobalTransactionId:[B@4ae75d2d
> HeuristicStatus:UNKNOWN
> NodeName:null
> Timeout:0
> FormatId:-1
> BranchQualifier:[B@5eaa38ce
> Type:/StateManager/AbstractRecord/XAResourceRecord
> Participant:true
> EisProductVersion:9.3.15
> ClassName:com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> EisProductName:PostgreSQL
> Id:0:ffff7f000001:39e6900e:5ab0fb4a:23
> {code}
> The issue is valid for:
> * 6.4.x -> WF12
> * 7.0.X -> WF12
> The issue is *not* valid for:
> * WF12 -> 6.4.x
> * WF12-> 7.0.x
> * 7.1.0 -> WF 12
> If you have any question (about testsuite, scenario,...) feel free to ask.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-10053) TM is not forward compatible
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10053?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-10053:
----------------------------------------
I successfully run the test like this (I downloaded the eap and wildfly zip instances):
{{mvn test -Dts.eap1.version=7.0.9 -Dts.eap1.dist.path=/home/ochaloup/jboss/jboss-eap-7.0.9 -Dts.eap2.dist.path=/home/ochaloup/jboss/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT -Dts.eap2.version=7.2.0 -Dts.tx.impl=JTA -Dts.log.arjuna.all -Dtest=FirstCallSecondTests#jvmCrashEntryCommitSecondServer -DfailIfNoTests=false}}
when the test finishes in my case is possible to run just those two servers and try to debug the first server
{code}
cd tests-transactions-propagation/manu-unit-eap-transactions-propagation/out/EAP1_7.0.9/workspace/jboss-eap-7.0.9
./bin/standalone.sh -c standalone-full.xml
cd tests-transactions-propagation/manu-unit-eap-transactions-propagation/out/EAP2_7.2.0/workspace/wildfly-13.0.0.Alpha1-SNAPSHOT
./bin/standalone.sh -c standalone-full.xml -Djboss.socket.binding.port-offset=100
{code}
I got to the point where the {{receiverContexts}} is {{null}} (https://github.com/wildfly/jboss-ejb-client/blob/2.1.8.Final/src/main/jav...), just I don't know the reason.
During investigation I found it sounds a bit similar to this one https://bugzilla.redhat.com/show_bug.cgi?id=952746 where the connection to the remote server was not available until there was some different successful ejb call from server1 to server2.
>From that I tried to add the call {{int retCode = beanInvoker.invoke();}} just after the line https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/tests-transactions-p..., added a bit tuning for not changing db value again and but it seems it's not connected.
[~istraka] what is your results on running the test with {{7.0.9 -> 7.0.9}}, please?
> TM is not forward compatible
> -----------------------------
>
> Key: WFLY-10053
> URL: https://issues.jboss.org/browse/WFLY-10053
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 12.0.0.Final
> Reporter: Ivan Straka
> Assignee: Tom Jenkinson
> Attachments: EAP7.0.9.log, WF12.log
>
>
> TM is unable to recover transaction after one of the nodes crash during commit phase of a resource.
> Scenario:
> # EAP 7.0.9 enlists dummy XA resource, update db value (XADatasource) and call WildFly 12
> # WildFly 12 enlists dummy XA resource, update other db value
> # At entry of commit phase of dummy XA resource on WildFly12 byteman crash the server
> # WildFly 12 is started
> # Recovery process should recover the transaction
> Following exception is seen in EAP 7.0.9 log
> {code:java}
> 2018-03-20 12:42:35,171 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016036: commit on < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff7f000001:643452d5:5ab0f37d:f, node_name=eap1, branch_uid=0:ffff7f000001:643452d5:5ab0f37d:1e, subordinatenodename=null, eis_name=unknown eis name > (RecoveryOnlySerializedEJBXAResource{ejbReceiverNodeName='eap2'}) failed with exception $XAException.XA_RETRY: javax.transaction.xa.XAException
> at org.jboss.ejb.client.RecoveryOnlySerializedEJBXAResource.commit(RecoveryOnlySerializedEJBXAResource.java:56)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:477)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2869)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2785)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1853)
> at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> {code}
> Result is that resources on EAP7.0.9 are commited and resources on WF12 are not:
> {code:java}
> [INFO] there is (are) 1 transaction(s) in tx obj store /home/istraka/manu-units/tests-transactions-propagation/manu-unit-eap-transactions-propagation/out/EAP2_7.2.0/workspace/wildfly-12.0.0.Final/standalone/data/tx-object-store
> [INFO] Transaction
> Xid:< formatId=131077, gtrid_length=32, bqual_length=40, tx_uid=0:ffff7f000001:-174ad8d9:5ab0fb3b:f, node_name=eap1, branch_uid=0:ffff7f000001:-174ad8d9:5ab0fb3b:1e, subordinatenodename=eap2, eis_name=0 >
> Type:StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA
> ParentNodeName:eap1
> Participant:false
> CreationTime:Tue, 20 Mar 2018 13:15:18 +0100
> AgeInSeconds:269
> Id:0:ffff7f000001:39e6900e:5ab0fb4a:13
> Participant
> HeuristicValue:-1
> Status:PREPARED
> JndiName:java:/TestXAResource
> GlobalTransactionId:[B@5753c786
> HeuristicStatus:UNKNOWN
> NodeName:null
> Timeout:0
> FormatId:-1
> BranchQualifier:[B@1874640
> Type:/StateManager/AbstractRecord/XAResourceRecord
> Participant:true
> EisProductVersion:EAP Test
> ClassName:com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> EisProductName:Crash Recovery Test
> Id:0:ffff7f000001:39e6900e:5ab0fb4a:1d
> Participant
> HeuristicValue:-1
> Status:PREPARED
> JndiName:java:jboss/eap2-ds-jndi
> GlobalTransactionId:[B@4ae75d2d
> HeuristicStatus:UNKNOWN
> NodeName:null
> Timeout:0
> FormatId:-1
> BranchQualifier:[B@5eaa38ce
> Type:/StateManager/AbstractRecord/XAResourceRecord
> Participant:true
> EisProductVersion:9.3.15
> ClassName:com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> EisProductName:PostgreSQL
> Id:0:ffff7f000001:39e6900e:5ab0fb4a:23
> {code}
> The issue is valid for:
> * 6.4.x -> WF12
> * 7.0.X -> WF12
> The issue is *not* valid for:
> * WF12 -> 6.4.x
> * WF12-> 7.0.x
> * 7.1.0 -> WF 12
> If you have any question (about testsuite, scenario,...) feel free to ask.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
- 1
- 0