April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-758) GuidedDecisionTreeModelUnmarshallingVisitor doesn't support unmarshalling of oneline rules

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-758?page=com.atlassian.jira.plugin... ] Tibor Zimányi commented on DROOLS-758: -------------------------------------- PR with test reproducing bad unmarshalling of oneline rule: https://github.com/droolsjbpm/drools/pull/426 > GuidedDecisionTreeModelUnmarshallingVisitor doesn't support unmarshalling of oneline rules > ------------------------------------------------------------------------------------------ > > Key: DROOLS-758 > URL: https://issues.jboss.org/browse/DROOLS-758 > Project: Drools > Issue Type: Bug > Reporter: Tibor Zimányi > Assignee: Mark Proctor > Priority: Minor > > Method visit() from GuidedDecisionTreeModelUnmarshallingVisitor doesn't support rules, that are written in one line (so it doesn't unmarshall them correctly). According to documentation [1] (Block 7.1.2), rule can be written without line separators. Also depending on line separators introduce problems with rules from DRL files that are written on operating systems with different line separator that is on a system where drools engine runs (this can be seen running GuidedDecisionTreeDRLPersistenceUnmarshallingMessagesTest in Windows environment). > The problematic part of the code: [2] > But there are also other places, where there is parsing line by line used. I.e. [3]. > Rules should be parsed by keywords without depending on line separator or generally on lines. > [1] https://docs.jboss.org/drools/release/6.1.0.Final/drools-docs/html_single... > [2] https://github.com/droolsjbpm/drools/blob/007148f6e910a4706f6a20862abc002... > [3] https://github.com/droolsjbpm/drools/blob/9019854d3427a6079eeea19f548a102... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-758) GuidedDecisionTreeModelUnmarshallingVisitor doesn't support unmarshalling of oneline rules

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-758?page=com.atlassian.jira.plugin... ] Tibor Zimányi updated DROOLS-758: --------------------------------- Description: Method visit() from GuidedDecisionTreeModelUnmarshallingVisitor doesn't support rules, that are written in one line (so it doesn't unmarshall them correctly). According to documentation [1] (Block 7.1.2), rule can be written without line separators. Also depending on line separators introduce problems with rules from DRL files that are written on operating systems with different line separator that is on a system where drools engine runs (this can be seen running GuidedDecisionTreeDRLPersistenceUnmarshallingMessagesTest in Windows environment). The problematic part of the code: [2] But there are also other places, where there is parsing line by line used. I.e. [3]. Rules should be parsed by keywords without depending on line separator or generally on lines. [1] https://docs.jboss.org/drools/release/6.1.0.Final/drools-docs/html_single... [2] https://github.com/droolsjbpm/drools/blob/007148f6e910a4706f6a20862abc002... [3] https://github.com/droolsjbpm/drools/blob/9019854d3427a6079eeea19f548a102... was: Method visit() from GuidedDecisionTreeModelUnmarshallingVisitor doesn't support rules, that are written in one line. According to documentation [1] (Block 7.1.2), rule can be written without line separators. Also depending on line separators introduce problems with rules from DRL files that are written on operating systems with different line separator that is on a system where drools engine runs (this can be seen running GuidedDecisionTreeDRLPersistenceUnmarshallingMessagesTest in Windows environment). The problematic part of the code: [2] But there are also other places, where there is parsing line by line used. I.e. [3]. Rules should be parsed by keywords without depending on line separator or generally on lines. [1] https://docs.jboss.org/drools/release/6.1.0.Final/drools-docs/html_single... [2] https://github.com/droolsjbpm/drools/blob/007148f6e910a4706f6a20862abc002... [3] https://github.com/droolsjbpm/drools/blob/9019854d3427a6079eeea19f548a102... > GuidedDecisionTreeModelUnmarshallingVisitor doesn't support unmarshalling of oneline rules > ------------------------------------------------------------------------------------------ > > Key: DROOLS-758 > URL: https://issues.jboss.org/browse/DROOLS-758 > Project: Drools > Issue Type: Bug > Reporter: Tibor Zimányi > Assignee: Mark Proctor > Priority: Minor > > Method visit() from GuidedDecisionTreeModelUnmarshallingVisitor doesn't support rules, that are written in one line (so it doesn't unmarshall them correctly). According to documentation [1] (Block 7.1.2), rule can be written without line separators. Also depending on line separators introduce problems with rules from DRL files that are written on operating systems with different line separator that is on a system where drools engine runs (this can be seen running GuidedDecisionTreeDRLPersistenceUnmarshallingMessagesTest in Windows environment). > The problematic part of the code: [2] > But there are also other places, where there is parsing line by line used. I.e. [3]. > Rules should be parsed by keywords without depending on line separator or generally on lines. > [1] https://docs.jboss.org/drools/release/6.1.0.Final/drools-docs/html_single... > [2] https://github.com/droolsjbpm/drools/blob/007148f6e910a4706f6a20862abc002... > [3] https://github.com/droolsjbpm/drools/blob/9019854d3427a6079eeea19f548a102... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-758) GuidedDecisionTreeModelUnmarshallingVisitor doesn't support unmarshalling of oneline rules

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-758: ------------------------------------ Summary: GuidedDecisionTreeModelUnmarshallingVisitor doesn't support unmarshalling of oneline rules Key: DROOLS-758 URL: https://issues.jboss.org/browse/DROOLS-758 Project: Drools Issue Type: Bug Reporter: Tibor Zimányi Assignee: Mark Proctor Priority: Minor Method visit() from GuidedDecisionTreeModelUnmarshallingVisitor doesn't support rules, that are written in one line. According to documentation [1] (Block 7.1.2), rule can be written without line separators. Also depending on line separators introduce problems with rules from DRL files that are written on operating systems with different line separator that is on a system where drools engine runs (this can be seen running GuidedDecisionTreeDRLPersistenceUnmarshallingMessagesTest in Windows environment). The problematic part of the code: [2] But there are also other places, where there is parsing line by line used. I.e. [3]. Rules should be parsed by keywords without depending on line separator or generally on lines. [1] https://docs.jboss.org/drools/release/6.1.0.Final/drools-docs/html_single... [2] https://github.com/droolsjbpm/drools/blob/007148f6e910a4706f6a20862abc002... [3] https://github.com/droolsjbpm/drools/blob/9019854d3427a6079eeea19f548a102... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4374) java.lang.IllegalAccessError and other classloader issues

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-4374?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-4374: ----------------------------------- It meets the EE specification (and our own documentation) because we allow Class-Path to explicitly state dependencies, of course. You just cannot expect split packages to function as if they were the same package, because you (the user) cannot (by Java EE spec) rely on the configuration or arrangement of class loaders within your application and expect your application to be portable. As I said if you want to put more than one JAR into the same class loader you must use the deployment structure descriptor to stipulate that. > java.lang.IllegalAccessError and other classloader issues > --------------------------------------------------------- > > Key: WFLY-4374 > URL: https://issues.jboss.org/browse/WFLY-4374 > Project: WildFly > Issue Type: Bug > Components: Class Loading > Affects Versions: 8.2.0.Final, 9.0.0.Beta2 > Environment: Windows 7/Java 7 update 67 > Reporter: John Sipher > Assignee: David Lloyd > Attachments: problem-demo.zip > > > Update 4/1/2015: I have verified that 9.0.0.Beta2 fixes the IllegalAccessError and the war file in problem-demo.zip/hello-world6/target now duplicates the original problem. The order of the jar files in the classpath should be > WEB-INF/lib/patch/patch2.jar > WEB-INF/lib/patch/patch1.jar > WEB-INF/lib/base/helloworld-sans-cdi.jar > org.jboss.as.quickstarts.helloworld.HelloService exists in both patch2.jar and helloworld-sans-cdi.jar. The version from patch2.jar should be used because it is first in the classpath, but the classloader is picking up the original class from helloworld-sans-cdi.jar instead. > Original problem description follows: > We use manifest-only jar files in our WAR and EAR files to control the order that jar files are searched for classes. When we issue patches, we put the modified class(es) in a separate jar file, add that jar file to the affected EAR or WAR file, and update the classpath in our manifest-only jar file to put the new patch at the beginning of the class path so that it will be used in place of the original class (which is still in the original jar file). > > For example, WEB-INF/lib will contain a single jar file named manifest.jar and sub-folders named 3rdparty, base, patch, and custom. The Class-Path entry in WEB-INF/lib/manifest.jar|META-INF/MANIFEST.MF looks like this: > Class-Path: 3rdparty/manifest.jar patch/manifest.jar base/manifest.jar custom/manifest.jar > > When we publish a patch, the patch jar file is added to WEB-INF/lib/patch and to the front of the classpath in WEB-INF/lib/patch/manifest.jar's MANIFEST.MF. > > This worked fine for us for years with JBoss 4.2.3.GA, 5.1.0.GA, 7.1.2.Final, and 7.2.0.Final, but it's broken in WildFly 8.2.0.Final. > When I run it in debug I can see where the problem shows up in this section of org.jboss.modules.Module (lines 562 - 573). > final String path = pathOfClass(className); > final Map<String, List<LocalLoader>> paths = getPathsUnchecked(); > final List<LocalLoader> loaders = paths.get(path); > if (loaders != null) { > Class<?> clazz; > for (LocalLoader loader : loaders) { > clazz = loader.loadClassLocal(className, resolve); > if (clazz != null) { > return clazz; > } > } > } > The modules in the loaders list at line 565 are > * deployment.service.ear.lib/base/shared.jar:main > * deployment.service.ear.lib/base/deployment.jar:main > * deployment.service.ear.lib/patch/patch.jar:main > The last one should actually be the first in the list. I haven't been able to track down the actual source of the error yet. > I've been trying to create a simple example based on the helloworld quickstart to reproduce the problem, but I haven't been successful yet because of other classloader errors that I've run into. I decided to go ahead and open this issue and document the things I am able to reproduce. Those are: > 1. CDI injection doesn't work when the annotated classes are in jar files under WEB-INF/lib instead of unpacked in WEB-INF/classes. > 2. WildFly doesn't process the javax.servlet.annotation.WebServlet annotation if the jar file containing the annotated class is in a sub-folder of WEB-INF/lib. > 3. WildFly throws a java.lang.IllegalAccessError trying to load a "patched" class. > The first problem exists in both 7.2.0.Final and 8.2.0.Final. The other two problems are new in 8.2.0.Final. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-631) Wildcard operation inside composite is missing address node

by Harald Pehl (JIRA)

Harald Pehl created WFCORE-631: ---------------------------------- Summary: Wildcard operation inside composite is missing address node Key: WFCORE-631 URL: https://issues.jboss.org/browse/WFCORE-631 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Harald Pehl Assignee: Brian Stansberry The result of a composite operation which contains a {{read-resource}} operation with wildcards is missing the {{address}} node. {code:title=WildFly 9|borderStyle=solid} [domain@localhost:9990 /] batch [domain@localhost:9990 / #] /server-group=*/deployment=*:read-resource [domain@localhost:9990 / #] run-batch --verbose { "outcome" => "success", "result" => {"step-1" => { "outcome" => "success", "result" => [{ "address" => undefined, "outcome" => undefined, "result" => { "enabled" => false, "name" => "jboss-as-login.war", "runtime-name" => "jboss-as-login.war" } }] }}, "server-groups" => undefined } {code} {code:title=WildFly 8.2.0|borderStyle=solid} [domain@localhost:9990 /] batch [domain@localhost:9990 / #] /server-group=*/deployment=*:read-resource [domain@localhost:9990 / #] run-batch --verbose { "outcome" => "success", "result" => {"step-1" => { "outcome" => "success", "result" => [{ "address" => [ ("server-group" => "main-server-group"), ("deployment" => "test-application.war") ], "outcome" => undefined, "result" => { "enabled" => false, "name" => "test-application.war", "runtime-name" => "test-application.war" } }] }}, "server-groups" => undefined } {code} Executing the {{read-resource}} op itself yields the same result for WildFly 8.2.0.Final and 9 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?

by Georgy Go (JIRA)

[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ] Georgy Go edited comment on WFLY-4373 at 4/8/15 7:46 AM: --------------------------------------------------------- No, there're 2 deployments at the single WF instance: Kernel.war and asdasd.war. I redeploying asdasd from servlet of another one. asdasd.war is Kernel.war, but with another deployment name. was (Author: wilddev): No, there're 2 deployments at the single WF instance: Kernel.war and asdasd.war. I redeploying asdasd from servlet of another one. > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: Domain Management, IO > Affects Versions: 8.2.0.Final > Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final > Reporter: Georgy Go > Assignee: Tomaz Cerar > Labels: cli, dmr > Attachments: threaddump.zip > > > The following snippet of code to redeploy an application: > ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); > ModelNode operation = new ModelNode(); > operation.get("operation").set("redeploy"); > operation.get("address").add("deployment", "server.war"); > cl.execute(operation); > cl.close(); > - works fine, but .close() freezes forever. > This issue depends to not only redeploy, but also for any other operations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?

by Georgy Go (JIRA)

[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ] Georgy Go edited comment on WFLY-4373 at 4/8/15 7:11 AM: --------------------------------------------------------- No, there're 2 deployments at the single WF instance: Kernel.war and asdasd.war. I redeploying asdasd from servlet of another one. was (Author: wilddev): No, there're 2 deployments at the single WF instance: Kernel.war and asdasd.war. I redeploying asdasd from another one. > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: Domain Management, IO > Affects Versions: 8.2.0.Final > Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final > Reporter: Georgy Go > Assignee: Tomaz Cerar > Labels: cli, dmr > Attachments: threaddump.zip > > > The following snippet of code to redeploy an application: > ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); > ModelNode operation = new ModelNode(); > operation.get("operation").set("redeploy"); > operation.get("address").add("deployment", "server.war"); > cl.execute(operation); > cl.close(); > - works fine, but .close() freezes forever. > This issue depends to not only redeploy, but also for any other operations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?

by Georgy Go (JIRA)

[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ] Georgy Go commented on WFLY-4373: --------------------------------- No, there're 2 deployments at the single WF instance: Kernel.war and asdasd.war. I redeploying asdasd from another one. > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: Domain Management, IO > Affects Versions: 8.2.0.Final > Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final > Reporter: Georgy Go > Assignee: Tomaz Cerar > Labels: cli, dmr > Attachments: threaddump.zip > > > The following snippet of code to redeploy an application: > ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); > ModelNode operation = new ModelNode(); > operation.get("operation").set("redeploy"); > operation.get("address").add("deployment", "server.war"); > cl.execute(operation); > cl.close(); > - works fine, but .close() freezes forever. > This issue depends to not only redeploy, but also for any other operations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4489) NPE on missing name of <distributed-workmanager>

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-4489?page=com.atlassian.jira.plugin.... ] Jesper Pedersen reassigned WFLY-4489: ------------------------------------- Fix Version/s: 9.0.0.CR1 Assignee: Philippe Marschall (was: Jesper Pedersen) Affects Version/s: 9.0.0.Beta2 > NPE on missing name of <distributed-workmanager> > ------------------------------------------------ > > Key: WFLY-4489 > URL: https://issues.jboss.org/browse/WFLY-4489 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 9.0.0.Beta2 > Reporter: Philippe Marschall > Assignee: Philippe Marschall > Fix For: 9.0.0.CR1 > > > When the name attribute of {{<distributed-workmanager>}} is missing instead of a descriptive log message you get a {{NullPointerException}}. The issue is that the {{StringBuilder}} constructor is called with the value of the name attribute instead of the name of the name attribute ("name"). > Something like this: > {code} > <subsystem xmlns="urn:jboss:domain:jca:2.0"> > <distributed-workmanager/> > </subsystem> > {code} > Will produce a stack trace like this: > {code} > [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) > at org.jboss.as.server.ServerService.boot(ServerService.java:347) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:271) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at java.lang.StringBuilder.<init>(StringBuilder.java:112) > at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.parseDistributedWorkManager(JcaExtension.java:560) > at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.readElement(JcaExtension.java:367) > at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.readElement(JcaExtension.java:119) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) > at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1199) > at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:457) > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:144) > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:106) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) > {code} > After the patch the stack trace looks like this: > {code} > org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-1.0.0.Beta2.jar:1.0.0.Beta2] > at org.jboss.as.server.ServerService.boot(ServerService.java:347) [wildfly-server-1.0.0.Beta2.jar:1.0.0.Beta2] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:271) [wildfly-controller-1.0.0.Beta2.jar:1.0.0.Beta2] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40] > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[274,13] > Message: WFLYCTL0133: Missing required attribute(s): name > at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.parseDistributedWorkManager(JcaExtension.java:563) > at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.readElement(JcaExtension.java:368) > at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.readElement(JcaExtension.java:120) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1199) [wildfly-server-1.0.0.Beta2.jar:1.0.0.Beta2] > at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:457) [wildfly-server-1.0.0.Beta2.jar:1.0.0.Beta2] > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:144) [wildfly-server-1.0.0.Beta2.jar:1.0.0.Beta2] > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:106) [wildfly-server-1.0.0.Beta2.jar:1.0.0.Beta2] > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-1.0.0.Beta2.jar:1.0.0.Beta2] > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-4373: ----------------------------------- Am I reading thread dump correctly? you call redeploy in servlet from inside application that you want to redeploy? > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: Domain Management, IO > Affects Versions: 8.2.0.Final > Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final > Reporter: Georgy Go > Assignee: Tomaz Cerar > Labels: cli, dmr > Attachments: threaddump.zip > > > The following snippet of code to redeploy an application: > ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); > ModelNode operation = new ModelNode(); > operation.get("operation").set("redeploy"); > operation.get("address").add("deployment", "server.war"); > cl.execute(operation); > cl.close(); > - works fine, but .close() freezes forever. > This issue depends to not only redeploy, but also for any other operations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015