June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1216) Ban commons-logging and log4j deps

by Petr Široký (JIRA)

Petr Široký created DROOLS-1216: ----------------------------------- Summary: Ban commons-logging and log4j deps Key: DROOLS-1216 URL: https://issues.jboss.org/browse/DROOLS-1216 Project: Drools Issue Type: Task Components: build Affects Versions: 6.4.0.Final Reporter: Petr Široký Assignee: Petr Široký We are using slf4j + logback for logging. Sometimes other logging libs like commons-logging or log4j creep into the dependency tree. Only way to make sure we get rid of them once and for all is to ban them explicitly via enforcer. There is a rule "bannedDependencies" which can be easily used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6499) Add support for soft-index file cache store to infinispan subsystem

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6499?page=com.atlassian.jira.plugin.... ] Radoslav Husar edited comment on WFLY-6499 at 6/21/16 10:57 AM: ---------------------------------------------------------------- --Sounds like it's not that stable yet.-- https://issues.jboss.org/browse/ISPN-5743 https://issues.jboss.org/browse/ISPN-5753 https://issues.jboss.org/browse/ISPN-5596 https://issues.jboss.org/browse/ISPN-5782 All of the above are resolved by now. was (Author: rhusar): Sounds like it's not that stable yet. https://issues.jboss.org/browse/ISPN-5743 https://issues.jboss.org/browse/ISPN-5753 https://issues.jboss.org/browse/ISPN-5596 https://issues.jboss.org/browse/ISPN-5782 > Add support for soft-index file cache store to infinispan subsystem > ------------------------------------------------------------------- > > Key: WFLY-6499 > URL: https://issues.jboss.org/browse/WFLY-6499 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1464) LogContexts are not removed for ear subdeployments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1464?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1464: ------------------------------------------------- Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1324572|https://bugzilla.redhat.com/show_bug.cgi?id=1324572] from ON_QA to VERIFIED > LogContexts are not removed for ear subdeployments > -------------------------------------------------- > > Key: WFCORE-1464 > URL: https://issues.jboss.org/browse/WFCORE-1464 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Affects Versions: 2.1.0.Final > Reporter: Aaron Ogburn > Assignee: Aaron Ogburn > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > Attachments: app.ear > > > If an ear does not have its own LogContext created, but a subdeployment in it does, the subdeployment never has its LogContext cleaned up upon undeploy, leading to PermGen leaks. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6682) Upgrade Hibernate to 5.2.0

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6682?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-6682: ------------------------------------ Sounds like a good approach [~epbernard] ! I heard something about adding the hibernate java8/entitymanager maven dependencies back in 5.2.1, which I guess could help with application build time issues. Is that also the plan? If yes, the [https://github.com/wildfly/wildfly/pull/8961] pull request will need some adjustment to not delete those modules. > Upgrade Hibernate to 5.2.0 > -------------------------- > > Key: WFLY-6682 > URL: https://issues.jboss.org/browse/WFLY-6682 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Frank Langelage > Assignee: Scott Marlow > Priority: Critical > Fix For: 10.1.0.Final > > Attachments: screenshot-1.png > > > Upgrade Hibernate to latest version 5.2.0.Final. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1215) import function(s) with collision on declared Pojo field names odd behavior and no warning

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1215?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1215: ----------------------------------- Attachment: DROOLS-1215.zip > import function(s) with collision on declared Pojo field names odd behavior and no warning > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1215 > URL: https://issues.jboss.org/browse/DROOLS-1215 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final > Reporter: Matteo Mortari > Assignee: Mario Fusco > Attachments: DROOLS-1215.zip > > > Hello, > not sure (yet) what is causing this odd behavior, but considering the following rule-base in the attached reproducer, evolved from the usual kie example archetype: > {code} > global java.util.Set controlSet; > rule "will execute per each Measurement having ID color" > no-loop > when > WantToKeep( condition == "color" ) > Measurement( id == "color", $colorVal : val ) > then > controlSet.add($colorVal); > end > declare WantToKeep > condition : String > end > rule "kickstart" > salience 999 > when > eval( true ) > then > insert(new WantToKeep( "color" )); > end > {code} > This works as expected until adding the following import statement: > {code} > import function org.jooq.impl.DSL.*; > {code} > and then the test will fail. > I suspect because some "functions"/static method exists on {{org.jooq.impl.DSL}} with name "condition" which is colliding with the declared Pojo field name "condition", but I can't understand why this supposed collision happens as in the LHS I'm looking for the field not a method invocation with the {{condition()}} form. > I'm willing to investigate more on this later, for the time being I thought worthy at least to raise this JIRA record for tracking. > I will attach reproducer and workaround in the appropriate sections. > Thank you, > Ciao, > MM -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/REMJMX-94?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on REMJMX-94: ----------------------------------------------- Filip Brychta <fbrychta(a)redhat.com> changed the Status of [bug 1191002|https://bugzilla.redhat.com/show_bug.cgi?id=1191002] from ON_QA to ASSIGNED > Memory leak in remoting-jmx > --------------------------- > > Key: REMJMX-94 > URL: https://issues.jboss.org/browse/REMJMX-94 > Project: Remoting JMX > Issue Type: Bug > Affects Versions: 1.1.3.Final > Reporter: Libor Zoubek > Assignee: Darran Lofthouse > Labels: memory_leak > Fix For: 2.0.2.CR1 > > > In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed. > I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps: > 1. start new thread > 2. assign URL classloader to this thread (point it to jboss-client.jar) > 3. connect & disconnect to jmx-remoting endpoint > In this test no classes don't get GCed which after serveral iterations ends up in OOM. > My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org... > I am not sure if memleak is in remoting-jmx or some other underlying stuff. > I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1215) import function(s) with collision on declared Pojo field names odd behavior and no warning

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1215: -------------------------------------- Summary: import function(s) with collision on declared Pojo field names odd behavior and no warning Key: DROOLS-1215 URL: https://issues.jboss.org/browse/DROOLS-1215 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.4.0.Final Reporter: Matteo Mortari Assignee: Mario Fusco Hello, not sure (yet) what is causing this odd behavior, but considering the following rule-base in the attached reproducer, evolved from the usual kie example archetype: {code} global java.util.Set controlSet; rule "will execute per each Measurement having ID color" no-loop when WantToKeep( condition == "color" ) Measurement( id == "color", $colorVal : val ) then controlSet.add($colorVal); end declare WantToKeep condition : String end rule "kickstart" salience 999 when eval( true ) then insert(new WantToKeep( "color" )); end {code} This works as expected until adding the following import statement: {code} import function org.jooq.impl.DSL.*; {code} and then the test will fail. I suspect because some "functions"/static method exists on {{org.jooq.impl.DSL}} with name "condition" which is colliding with the declared Pojo field name "condition", but I can't understand why this supposed collision happens as in the LHS I'm looking for the field not a method invocation with the {{condition()}} form. I'm willing to investigate more on this later, for the time being I thought worthy at least to raise this JIRA record for tracking. I will attach reproducer and workaround in the appropriate sections. Thank you, Ciao, MM -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4316) InvalidBytecodeException when an EJB local interface declares static method

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4316?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4316: ----------------------------------------------- Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1346242|https://bugzilla.redhat.com/show_bug.cgi?id=1346242] from ASSIGNED to POST > InvalidBytecodeException when an EJB local interface declares static method > --------------------------------------------------------------------------- > > Key: WFLY-4316 > URL: https://issues.jboss.org/browse/WFLY-4316 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Jozef Hartinger > Assignee: Jozef Hartinger > Fix For: 9.0.0.Beta1 > > > {noformat} > Caused by: org.jboss.classfilewriter.InvalidBytecodeException: Cannot load variable at 1. Local Variables: Local Variables: [StackEntry [descriptor=Ljava/lang/String;, type=OBJECT]] > at org.jboss.classfilewriter.code.CodeAttribute.aload(CodeAttribute.java:185) > at org.jboss.invocation.proxy.ProxyFactory$ProxyMethodBodyCreator.overrideMethod(ProxyFactory.java:150) > at org.jboss.invocation.proxy.AbstractSubclassFactory.overrideMethod(AbstractSubclassFactory.java:106) > at org.jboss.invocation.proxy.AbstractSubclassFactory.addInterface(AbstractSubclassFactory.java:363) > at org.jboss.invocation.proxy.ProxyFactory.generateClass(ProxyFactory.java:286) > at org.jboss.invocation.proxy.AbstractClassFactory.buildClassDefinition(AbstractClassFactory.java:207) > at org.jboss.invocation.proxy.AbstractClassFactory.defineClass(AbstractClassFactory.java:160) > at org.jboss.invocation.proxy.AbstractProxyFactory.getCachedMethods(AbstractProxyFactory.java:150) > at org.jboss.as.ejb3.component.stateless.StatelessComponentDescription$3.configure(StatelessComponentDescription.java:150) > at org.jboss.as.ee.component.DefaultComponentViewConfigurator.configure(DefaultComponentViewConfigurator.java:68) > at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:81) > ... 6 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-306) Update add-user to use AESH or move it into the CLI

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin... ] Marek Kopecký reassigned WFCORE-306: ------------------------------------ Assignee: Marek Kopecký (was: Darran Lofthouse) > Update add-user to use AESH or move it into the CLI > --------------------------------------------------- > > Key: WFCORE-306 > URL: https://issues.jboss.org/browse/WFCORE-306 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Scripts > Reporter: Darran Lofthouse > Assignee: Marek Kopecký > Fix For: 3.0.0.Alpha3 > > > Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin > Switching to AESH would allow us to use the implementation there to handle this. > Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible. > Overall this is going to require further discussion so the comments here are just a starting point. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-306) Update add-user to use AESH or move it into the CLI

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin... ] Marek Kopecký reassigned WFCORE-306: ------------------------------------ Assignee: Darran Lofthouse (was: Marek Kopecký) > Update add-user to use AESH or move it into the CLI > --------------------------------------------------- > > Key: WFCORE-306 > URL: https://issues.jboss.org/browse/WFCORE-306 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Scripts > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha3 > > > Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin > Switching to AESH would allow us to use the implementation there to handle this. > Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible. > Overall this is going to require further discussion so the comments here are just a starting point. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

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 June 2016