April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate with started conversation

by Tom Schuller (JIRA)

[ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.... ] Tom Schuller commented on WFLY-4067: ------------------------------------ confirmation that it's fixed and runs under "wildfly-9.0.0.CR1-SNAPSHOT (build #1647)" > DummyTransaction exception during session.invalidate with started conversation > ------------------------------------------------------------------------------ > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Fix For: 9.0.0.Beta1 > > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > We are working in "full-ha" with session distribution enabled (<distributable/> in web.xml) > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1475) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

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

by Jive JIRA Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4187?page=com.atlassian.jira.plugin.... ] Jive JIRA Integration updated WFLY-4187: ---------------------------------------- Forum Reference: https://developer.jboss.org/message/923760#923760 > 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)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4507) Fix Compiler Warnings in Mail Subsystem

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/WFLY-4507?page=com.atlassian.jira.plugin.... ] Philippe Marschall updated WFLY-4507: ------------------------------------- Fix Version/s: 9.0.0.CR1 > Fix Compiler Warnings in Mail Subsystem > --------------------------------------- > > Key: WFLY-4507 > URL: https://issues.jboss.org/browse/WFLY-4507 > Project: WildFly > Issue Type: Patch > Components: Mail > Reporter: Philippe Marschall > Assignee: Tomaz Cerar > Fix For: 9.0.0.CR1 > > > The mail subsystem contains several compiler warnings. Some of them (mostly related to generics) are quite easy to fix. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4506) Fix Compiler Warnings in JDR Subsystem

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/WFLY-4506?page=com.atlassian.jira.plugin.... ] Philippe Marschall updated WFLY-4506: ------------------------------------- Fix Version/s: 9.0.0.CR1 > Fix Compiler Warnings in JDR Subsystem > -------------------------------------- > > Key: WFLY-4506 > URL: https://issues.jboss.org/browse/WFLY-4506 > Project: WildFly > Issue Type: Patch > Components: JDR > Reporter: Philippe Marschall > Assignee: Jesse Jaggars > Fix For: 9.0.0.CR1 > > > The jdr subsystem contains three compiler warnings. Two of them (related to generics) are quite easy to fix. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4500) CMResourceService#stop fails to clean up

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/WFLY-4500?page=com.atlassian.jira.plugin.... ] Philippe Marschall updated WFLY-4500: ------------------------------------- Fix Version/s: 9.0.0.CR1 > CMResourceService#stop fails to clean up > ---------------------------------------- > > Key: WFLY-4500 > URL: https://issues.jboss.org/browse/WFLY-4500 > Project: WildFly > Issue Type: Patch > Components: Transactions > Reporter: Philippe Marschall > Assignee: Philippe Marschall > Fix For: 9.0.0.CR1 > > > CMResourceService#stop fails to clean up values that #start creates. > The issue is the line > {code} > jtaEnvironmentBean.getValue().getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap().remove(immediateCleanup); > {code} > immediateCleanup is a {{Boolean}} and the return type of {{getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap()}} is {{Map<String, Boolean>}} > So this line never does anything. The line should read > {code} > jtaEnvironmentBean.getValue().getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap().remove(jndiName); > {code} > because if we look a the #start method above we see > {code} > Map<String, Boolean> performImmediateCleanupOfConnectableResourceBranchesMap = jtaEnvironmentBean.getValue().getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap(); > performImmediateCleanupOfConnectableResourceBranchesMap.put(jndiName, immediateCleanup); > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4505) Fix Compiler Warnings in JAX-RS Subsystem

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/WFLY-4505?page=com.atlassian.jira.plugin.... ] Philippe Marschall updated WFLY-4505: ------------------------------------- Fix Version/s: 9.0.0.CR1 > Fix Compiler Warnings in JAX-RS Subsystem > ----------------------------------------- > > Key: WFLY-4505 > URL: https://issues.jboss.org/browse/WFLY-4505 > Project: WildFly > Issue Type: Patch > Components: REST > Reporter: Philippe Marschall > Assignee: Stuart Douglas > Fix For: 9.0.0.CR1 > > > The jaxrs subsystem contains several compiler warnings. Some of them (mostly related to generics and unused variables) are quite easy to fix. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4499) Fix Compiler Warnings in Transactions Subsystem

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/WFLY-4499?page=com.atlassian.jira.plugin.... ] Philippe Marschall updated WFLY-4499: ------------------------------------- Fix Version/s: 9.0.0.CR1 > Fix Compiler Warnings in Transactions Subsystem > ----------------------------------------------- > > Key: WFLY-4499 > URL: https://issues.jboss.org/browse/WFLY-4499 > Project: WildFly > Issue Type: Patch > Components: Transactions > Reporter: Philippe Marschall > Assignee: Philippe Marschall > Fix For: 9.0.0.CR1 > > > The transactions subsystem contains several compiler warnings. Some of them (mostly related to generics) are quite easy to fix. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

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

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-639?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-639: ----------------------------------------- Emmanuel, we don't need to do this as part of this fix, but since we're changing APIs anyway it's worth considering. Should the JmxPermissionFactory interface go away? The new getUserPermissions and getRequiredPermissions methods can go in the PermissionFactory interface. The existing JmxPermissionFactory.getUserRoles method will no longer be used. And the JmxPermissionFactory.isNonFacadeMBeansSensitive method is an odd fit and doesn't really belong in a "permission factory" interface. > 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)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-642) ReadOperationDescriptionHandler doesn't handle multi-process wildcard addresses nicely

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-642?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-642: ------------------------------------ Fix Version/s: 1.0.0.Beta5 (was: 1.0.0.CR1) > ReadOperationDescriptionHandler doesn't handle multi-process wildcard addresses nicely > -------------------------------------------------------------------------------------- > > Key: WFCORE-642 > URL: https://issues.jboss.org/browse/WFCORE-642 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta5 > > > Getting WFCORE-282 to work surfaces a problem with :read-operation-description handling, which will get invoked in the background by the CLI whenever the user inputs a wildcard read op. > Problem is ReadOperationDescriptionHandler.getDescribedOp, which attempts to deal with cases where there is no resource registration for the target address. It checks if the request is for a wildcard address, and if so it sees if there are concrete registrations for that address, and if so whether they all use the same description. If yes, it provides the description. > This is broken in a couple ways: > 1) It assumes the wildcard applies to the last element in the address, which may not be the case with ops that support wildcard addressing schemes. > 2) It looks vulnerable to problems with proxy resources, particularly the /host=* case on the DC where there can be a normal ConcreteResourceRegistration for the local host=master child, and then ProxyControllerRegistration instances for the various host=slave-x registrations. I suspect this might lead to false results. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-643) On Windows, setting the JAVA_OPTS variable is not

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-643?page=com.atlassian.jira.plugin... ] Tomaz Cerar moved WFLY-4523 to WFCORE-643: ------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-643 (was: WFLY-4523) Affects Version/s: 1.0.0.Beta4 (was: 9.0.0.Alpha1) Component/s: Scripts (was: Scripts) > On Windows, setting the JAVA_OPTS variable is not > ------------------------------------------------- > > Key: WFCORE-643 > URL: https://issues.jboss.org/browse/WFCORE-643 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 1.0.0.Beta4 > Environment: Windows 7 x64, JRE was bundled with JDK 8 u40 x64. > Hardware specs: > CPU: Intel Core i7-3720QM CPU @ 2.60 GHz > RAM: 16.0 GB > GPU: NVIDIA Quadro K1000M > Others upon request. > Reporter: Tom Kelley > Assignee: Alexey Loubyansky > Priority: Minor > > {warn} This issue was copy/pasted from a github issue [here|https://github.com/wildfly/wildfly/issues/7352]. I apologize for 1) the issue duplication, 2) the length of the issue, 3) any poor communication that the transcription caused. {warn} > My company uses JBoss AS, and I have a copy on my local machine. In setting it up, I wrote a small script that lives in the bin directory and looks something like this: > {code} > @rem Delete current log file > del /F /Q ..\standalone\log\server.log > @rem Set Java Opts because I want to > set JAVA_OPTS="-XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms1303M -Xmx1303M -XX:MaxPermSize=256M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -agentlib:jdwp=transport=dt_socket,server=y,suspend=n" > @rem Set the new Java Home > set JAVA_HOME=C:\bin\java\jdk8_u40_64\jre > @rem Run Jboss > standalone.bat -c=standalone-full.xml --debug > {code} > I noticed when I was starting the server that the JAVA_OPTS in the debug text were not what I was passing in. I figured I could get to the bottom of what was going on, so I started digging in. My investigation led me to standalone.conf.bat, which looks like this: > {code} > rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters) > rem set PRESERVE_JAVA_OPTS=true > if not "x%JAVA_OPTS%" == "x" ( > echo "JAVA_OPTS already set in environment; overriding default settings with values: %JAVA_OPTS%" > goto JAVA_OPTS_SET > ) > {code} > This is very interesting. This snippet of code appears to be a bug. As someone who has worked with batch files, I believe that the correct code should look like this: > {code} > rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters) > rem set PRESERVE_JAVA_OPTS=true > if not "x"%JAVA_OPTS% == "x" ( > echo "JAVA_OPTS already set in environment; overriding default settings with values: %JAVA_OPTS%" > goto JAVA_OPTS_SET > ) > {code} > You must be thinking, "if you know how to do this, why don't you just make the change yourself? It seems trivial." I would, but I'm not able to find the batch file in the source tree. It appears (to me) that the batch file is generated, and I don't know what to start looking for in order to fix this issue on my own. > As such, I've created a test batch file (meant to be run on Windows) that I've attached to this Issue. When the issue is fixed, it should output something like this: > {code} > Calling "C:\bin\wildfly\src\wildfly\build\target\wildfly-9.0.0.CR1-SNAPSHOT\bin\standalone.conf.bat" > "JAVA_OPTS already set in environment; overriding default settings with values: "Look at me. LOOK AT ME. I am the JAVA_OPTS now."" > Setting JAVA property to "C:\bin\java\jdk8_u40_64\jre\bin\java" > =============================================================================== > JBoss Bootstrap Environment > JBOSS_HOME: "C:\bin\wildfly\src\wildfly\build\target\wildfly-9.0.0.CR1-SNAPSHOT" > JAVA: "C:\bin\java\jdk8_u40_64\jre\bin\java" > JAVA_OPTS: "-Dprogram.name=standalone.bat "Look at me. LOOK AT ME. I am the JAVA_OPTS now."" > =============================================================================== > Error: Could not find or load main class Look at me. LOOK AT ME. I am the JAVA_OPTS now. > {code} > The batch file can be acquired [here|https://cloud.githubusercontent.com/assets/2186874/7147925/844bc00c-...], just save the link as a batch file, or save it and change the extension (the same way that we get around email filters that don't let us send *.exe's). The way that I ran this was to put the batch file at the root of the Wildfly directory and then call it using window's CMD. The test case does several things: > 1. Maven clean > 2. Call build.bat > 3. Set a JAVA_OPTS system variable > 4. Call the standalone.bat in the new version of Wildfly that was created in step 2 (as long as the target dir is still wildfly-9.0.0.CR1-SNAPSHOT). > I would love to take lead on fixing this, but I'm not sure where to start. If someone could give me a point in the right direction, that would be great. Thanks. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

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