April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4187) Cloning org.jboss.invocation.InterceptorContext leaks memory

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-4187?page=com.atlassian.jira.plugin.... ] Eduardo Martins commented on WFLY-4187: --------------------------------------- This was fixed by JBoss Invocation 1.4.1.Final, which will be integrated in this week WildFly Core 1.0.0.Beta5 release, and that should mean the issue will be fixed in next WildFly 9.0.0 release. I will keep an eye on it and close the issue when WildFly master has the fixed JBoss Invocation integrated. In case you want WildFly 8.x with such fix you need to upgrade JBoss Invocation to 1.4.1.Final or, in case its not fully compatible, fork the tag of the included JBoss Invocation, and apply https://github.com/jbossas/jboss-invocation/commit/21cbe4d6d08d245ac80efe... > Cloning org.jboss.invocation.InterceptorContext leaks memory > ------------------------------------------------------------ > > Key: WFLY-4187 > URL: https://issues.jboss.org/browse/WFLY-4187 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.1.0.Final, 8.2.0.Final > Reporter: Jeroen Wielandt > Assignee: Eduardo Martins > > The clone function uses sublist to set the new list of interceptors. > public InterceptorContext clone() { > .... > clone.setInterceptors(interceptors.subList(next, interceptors.size())); > return clone; > } > This will keep a reference to the original list around. So the original list will never be released. Chaining clone multiple times will eventually cause an out of memory because each sublist grows slightly. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4187) Cloning org.jboss.invocation.InterceptorContext leaks memory

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-4187?page=com.atlassian.jira.plugin.... ] Eduardo Martins reassigned WFLY-4187: ------------------------------------- Assignee: Eduardo Martins (was: Jason Greene) > Cloning org.jboss.invocation.InterceptorContext leaks memory > ------------------------------------------------------------ > > Key: WFLY-4187 > URL: https://issues.jboss.org/browse/WFLY-4187 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.1.0.Final, 8.2.0.Final > Reporter: Jeroen Wielandt > Assignee: Eduardo Martins > > The clone function uses sublist to set the new list of interceptors. > public InterceptorContext clone() { > .... > clone.setInterceptors(interceptors.subList(next, interceptors.size())); > return clone; > } > This will keep a reference to the original list around. So the original list will never be released. Chaining clone multiple times will eventually cause an out of memory because each sublist grows slightly. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4520) Multi-JSF archive deploy fails with JBAS014746: steps may not be null

by Paul Newport (JIRA)

[ https://issues.jboss.org/browse/WFLY-4520?page=com.atlassian.jira.plugin.... ] Paul Newport updated WFLY-4520: ------------------------------- Attachment: install-mojarra-1.2_15.cli Example file to deploy built by mvn > Multi-JSF archive deploy fails with JBAS014746: steps may not be null > --------------------------------------------------------------------- > > Key: WFLY-4520 > URL: https://issues.jboss.org/browse/WFLY-4520 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 8.2.0.Final > Reporter: Paul Newport > Assignee: Farah Juma > Attachments: install-mojarra-1.2_15.cli > > > Deploying a multi-jsf archive fails with a steps may not be null error > deploy install-mojarra-1.2_15.cli > { > "outcome" => "failed", > "failure-description" => "JBAS014746: steps may not be null", > "rolled-back" => true > } -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4520) Multi-JSF archive deploy fails with JBAS014746: steps may not be null

by Paul Newport (JIRA)

Paul Newport created WFLY-4520: ---------------------------------- Summary: Multi-JSF archive deploy fails with JBAS014746: steps may not be null Key: WFLY-4520 URL: https://issues.jboss.org/browse/WFLY-4520 Project: WildFly Issue Type: Bug Components: JSF Affects Versions: 8.2.0.Final Reporter: Paul Newport Assignee: Farah Juma Deploying a multi-jsf archive fails with a steps may not be null error deploy install-mojarra-1.2_15.cli { "outcome" => "failed", "failure-description" => "JBAS014746: steps may not be null", "rolled-back" => true } -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4519) Customizable Console Log Viewer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4519?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4519: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1212078 > Customizable Console Log Viewer > ------------------------------- > > Key: WFLY-4519 > URL: https://issues.jboss.org/browse/WFLY-4519 > Project: WildFly > Issue Type: Enhancement > Components: Logging > Affects Versions: 9.0.0.Beta2 > Reporter: Carlton Zachary > Assignee: James Perkins > > Currently the Console log viewer only points to jboss.server.log.dir. In our Domain environment we have our server.log write to a non-default location. This is defined in the host-slave.xml as: > <paths> > <path name="custom.jboss.server.log.dir" path="/apps/logs/server1"/> > </paths> > it is then referenced in the domain.xml file logging subsystem as: > <file relative-to="custom.jboss.server.log.dir" path="server.log"/> > Can the Console logviewer be enhanced to allow it to be configured to point to a custom server.log location? > https://bugzilla.redhat.com/show_bug.cgi?id=1191180 > Thanks -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4519) Customizable Console Log Viewer

by Carlton Zachary (JIRA)

[ https://issues.jboss.org/browse/WFLY-4519?page=com.atlassian.jira.plugin.... ] Carlton Zachary updated WFLY-4519: ---------------------------------- Description: Currently the Console log viewer only points to jboss.server.log.dir. In our Domain environment we have our server.log write to a non-default location. This is defined in the host-slave.xml as: <paths> <path name="custom.jboss.server.log.dir" path="/apps/logs/server1"/> </paths> it is then referenced in the domain.xml file logging subsystem as: <file relative-to="custom.jboss.server.log.dir" path="server.log"/> Can the Console logviewer be enhanced to allow it to be configured to point to a custom server.log location? https://bugzilla.redhat.com/show_bug.cgi?id=1191180 Thanks was: Currently the Console log viewer only points to jboss.server.log.dir. In our Domain environment we have our server.log write to a non-default location. This is defined in the host-slave.xml as: <paths> <path name="custom.jboss.server.log.dir" path="/apps/logs/server1"/> </paths> it is then referenced in the domain.xml file logging subsystem as: <file relative-to="custom.jboss.server.log.dir" path="server.log"/> Can the Console logviewer be enhanced to allow it to be configured to point to a custom server.log location? Thanks > Customizable Console Log Viewer > ------------------------------- > > Key: WFLY-4519 > URL: https://issues.jboss.org/browse/WFLY-4519 > Project: WildFly > Issue Type: Enhancement > Components: Logging > Affects Versions: 9.0.0.Beta2 > Reporter: Carlton Zachary > Assignee: James Perkins > > Currently the Console log viewer only points to jboss.server.log.dir. In our Domain environment we have our server.log write to a non-default location. This is defined in the host-slave.xml as: > <paths> > <path name="custom.jboss.server.log.dir" path="/apps/logs/server1"/> > </paths> > it is then referenced in the domain.xml file logging subsystem as: > <file relative-to="custom.jboss.server.log.dir" path="server.log"/> > Can the Console logviewer be enhanced to allow it to be configured to point to a custom server.log location? > https://bugzilla.redhat.com/show_bug.cgi?id=1191180 > Thanks -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4519) Customizable Console Log Viewer

by Carlton Zachary (JIRA)

Carlton Zachary created WFLY-4519: ------------------------------------- Summary: Customizable Console Log Viewer Key: WFLY-4519 URL: https://issues.jboss.org/browse/WFLY-4519 Project: WildFly Issue Type: Enhancement Components: Logging Affects Versions: 9.0.0.Beta2 Reporter: Carlton Zachary Assignee: James Perkins Currently the Console log viewer only points to jboss.server.log.dir. In our Domain environment we have our server.log write to a non-default location. This is defined in the host-slave.xml as: <paths> <path name="custom.jboss.server.log.dir" path="/apps/logs/server1"/> </paths> it is then referenced in the domain.xml file logging subsystem as: <file relative-to="custom.jboss.server.log.dir" path="server.log"/> Can the Console logviewer be enhanced to allow it to be configured to point to a custom server.log location? Thanks -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-639) ManagementPermissionAuthorizer is limited to the standard roles for its authorizeJmxOperation impl

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-639?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet reassigned WFCORE-639: ---------------------------------------- Assignee: ehsavoie Hugonnet > ManagementPermissionAuthorizer is limited to the standard roles for its authorizeJmxOperation impl > -------------------------------------------------------------------------------------------------- > > Key: WFCORE-639 > URL: https://issues.jboss.org/browse/WFCORE-639 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > > ManagementPermissionAuthorizer.authorizeJmxOperation uses hard coded decision making based on the standard 7 roles. This is inflexible and specifically doesn't allow scoped roles to function properly. > I believe the JmxPermissionFactory interface needs to be redone to use permissions instead of role names. It should have an API more like org.jboss.as.controller.access.permission.PermissionFactory, with getUserPermissions and getRequiredPermissions. Something like > PermissionCollection getUserPermissions(Caller caller, Environment callEnvironment, JmxAction action) > PermissionCollection getRequiredPermissions(JmxAction action); > Then ManagementPermissionAuthorizer.authorizeJmxOperation does a permission match check similar to what it does for management resource permissions. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-764) Delete the dependency to commons-lang 2 in all poms in Drools and jBPM (use commons-lang 3 instead)

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created DROOLS-764: --------------------------------------- Summary: Delete the dependency to commons-lang 2 in all poms in Drools and jBPM (use commons-lang 3 instead) Key: DROOLS-764 URL: https://issues.jboss.org/browse/DROOLS-764 Project: Drools Issue Type: Task Reporter: Geoffrey De Smet Assignee: Michael Biarnes Kiefer Priority: Minor Make an inventory of all modules that still use commons-lang and ask their owners to replace the commons-lang 2 usage with commons-lang 3. See recipe below how they can quickly do that. Once all our modules are upgraded, see if we can remove the commons-lang 2 dependency as much as possible (including the ip-bom hopefully). {code} Currently we have commons-lang 2.6 and 3.1 in our classpath (which is not a problem because they use a different package namespace). Nevertheless, having it twice doesn't look good and 2.6 might miss security fixes. Luckily upgrading is easy (it took me 15 minutes for optaplanner): 1) Replace: <dependency> <groupId>commons-lang</groupId> <artifactId>commons-lang</artifactId> </dependency> with <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> </dependency> (Both are already in the ip-bom, so no need to worry about <version>) 2) Replace "import org.apache.commons.lang." with "import org.apache.commons.lang3." I had about 170 occurrences. 3) Compile. If you have a compile error, look for that class on: https://commons.apache.org/proper/commons-lang/article3_0.html I only had 1 error. Replacing "StringEscapeUtils.escapeHtml(s)" with "StringEscapeUtils.ESCAPE_HTML4.translate(s)" fixed that. {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4411) Upgrade Jackson from 2.4.1 to 2.5.1

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4411?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-4411. ------------------------------- Fix Version/s: 9.0.0.Beta1 Resolution: Done > Upgrade Jackson from 2.4.1 to 2.5.1 > ----------------------------------- > > Key: WFLY-4411 > URL: https://issues.jboss.org/browse/WFLY-4411 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Affects Versions: 9.0.0.Alpha1 > Reporter: Frank Langelage > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 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 April 2015