December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1469) Create profile for running only tests which are stable on all platforms

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-1469: --------------------------------- Summary: Create profile for running only tests which are stable on all platforms Key: ELY-1469 URL: https://issues.jboss.org/browse/ELY-1469 Project: WildFly Elytron Issue Type: Enhancement Components: Testsuite Affects Versions: 1.2.0.Beta10 Reporter: Ondrej Lukas Assignee: Ondrej Lukas Create profile {{stable-tests}} which will exclude all tests which are not stable on any supported platform. This profile must be turned off as default and will be enabled through passing {{-Dstable-tests}} property to maven command. This profile will serve for running testsuite on all supported platform and fail of any test will be unexpected (i.e. it can be simply checked whether everything is ok). This profile will be useful for CI smoke testing on every supported platforms (current tests during pull requests are run only on RHEL and Windows). Tests and TestSuite which should be currently excluded (and possibly fixed in the future): * GssapiTestSuite * SelfSignedX509CertificateAndSigningKeyTest * KeyStoreCredentialStoreTest -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9618) Record and report stack trace of setRollbackOnly() calls

by David Lloyd (JIRA)

David Lloyd created WFLY-9618: --------------------------------- Summary: Record and report stack trace of setRollbackOnly() calls Key: WFLY-9618 URL: https://issues.jboss.org/browse/WFLY-9618 Project: WildFly Issue Type: Enhancement Components: EJB, Transactions Reporter: David Lloyd We should track the stack trace of the first, or of each, caller of setRollbackOnly(), and if the transaction ultimately throws RollbackException or similar, we can add the stack trace as a cause. If multiple calls are done, then the latest should be the cause and the earlier should show up as suppressed exceptions. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-283: -------------------------------------- [~dmlloyd] Do you have an recommendations for contact? Overall we have run into a few issues we believe are JVM issues - maybe if we connect with them we can work on a few different issues. > Investigate Elytron and gssproxy interoperability > ------------------------------------------------- > > Key: ELY-283 > URL: https://issues.jboss.org/browse/ELY-283 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Peter Skopek > Assignee: Jan Kalina > Fix For: 2.0.0.Alpha1 > > Attachments: openjdk-patch-native-mechs.patch > > > Investigate Elytron and gssproxy interoperability. > https://fedorahosted.org/gss-proxy/ -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9617) Add persistend store to infinispan via CLI fail

by Domenico Briganti (JIRA)

[ https://issues.jboss.org/browse/WFLY-9617?page=com.atlassian.jira.plugin.... ] Domenico Briganti commented on WFLY-9617: ----------------------------------------- Ok, understand. Thanks. > Add persistend store to infinispan via CLI fail > ----------------------------------------------- > > Key: WFLY-9617 > URL: https://issues.jboss.org/browse/WFLY-9617 > Project: WildFly > Issue Type: Bug > Components: Clustering, Domain Management > Affects Versions: 11.0.0.Final > Reporter: Domenico Briganti > Assignee: Paul Ferraro > > Configure a persistent file for a local-cache via CLI fail if not into a batch block. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3463) EmbeddedProcessFactory should not require classes meant to be loaded from the modular classloader

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3463: ---------------------------------------- Summary: EmbeddedProcessFactory should not require classes meant to be loaded from the modular classloader Key: WFCORE-3463 URL: https://issues.jboss.org/browse/WFCORE-3463 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor EmbeddedProcessFactory is loading EmbeddedHostControllerFactory and EmbeddedStandaloneServerFactory using its own classloader solely in order to get their names in order to pass those into the modular classloader. This unnecessarily ties the embedding app classloading environment to the embedded server side. This is minor as it doesn't really cause any harm. It's just a cleanup to help make it easier to divide the two sides. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-187) The ClassLoaderLogContextSelector check for the log context should return null

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-187?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-187: --------------------------------- Description: The {{ClassLoaderLogContextSelector}} check for the registered {{LogContext}} returns {{defaultSelector.getLogContext()}} in the {{check()}} method and should return {{null}}. {code:title=Previous Version} private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() { public LogContext run() { for (Class<?> caller : GATEWAY.getClassContext()) { final ClassLoader classLoader = caller.getClassLoader(); final LogContext result = check(classLoader); if (result != null) { return result; } } return defaultSelector.getLogContext(); } private LogContext check(final ClassLoader classLoader) { if (classLoader != null && !logApiClassLoaders.contains(classLoader)) { final LogContext context = contextMap.get(classLoader); if (context != null) { return context; } if (checkParentClassLoaders) { return check(classLoader.getParent()); } } return null; } }; {code} {code:title=Current Version} private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() { public LogContext run() { final Class<?> callingClass = JDKSpecific.findCallingClass(logApiClassLoaders); return callingClass == null ? defaultSelector.getLogContext() : check(callingClass.getClassLoader()); } private LogContext check(final ClassLoader classLoader) { final LogContext context = contextMap.get(classLoader); if (context != null) { return context; } final ClassLoader parent = classLoader.getParent(); if (parent != null && checkParentClassLoaders && ! logApiClassLoaders.contains(parent)) { return check(parent); } return defaultSelector.getLogContext(); } }; {code} The new version only checks the first caller found, then returns the default. The older version checks the callers until it finds a non-null value finally returning the default if no callers were found with associated contexts. was:The {{ClassLoaderLogContextSelector}} check for the registered {{LogContext}} returns {{defaultSelector.getLogContext()}} in the {{check()}} method and should return {{null}}. > The ClassLoaderLogContextSelector check for the log context should return null > ------------------------------------------------------------------------------ > > Key: LOGMGR-187 > URL: https://issues.jboss.org/browse/LOGMGR-187 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > > The {{ClassLoaderLogContextSelector}} check for the registered {{LogContext}} returns {{defaultSelector.getLogContext()}} in the {{check()}} method and should return {{null}}. > {code:title=Previous Version} > private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() { > public LogContext run() { > for (Class<?> caller : GATEWAY.getClassContext()) { > final ClassLoader classLoader = caller.getClassLoader(); > final LogContext result = check(classLoader); > if (result != null) { > return result; > } > } > return defaultSelector.getLogContext(); > } > private LogContext check(final ClassLoader classLoader) { > if (classLoader != null && !logApiClassLoaders.contains(classLoader)) { > final LogContext context = contextMap.get(classLoader); > if (context != null) { > return context; > } > if (checkParentClassLoaders) { > return check(classLoader.getParent()); > } > } > return null; > } > }; > {code} > {code:title=Current Version} > private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() { > public LogContext run() { > final Class<?> callingClass = JDKSpecific.findCallingClass(logApiClassLoaders); > return callingClass == null ? defaultSelector.getLogContext() : check(callingClass.getClassLoader()); > } > private LogContext check(final ClassLoader classLoader) { > final LogContext context = contextMap.get(classLoader); > if (context != null) { > return context; > } > final ClassLoader parent = classLoader.getParent(); > if (parent != null && checkParentClassLoaders && ! logApiClassLoaders.contains(parent)) { > return check(parent); > } > return defaultSelector.getLogContext(); > } > }; > {code} > The new version only checks the first caller found, then returns the default. The older version checks the callers until it finds a non-null value finally returning the default if no callers were found with associated contexts. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7298) Testsuite IO ops housekeeping

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-7298?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-7298: ---------------------------------------- If there's any further work on this please open a new issue. > Testsuite IO ops housekeeping > ----------------------------- > > Key: WFLY-7298 > URL: https://issues.jboss.org/browse/WFLY-7298 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 12.0.0.Alpha1 > > > Do some needed housekeeping of testsuite -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-187) The ClassLoaderLogContextSelector check for the log context should return null

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-187?page=com.atlassian.jira.plugin... ] James Perkins reassigned LOGMGR-187: ------------------------------------ Assignee: James Perkins > The ClassLoaderLogContextSelector check for the log context should return null > ------------------------------------------------------------------------------ > > Key: LOGMGR-187 > URL: https://issues.jboss.org/browse/LOGMGR-187 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > > The {{ClassLoaderLogContextSelector}} check for the registered {{LogContext}} returns {{defaultSelector.getLogContext()}} in the {{check()}} method and should return {{null}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-887) "Deprecate" using an expression in model refs to interfaces

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-887: ------------------------------------ Fix Version/s: 4.0.0.Alpha6 (was: 4.0.0.Alpha5) > "Deprecate" using an expression in model refs to interfaces > ----------------------------------------------------------- > > Key: WFCORE-887 > URL: https://issues.jboss.org/browse/WFCORE-887 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 4.0.0.Alpha6 > > > SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions. > Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1. > There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support. > We use INFO messages for other management API deprecation messages, but these I believe deserve a WARN. The issue here isn't just that we may change something in the future (seen as not justifying a WARN) but also that the capability/requirement bookkeeping for the attribute cannot be properly done if an expression is used, meaning the model integrity behavior meant to be in place cannot be used. > We should look for other cases like this too, although those changes should be separate JIRAs. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2336) Remove ModelController.createClient

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2336?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2336: ------------------------------------- Fix Version/s: 4.0.0.Alpha6 (was: 4.0.0.Alpha5) > Remove ModelController.createClient > ----------------------------------- > > Key: WFCORE-2336 > URL: https://issues.jboss.org/browse/WFCORE-2336 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 4.0.0.Alpha6 > > > Follow up on WFCORE-1507 by removing ModelController.createClient and any use of it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 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 December 2017