[Red Hat JIRA] (WFLY-14199) OnOffOpenTracingTestCase leaves the server in a bad state
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-14199?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFLY-14199:
--------------------------------------
While I think we need to look at this issue the {{OnOffOpenTracingTestCase}} seems wrong to me. The {{SimpleJaxRs}} is deployed with an injected {{Tracer}}. Then the subsystem is removed and the server restarted which causes a deployment issue.
{code}
17:17:18,682 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /deployment/rest/getTracer: java.lang.NoClassDefFoundError: Lio/opentracing/Tracer;
at java.base/java.lang.Class.getDeclaredFields0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredFields(Class.java:3061)
at java.base/java.lang.Class.getDeclaredFields(Class.java:2248)
at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.spi.metadata.ResourceBuilder.processDeclaredFields(ResourceBuilder.java:1008)
at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.spi.metadata.ResourceBuilder.processFields(ResourceBuilder.java:987)
at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.spi.metadata.ResourceBuilder.fromAnnotations(ResourceBuilder.java:869)
at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.spi.metadata.ResourceBuilder.getRootResourceFromAnnotations(ResourceBuilder.java:830)
at org.jboss.resteasy.resteasy-jaxrs(a)3.13.2.Final//org.jboss.resteasy.plugins.server.resourcefactory.POJOResourceFactory.<init>(POJOResourceFactory.java:38)
at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:81)
at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:487)
at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:288)
at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:93)
at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:140)
at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:42)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
at org.wildfly.security.elytron-web.undertow-server-servlet@1.8.0.Final//org.wildfly.elytron.web.undertow.server.servlet.RunAsLifecycleInterceptor.doIt(RunAsLifecycleInterceptor.java:70)
at org.wildfly.security.elytron-web.undertow-server-servlet@1.8.0.Final//org.wildfly.elytron.web.undertow.server.servlet.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:76)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:305)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.core.ManagedServlet.forceInit(ManagedServlet.java:212)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletChain.forceInit(ServletChain.java:130)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:63)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.security.elytron-web.undertow-server@1.8.0.Final//org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.lambda$handleRequest$1(ElytronRunAsHandler.java:68)
at org.wildfly.security.elytron-private@1.14.0.Final//org.wildfly.security.auth.server.FlexibleIdentityAssociation.runAsFunctionEx(FlexibleIdentityAssociation.java:103)
at org.wildfly.security.elytron-private@1.14.0.Final//org.wildfly.security.auth.server.Scoped.runAsFunctionEx(Scoped.java:161)
at org.wildfly.security.elytron-private@1.14.0.Final//org.wildfly.security.auth.server.Scoped.runAs(Scoped.java:73)
at org.wildfly.security.elytron-web.undertow-server@1.8.0.Final//org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.handleRequest(ElytronRunAsHandler.java:67)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.core@2.2.2.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.core@2.2.2.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.core@2.2.2.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at org.wildfly.security.elytron-web.undertow-server-servlet@1.8.0.Final//org.wildfly.elytron.web.undertow.server.servlet.CleanUpHandler.handleRequest(CleanUpHandler.java:38)
at io.undertow.core@2.2.2.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow@22.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.core@2.2.2.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow@22.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
at io.undertow.core@2.2.2.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow@22.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow@22.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow@22.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow@22.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at io.undertow.core@2.2.2.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
at io.undertow.core@2.2.2.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
at org.jboss.threads@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
at org.jboss.xnio@3.8.4.Final//org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.ClassNotFoundException: io.opentracing.Tracer from [Module "deployment.deployment.war" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
... 63 more
{code}
The failure makes sense as the subsystem has been removed. It doesn't make much sense to me we should be testing the CNFE though.
> OnOffOpenTracingTestCase leaves the server in a bad state
> ---------------------------------------------------------
>
> Key: WFLY-14199
> URL: https://issues.redhat.com/browse/WFLY-14199
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing, Test Suite
> Affects Versions: 22.0.0.Alpha1
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> {color:#333333}OnOffOpenTracingTestCase{color} will leave the server in such a state that SimpleRestClientTestCase will fail. Removing and adding the opentracing subsystem to check that it doesn't work once removed shoudl be reevaluated.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14199) OnOffOpenTracingTestCase leaves the server in a bad state
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-14199?page=com.atlassian.jira.plugi... ]
James Perkins edited comment on WFLY-14199 at 12/10/20 7:52 PM:
----------------------------------------------------------------
[~ron_sigal] Hello, you need to run the tests in the 'proper' order :
{code:java}
@RunWith(Suite.class)
@SuiteClasses({
org.wildfly.test.integration.microprofile.opentracing.OnOffOpenTracingTestCase.class,
org.wildfly.test.integration.microprofile.opentracing.SimpleRestClientTestCase.class
})
public class WFLY14199TestSuite {}
{code}
look at my branch [https://github.com/wildfly/wildfly/pull/13774|https://github.com/wildfly/...].
The tests have been moved to testsuite/integration/microprofile
was (Author: ehugonnet):
[~ron_sigal] Hello, you need to run the tests in the 'proper' order :
{code:java}
@RunWith(Suite.class)
@SuiteClasses({
org.wildfly.test.integration.microprofile.opentracing.OnOffOpenTracingTestCase.class,
org.wildfly.test.integration.microprofile.opentracing.SimpleRestClientTestCase.class
})
public class WFLY14199TestSuite {}
{code}
look at my branch [https://github.com/wildfly/wildfly/pull/13774|https://github.com/wildfly/...]
The tests have been moved to testsuite/integration/microprofile
> OnOffOpenTracingTestCase leaves the server in a bad state
> ---------------------------------------------------------
>
> Key: WFLY-14199
> URL: https://issues.redhat.com/browse/WFLY-14199
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing, Test Suite
> Affects Versions: 22.0.0.Alpha1
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> {color:#333333}OnOffOpenTracingTestCase{color} will leave the server in such a state that SimpleRestClientTestCase will fail. Removing and adding the opentracing subsystem to check that it doesn't work once removed shoudl be reevaluated.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFCORE-5226) No acceptedIssuers is sent when CRLs are configured
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-5226?page=com.atlassian.jira.plug... ]
Farah Juma edited comment on WFCORE-5226 at 12/10/20 5:27 PM:
--------------------------------------------------------------
[~szaldana] I think the underlying issue here is in {{X509RevocationTrustManager}}:
* Notice that the {{trustStore}} that is specified using the {{X509RevocationTrustManager.Builder}} is successfully used to instantiate the {{trustManager}} in the {{X509RevocationTrustManager}} [constructor|https://github.com/wildfly-security/wildfly-elytron/blob/1.x/...].
* A call to {{trustManager.getAcceptedIssuers()}} would return the correct accepted issuers.
* However, the {{X509RevocationTrustManager#getAcceptedIssuers}} method actually returns the value of {{builder.acceptedIssuers}}. This means that if no accepted issuers have been explicitly configured using the {{builder}}, {{X509RevocationTrustManager#getAcceptedIssuers}} returns {{X500.NO_CERTIFICATES}}.
* If no accepted issuers have been explicitly configured, I think we should delegate to the {{trustManager#getAcceptedIssuers}} method instead of using {{X500.NO_CERTIFICATES}}.
was (Author: fjuma):
[~szaldana] I think the underlying issue here is in {{X509RevocationTrustManager}}:
* Notice that the {{trustStore}} that is specified using the {{X509RevocationTrustManager.Builder}} is successfully used to instantiate the {{trustManager}} in the {{X509RevocationTrustManager}} [constructor|https://github.com/wildfly-security/wildfly-elytron/blob/1.x/...].
* A call to {{trustManager.getAcceptedIssuers()}} would return the correct accepted issuers.
* However, the {{X509RevocationTrustManager#getAcceptedIssuers}} method actually returns the value of {{builder.acceptedIssuers}}. This means that if no accepted issuers have been explicitly configured using the {{builder}}, {{X509RevocationTrustManager#getAcceptedIssuers}} returns {{X500.NO_CERTIFICATES}}.
* If no accepted issuers have been explicitly configured, I think we should delegate to the {{trustManager#getAcceptedIssuers}} method instead of using {{X500.NO_CERTIFICATES}}.
> No acceptedIssuers is sent when CRLs are configured
> ---------------------------------------------------
>
> Key: WFCORE-5226
> URL: https://issues.redhat.com/browse/WFCORE-5226
> Project: WildFly Core
> Issue Type: Bug
> Reporter: David MAFFRAND
> Assignee: Sonia Zaldana
> Priority: Major
>
> When CRLs are configured there're no client certificate CA names sent for a tls 2 way connexion.
> Method setAcceptedIssuers of X509RevocationTrustManager builder is never called, so acceptedIssuers is always empty.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFCORE-5226) No acceptedIssuers is sent when CRLs are configured
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-5226?page=com.atlassian.jira.plug... ]
Farah Juma commented on WFCORE-5226:
------------------------------------
[~szaldana] I think the underlying issue here is in {{X509RevocationTrustManager}}:
* Notice that the {{trustStore}} that is specified using the {{X509RevocationTrustManager.Builder}} is successfully used to instantiate the {{trustManager}} in the {{X509RevocationTrustManager}} [constructor|https://github.com/wildfly-security/wildfly-elytron/blob/1.x/...].
* A call to {{trustManager.getAcceptedIssuers()}} would return the correct accepted issuers.
* However, the {{X509RevocationTrustManager#getAcceptedIssuers}} method actually returns the value of {{builder.acceptedIssuers}}. This means that if no accepted issuers have been explicitly configured using the {{builder}}, {{X509RevocationTrustManager#getAcceptedIssuers}} returns {{X500.NO_CERTIFICATES}}.
* If no accepted issuers have been explicitly configured, I think we should delegate to the {{trustManager#getAcceptedIssuers}} method instead of using {{X500.NO_CERTIFICATES}}.
> No acceptedIssuers is sent when CRLs are configured
> ---------------------------------------------------
>
> Key: WFCORE-5226
> URL: https://issues.redhat.com/browse/WFCORE-5226
> Project: WildFly Core
> Issue Type: Bug
> Reporter: David MAFFRAND
> Assignee: Sonia Zaldana
> Priority: Major
>
> When CRLs are configured there're no client certificate CA names sent for a tls 2 way connexion.
> Method setAcceptedIssuers of X509RevocationTrustManager builder is never called, so acceptedIssuers is always empty.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14211) Always cleaning feature pack modules
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-14211:
---------------------------------------
Summary: Always cleaning feature pack modules
Key: WFLY-14211
URL: https://issues.redhat.com/browse/WFLY-14211
Project: WildFly
Issue Type: Task
Components: Build System
Reporter: Brian Stansberry
http://maven.apache.org/plugins/maven-clean-plugin/usage.html#Running_the...
^^^ might be useful for our maven modules that build feature packs.
I often get failed FP builds as i switch from branch to branch and I believe it's because the target dir has stuff left over from a previous build, e.g. layer-spec.xml files etc, that no longer match the current branch. Doing mvn clean install for the whole build is annoying; WF is a huge build. And manually cleaning a few modules is also annoying. But it seems you can turn on a clean as part of the module's own pom.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14211) Always cleaning feature pack modules
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-14211?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-14211:
-----------------------------------------
One thing that might be an issue is if there is no way to do this without taking over the version of the thing that does the normal clean execution.
> Always cleaning feature pack modules
> ------------------------------------
>
> Key: WFLY-14211
> URL: https://issues.redhat.com/browse/WFLY-14211
> Project: WildFly
> Issue Type: Task
> Components: Build System
> Reporter: Brian Stansberry
> Priority: Minor
>
> http://maven.apache.org/plugins/maven-clean-plugin/usage.html#Running_the...
> ^^^ might be useful for our maven modules that build feature packs.
> I often get failed FP builds as i switch from branch to branch and I believe it's because the target dir has stuff left over from a previous build, e.g. layer-spec.xml files etc, that no longer match the current branch. Doing mvn clean install for the whole build is annoying; WF is a huge build. And manually cleaning a few modules is also annoying. But it seems you can turn on a clean as part of the module's own pom.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14210) The jaxrs subsystem had new attributes added without a schema bump
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-14210?page=com.atlassian.jira.plugi... ]
James Perkins updated WFLY-14210:
---------------------------------
Fix Version/s: 22.0.0.Beta1
> The jaxrs subsystem had new attributes added without a schema bump
> ------------------------------------------------------------------
>
> Key: WFLY-14210
> URL: https://issues.redhat.com/browse/WFLY-14210
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Blocker
> Fix For: 22.0.0.Beta1
>
>
> WFLY-12298 introduced attributes to the jaxrs subsystem. While the schema was bumped, the model version was not. Because of this there is no reliable way to correctly use transformers from WildFly 19 -> WildFly 11. Note that WildFly 11 was the first version to bump to model version 2.0.0 and WildFly 19 kept the same model version, but added the attributes.
> JBoss EAP should not be impacted as no releases contain, with the exception of JBoss EAP CD19 and JBoss EAP CD20 Tech Preview releases, the attributes.
> We should set the transformers up to reject the attributes for model version 2.0.0 and 1.0.0. An unsupported system property should be introduced to allow the rejection of attributes for 2.0.0 on WildFly mixed domain environments. While this is an unlikely scenario it would be nice to have.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14210) The jaxrs subsystem had new attributes added without a schema bump
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-14210?page=com.atlassian.jira.plugi... ]
James Perkins updated WFLY-14210:
---------------------------------
Priority: Blocker (was: Major)
> The jaxrs subsystem had new attributes added without a schema bump
> ------------------------------------------------------------------
>
> Key: WFLY-14210
> URL: https://issues.redhat.com/browse/WFLY-14210
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Blocker
>
> WFLY-12298 introduced attributes to the jaxrs subsystem. While the schema was bumped, the model version was not. Because of this there is no reliable way to correctly use transformers from WildFly 19 -> WildFly 11. Note that WildFly 11 was the first version to bump to model version 2.0.0 and WildFly 19 kept the same model version, but added the attributes.
> JBoss EAP should not be impacted as no releases contain, with the exception of JBoss EAP CD19 and JBoss EAP CD20 Tech Preview releases, the attributes.
> We should set the transformers up to reject the attributes for model version 2.0.0 and 1.0.0. An unsupported system property should be introduced to allow the rejection of attributes for 2.0.0 on WildFly mixed domain environments. While this is an unlikely scenario it would be nice to have.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months