January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3564) Bad CLI complementation server groups

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3564?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-3564: ---------------------------------------------- [~vmarek], thank-you for reporting the issue, if you plan to add a unit test to cover the problem, we have a CliCompletionTestCase class in testsuite/domain that is perfect to deal with this kind of issues. You could add a new test in it. Thanks. > Bad CLI complementation server groups > ------------------------------------- > > Key: WFCORE-3564 > URL: https://issues.jboss.org/browse/WFCORE-3564 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Vratislav Marek > Assignee: Jean-Francois Denise > > *Cli complementation insert the whole word without delete writed letters* > * --server-groups={color:#d04437}m{color}main-server-group > * --server-groups={color:#d04437}o{color}other-server-group > * --server-groups={color:#d04437}othe{color}other-server-group > {noformat} > [domain@localhost:9990 /] deployment disable * --server-groups= > main-server-group other-server-group > [domain@localhost:9990 /] deployment disable * --server-groups=mmain-server-group > {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"server-group\" => \"mmain-server-group\")]' not found"}} > [domain@localhost:9990 /] deployment disable * --server-groups=oother-server-group > {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"server-group\" => \"oother-server-group\")]' not found"}} > [domain@localhost:9990 /] > [domain@localhost:9990 /] deployment disable * --server-groups=otheother-server-group > {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"server-group\" => \"otheother-server-group\")]' not found"}} > [domain@localhost:9990 /] > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2280) Resolving rule unit classnames depends on File.separator character

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2280?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-2280: ---------------------------------- Description: When running testNamingConventionOnDrlFile test on Windows, it fails on NPE, because the engine cannot find the rule unit "org/kie/test/MyRuleUnit" defined in the test, because it contains "/" separator character. The method that resolves the classname searches for File.separator character in the mentioned string, which is "\" on Windows [1]. This is a bug, because e.g. MemoryFileSystem uses "/" also when running on Windows. The classname resolution should be OS independent. [1] https://github.com/kiegroup/drools/blob/5fad04919f255933bdd34afdb8da10b94... was: When running testNamingConventionOnDrlFile test on Windows, it fails on NPE, because the engine cannot find the rule unit "org/kie/test/MyRuleUnit" defined in the test, because it contains "/" separator character. I will provide a fix to the test. For resolving the rule unit class, the engine uses OS independent character correctly here [1]. [1] https://github.com/kiegroup/drools/blob/5fad04919f255933bdd34afdb8da10b94... > Resolving rule unit classnames depends on File.separator character > ------------------------------------------------------------------ > > Key: DROOLS-2280 > URL: https://issues.jboss.org/browse/DROOLS-2280 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.5.0.Final > Reporter: Tibor Zimányi > Assignee: Tibor Zimányi > Priority: Minor > > When running testNamingConventionOnDrlFile test on Windows, it fails on NPE, because the engine cannot find the rule unit "org/kie/test/MyRuleUnit" defined in the test, because it contains "/" separator character. The method that resolves the classname searches for File.separator character in the mentioned string, which is "\" on Windows [1]. > This is a bug, because e.g. MemoryFileSystem uses "/" also when running on Windows. The classname resolution should be OS independent. > [1] https://github.com/kiegroup/drools/blob/5fad04919f255933bdd34afdb8da10b94... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2280) Resolving rule unit classnames depends on File.separator character

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2280?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-2280: ---------------------------------- Summary: Resolving rule unit classnames depends on File.separator character (was: Test RuleUnitTest.testNamingConventionOnDrlFile() uses OS specific separator character) > Resolving rule unit classnames depends on File.separator character > ------------------------------------------------------------------ > > Key: DROOLS-2280 > URL: https://issues.jboss.org/browse/DROOLS-2280 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.5.0.Final > Reporter: Tibor Zimányi > Assignee: Tibor Zimányi > Priority: Minor > > When running testNamingConventionOnDrlFile test on Windows, it fails on NPE, because the engine cannot find the rule unit "org/kie/test/MyRuleUnit" defined in the test, because it contains "/" separator character. > I will provide a fix to the test. > For resolving the rule unit class, the engine uses OS independent character correctly here [1]. > [1] https://github.com/kiegroup/drools/blob/5fad04919f255933bdd34afdb8da10b94... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9742) ClassLoader leak in JBoss Threads caused by MDBs

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9742?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-9742: ----------------------------------- I'm in a conference this week, so I won't get to it until next week. If you want to work up a PR that would be great. > ClassLoader leak in JBoss Threads caused by MDBs > ------------------------------------------------ > > Key: WFLY-9742 > URL: https://issues.jboss.org/browse/WFLY-9742 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final > Reporter: Markus Dlugi > Assignee: David Lloyd > Attachments: default-threads-tccl.png, jboss-threads-tccl-example.zip > > > There is a classloader leak in JBoss Threads which is most noticable when deploying MDBs. When a new MDB is created and a new thread for the MDB is started in the JCA thread pool ("default-threads - x"), the thread will be created using the context classloader of the MDB's deployment unit. This is because [MessageDrivenComponent.activate()|https://github.com/wildfly/wildfly/blob...] sets the context classloader of the ServerService thread in order to create the MDB, and this classloader will then also be used by the child thread. > In the default configuration, the threads in the default thread pool will not be terminated and therefore the thread will keep the reference to the classloader even when the deployment unit is undeployed. This in turn can lead to "OutOfMemoryError: Metaspace" after a couple of redeployments. > As a workaround, we changed [JBossThreadFactory.createThread()|https://github.com/jbossas/jboss-thread...] to set the context classloader to null after a new thread has been created. While this fixes the issue for us, I am not sure whether this is a good solution for all consumers of the thread factory, or if this should be fixed in the JCA subsystem instead. That's also the reason why I opened this issue against the WildFly project instead of JBoss Threads. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-316) Invalid URL

by Leonid Konov (JIRA)

Leonid Konov created JBWEB-316: ---------------------------------- Summary: Invalid URL Key: JBWEB-316 URL: https://issues.jboss.org/browse/JBWEB-316 Project: JBoss Web Issue Type: Enhancement Reporter: Leonid Konov Assignee: Remy Maucherat Priority: Minor http://jbossweb.jboss.org/downloads/jboss-native-2-0-8.html All download hyperlinks does not works -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3563) Could not enable application deployment on two server groups in domain

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3563?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-3563: ---------------------------------------------- [~vmarek], is it a new behavior? I just checked in 3.x branch and the behavior is similar, we can't re-deploy a disabled deployment in domain mode from the command. [~mkopecky] could you confirm that 7.1 has same behavior? > Could not enable application deployment on two server groups in domain > ---------------------------------------------------------------------- > > Key: WFCORE-3563 > URL: https://issues.jboss.org/browse/WFCORE-3563 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Vratislav Marek > Assignee: Jean-Francois Denise > > {noformat} > [domain@localhost:9990 /] deployment enable --server-groups=other-server-group,main-server-group cli-test-app-deploy-all.ear > {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [ > (\"server-group\" => \"other-server-group\"), > (\"deployment\" => \"cli-test-app-deploy-all.ear\") > ]"}} > [domain@localhost:9990 /] > {noformat} > {noformat} > [domain@localhost:9990 /] deploy --name=cli-test-app-deploy-all.ear --server-groups=other-server-group,main-server-group > {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [ > (\"server-group\" => \"other-server-group\"), > (\"deployment\" => \"cli-test-app-deploy-all.ear\") > ]"}} > [domain@localhost:9990 /] > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2283) [GSS](6.4.z) NPE when creating KieModuleMetaData with wrong release id

by Martin Weiler (JIRA)

Martin Weiler created DROOLS-2283: ------------------------------------- Summary: [GSS](6.4.z) NPE when creating KieModuleMetaData with wrong release id Key: DROOLS-2283 URL: https://issues.jboss.org/browse/DROOLS-2283 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.0.0.CR3 Reporter: Martin Weiler Assignee: Mario Fusco Fix For: 7.0.0.Final If user tries to create new KieModuleMetaData using KieModuleMetaData.Factory.newKieModuleMetaData() with not existing release id then NPE is thrown, see stacktrace in attachment. This error can be simulated on Kie server. See PR with reproducer [1]. [1] https://github.com/kiegroup/droolsjbpm-integration/pull/950 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9742) ClassLoader leak in JBoss Threads caused by MDBs

by Markus Dlugi (JIRA)

[ https://issues.jboss.org/browse/WFLY-9742?page=com.atlassian.jira.plugin.... ] Markus Dlugi commented on WFLY-9742: ------------------------------------ Alright, thanks for the quick response. That's what I thought as well, I just wasn't sure that there is no code which relies on the initial TCCL of the JBoss Threads. I could provide a PR for this if you want? Although it's just one line of code, so it might be easier for you to do it yourself. > ClassLoader leak in JBoss Threads caused by MDBs > ------------------------------------------------ > > Key: WFLY-9742 > URL: https://issues.jboss.org/browse/WFLY-9742 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final > Reporter: Markus Dlugi > Assignee: David Lloyd > Attachments: default-threads-tccl.png, jboss-threads-tccl-example.zip > > > There is a classloader leak in JBoss Threads which is most noticable when deploying MDBs. When a new MDB is created and a new thread for the MDB is started in the JCA thread pool ("default-threads - x"), the thread will be created using the context classloader of the MDB's deployment unit. This is because [MessageDrivenComponent.activate()|https://github.com/wildfly/wildfly/blob...] sets the context classloader of the ServerService thread in order to create the MDB, and this classloader will then also be used by the child thread. > In the default configuration, the threads in the default thread pool will not be terminated and therefore the thread will keep the reference to the classloader even when the deployment unit is undeployed. This in turn can lead to "OutOfMemoryError: Metaspace" after a couple of redeployments. > As a workaround, we changed [JBossThreadFactory.createThread()|https://github.com/jbossas/jboss-thread...] to set the context classloader to null after a new thread has been created. While this fixes the issue for us, I am not sure whether this is a good solution for all consumers of the thread factory, or if this should be fixed in the JCA subsystem instead. That's also the reason why I opened this issue against the WildFly project instead of JBoss Threads. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9742) ClassLoader leak in JBoss Threads caused by MDBs

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9742?page=com.atlassian.jira.plugin.... ] David Lloyd reassigned WFLY-9742: --------------------------------- Assignee: David Lloyd (was: Jason Greene) > ClassLoader leak in JBoss Threads caused by MDBs > ------------------------------------------------ > > Key: WFLY-9742 > URL: https://issues.jboss.org/browse/WFLY-9742 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final > Reporter: Markus Dlugi > Assignee: David Lloyd > Attachments: default-threads-tccl.png, jboss-threads-tccl-example.zip > > > There is a classloader leak in JBoss Threads which is most noticable when deploying MDBs. When a new MDB is created and a new thread for the MDB is started in the JCA thread pool ("default-threads - x"), the thread will be created using the context classloader of the MDB's deployment unit. This is because [MessageDrivenComponent.activate()|https://github.com/wildfly/wildfly/blob...] sets the context classloader of the ServerService thread in order to create the MDB, and this classloader will then also be used by the child thread. > In the default configuration, the threads in the default thread pool will not be terminated and therefore the thread will keep the reference to the classloader even when the deployment unit is undeployed. This in turn can lead to "OutOfMemoryError: Metaspace" after a couple of redeployments. > As a workaround, we changed [JBossThreadFactory.createThread()|https://github.com/jbossas/jboss-thread...] to set the context classloader to null after a new thread has been created. While this fixes the issue for us, I am not sure whether this is a good solution for all consumers of the thread factory, or if this should be fixed in the JCA subsystem instead. That's also the reason why I opened this issue against the WildFly project instead of JBoss Threads. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3566) Different results of disabling commands already disabled deployment

by Vratislav Marek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3566?page=com.atlassian.jira.plugi... ] Vratislav Marek commented on WFCORE-3566: ----------------------------------------- Should they both commands to warn or report an error? > Different results of disabling commands already disabled deployment > ------------------------------------------------------------------- > > Key: WFCORE-3566 > URL: https://issues.jboss.org/browse/WFCORE-3566 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Vratislav Marek > Assignee: Jean-Francois Denise > > *Different command result of disabling already disabled deployment in standalone and domain mode* > * In standalone return > {noformat} > WFLYCTL0155: 'steps' may not be null > {noformat} > * In domain return nothing, no warning or error > {noformat} > [standalone@localhost:9990 /] deployment info > NAME RUNTIME-NAME PERSISTENT ENABLED STATUS > cli-test-another-deploy.war cli-test-another-deploy.war true true OK > cli-test-app1-deploy.war cli-test-app1-deploy.war true false STOPPED > cli-test-app2-deploy.war cli-test-app2-deploy.war true true OK > [standalone@localhost:9990 /] deployment disable cli-test-app1-deploy-all.war > WFLYCTL0155: 'steps' may not be null > [standalone@localhost:9990 /] > {noformat} > {noformat} > [domain@localhost:9990 /] deployment info --server-groups=main-server-group > NAME RUNTIME-NAME STATE > cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled > cli-test-app1-deploy-all.war cli-test-app1-deploy-all.war added > cli-test-app2-deploy-all.war cli-test-app2-deploy-all.war not added > cli-test-app3-deploy-all.war cli-test-app3-deploy-all.war enabled > [domain@localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war > [domain@localhost:9990 /] > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2018