April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-181) Install Openshift 3.9 Cluster B21

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-181?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-181: ------------------------------------------ Description: Reinstall Openshift 3.9 > Install Openshift 3.9 Cluster B21 > --------------------------------- > > Key: SWSQE-181 > URL: https://issues.jboss.org/browse/SWSQE-181 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > > Reinstall Openshift 3.9 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10197) AuthenticationPolicyContextTestCase fails under a security manager

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-10197?page=com.atlassian.jira.plugin... ] David Lloyd commented on WFLY-10197: ------------------------------------ This looks fixed now, correct? > AuthenticationPolicyContextTestCase fails under a security manager > ------------------------------------------------------------------ > > Key: WFLY-10197 > URL: https://issues.jboss.org/browse/WFLY-10197 > Project: WildFly > Issue Type: Bug > Components: Test Suite, Web Services > Reporter: David Lloyd > Assignee: Martin Stefanko > > Stack trace: > {noformat} > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.security.SecurityPermission" "getPolicy")" in code source "(vfs:/content/picketlink-sts-ws.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.picketlink-sts-ws.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) > at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:99) > at org.jboss.as.test.integration.ws.authentication.policy.resources.EchoService.echo(EchoService.java:62) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) > at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90) > at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) > ... 103 more > {noformat} > I think the {{EchoService}} deployment needs the {{getPolicy}} permission in order to complete its task. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10256) WildFly Common and shaded jars with MR overlays do not have defined Multi-Release in Manifest

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-10256?page=com.atlassian.jira.plugin... ] David Lloyd commented on WFLY-10256: ------------------------------------ I think this JIRA applies only to the client JARs, since those are the only ones actually built by this project. Each of the other two problems need their own upstream JIRA. > WildFly Common and shaded jars with MR overlays do not have defined Multi-Release in Manifest > ---------------------------------------------------------------------------------------------- > > Key: WFLY-10256 > URL: https://issues.jboss.org/browse/WFLY-10256 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 12.0.0.Final > Reporter: Rostislav Svoboda > Assignee: David Lloyd > Priority: Critical > > Several jars with MR overlays do not have defined Multi-Release in Manifest > Results with WildFly master from 2018-04-18: > {code} > DistributionTestCase.checkOverlayDirectoryAndManifestEntryForExpectedMRJars:93 > The following 4 assertions failed: > 1) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/bin/wildfly-elytron-tool.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> > at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> > 2) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/bin/client/jboss-cli-client.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> > at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> > 3) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/bin/client/jboss-client.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> > at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> > 4) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/wildfly/common/main/wildfly-common-1.3.1.Final.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> > at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> > {code} > According MR JAR Support in JBoss Parent proposal WildFly Common should have Manifest entry > * modules/system/layers/base/org/wildfly/common/main/wildfly-common-1.3.1.Final.jar > I believe shaded jars should also have Manifest entry > * bin/wildfly-elytron-tool.jar > * bin/client/jboss-cli-client.jar > * bin/client/jboss-client.jar > Using https://github.com/jboss-eap-qe/jarest/pull/3/files ++ mvn test -Djarest.input.dir=/Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10258) Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin... ] David Lloyd commented on WFLY-10258: ------------------------------------ I did some more research and I have concluded that not only does our delisting code not do any good, I think it is actually doing harm by leaving orphaned transactions on subordinates in the case where there was no transaction work done. I will open a WFTC for this problem. > Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew > --------------------------------------------------------------------------------------------- > > Key: WFLY-10258 > URL: https://issues.jboss.org/browse/WFLY-10258 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Affects Versions: 12.0.0.Final > Reporter: Jörg Bäsner > > Scenario: > - server-1 (intermediary) > -- Running standalone profile > -- Has a remote-outbound-connection pointing at server-2 through server-2's public IP address > -- Intermediary bean need to lookup the Target bean in server-2 and also inject the {{TransactionManager}} > -- Intermediary bean need to enlist a _dummy_ XAResource > - server-2 (target) > -- disable {{JBOSS-LOCAL-USER}} auth > -- Target bean needs to be annotated with {{@REQUIRES_NEW}} (important) > - Standalone EJB client invokes an intermediary bean server-1, which as a result invokes target bean on server-2. > The _dummy_ XAResource should log in the {{commit}} method whether one-phase optimization is being used like: > {code} > @Override > public void commit(Xid arg0, boolean onePhaseOptim) throws XAException { > logger.info("-- Committing in the client resource. One-phase optimisation is: " + onePhaseOptim + " --" > + (onePhaseOptim ? "" : " -> TWO-PHASE COMMIT !!!")); > } > {code} > In this scenario it is expected that the one-phase optimization is being used! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2265) Jgroup MERGE3 is not merging big cluster

by lokesh raheja (JIRA)

lokesh raheja created JGRP-2265: ----------------------------------- Summary: Jgroup MERGE3 is not merging big cluster Key: JGRP-2265 URL: https://issues.jboss.org/browse/JGRP-2265 Project: JGroups Issue Type: Feature Request Reporter: lokesh raheja Assignee: Bela Ban MERGE3 is not merging the cluster: We have a cluster of 105 nodes.I see after the cluster split it merge the cluster every time. But sometimes it gets stuck and divided into two or three clusters .1 big cluster and 2 small clusters. We have to restart the node in the small cluster to join the big cluster. In the case when it doesn’t join the cluster, I noticed that the node which is not in big cluster show the coordinator(using MERGE3.dumpviews) is the one which is already in a big cluster.The strange part is if I shut down the coordinator of a small cluster, but on all the nodes of the small cluster, it shows that same coordinator which is shut down. Is some caching issue?Could you please help on the same -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1239) Elytron client, elytron-1_0.xsd, protection-parameter-credentials is incorrectly defined as client-credentials-type.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1239?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1239: ---------------------------------- Fix Version/s: 1.3.1.Final (was: 1.3.0.Final) > Elytron client, elytron-1_0.xsd, protection-parameter-credentials is incorrectly defined as client-credentials-type. > -------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1239 > URL: https://issues.jboss.org/browse/ELY-1239 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client, Credential Store > Reporter: Hynek Švábek > Assignee: Peter Skopek > Priority: Blocker > Fix For: 1.3.1.Final > > > Elytron client, elytron-1_0.xsd, *protection-parameter-credentials* is incorrectly defined as client-credentials-type [1]. > For *protection-parameter-credentials* is valid only credential-store-reference element: > {code} > <xsd:element name="credential-store-reference" type="credential-store-reference-type"/> > {code} > But now is *protection-parameter-credentials* defined as type *client-credentials-type* [1] which can have these values: > {code} > <xsd:complexType name="client-credentials-type"> > <xsd:choice minOccurs="0" maxOccurs="unbounded"> > <xsd:element name="key-store-reference" type="key-store-ref-type"/> > <xsd:element name="credential-store-reference" type="credential-store-reference-type"/> > <xsd:element name="clear-password" type="clear-password-type"/> > <xsd:element name="hashed-password" type="hashed-password-type"/> > <xsd:element name="crypt-password" type="crypt-password-type"/> > <xsd:element name="key-pair" type="key-pair-type"/> > <xsd:element name="certificate" type="certificate-type"/> > <xsd:element name="public-key-pem" type="xsd:string"/> > <xsd:element name="bearer-token" type="bearer-token-type"/> > <xsd:element name="oauth2-bearer-token" type="oauth2-bearer-token-type"/> > </xsd:choice> > </xsd:complexType> > {code} > Please keep on mind that changes must be done accordingly in ElytronXMLParser too. > [1] https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta47/src... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1082) Documentation is missing in elytron-1_0.xsd

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1082?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1082: ---------------------------------- Fix Version/s: 1.3.1.Final (was: 1.3.0.Final) > Documentation is missing in elytron-1_0.xsd > ------------------------------------------- > > Key: ELY-1082 > URL: https://issues.jboss.org/browse/ELY-1082 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta34 > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > Priority: Critical > Fix For: 1.3.1.Final > > > XSD file {{elytron-1_0.xsd}} [1] includes almost no documentation. If this XSD is included in server distribution (as {{docs/schema/elytron-1_0.xsd}}) then it affects user experience. > [1] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-816) Support for masked passwords in client XML config

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-816?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-816: --------------------------------- Fix Version/s: 1.3.1.Final (was: 1.3.0.Final) > Support for masked passwords in client XML config > ------------------------------------------------- > > Key: ELY-816 > URL: https://issues.jboss.org/browse/ELY-816 > Project: WildFly Elytron > Issue Type: Task > Reporter: David Lloyd > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.3.1.Final > > > We need a way to support masked passwords in the auth configuration file, either as: > * A dedicated masked-password-type XML type > * Adding necessary fields to hashed-password-type > * Adding a modular crypt format > Needs to be supported anywhere passwords are allowed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-787) SASL mechanisms are not IANA registered and specifications are not provided

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-787?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-787: --------------------------------- Fix Version/s: 1.3.1.Final (was: 1.3.0.Final) > SASL mechanisms are not IANA registered and specifications are not provided > --------------------------------------------------------------------------- > > Key: ELY-787 > URL: https://issues.jboss.org/browse/ELY-787 > Project: WildFly Elytron > Issue Type: Task > Reporter: Josef Cacek > Priority: Critical > Labels: sasl > Fix For: 1.3.1.Final > > > Elytron comes with set of SASL mechanisms (as requested by EAP7-530), but they don't fit SASL requirements. > New mechanisms has to be registered by IANA as requested by [SASL RFC 4422 section 5|https://tools.ietf.org/html/rfc4422#section-5] and Java [SaslClientFactory|http://docs.oracle.com/javase/8/docs/api/javax/security...] and [SaslServerFactory|http://docs.oracle.com/javase/8/docs/api/javax/security...] contracts. > Current list of mechanisms provided by Elytron, which are not IANA registered: > * DIGEST-SHA > * DIGEST-SHA-256 > * DIGEST-SHA-512 > * JBOSS-LOCAL-USER > *Suggestion for improvement:* > Provide specifications for the new mechanisms and register the names by IANA (see [section 7 in RFC-4422|https://tools.ietf.org/html/rfc4422#section-7]). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-533) Deprecate all legacy code

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-533?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-533: --------------------------------- Fix Version/s: 1.3.1.Final (was: 1.3.0.Final) > Deprecate all legacy code > ------------------------- > > Key: ELY-533 > URL: https://issues.jboss.org/browse/ELY-533 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.3.1.Final > > > In a few places we have legacy behaviour within the project to assist migration from previous JBoss / WildFly releases - this code should be flagged as deprecated to encourage minimal use. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2018