[JBoss JIRA] (WFLY-4757) ConfigurationPersistenceException when persisting mod_cluster subsystem's "proxies" attribute
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-4757?page=com.atlassian.jira.plugin.... ]
Michal Karm Babacek closed WFLY-4757.
-------------------------------------
EAP 7 DR5 / WF 10 Alpha5
> ConfigurationPersistenceException when persisting mod_cluster subsystem's "proxies" attribute
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-4757
> URL: https://issues.jboss.org/browse/WFLY-4757
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2
> Reporter: Michal Karm Babacek
> Assignee: Radoslav Husar
> Priority: Blocker
> Labels: mod_cluster
> Fix For: 9.0.0.Final, 10.0.0.Alpha4
>
>
> If one takes a vanilla EAP 7 DR build and starts it with {{./standalone.sh -c standalone.ha}}, i.e. with mod_cluster subsystem loaded, but without any static proxies configuration directives, the server registers with mod_cluster load balancers and accepts hot deployments without any error.
> If one sets a static proxy configuration, e.g.:
> {code:xml}
> +++
> <mod-cluster-config advertise-socket="modcluster" connector="ajp" proxies="my-proxy-one">
> +++
> <outbound-socket-binding name="my-proxy-one">
> <remote-destination host="10.40.4.50" port="6666"/>
> </outbound-socket-binding>
> +++
> {code}
> then the server processes hot deployments only as long as it's not registered with any mod_cluster load balancer. As soon as it registers with a load balancer, any hot deployment causes the following exception:
> {noformat}
> 14:39:13,475 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0004: Found simplecontext.war in deployment directory. To trigger deployment create a file called simplecontext.war.dodeploy
> 14:39:13,520 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "simplecontext.war" (runtime-name: "simplecontext.war")
> 14:39:14,028 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0021: Registered web context: /simplecontext
> 14:39:14,080 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0008: Failed to persist configuration change: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0084: Failed to marshal configuration
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:49)
> at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.<init>(ConfigurationFilePersistenceResource.java:45)
> at org.jboss.as.controller.persistence.BackupXmlConfigurationPersister.store(BackupXmlConfigurationPersister.java:109)
> at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:738)
> at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:403)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:643)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:918)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:885)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1170)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:363)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:219)
> at org.jboss.as.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:716)
> at org.jboss.as.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:710)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.as.controller.ModelControllerImpl$3$1.run(ModelControllerImpl.java:710)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0089: Failed to write configuration
> at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:100)
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:42)
> ... 26 more
> Caused by: java.lang.reflect.UndeclaredThrowableException
> at org.jboss.staxmapper.FormattingXMLStreamWriter$4.run(FormattingXMLStreamWriter.java:249)
> at org.jboss.staxmapper.FormattingXMLStreamWriter.runAttrQueue(FormattingXMLStreamWriter.java:221)
> at org.jboss.staxmapper.FormattingXMLStreamWriter.writeStartElement(FormattingXMLStreamWriter.java:96)
> at org.wildfly.extension.mod_cluster.ModClusterSubsystemXMLWriter.writeDynamicLoadProvider(ModClusterSubsystemXMLWriter.java:104)
> at org.wildfly.extension.mod_cluster.ModClusterSubsystemXMLWriter.writeModClusterConfig(ModClusterSubsystemXMLWriter.java:69)
> at org.wildfly.extension.mod_cluster.ModClusterSubsystemXMLWriter.writeContent(ModClusterSubsystemXMLWriter.java:51)
> at org.wildfly.extension.mod_cluster.ModClusterSubsystemXMLWriter.writeContent(ModClusterSubsystemXMLWriter.java:42)
> at org.jboss.as.server.parsing.StandaloneXml_4.writeServerProfile(StandaloneXml_4.java:695)
> at org.jboss.as.server.parsing.StandaloneXml_4.writeContent(StandaloneXml_4.java:613)
> at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:77)
> at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:47)
> at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88)
> at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83)
> at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:94)
> ... 27 more
> Caused by: javax.xml.stream.XMLStreamException: Trying to write an attribute when there is no open start element.
> at com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:1537)
> at com.ctc.wstx.sw.BaseStreamWriter.reportNwfStructure(BaseStreamWriter.java:1566)
> at com.ctc.wstx.sw.BaseNsStreamWriter.writeAttribute(BaseNsStreamWriter.java:226)
> at org.jboss.staxmapper.FormattingXMLStreamWriter$4.run(FormattingXMLStreamWriter.java:247)
> ... 40 more
> 14:39:14,085 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0021: Deploy of deployment "simplecontext.war" was rolled back with the following failure message: "WFLYCTL0086: Failed to persist configuration change: WFLYCTL0084: Failed to marshal configuration"
> 14:39:14,095 INFO [org.jboss.modcluster] (MSC service thread 1-3) MODCLUSTER000021: All pending requests drained from default-host:/simplecontext in 0.0 seconds
> 14:39:14,098 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0022: Unregistered web context: /simplecontext
> 14:39:14,142 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-8) HV000001: Hibernate Validator 5.1.3.Final
> 14:39:14,177 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment simplecontext.war (runtime-name: simplecontext.war) in 92ms
> {noformat}
> The problem is IMHO related to the new configuration attribute WFLY-457.
>
> Note that this issue affects *hot deployments only*. If the server starts with deployments already present, no exception is thrown and everything works as expected. I find this issue being of {color:red}critical{color} severity, because it breaks core functionality of the application server -- hot deployments.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4757) ConfigurationPersistenceException when persisting mod_cluster subsystem's "proxies" attribute
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-4757?page=com.atlassian.jira.plugin.... ]
Michal Karm Babacek commented on WFLY-4757:
-------------------------------------------
THX
> ConfigurationPersistenceException when persisting mod_cluster subsystem's "proxies" attribute
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-4757
> URL: https://issues.jboss.org/browse/WFLY-4757
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2
> Reporter: Michal Karm Babacek
> Assignee: Radoslav Husar
> Priority: Blocker
> Labels: mod_cluster
> Fix For: 9.0.0.Final, 10.0.0.Alpha4
>
>
> If one takes a vanilla EAP 7 DR build and starts it with {{./standalone.sh -c standalone.ha}}, i.e. with mod_cluster subsystem loaded, but without any static proxies configuration directives, the server registers with mod_cluster load balancers and accepts hot deployments without any error.
> If one sets a static proxy configuration, e.g.:
> {code:xml}
> +++
> <mod-cluster-config advertise-socket="modcluster" connector="ajp" proxies="my-proxy-one">
> +++
> <outbound-socket-binding name="my-proxy-one">
> <remote-destination host="10.40.4.50" port="6666"/>
> </outbound-socket-binding>
> +++
> {code}
> then the server processes hot deployments only as long as it's not registered with any mod_cluster load balancer. As soon as it registers with a load balancer, any hot deployment causes the following exception:
> {noformat}
> 14:39:13,475 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0004: Found simplecontext.war in deployment directory. To trigger deployment create a file called simplecontext.war.dodeploy
> 14:39:13,520 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "simplecontext.war" (runtime-name: "simplecontext.war")
> 14:39:14,028 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0021: Registered web context: /simplecontext
> 14:39:14,080 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0008: Failed to persist configuration change: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0084: Failed to marshal configuration
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:49)
> at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.<init>(ConfigurationFilePersistenceResource.java:45)
> at org.jboss.as.controller.persistence.BackupXmlConfigurationPersister.store(BackupXmlConfigurationPersister.java:109)
> at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:738)
> at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:403)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:643)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:918)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:885)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1170)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:363)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:219)
> at org.jboss.as.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:716)
> at org.jboss.as.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:710)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.as.controller.ModelControllerImpl$3$1.run(ModelControllerImpl.java:710)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0089: Failed to write configuration
> at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:100)
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:42)
> ... 26 more
> Caused by: java.lang.reflect.UndeclaredThrowableException
> at org.jboss.staxmapper.FormattingXMLStreamWriter$4.run(FormattingXMLStreamWriter.java:249)
> at org.jboss.staxmapper.FormattingXMLStreamWriter.runAttrQueue(FormattingXMLStreamWriter.java:221)
> at org.jboss.staxmapper.FormattingXMLStreamWriter.writeStartElement(FormattingXMLStreamWriter.java:96)
> at org.wildfly.extension.mod_cluster.ModClusterSubsystemXMLWriter.writeDynamicLoadProvider(ModClusterSubsystemXMLWriter.java:104)
> at org.wildfly.extension.mod_cluster.ModClusterSubsystemXMLWriter.writeModClusterConfig(ModClusterSubsystemXMLWriter.java:69)
> at org.wildfly.extension.mod_cluster.ModClusterSubsystemXMLWriter.writeContent(ModClusterSubsystemXMLWriter.java:51)
> at org.wildfly.extension.mod_cluster.ModClusterSubsystemXMLWriter.writeContent(ModClusterSubsystemXMLWriter.java:42)
> at org.jboss.as.server.parsing.StandaloneXml_4.writeServerProfile(StandaloneXml_4.java:695)
> at org.jboss.as.server.parsing.StandaloneXml_4.writeContent(StandaloneXml_4.java:613)
> at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:77)
> at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:47)
> at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88)
> at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83)
> at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:94)
> ... 27 more
> Caused by: javax.xml.stream.XMLStreamException: Trying to write an attribute when there is no open start element.
> at com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:1537)
> at com.ctc.wstx.sw.BaseStreamWriter.reportNwfStructure(BaseStreamWriter.java:1566)
> at com.ctc.wstx.sw.BaseNsStreamWriter.writeAttribute(BaseNsStreamWriter.java:226)
> at org.jboss.staxmapper.FormattingXMLStreamWriter$4.run(FormattingXMLStreamWriter.java:247)
> ... 40 more
> 14:39:14,085 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0021: Deploy of deployment "simplecontext.war" was rolled back with the following failure message: "WFLYCTL0086: Failed to persist configuration change: WFLYCTL0084: Failed to marshal configuration"
> 14:39:14,095 INFO [org.jboss.modcluster] (MSC service thread 1-3) MODCLUSTER000021: All pending requests drained from default-host:/simplecontext in 0.0 seconds
> 14:39:14,098 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0022: Unregistered web context: /simplecontext
> 14:39:14,142 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-8) HV000001: Hibernate Validator 5.1.3.Final
> 14:39:14,177 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment simplecontext.war (runtime-name: simplecontext.war) in 92ms
> {noformat}
> The problem is IMHO related to the new configuration attribute WFLY-457.
>
> Note that this issue affects *hot deployments only*. If the server starts with deployments already present, no exception is thrown and everything works as expected. I find this issue being of {color:red}critical{color} severity, because it breaks core functionality of the application server -- hot deployments.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (DROOLS-383) switch over String in function
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-383?page=com.atlassian.jira.plugin... ]
Petr Široký resolved DROOLS-383.
--------------------------------
Assignee: Petr Široký (was: Mark Proctor)
Fix Version/s: 6.3.0.Beta2
Resolution: Done
> switch over String in function
> ------------------------------
>
> Key: DROOLS-383
> URL: https://issues.jboss.org/browse/DROOLS-383
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Reporter: Matteo Mortari
> Assignee: Petr Široký
> Fix For: 6.3.0.Beta2
>
> Attachments: 20131219.drools6scratch-switchoverstring.zip
>
>
> *Executive Summary*: if I try to implement switch over String as per Java 1.7, inside of DRL function, compilation of DRL fails, but the error message would suggest that actually switch over String should work.
> *Steps to reproduce*
> Have a DRL file with function with String parameter and inside the function a switch over the parameter, for example
> {code:title=acme.drl|borderStyle=solid}
> rule "Stupid rule over String"
> when
> String()
> then
> System.out.println("Hello world");
> end
> function void theTest(String input) {
> switch(input) {
> case "Hello World" :
> System.out.println("yep");
> break;
> default :
> System.out.println("uh");
> break;
> }
> }
> {code}
> Have simple code to compile DRL for default KieBase, for example snippet:
> {code:title=App.java|borderStyle=solid}
> String input = "Hello World";
> // Java 1.7
> switch(input) {
> case "Hello World" :
> System.out.println("yep");
> break;
> default :
> System.out.println("uh");
> break;
> }
> System.out.println( "Hello World!" );
> KieServices ks = KieServices.Factory.get();
> KieContainer kContainer = ks.getKieClasspathContainer();
> KieBase kieBase = kContainer.getKieBase();
> for ( KiePackage kp : kieBase.getKiePackages() ) {
> for (Rule rule : kp.getRules()) {
> System.out.println("kp" + kp + " rule " + rule.getName());
> }
> }
> {code}
> Console would log DRL compile fails with error:
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=acme.drl, line=-1, column=0
> text=Error importing : 'defaultpkg.TheTest.theTest'], Message [id=2, level=ERROR, path=acme.drl, line=8, column=0
> text=[ function theTesttheTest (line:8): Cannot switch on a value of type String. Only convertible int values, strings or enum constants are permitted
> ]], Message [id=3, level=ERROR, path=acme.drl, line=1, column=0
> text=Rule Compilation error The import defaultpkg.TheTest cannot be resolved]]
> {noformat}
> Please notice the 'strings' bit in the error message : {{Cannot switch on a value of type String. Only convertible int values, *strings* or enum constants are permitted}}
> Therefore would suggest it would compile a switch over String, but for some reason it is failing to recognize that input parameter is indeed a String?
> Thank you
> Ciao
> MM
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4854) Exclude org.jboss.logmanager:jboss-logmanager from wildfly-client-all (jboss-client.jar)
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4854?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-4854:
------------------------------------
Assignee: Jeff Mesnil (was: Stuart Douglas)
> Exclude org.jboss.logmanager:jboss-logmanager from wildfly-client-all (jboss-client.jar)
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-4854
> URL: https://issues.jboss.org/browse/WFLY-4854
> Project: WildFly
> Issue Type: Bug
> Components: Application Client
> Reporter: Martin Simka
> Assignee: Jeff Mesnil
>
> Exclude org.jboss.logmanager:jboss-logmanager from wildfly-client-all (jboss-client.jar)
> its presence causes TCK failures with error:
> {noformat}
> IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> {noformat}
> as LogManager is loaded twice, from jboss-client.jar and from module. It was brought in together with ActiveMQ Artemis messaging.
> {noformat}
> [INFO] --- maven-dependency-plugin:2.9:tree (default-cli) @ wildfly-client-all ---
> [INFO] org.wildfly:wildfly-client-all:jar:10.0.0.Alpha5-SNAPSHOT
> [INFO] +- org.wildfly:wildfly-ejb-client-bom:pom:10.0.0.Alpha5-SNAPSHOT:compile
> [INFO] | +- org.jboss:jboss-ejb-client:jar:2.1.1.Final:compile
> [INFO] | +- org.jboss:jboss-remote-naming:jar:2.0.4.Final:compile
> [INFO] | +- org.jboss.logging:jboss-logging:jar:3.2.1.Final:compile
> [INFO] | +- org.jboss.marshalling:jboss-marshalling:jar:1.4.10.Final:compile
> [INFO] | +- org.jboss.marshalling:jboss-marshalling-river:jar:1.4.10.Final:compile
> [INFO] | +- org.jboss.remoting:jboss-remoting:jar:4.0.9.Final:compile
> [INFO] | +- org.jboss.sasl:jboss-sasl:jar:1.0.5.Final:compile
> [INFO] | +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:compile
> [INFO] | +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:compile
> [INFO] | +- org.jboss.xnio:xnio-api:jar:3.3.1.Final:compile
> [INFO] | \- org.jboss.xnio:xnio-nio:jar:3.3.1.Final:compile
> [INFO] +- org.wildfly:wildfly-jms-client-bom:pom:10.0.0.Alpha5-SNAPSHOT:compile
> [INFO] | +- org.apache.activemq:artemis-commons:jar:1.0.0:compile
> [INFO] | | +- org.jboss.logmanager:jboss-logmanager:jar:2.0.0.Final:compile
> [INFO] | | \- commons-beanutils:commons-beanutils:jar:1.9.2:compile
> [INFO] | | \- commons-collections:commons-collections:jar:3.2.1:compile
> [INFO] | +- org.apache.activemq:artemis-core-client:jar:1.0.0:compile
> [INFO] | | +- org.jgroups:jgroups:jar:3.6.4.Final:compile
> [INFO] | | +- org.apache.activemq:artemis-selector:jar:1.0.0:compile
> [INFO] | | \- org.apache.activemq:artemis-journal:jar:1.0.0:compile
> [INFO] | | \- org.apache.activemq:artemis-native:jar:1.0.0:compile
> [INFO] | +- org.apache.activemq:artemis-jms-client:jar:1.0.0:compile
> [INFO] | | +- org.apache.geronimo.specs:geronimo-jms_2.0_spec:jar:1.0-alpha-1:compile
> [INFO] | | \- javax.inject:javax.inject:jar:1:compile
> [INFO] | +- org.hornetq:hornetq-commons:jar:2.4.7.Final:compile
> [INFO] | +- org.hornetq:hornetq-core-client:jar:2.4.7.Final:compile
> [INFO] | | \- org.hornetq:hornetq-journal:jar:2.4.7.Final:compile
> [INFO] | | \- org.hornetq:hornetq-native:jar:2.4.7.Final:compile
> [INFO] | +- org.hornetq:hornetq-jms-client:jar:2.4.7.Final:compile
> [INFO] | +- io.netty:netty-all:jar:4.0.26.Final:compile
> [INFO] | +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:compile
> [INFO] | \- org.slf4j:jcl-over-slf4j:jar:1.7.7.jbossorg-1:compile
> [INFO] | \- org.slf4j:slf4j-api:jar:1.7.7.jbossorg-1:compile
> [INFO] +- org.jboss.remotingjmx:remoting-jmx:jar:2.0.1.Final:compile
> [INFO] \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.3.Final:compile
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (DROOLS-831) KIE Execution Server is not able to find the Maven repository
by Roger Martínez (JIRA)
[ https://issues.jboss.org/browse/DROOLS-831?page=com.atlassian.jira.plugin... ]
Roger Martínez updated DROOLS-831:
----------------------------------
Steps to Reproduce:
1.- Run drools-workbench-showcase & kie-server-showcase containers with default configuration
2.- Build&Deploy mortgages project on the Drools WB
3.- Register the kie-server on the Drools WB
3.1- MenuDeploy -> run deployments -> Register
- endpoint: http://<container_ip>:8080/kie-server/services/rest/server
- user/pass: kie-server/kie-server
3.2.- Create a container on kie-server
Click on "+" on the right side of the server registered
Add a mortgages container (any name and search for mortgages artifact)
4.- Select the container just created and run it.
The exception is thrown on the kie-server side
> KIE Execution Server is not able to find the Maven repository
> -------------------------------------------------------------
>
> Key: DROOLS-831
> URL: https://issues.jboss.org/browse/DROOLS-831
> Project: Drools
> Issue Type: Bug
> Components: docker images
> Affects Versions: 6.2.0.Final
> Environment: ALL
> Reporter: Roger Martínez
> Assignee: Roger Martínez
>
> In a non-Docker installation of the KIE execution server, the user must configure the Maven settings file to specify where the Maven repository for the artifacts is located.
> As Docker images are immutable, this configuration must be specified at runtime using environment variables when the container starts.
> This feature is not implemented on latest image tag and it's mandatory for being able to use the external Maven repository.
> This bug is reported from community feedback:
> "I'm trying out the docker images for the workbench-showcase and the execution-showcase. Fresh install. I'm using -p 8080:8080 for the wb and 8081:8080 for the exec. WB runs fine and I can build and deploy the mortgage project. Exec runs fine and I can access using REST. I can register the exec server fine. Mortgage container creates fine. Starting the container produces this error on the exec docker:
> 987 ERROR [org.kie.server.services.rest.KieServerRestImpl] (default task-5) Error creating container 'Test1' for module 'mortgages:mortgages:0.0.1': java.lang.RuntimeException: Cannot find KieModule: mortgages:mortgages:0.0.1
> Should this work out of the box?"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4854) Exclude org.jboss.logmanager:jboss-logmanager from wildfly-client-all (jboss-client.jar)
by Martin Simka (JIRA)
Martin Simka created WFLY-4854:
----------------------------------
Summary: Exclude org.jboss.logmanager:jboss-logmanager from wildfly-client-all (jboss-client.jar)
Key: WFLY-4854
URL: https://issues.jboss.org/browse/WFLY-4854
Project: WildFly
Issue Type: Bug
Components: Application Client
Reporter: Martin Simka
Assignee: Stuart Douglas
Exclude org.jboss.logmanager:jboss-logmanager from wildfly-client-all (jboss-client.jar)
its presence causes TCK failures with error:
{noformat}
IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
{noformat}
as LogManager is loaded twice, from jboss-client.jar and from module. It was brought in together with ActiveMQ Artemis messaging.
{noformat}
[INFO] --- maven-dependency-plugin:2.9:tree (default-cli) @ wildfly-client-all ---
[INFO] org.wildfly:wildfly-client-all:jar:10.0.0.Alpha5-SNAPSHOT
[INFO] +- org.wildfly:wildfly-ejb-client-bom:pom:10.0.0.Alpha5-SNAPSHOT:compile
[INFO] | +- org.jboss:jboss-ejb-client:jar:2.1.1.Final:compile
[INFO] | +- org.jboss:jboss-remote-naming:jar:2.0.4.Final:compile
[INFO] | +- org.jboss.logging:jboss-logging:jar:3.2.1.Final:compile
[INFO] | +- org.jboss.marshalling:jboss-marshalling:jar:1.4.10.Final:compile
[INFO] | +- org.jboss.marshalling:jboss-marshalling-river:jar:1.4.10.Final:compile
[INFO] | +- org.jboss.remoting:jboss-remoting:jar:4.0.9.Final:compile
[INFO] | +- org.jboss.sasl:jboss-sasl:jar:1.0.5.Final:compile
[INFO] | +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:compile
[INFO] | +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:compile
[INFO] | +- org.jboss.xnio:xnio-api:jar:3.3.1.Final:compile
[INFO] | \- org.jboss.xnio:xnio-nio:jar:3.3.1.Final:compile
[INFO] +- org.wildfly:wildfly-jms-client-bom:pom:10.0.0.Alpha5-SNAPSHOT:compile
[INFO] | +- org.apache.activemq:artemis-commons:jar:1.0.0:compile
[INFO] | | +- org.jboss.logmanager:jboss-logmanager:jar:2.0.0.Final:compile
[INFO] | | \- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO] | | \- commons-collections:commons-collections:jar:3.2.1:compile
[INFO] | +- org.apache.activemq:artemis-core-client:jar:1.0.0:compile
[INFO] | | +- org.jgroups:jgroups:jar:3.6.4.Final:compile
[INFO] | | +- org.apache.activemq:artemis-selector:jar:1.0.0:compile
[INFO] | | \- org.apache.activemq:artemis-journal:jar:1.0.0:compile
[INFO] | | \- org.apache.activemq:artemis-native:jar:1.0.0:compile
[INFO] | +- org.apache.activemq:artemis-jms-client:jar:1.0.0:compile
[INFO] | | +- org.apache.geronimo.specs:geronimo-jms_2.0_spec:jar:1.0-alpha-1:compile
[INFO] | | \- javax.inject:javax.inject:jar:1:compile
[INFO] | +- org.hornetq:hornetq-commons:jar:2.4.7.Final:compile
[INFO] | +- org.hornetq:hornetq-core-client:jar:2.4.7.Final:compile
[INFO] | | \- org.hornetq:hornetq-journal:jar:2.4.7.Final:compile
[INFO] | | \- org.hornetq:hornetq-native:jar:2.4.7.Final:compile
[INFO] | +- org.hornetq:hornetq-jms-client:jar:2.4.7.Final:compile
[INFO] | +- io.netty:netty-all:jar:4.0.26.Final:compile
[INFO] | +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:compile
[INFO] | \- org.slf4j:jcl-over-slf4j:jar:1.7.7.jbossorg-1:compile
[INFO] | \- org.slf4j:slf4j-api:jar:1.7.7.jbossorg-1:compile
[INFO] +- org.jboss.remotingjmx:remoting-jmx:jar:2.0.1.Final:compile
[INFO] \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.3.Final:compile
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4853) Provide two cluster test case for EJBClient
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-4853?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz reassigned WFLY-4853:
-----------------------------------------
Assignee: Richard Achmatowicz
> Provide two cluster test case for EJBClient
> -------------------------------------------
>
> Key: WFLY-4853
> URL: https://issues.jboss.org/browse/WFLY-4853
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 10.0.0.Alpha4
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
>
> The Wildfly test suite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle.
> The test setup:
> - two clusters
> {noformat}
> ejb-forwarder = {node0, node1}
> ejb={node3, node4}
> {noformat}
> where each node of cluster ejb-forwarder has a remote outbound connection to node3
> - a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb
> - a non-forwarding deployment on cluster ejb
> - a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms
> The test execution:
> - once the servers and deployments have been deployed, each server is shut down and then restarted in turn, at which time the test ends.
> The expected behaviour:
> - at least 90% of client invocations will complete without exception
> - test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down)
> - server-client invocations on ejb will fail-over from node3 to node 4 (or vice versa depending on which node of cluster ejb is down)
> The invocation transaction attribute set up:
> - invocations from the client to ejb-forwarder are not in transaction scope
> - invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
> This allows exercising invocations from a managed transaction context, which uncovered a number of issues...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4853) Provide two cluster test case for EJBClient
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-4853?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-4853 at 7/1/15 10:58 AM:
--------------------------------------------------------------------
The test case has identified a number of issues:
- problems with ejb cache renaming (https://issues.jboss.org/browse/WFLY-3290)
- problems with batching in Wildfly clustering (https://issues.jboss.org/browse/WFLY-4678)
- problems with EJBClient and clean shutdown (https://issues.jboss.org/browse/WFLY-4697)
- problems with EJBCLient retry mechanism being used with invocations from a managed context (see https://issues.jboss.org/browse/EJBCLIENT-137 )
I'm currently working on resolving the last issue.
was (Author: rachmato):
The test case has identified a number of issues:
- problems with ejb cache renaming (https://issues.jboss.org/browse/WFLY-3290)
- problems with batching in Wildfly clustering (https://issues.jboss.org/browse/WFLY-4678)
- problems with EJBClient and clean shutdown (https://issues.jboss.org/browse/WFLY-4697)
- problems with EJBCLient retry mechanism being used with invocations from a managed context (see https://issues.jboss.org/browse/WFLY-4697)
I'm currently working on resolving the last issue.
> Provide two cluster test case for EJBClient
> -------------------------------------------
>
> Key: WFLY-4853
> URL: https://issues.jboss.org/browse/WFLY-4853
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 10.0.0.Alpha4
> Reporter: Richard Achmatowicz
>
> The Wildfly test suite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle.
> The test setup:
> - two clusters
> {noformat}
> ejb-forwarder = {node0, node1}
> ejb={node3, node4}
> {noformat}
> where each node of cluster ejb-forwarder has a remote outbound connection to node3
> - a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb
> - a non-forwarding deployment on cluster ejb
> - a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms
> The test execution:
> - once the servers and deployments have been deployed, each server is shut down and then restarted in turn, at which time the test ends.
> The expected behaviour:
> - at least 90% of client invocations will complete without exception
> - test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down)
> - server-client invocations on ejb will fail-over from node3 to node 4 (or vice versa depending on which node of cluster ejb is down)
> The invocation transaction attribute set up:
> - invocations from the client to ejb-forwarder are not in transaction scope
> - invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
> This allows exercising invocations from a managed transaction context, which uncovered a number of issues...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4853) Provide two cluster test case for EJBClient
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-4853?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated WFLY-4853:
--------------------------------------
Description:
The Wildfly test suite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle.
The test setup:
- two clusters
{noformat}
ejb-forwarder = {node0, node1}
ejb={node3, node4}
{noformat}
where each node of cluster ejb-forwarder has a remote outbound connection to node3
- a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb
- a non-forwarding deployment on cluster ejb
- a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms
The test execution:
Once the servers and deployments have been deployed, each server is shut down and then restarted in turn, at which time the test ends.
The expected behaviour:
- at least 90% of client invocations will complete without exception
- test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down)
- server-client invocations on ejb will fail-over from node3 to node 4 (or vice versa depending on which node of cluster ejb is down)
The invocation transaction attribute set up:
- invocations from the client to ejb-forwarder are not in transaction scope
- invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
This allows exercising invocations from a managed transaction context, which uncovered a number of issues...
was:
The Wildfly test suite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle.
The test setup:
- two clusters
{noformat}
ejb-forwarder = {node0, node1}
ejb={node3, node4}
{noformat}
where each node of cluster ejb-forwarder has a remote outbound connection to node3
- a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb
- a non-forwarding deployment on cluster ejb
- a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms
The test execution:
Once the servers and deployments have been deployed, each server is shut down and then restarted in turn, at which time the test ends.
The expected behaviour is that:
- at least 90% of client invocations will complete without exception
- test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down)
- server-client invocations on ejb will fail-over from node3 to node 4 (or vice versa depending on which node of cluster ejb is down)
The transaction set up is currently:
- invocations from the client to ejb-forwarder are not in transaction scope
- invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
This allows exercising invocations from a managed transaction context.
> Provide two cluster test case for EJBClient
> -------------------------------------------
>
> Key: WFLY-4853
> URL: https://issues.jboss.org/browse/WFLY-4853
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 10.0.0.Alpha4
> Reporter: Richard Achmatowicz
>
> The Wildfly test suite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle.
> The test setup:
> - two clusters
> {noformat}
> ejb-forwarder = {node0, node1}
> ejb={node3, node4}
> {noformat}
> where each node of cluster ejb-forwarder has a remote outbound connection to node3
> - a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb
> - a non-forwarding deployment on cluster ejb
> - a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms
> The test execution:
> Once the servers and deployments have been deployed, each server is shut down and then restarted in turn, at which time the test ends.
> The expected behaviour:
> - at least 90% of client invocations will complete without exception
> - test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down)
> - server-client invocations on ejb will fail-over from node3 to node 4 (or vice versa depending on which node of cluster ejb is down)
> The invocation transaction attribute set up:
> - invocations from the client to ejb-forwarder are not in transaction scope
> - invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
> This allows exercising invocations from a managed transaction context, which uncovered a number of issues...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years