October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9406) Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on WFLY-9406: --------------------------------------- [~tibor17], yes, not doable. The upgrade to CXF 3.2 requires also upgrading to JBossWS 5.2, which is not ready for release. And if it was ready, it would already be too late for such a change in WFLY 11, which is close to being released. > Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ----------------------------------------------------------------------------- > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, JPA / Hibernate, Web Services > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Alessio Soldano > Priority: Minor > Fix For: 12.0.0.Alpha1 > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian Extension dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9375) META-INF/services are always accessible from dependencies

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-9375?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-9375: -------------------------------------- The changes look good, however as we are about to release and we are in 'blockers only' mode they will probably not make it in till the next release. > META-INF/services are always accessible from dependencies > --------------------------------------------------------- > > Key: WFLY-9375 > URL: https://issues.jboss.org/browse/WFLY-9375 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final, 10.1.0.Final, 11.0.0.CR1 > Reporter: Alexander Kudrevatykh > Assignee: Stuart Douglas > > I found regression in Wildfly 10.1 (10.0 and 11 CR1 also affected) - META-INF/services entries are accesible from war dependencies, even if not marked as "import" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3318) User is unable to use WildflySasl.REALM_LIST property together with DIGEST-MD5

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3318?page=com.atlassian.jira.plugi... ] Hynek Švábek commented on WFCORE-3318: -------------------------------------- Hi [~dmlloyd], Thank you, it works as you described. > User is unable to use WildflySasl.REALM_LIST property together with DIGEST-MD5 > ------------------------------------------------------------------------------ > > Key: WFCORE-3318 > URL: https://issues.jboss.org/browse/WFCORE-3318 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > > User is unable to use WildflySasl.REALM_LIST property together with DIGEST-MD5. > When I look to org.wildfly.security.sasl.digest.DigestServerFactory [1] I see there callback handler and I expect that this callback handle org.wildfly.security.sasl.util.AvailableRealmsSaslServerFactory too. When you look into this factory [2] you can see that there is processed property REALM_LIST. > I added there break point but nothing happened. > If I understand correctly I found out that in SaslServerDefinitions [3] is not added AvailableRealmsSaslServerFactory when property (or some another condition) is set. > [1] https://github.com/wildfly-security/wildfly-elytron/blob/1.2.0.Beta3/src/... > [2] https://github.com/wildfly-security/wildfly-elytron/blob/1.2.0.Beta3/src/... > [3] https://github.com/wildfly/wildfly-core/blob/3.0.3.Final/elytron/src/main... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Tibor Digana (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Tibor Digana updated WFLY-9406: ------------------------------- Description: Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 Arquillian Extension dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. Please upgrade it in POM: https://github.com/wildfly/wildfly/blob/master/pom.xml was: Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. Please upgrade it in POM: https://github.com/wildfly/wildfly/blob/master/pom.xml > Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ----------------------------------------------------------------------------- > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, JPA / Hibernate, Web Services > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Alessio Soldano > Priority: Minor > Fix For: 12.0.0.Alpha1 > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian Extension dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Tibor Digana (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Tibor Digana updated WFLY-9406: ------------------------------- Summary: Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) (was: [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)) > Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ----------------------------------------------------------------------------- > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, JPA / Hibernate, Web Services > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Alessio Soldano > Priority: Minor > Fix For: 12.0.0.Alpha1 > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Tibor Digana (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Tibor Digana commented on WFLY-9406: ------------------------------------ [~asoldano] Would it be a big problem to schedule CXF 3.2 for WFLY11? > [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ------------------------------------------------------------------------------------------ > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, JPA / Hibernate, Web Services > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Alessio Soldano > Priority: Minor > Fix For: 12.0.0.Alpha1 > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Tibor Digana (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Tibor Digana commented on WFLY-9406: ------------------------------------ [~jaikiran] I found this issue when focused on StackOverflowError in real box with Arquilian: https://github.com/arquillian/arquillian-extension-jacoco/issues/25#issue... > [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ------------------------------------------------------------------------------------------ > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, JPA / Hibernate, Web Services > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Alessio Soldano > Priority: Minor > Fix For: 12.0.0.Alpha1 > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3330) ServerRootResourceDefinition passes ExtensionRegistryType.SLAVE to ExtensionResourceDefinition

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3330?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3330: ------------------------------------- Description: It should be ExtensionRegistryType.SERVER. Only impact of this is it results in a contrary to spec result for the extension add op if it is invoked after boot: {code} [standalone@embedded /] /extension=org.jboss.as.xts:add { "outcome" => "success", "result" => [("xts" => "2.0.0")] } {code} That result is what a slave HC communicates to the master; it's not meant to be presented to an end user. was: It should be ExtensionRegistryType.SERVER. Only impact of this is it results in a contrary to spec result valid for the extension add op if it is invoked after boot: {code} [standalone@embedded /] /extension=org.jboss.as.xts:add { "outcome" => "success", "result" => [("xts" => "2.0.0")] } {code} That result is what a slave HC communicates to the master; it's not meant to be presented to an end user. > ServerRootResourceDefinition passes ExtensionRegistryType.SLAVE to ExtensionResourceDefinition > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-3330 > URL: https://issues.jboss.org/browse/WFCORE-3330 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > It should be ExtensionRegistryType.SERVER. > Only impact of this is it results in a contrary to spec result for the extension add op if it is invoked after boot: > {code} > [standalone@embedded /] /extension=org.jboss.as.xts:add > { > "outcome" => "success", > "result" => [("xts" => "2.0.0")] > } > {code} > That result is what a slave HC communicates to the master; it's not meant to be presented to an end user. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3330) ServerRootResourceDefinition passes ExtensionRegistryType.SLAVE to ExtensionResourceDefinition

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3330: ---------------------------------------- Summary: ServerRootResourceDefinition passes ExtensionRegistryType.SLAVE to ExtensionResourceDefinition Key: WFCORE-3330 URL: https://issues.jboss.org/browse/WFCORE-3330 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor It should be ExtensionRegistryType.SERVER. Only impact of this is it results in a contrary to spec result valid for the extension add op if it is invoked after boot: {code} [standalone@embedded /] /extension=org.jboss.as.xts:add { "outcome" => "success", "result" => [("xts" => "2.0.0")] } {code} That result is what a slave HC communicates to the master; it's not meant to be presented to an end user. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3327) Confusion about the recording of the org.wildfly.remoting.endpoint capability and the resource that configures it

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3327?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3327: ------------------------------------------ [~aloubyansky] AIUI the undertow and ejb3 cases are not the same. In undertow and ejb3 we have a parent resource providing a capability that depends on capabilities provided by children. But those resources are real resources, meaning they actually provide real runtime services. The /subsystem=remoting/configuration=endpoint resource is not a real resource. It doesn't provide any runtime service. It's just a chunk of configuration used by the true resource, it's parent. It's an oddly implemented variant of that kind of configuration chunk, because the server itself adds it if the user doesn't, which is a pattern I don't recall elsewhere. I've been looking at this and I'm starting to think that there's a 3) that's simpler than 2). Don't add a complex attribute to /subsystem=remoting. Instead, just add the /subsystem=remoting/configuration=endpoint attributes to it as simple attributes. No need to wrap them as fields in a complex attribute. As with 2) for API compatibility purposes only leave /subsystem=remoting/configuration=endpoint as an alias to those attributes. The /subsystem=remoting 'worker' attribute then is a simple attribute of the resource that provides the capability, the same as 99% of all capability reference attributes. It seems like the only purpose /subsystem=remoting/configuration=endpoint served was as a kind of resource tree counterpart to the 'endpoint' child element in the xml that wraps these attributes. But there are plenty of ways to get that xml representation without adding a child resource. 3) is harder to implement than 2) for a mixed domain, but oh well. > Confusion about the recording of the org.wildfly.remoting.endpoint capability and the resource that configures it > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3327 > URL: https://issues.jboss.org/browse/WFCORE-3327 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Remoting > Affects Versions: 3.0.3.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 4.0.0.Beta1 > > > The org.wildfly.remoting.endpoint capability is reported by the /subsystem=remoting resource, but it is the /subsystem=remoting/configuration=endpoint that actually configures it. This is confusing for humans and difficult for tooling like the new provisioning tools. > The configuration=endpoint child is essentially a singleton and internally it just provides configuration to its parent. Further, if the user does not configure this resource, a default one is added automatically. This child resources is really just a configuration chunk for its parent. > In the end it is the parent resource that actually provides the capability, by installing a service. It reads its child resource to configure the capability. > There are a couple possibilities here: > 1) Simply move the declaration of the capability to the child resource. Per discussion with [~aloubyansky] is seems that solves the tool problem. It leaves the actual situation obscure though, because now a seemingly non-required child resource is the thing that provides a capability that actually will always be present. > 2) Deprecate that child resource and add a complex attribute to the parent. The child resource continues to exist in the API for compatibility reasons, but simply modifies the attribute on the parent. The cap remains on the parent. > Note that 2) may require some manipulation of how we handle undefined complex attributes; i.e. that when we resolve them, even if the root attribute is undefined, we need to resolve the fields, in case those have default values, with the resolved parent then including the default field values. That can be tricky though, e.g. in cases of things like the defaulted attribute having requires, or other fields in the complex attribute being required. > This latter point is relevant because it would be a 'worker' field in a complex attribute that would actually declare the name of the needed io worker capability. That field would have a default value 'default'. > Perhaps the declaration of the complex attribute itself (i.e. ObjectTypeAttributeDefinition) would need to indicate how things should be handled. That could just be the complex attribute itself has a default value, {"worker"=>"default"}. Or it could be a flag that enables looking at the fields for defaults if the top level attribute is undefined. Or maybe investigation will show this isn't a problem at all. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

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