[JBoss JIRA] (WFLY-5851) Add support for "rebalanceConnections" to inbound-config
by Justin Bertram (JIRA)
Justin Bertram created WFLY-5851:
------------------------------------
Summary: Add support for "rebalanceConnections" to inbound-config
Key: WFLY-5851
URL: https://issues.jboss.org/browse/WFLY-5851
Project: WildFly
Issue Type: Enhancement
Components: JMS
Affects Versions: 10.0.0.CR4
Reporter: Justin Bertram
Assignee: Jeff Mesnil
ARTEMIS-293 added a new feature which is configured via the "rebalanceConnections" activation configuration property. This should also be available on the inbound-config of the pooled-connection-factory in the XML configuration so that users don't need to explicitly set the activation configuration property on their MDBs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-644) jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFCORE-644:
-----------------------------------------
>From the WildFly Core perspective I would suggest leaving this one as it will in the future be picked up with Elytron configuration.
> jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-644
> URL: https://issues.jboss.org/browse/WFCORE-644
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Derek Horton
> Assignee: Alexey Loubyansky
>
> The cli's SSL configuration should be expanded to support using PKCS11 keystores/truststores. Currently it does not appear to be possible to configure the keystore/truststore type in the jboss-cli.xml file.
> This is problematic when the JVM is running in FIPS mode.
> The cli throws the following exception on startup:
> $ ./bin/jboss-cli.sh
> org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:541)
> at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:291)
> at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:294)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:277)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:126)
> at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:89)
> at javax.net.ssl.SSLContext.init(SSLContext.java:283)
> at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:537)
> ... 11 more
> It is possible to workaround the issue by setting the javax.net.ssl.keyStore / javax.net.ssl.trustStore system properties in the bin/jboss-cli.sh file:
> JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11"
> JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=imapassword"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1996) org.jgroups.tests.QueueTest.testBarrierWithTimeOut fails on several configurations
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/JGRP-1996?page=com.atlassian.jira.plugin.... ]
Ivan Straka deleted JGRP-1996:
------------------------------
> org.jgroups.tests.QueueTest.testBarrierWithTimeOut fails on several configurations
> ----------------------------------------------------------------------------------
>
> Key: JGRP-1996
> URL: https://issues.jboss.org/browse/JGRP-1996
> Project: JGroups
> Issue Type: Bug
> Reporter: Ivan Straka
> Assignee: Bela Ban
>
> org.jgroups.tests.QueueTest.testBarrierWithTimeOut fails on several configurations
> actual num_dead differs on some configurations
> {code:java}
> Error Message
> num_dead should have been 10 but was 9
> Stacktrace
> java.lang.AssertionError
> at org.jgroups.tests.QueueTest.testBarrierWithTimeOut(QueueTest.java:666)
> 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:497)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:816)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1124)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
> at org.testng.TestRunner.privateRun(TestRunner.java:774)
> at org.testng.TestRunner.run(TestRunner.java:624)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:359)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:354)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:312)
> at org.testng.SuiteRunner.run(SuiteRunner.java:261)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1215)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> at org.testng.TestNG.run(TestNG.java:1048)
> at org.testng.TestNG.privateMain(TestNG.java:1355)
> at org.testng.TestNG.main(TestNG.java:1324)
>
> Standard Output
> ------------- testAddAll -----------
> queue is Queue (3) elements
> ------------- testBarrier -----------
> -- adding element 99
> -- adding element 100
> remover #0 is alive
> remover #1 is alive
> remover #2 is alive
> remover #3 is alive
> remover #4 is alive
> remover #5 is alive
> remover #6 is alive
> remover #7 is terminated
> remover #8 is alive
> remover #9 is terminated
> ------------- testBarrierWithTimeOut -----------
> -- adding element 99
> -- adding element 100
> Thread #9: retrieved 99
> remover #0 is alive
> Thread #8: retrieved 100
> remover #1 is alive
> remover #2 is alive
> remover #3 is alive
> remover #4 is alive
> remover #5 is alive
> remover #6 is alive
> remover #7 is alive
> remover #8 is terminated
> remover #9 is terminated
> closing queue - causing all remaining threads to terminate
> Thread #0: queue was closed
> Thread #1: queue was closed
> remover #0 is alive
> Thread #5: queue was closed
> Thread #4: queue was closed
> Thread #3: queue was closed
> Thread #2: queue was closed
> Thread #7: queue was closed
> remover #1 is terminated
> remover #2 is terminated
> remover #3 is terminated
> remover #4 is terminated
> remover #5 is terminated
> remover #6 is alive
> remover #7 is terminated
> remover #8 is terminated
> remover #9 is terminated
> Thread #6: queue was closed
> ------------- testClear -----------
> ------------- testCloseWithFlush -----------
> ------------- testCloseWithFlush2 -----------
> ------------- testCloseWithoutFlush -----------
> ------------- testConcurrentAccess -----------
> current queue size=139
> current queue size=155
> Thread #0: 102 writes, 185 reads
> Thread #1: 86 writes, 61 reads
> Thread #2: 161 writes, 67 reads
> Thread #3: 78 writes, 65 reads
> Thread #4: 73 writes, 52 reads
> Thread #5: 129 writes, 70 reads
> Thread #6: 29 writes, 51 reads
> Thread #7: 47 writes, 30 reads
> Thread #8: 24 writes, 17 reads
> Thread #9: 28 writes, 4 reads
> total writes=757, total_reads=602, diff=155
> ------------- testConcurrentAddRemove -----------
> time to add/remove 1000000 elements: 609
> ------------- testEmptyQueue -----------
> ------------- testInsertionAndRemoval -----------
> o1=Q1, o2=Q1, o1.equals(o2)=true
> ------------- testInterruptAndRemove -----------
> ------------- testLargeInsertion -----------
> Inserting 100000 elements
> Took 11 msecs
> Removing 100000 elements
> Took 6 msecs
> ------------- testMultipleWriterOneReader -----------
> adder #0 is terminated
> adder #1 is terminated
> adder #2 is terminated
> adder #3 is terminated
> adder #4 is terminated
> adder #5 is terminated
> adder #6 is terminated
> adder #7 is terminated
> adder #8 is terminated
> adder #9 is terminated
> ------------- testQueue -----------
> ------------- testRemoveAndClose -----------
> ------------- testRemoveAndCloseWithTimeout -----------
> ------------- testRemoveAndInterrupt -----------
> -- removing element
> -- closing queue
> ------------- testRemoveElementNoElement -----------
> ------------- testRemoveElementOneElement -----------
> ------------- testRemoveElementThreeElementsFirstFound -----------
> ------------- testRemoveElementThreeElementsSecondFound -----------
> ------------- testRemoveElementThreeElementsThirdFound -----------
> ------------- testRemoveElementTwoElementsFirstFound -----------
> ------------- testRemoveElementTwoElementsSecondFound -----------
> ------------- testValues -----------
> queue: 1
> 3
> 99
> 8
> ------------- testWaitUntilClosed -----------
> ------------- testWaitUntilClosed2 -----------
> ------------- testWaitUntilClosed3 -----------
> ------------- testWaitUntilClosed4 -----------
> -- removed 0
> -- removed 1
> -- removed 2
> -- removed 3
> -- removed 4
> -- removed 5
> -- removed 6
> -- removed 7
> -- removed 8
> -- removed 9
> ------------- testWaitUntilClosed5 -----------
> -- removed 0
> -- removed 1
> -- removed 2
> Standard Error
> Thread #2: queue was closed
> Thread #4: queue was closed
> java.lang.InterruptedException
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1123) Recreate HttpPostMgmtOpsTestCase.testAddRemove
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1123?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1123:
-------------------------------------
Fix Version/s: 3.0.0.Alpha1
> Recreate HttpPostMgmtOpsTestCase.testAddRemove
> ----------------------------------------------
>
> Key: WFCORE-1123
> URL: https://issues.jboss.org/browse/WFCORE-1123
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Priority: Minor
> Fix For: 3.0.0.Alpha1
>
>
> HttpPostMgmtOpsTestCase.testAddRemove was ignored when the test was moved from full to core because the test impl used undertow subsystem resources.
> We should resurrect this test, using resources in core.
> The goal of the test is to execute add and remove ops via POST, not to test add/remove of a particular resource. So the task is not to move the test to full and test undertow subsystem, it's to make POST calls against core that add/remove.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (DROOLS-1007) ArrayIndexOutOfBoundsException attempting to remove a rule containing a OR
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1007?page=com.atlassian.jira.plugi... ]
Mario Fusco closed DROOLS-1007.
-------------------------------
Fix Version/s: 6.4.x
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/3739b5c4d
> ArrayIndexOutOfBoundsException attempting to remove a rule containing a OR
> --------------------------------------------------------------------------
>
> Key: DROOLS-1007
> URL: https://issues.jboss.org/browse/DROOLS-1007
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
>
> At the moment the association between a node and a rule is kept by a Map inside the node having the rule as key. This implementation is not taking count of the fact that the same node could be associated multiple times to the same rule that it is indeed what happens when a rule contains a OR.
> During the removal of such a rule the nodes of the rule are removed from the Rete starting from the RuleTerminalNodes (in this case the rule has more than one RTNs because of the OR). This means that when the first RTN is removed the Join and LIA nodes that are sources for that RTN at any level got completely disassociated from the rule when it is too early. That in the end causes the following exception when the engine tries to remove also the second RTN of that rule
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:171)
> at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:173)
> at org.drools.core.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:163)
> at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1635)
> at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1626)
> at org.drools.core.impl.KnowledgeBaseImpl.internalRemoveRule(KnowledgeBaseImpl.java:1610)
> at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1581)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5850) Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFLY-5850?page=com.atlassian.jira.plugin.... ]
Ladislav Thon reassigned WFLY-5850:
-----------------------------------
Assignee: Ladislav Thon
> Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
> ----------------------------------------------------------------
>
> Key: WFLY-5850
> URL: https://issues.jboss.org/browse/WFLY-5850
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Ladislav Thon
> Assignee: Ladislav Thon
> Priority: Blocker
>
> I just tried to migrate a {{standalone.xml}} server from clean EAP 6.4.0 to WildFly 10.0.0.CR4 and then deploy the {{server-side}} part of the {{ejb-remote}} quickstart:
> {code}
> git clone git@github.com:jboss-developer/jboss-eap-quickstarts.git
> cd jboss-eap-quickstarts/
> git checkout -b 6.4.x origin/6.4.x
> cd ejb-remote/server-side/
> mvn clean package -s ../../settings.xml
> cd target
> unzip .../jboss-eap-6.4.0.zip
> unzip .../wildfly-10.0.0.CR4.zip
> cp jboss-eap-6.4/standalone/configuration/standalone.xml wildfly-10.0.0.CR4/standalone/configuration/test.xml
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml --admin-only
> # on a separate console
> ./wildfly-10.0.0.CR4/bin/jboss-cli.sh -c --controller=localhost:9999
> /subsystem=threads:remove
> /extension=org.jboss.as.threads:remove
> /subsystem=web:migrate
> shutdown
> # on the original console
> cp jboss-ejb-remote-server-side.jar wildfly-10.0.0.CR4/standalone/deployments/
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml
> {code}
> What I get is this horrible stack trace:
> {code}
> 15:35:50,913 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "jboss-ejb-remote-server-side.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath.
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:271)
> at org.hibernate.validator.internal.cdi.ValidationExtension.<init>(ValidationExtension.java:109)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_66]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_66]
> at java.lang.Class.newInstance(Class.java:442) [rt.jar:1.8.0_66]
> at org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:53)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:121)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> ... 5 more
> 15:35:50,921 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jboss-ejb-remote-server-side.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"jboss-ejb-remote-server-side.jar\"
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath."}}
> {code}
> When I deploy the same JAR to a clean install of WildFly 10.0.0.CR4, it works just fine. This suggests that something (probably the EJB subsystem?) doesn't correctly parse/serialize the legacy configuration. Or something like that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5850) Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFLY-5850?page=com.atlassian.jira.plugin.... ]
Ladislav Thon reassigned WFLY-5850:
-----------------------------------
Assignee: Eduardo Martins (was: Ladislav Thon)
> Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
> ----------------------------------------------------------------
>
> Key: WFLY-5850
> URL: https://issues.jboss.org/browse/WFLY-5850
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Ladislav Thon
> Assignee: Eduardo Martins
> Priority: Blocker
>
> I just tried to migrate a {{standalone.xml}} server from clean EAP 6.4.0 to WildFly 10.0.0.CR4 and then deploy the {{server-side}} part of the {{ejb-remote}} quickstart:
> {code}
> git clone git@github.com:jboss-developer/jboss-eap-quickstarts.git
> cd jboss-eap-quickstarts/
> git checkout -b 6.4.x origin/6.4.x
> cd ejb-remote/server-side/
> mvn clean package -s ../../settings.xml
> cd target
> unzip .../jboss-eap-6.4.0.zip
> unzip .../wildfly-10.0.0.CR4.zip
> cp jboss-eap-6.4/standalone/configuration/standalone.xml wildfly-10.0.0.CR4/standalone/configuration/test.xml
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml --admin-only
> # on a separate console
> ./wildfly-10.0.0.CR4/bin/jboss-cli.sh -c --controller=localhost:9999
> /subsystem=threads:remove
> /extension=org.jboss.as.threads:remove
> /subsystem=web:migrate
> shutdown
> # on the original console
> cp jboss-ejb-remote-server-side.jar wildfly-10.0.0.CR4/standalone/deployments/
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml
> {code}
> What I get is this horrible stack trace:
> {code}
> 15:35:50,913 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "jboss-ejb-remote-server-side.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath.
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:271)
> at org.hibernate.validator.internal.cdi.ValidationExtension.<init>(ValidationExtension.java:109)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_66]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_66]
> at java.lang.Class.newInstance(Class.java:442) [rt.jar:1.8.0_66]
> at org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:53)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:121)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> ... 5 more
> 15:35:50,921 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jboss-ejb-remote-server-side.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"jboss-ejb-remote-server-side.jar\"
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath."}}
> {code}
> When I deploy the same JAR to a clean install of WildFly 10.0.0.CR4, it works just fine. This suggests that something (probably the EJB subsystem?) doesn't correctly parse/serialize the legacy configuration. Or something like that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (DROOLS-1007) ArrayIndexOutOfBoundsException attempting to remove a rule containing a OR
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1007?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration updated DROOLS-1007:
--------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1291749
Bugzilla Update: Perform
> ArrayIndexOutOfBoundsException attempting to remove a rule containing a OR
> --------------------------------------------------------------------------
>
> Key: DROOLS-1007
> URL: https://issues.jboss.org/browse/DROOLS-1007
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
>
> At the moment the association between a node and a rule is kept by a Map inside the node having the rule as key. This implementation is not taking count of the fact that the same node could be associated multiple times to the same rule that it is indeed what happens when a rule contains a OR.
> During the removal of such a rule the nodes of the rule are removed from the Rete starting from the RuleTerminalNodes (in this case the rule has more than one RTNs because of the OR). This means that when the first RTN is removed the Join and LIA nodes that are sources for that RTN at any level got completely disassociated from the rule when it is too early. That in the end causes the following exception when the engine tries to remove also the second RTN of that rule
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:171)
> at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:173)
> at org.drools.core.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:163)
> at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1635)
> at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1626)
> at org.drools.core.impl.KnowledgeBaseImpl.internalRemoveRule(KnowledgeBaseImpl.java:1610)
> at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1581)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months