March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1364) Upgrade WildFly Build Tools to (at least) 1.1.3.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1364?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1364: ------------------------------------- Fix Version/s: 2.1.0.Final (was: 2.1.0.CR2) > Upgrade WildFly Build Tools to (at least) 1.1.3.Final > ----------------------------------------------------- > > Key: WFCORE-1364 > URL: https://issues.jboss.org/browse/WFCORE-1364 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 2.1.0.Final > > > This is required to resolve WFCORE-1357. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1357) Drop javax.sql.api module

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1357?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1357: ------------------------------------- Fix Version/s: 2.1.0.Final (was: 2.1.0.CR2) > Drop javax.sql.api module > ------------------------- > > Key: WFCORE-1357 > URL: https://issues.jboss.org/browse/WFCORE-1357 > Project: WildFly Core > Issue Type: Task > Components: Modules > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 2.1.0.Final > > > In anticipation of dropping the {{javax.transaction.xa}} package out of the {{javax.transaction.api}} module, we can drop the {{javax.sql.api}} module and ensure that the {{.xa}} package is included in {{javax.api}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1350) Upgrade XNIO to >= 3.3.5.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1350?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1350: ---------------------------------------- Fix Version/s: 2.1.0.Final (was: 2.1.0.CR2) Assignee: Jason Greene Resolution: Done > Upgrade XNIO to >= 3.3.5.Final > ------------------------------ > > Key: WFCORE-1350 > URL: https://issues.jboss.org/browse/WFCORE-1350 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: David Lloyd > Assignee: Jason Greene > Fix For: 2.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1351: ------------------------------------- Fix Version/s: 3.0.0.Alpha1 > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1351 > URL: https://issues.jboss.org/browse/WFCORE-1351 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Critical > Fix For: 3.0.0.Alpha1 > > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1349) Upgrate JBoss Marshalling to >= 1.4.11.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1349?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1349: ------------------------------------- Fix Version/s: 3.0.0.Alpha1 (was: 2.1.0.CR2) > Upgrate JBoss Marshalling to >= 1.4.11.Final > -------------------------------------------- > > Key: WFCORE-1349 > URL: https://issues.jboss.org/browse/WFCORE-1349 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: David Lloyd > Fix For: 3.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1351: ------------------------------------- Fix Version/s: (was: 2.1.0.CR2) > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1351 > URL: https://issues.jboss.org/browse/WFCORE-1351 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Critical > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1066) Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)

by Dominik Pospisil (JIRA)

[ https://issues.jboss.org/browse/WFLY-1066?page=com.atlassian.jira.plugin.... ] Dominik Pospisil commented on WFLY-1066: ---------------------------------------- Unfortunatelly I did not get it too much far. It is just a prototype suitable for nothing more than testing/demoing. It is more a hack than anything else. > Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING) > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1066 > URL: https://issues.jboss.org/browse/WFLY-1066 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Environment: Server running in Domain mode > Reporter: Wolf-Dieter Fink > Assignee: Tristan Tarrant > Labels: clustering, domain, jgroups > > It is complicated to keep the subsystem JGroups in sync if the tcp-stack is used in domain mode. > All new servers that join/leave a clustered server group (configuration) must be added or removed by hand for the jgroup configuration. > The domain server will receive the informations if a host-controller enrol and register server to a clustered server-group. > So the configuration of the initial_hosts can be done automaticaly to avoid old entries which cause unnecessary checks and ensure that all active servers are known. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6376) Class loader leak due to Infinispan ExpirationManagerImpl

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6376?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-6376: ------------------------------------ Ah - I see. The ThreadFactory used by Infinispan's thread pools doesn't associate any specific classloader to newly created threads - thus they can become associated with an application class loader - even if the executor service was instantiated eagerly (if core threads < max threads). I've submitted a subsequent pull request to resolve this. > Class loader leak due to Infinispan ExpirationManagerImpl > --------------------------------------------------------- > > Key: WFLY-6376 > URL: https://issues.jboss.org/browse/WFLY-6376 > Project: WildFly > Issue Type: Bug > Components: Clustering, JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Harald Wellmann > Assignee: Paul Ferraro > Priority: Critical > > h3. Scenario > Given a WAR containing a persistence unit with second level cache and query cache enabled, I'm consistently hitting a Metaspace OutOfMemoryError after redeploying the unchanged application a couple of times. > Analyzing the situation with Eclipse Memory Analyzer, I found one cause to be WFLY-6348, but even after applying that fix locally, I'm still having a Classloader leak which I can trace to a thread used by Infinispan referencing an obsolete web app classloader as context classloader. > Just to rule out that this might be related to WFLY-6283, WFLY-6285, I repeated my experiments with a local build of WildFly master (2f11a59aee0dbdd52b65c5c684eafa83c3f418da), with Hibernate locally upgraded to 5.0.9. > I'm still getting a classloader leak with that build. > h3. Analysis > {{org.infinispan.expiration.impl.ExpirationManagerImpl}} uses a {{LazyInitializingScheduledExecutorService}}. Due to lazy initialization, the {{ExecutorService}} and the underlying thread pool is not created until my web app is deployed. Thus, when the {{ExecutorService}} is created, the context class loader is set to the web app class loader, and this appears to propagate to the threads of the executor thread pool. > When the application is undeployed, {{ExpirationManagerImpl.stop()}} gets invoked to cancel any running expiration task. However, the {{ExecutorService}} is not shut down, the threads remain alive and still keep a reference to the now obsolete context classloader. > h3. Remarks > I'm not sure if this analysis is correct, at least I hope there's a clue for WildFly and Infinispan experts to identify the real cause. > By the way, it would be helpful if all threads created by Infinispan had meaningful names, rather than default names like {{pool-5-thread-1}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-794) IPv6ScopeIdMatchUnitTestCase fails if some IPv6 subinterface exists

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-794?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-794: --------------------------------------- Fix Version/s: 3.0.0.Alpha1 Assignee: Petr Kremensky (was: Jason Greene) Resolution: Done > IPv6ScopeIdMatchUnitTestCase fails if some IPv6 subinterface exists > ------------------------------------------------------------------- > > Key: WFCORE-794 > URL: https://issues.jboss.org/browse/WFCORE-794 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 2.0.0.Alpha5 > Reporter: Petr Kremensky > Assignee: Petr Kremensky > Fix For: 3.0.0.Alpha1 > > > The test (org.jboss.as.controller.interfacesIPv6ScopeIdMatchUnitTestCase) keeps failing on one of our Solaris boxes with following interfaces: > {noformat} > /usr/sbin/ifconfig -a > ... > lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1 > inet6 ::1/128 > net0: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2 > inet6 fe80::221:28ff:feb3:20f2/10 > net0:1: flags=120002080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6,PHYSRUNNING> mtu 1500 index 2 > inet6 2620:52:0:105f:221:28ff:feb3:20f2/64 > net4: flags=120002000840<RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 3 > inet6 ::/0 > {noformat} > *Error Message* > {noformat} > expected:</2620:52:0:105f:221:28ff:feb3:20f2%2> but was:<null> > {noformat} > *Stacktrace* > {noformat} > java.lang.AssertionError: expected:</2620:52:0:105f:221:28ff:feb3:20f2%2> but was:<null> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:144) > at org.jboss.as.controller.interfaces.IPv6ScopeIdMatchUnitTestCase.testNonLoopback(IPv6ScopeIdMatchUnitTestCase.java:129) > {noformat} > Promlem is, that getByName returns null when resolving NetworkInterface by its subinterface name (net0:1 in this case). See following example. > {noformat} > Enumeration<NetworkInterface> interfaces = NetworkInterface.getNetworkInterfaces(); > while (interfaces.hasMoreElements()) { > NetworkInterface nic = interfaces.nextElement(); > Enumeration<NetworkInterface> subInterfaces = nic.getSubInterfaces(); > while (subInterfaces.hasMoreElements()) { > NetworkInterface subInterface = subInterfaces.nextElement(); > System.out.println(subInterface.getName()); > System.out.println(NetworkInterface.getByName(subInterface.getName())); > } > } > {noformat} > ---- > {noformat} > em1:0 > null > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-467) Integrate CredentialStore with mechanism configuration so mechanisms can obtain the credentials they require.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-467: ------------------------------------ Summary: Integrate CredentialStore with mechanism configuration so mechanisms can obtain the credentials they require. Key: ELY-467 URL: https://issues.jboss.org/browse/ELY-467 Project: WildFly Elytron Issue Type: Feature Request Components: API / SPI, Credential Store Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta5 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 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 March 2016