[JBoss JIRA] (DROOLS-2165) Upgrade revapi-maven-plugin from 0.9.4 to 0.9.5
by Marek Novotny (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2165?page=com.atlassian.jira.plugi... ]
Marek Novotny commented on DROOLS-2165:
---------------------------------------
Why to upgrade to 0.9.5? Is there added @threadSafe somewhere in that version/release. I couldn't find it. Am I blind or looking in wrong place - https://github.com/revapi/revapi/commits/revapi-maven-plugin-0.9.5?
> Upgrade revapi-maven-plugin from 0.9.4 to 0.9.5
> -----------------------------------------------
>
> Key: DROOLS-2165
> URL: https://issues.jboss.org/browse/DROOLS-2165
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> It's a good thing to just do,
> but hopefully this message goes away on the jenkins job for drools:
> {code}
> 09:33:13 [INFO] ------------------------------------------------------------------------
> 09:33:13 [INFO] Building KIE :: Maven Archetypes 7.6.0-SNAPSHOT
> 09:33:13 [INFO] ------------------------------------------------------------------------
> 09:33:13 [WARNING] *****************************************************************
> 09:33:13 [WARNING] * Your build is requesting parallel execution, but project *
> 09:33:13 [WARNING] * contains the following plugin(s) that have goals not marked *
> 09:33:13 [WARNING] * as @threadSafe to support parallel building. *
> 09:33:13 [WARNING] * While this /may/ work fine, please look for plugin updates *
> 09:33:13 [WARNING] * and/or request plugins be made thread-safe. *
> 09:33:13 [WARNING] * If reporting an issue, report it against the plugin in *
> 09:33:13 [WARNING] * question, not against maven-core *
> 09:33:13 [WARNING] *****************************************************************
> 09:33:13 [WARNING] The following plugins are not marked @threadSafe in KIE :: Public API:
> 09:33:13 [WARNING] org.revapi:revapi-maven-plugin:0.9.4
> 09:33:13 [WARNING] Enable debug to see more precisely which goals are not marked @threadSafe.
> 09:33:13 [WARNING] *****************************************************************
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
by Scott Van Wart (JIRA)
[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ]
Scott Van Wart commented on WFLY-9529:
--------------------------------------
That sounds fair. I didn't realize it was CDI event specific, though your comment on December 13th sort of alluded to it. I can't think of a place where I've encountered this issue _without_ using CDI events. We use local CDI events and then have a service that watches for them and sends them out over JMS as necessary, which of course uses @Observe methods. Thanks.
> Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9529
> URL: https://issues.jboss.org/browse/WFLY-9529
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Naming
> Affects Versions: 10.1.0.Final, 11.0.0.Final
> Environment: Running on Windows 10, Java 64-bit 1.8.0_131
> Reporter: Scott Van Wart
> Assignee: Eduardo Martins
> Labels: ActiveMQ, jms, transaction
> Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
>
>
> If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread.
> My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions.
> I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-6191) ExpressionSubstitutionInContainerTestCase fails due to AccessControlException with security manager enabled
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFLY-6191?page=com.atlassian.jira.plugin.... ]
Yeray Borges updated WFLY-6191:
-------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/8802, https://github.com/wildfly/wildfly/pull/10741 (was: https://github.com/wildfly/wildfly/pull/8802)
> ExpressionSubstitutionInContainerTestCase fails due to AccessControlException with security manager enabled
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6191
> URL: https://issues.jboss.org/browse/WFLY-6191
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Yeray Borges
>
> *org.jboss.as.test.integration.management.api.expression.ExpressionSubstitutionInContainerTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.management.api.expression.ExpressionSubstitutionInContainerTestCase}}
> {code}
> Failed to start service jboss.deployment.unit."expression-substitution-test.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."expression-substitution-test.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "expression-substitution-test.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/expression-substitution-test.jar <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1525)
> at java.lang.Class.getClassLoader(Class.java:683)
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1529)
> at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51)
> at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2099)
> at org.jboss.msc.service.ServiceControllerImpl.commitInstallation(ServiceControllerImpl.java:265)
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:771)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> at org.jboss.as.test.integration.management.api.expression.ExpressionTestManagementService.activate(ExpressionTestManagementService.java:69)
> at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:74)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2225) Inconsistent values returned by AccessorKey.hashCode causes NullPointerException during binary deserialization
by Martin Weiler (JIRA)
Martin Weiler created DROOLS-2225:
-------------------------------------
Summary: Inconsistent values returned by AccessorKey.hashCode causes NullPointerException during binary deserialization
Key: DROOLS-2225
URL: https://issues.jboss.org/browse/DROOLS-2225
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.5.0.Final
Reporter: Martin Weiler
Assignee: Mario Fusco
Consider the following sequence of events:
# serialize a set of text rule files
# create a binary file for the serialized rule files
# deserialize the binary file created in the step 2.
When each step is executed in different JVM runs, step 3 fails with a NullPointerException:
{noformat}
java.lang.NullPointerException: null
at org.drools.core.reteoo.CompositeObjectSinkAdapter.isHashable(CompositeObjectSinkAdapter.java:158)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.getHashableAccessor(CompositeObjectSinkAdapter.java:149)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.addObjectSink(CompositeObjectSinkAdapter.java:108)
at org.drools.core.reteoo.SingleObjectSinkAdapter.addObjectSink(SingleObjectSinkAdapter.java:55)
at org.drools.core.reteoo.ObjectSource.addObjectSink(ObjectSource.java:216)
at org.drools.core.reteoo.LeftInputAdapterNode.attach(LeftInputAdapterNode.java:155)
at org.drools.core.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:141)
at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.buildTupleSource(GroupElementBuilder.java:126)
at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:109)
at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:161)
at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110)
at org.drools.core.impl.KnowledgeBaseImpl.internalAddRule(KnowledgeBaseImpl.java:1526)
at org.drools.core.impl.KnowledgeBaseImpl.internalAddPackages(KnowledgeBaseImpl.java:915)
at org.drools.core.impl.KnowledgeBaseImpl.lambda$addPackages$1(KnowledgeBaseImpl.java:717)
at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
at org.drools.core.impl.KnowledgeBaseImpl.addPackages(KnowledgeBaseImpl.java:717)
at org.drools.compiler.integrationtests.SerializedPackageMergeTwoSteps2Test.testBuildAndSerializePackagesInTwoSteps2(SerializedPackageMergeTwoSteps2Test.java:88)
{noformat}
If making one single run for all 3 steps, everything works fine.
The problem are inconsistent hashCode values for the AccessorKey object when the JVM is restarted, due to the usage of Enum.hashCode:
https://github.com/kiegroup/drools/blob/master/drools-core/src/main/java/...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2224) Inconsistent values returned by AccessorKey.hashCode causes NullPointerException during binary deserialization
by Martin Weiler (JIRA)
Martin Weiler created DROOLS-2224:
-------------------------------------
Summary: Inconsistent values returned by AccessorKey.hashCode causes NullPointerException during binary deserialization
Key: DROOLS-2224
URL: https://issues.jboss.org/browse/DROOLS-2224
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.5.0.Final
Reporter: Martin Weiler
Assignee: Mario Fusco
Consider the following sequence of events:
# serialize a set of text rule files
# create a binary file for the serialized rule files
# deserialize the binary file created in the step 2.
When each step is executed in different JVM runs, step 3 fails with a NullPointerException:
{noformat}
java.lang.NullPointerException: null
at org.drools.core.reteoo.CompositeObjectSinkAdapter.isHashable(CompositeObjectSinkAdapter.java:158)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.getHashableAccessor(CompositeObjectSinkAdapter.java:149)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.addObjectSink(CompositeObjectSinkAdapter.java:108)
at org.drools.core.reteoo.SingleObjectSinkAdapter.addObjectSink(SingleObjectSinkAdapter.java:55)
at org.drools.core.reteoo.ObjectSource.addObjectSink(ObjectSource.java:216)
at org.drools.core.reteoo.LeftInputAdapterNode.attach(LeftInputAdapterNode.java:155)
at org.drools.core.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:141)
at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.buildTupleSource(GroupElementBuilder.java:126)
at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:109)
at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:161)
at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110)
at org.drools.core.impl.KnowledgeBaseImpl.internalAddRule(KnowledgeBaseImpl.java:1526)
at org.drools.core.impl.KnowledgeBaseImpl.internalAddPackages(KnowledgeBaseImpl.java:915)
at org.drools.core.impl.KnowledgeBaseImpl.lambda$addPackages$1(KnowledgeBaseImpl.java:717)
at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
at org.drools.core.impl.KnowledgeBaseImpl.addPackages(KnowledgeBaseImpl.java:717)
at org.drools.compiler.integrationtests.SerializedPackageMergeTwoSteps2Test.testBuildAndSerializePackagesInTwoSteps2(SerializedPackageMergeTwoSteps2Test.java:88)
{noformat}
If making one single run for all 3 steps, everything works fine.
The problem are inconsistent hashCode values for the AccessorKey object when the JVM is restarted, due to the usage of Enum.hashCode:
https://github.com/kiegroup/drools/blob/master/drools-core/src/main/java/...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFLY-9529:
---------------------------------------
The issue is really bound to usage of the CDI event, that is delivered without the Java EE JNDI so if you use a Java EE component such as a EJB that will work fine. I was assuming you just wanted a workaround with the CDI event, and right now only real workaround would be replace the ear with a war.
> Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9529
> URL: https://issues.jboss.org/browse/WFLY-9529
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Naming
> Affects Versions: 10.1.0.Final, 11.0.0.Final
> Environment: Running on Windows 10, Java 64-bit 1.8.0_131
> Reporter: Scott Van Wart
> Assignee: Eduardo Martins
> Labels: ActiveMQ, jms, transaction
> Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
>
>
> If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread.
> My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions.
> I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months