September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9301) (7.1.0) TestSuite - Add test for ejb security propagation using PLAIN

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-9301: ---------------------------------- Summary: (7.1.0) TestSuite - Add test for ejb security propagation using PLAIN Key: WFLY-9301 URL: https://issues.jboss.org/browse/WFLY-9301 Project: WildFly Issue Type: Task Components: Test Suite Affects Versions: 11.0.0.CR1 Reporter: Brad Maxwell Assignee: Brad Maxwell Add test for ejb security propagation using PLAIN -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3204) Upgrade WildFly Elytron to 1.2.0.Beta2

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3204?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-3204: ------------------------------------- Summary: Upgrade WildFly Elytron to 1.2.0.Beta2 (was: Upgrade WildFly Elytron to 1.2.0.Beta1) > Upgrade WildFly Elytron to 1.2.0.Beta2 > -------------------------------------- > > Key: WFCORE-3204 > URL: https://issues.jboss.org/browse/WFCORE-3204 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9300) TestSuite - Add test for ejb security propagation using PLAIN

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-9300: ---------------------------------- Summary: TestSuite - Add test for ejb security propagation using PLAIN Key: WFLY-9300 URL: https://issues.jboss.org/browse/WFLY-9300 Project: WildFly Issue Type: Task Components: Test Suite Affects Versions: 11.0.0.CR1 Reporter: Brad Maxwell Assignee: Brad Maxwell Add test for ejb security propagation using PLAIN -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1356) Release WildFly Elytron 1.2.0.Beta2

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1356: ------------------------------------- Summary: Release WildFly Elytron 1.2.0.Beta2 Key: ELY-1356 URL: https://issues.jboss.org/browse/ELY-1356 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.2.0.Beta2 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1355) Release WildFly Elytron 1.1.2.CR1

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1355?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1355: ---------------------------------- Summary: Release WildFly Elytron 1.1.2.CR1 (was: Release WildFly Elytron 1.2.0.CR1) > Release WildFly Elytron 1.1.2.CR1 > --------------------------------- > > Key: ELY-1355 > URL: https://issues.jboss.org/browse/ELY-1355 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.2.CR1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1355) Release WildFly Elytron 1.2.0.CR1

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1355: ------------------------------------- Summary: Release WildFly Elytron 1.2.0.CR1 Key: ELY-1355 URL: https://issues.jboss.org/browse/ELY-1355 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.2.CR1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-3210: --------------------------------------- We'll have to take a look when we get a chance. It seems like what you're doing is highly customized for your specific needs. This issue seems very verbose so we'd have to look at the customization that is happening to see what is really going on. It will take some time to do this as we definitely have no shortage of issues :). To be honest I'm not really sure what the issue actually is. I know you're trying to do something with your own version of log4j and for all deployments. IMO you've attempt to explain more what you believe the issues to be rather than what you expect to happen. Ideally we'd need to know what your end goal is. > Wildfly module isolation not working consistently > ------------------------------------------------- > > Key: WFCORE-3210 > URL: https://issues.jboss.org/browse/WFCORE-3210 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Modules > Affects Versions: 2.2.0.Final > Reporter: Nuno Godinho de Matos > > There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems. > An example of this phenomena is given on the wildfly forum thread: > https://developer.jboss.org/thread/275839 > In this example, we have the logging subsystem setup to use a custome handler. > The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module. > What we see in this example is that an application gets from wildfly mixed behavior. > Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly. > But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module. > And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same. > This is not an isolated issue. > There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away. > This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable. > It should not be that the application server some time starts successfully and others not. > Booting wildfly should always result in the same outcode. > Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper. > In the case of thread: > https://developer.jboss.org/thread/275839 > Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen. > Many thanks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3239) TestSuite - CLIWrapper does not allow for use in multinode tests

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3239?page=com.atlassian.jira.plugi... ] Brad Maxwell updated WFCORE-3239: --------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2762, https://github.com/wildfly/wildfly-core/pull/2763 (was: https://github.com/wildfly/wildfly-core/pull/2762) > TestSuite - CLIWrapper does not allow for use in multinode tests > ---------------------------------------------------------------- > > Key: WFCORE-3239 > URL: https://issues.jboss.org/browse/WFCORE-3239 > Project: WildFly Core > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 3.0.1.Final > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > CLIWrapper needs a constructor to allow the host/port of the CLI to be specified as currently it does not allow the port to be specified which prevents connecting to a second test instance for configuring. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3239) TestSuite - CLIWrapper does not allow for use in multinode tests

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3239?page=com.atlassian.jira.plugi... ] Brad Maxwell updated WFCORE-3239: --------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2762 (was: https://github.com/wildfly/wildfly-core/pull/2761) > TestSuite - CLIWrapper does not allow for use in multinode tests > ---------------------------------------------------------------- > > Key: WFCORE-3239 > URL: https://issues.jboss.org/browse/WFCORE-3239 > Project: WildFly Core > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 3.0.1.Final > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > CLIWrapper needs a constructor to allow the host/port of the CLI to be specified as currently it does not allow the port to be specified which prevents connecting to a second test instance for configuring. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3239) TestSuite - CLIWrapper does not allow for use in multinode tests

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3239?page=com.atlassian.jira.plugi... ] Brad Maxwell updated WFCORE-3239: --------------------------------- Summary: TestSuite - CLIWrapper does not allow for use in multinode tests (was: [TEST] CLIWrapper does not allow for use in multinode tests) > TestSuite - CLIWrapper does not allow for use in multinode tests > ---------------------------------------------------------------- > > Key: WFCORE-3239 > URL: https://issues.jboss.org/browse/WFCORE-3239 > Project: WildFly Core > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 3.0.1.Final > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > CLIWrapper needs a constructor to allow the host/port of the CLI to be specified as currently it does not allow the port to be specified which prevents connecting to a second test instance for configuring. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 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 September 2017