May 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11540) Update Maven dependencies to reference individual Elytron modules.

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11540?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11540: ------------------------------------ Fix Version/s: 17.0.0.Beta1 (was: 17.0.0.Alpha1) > Update Maven dependencies to reference individual Elytron modules. > ------------------------------------------------------------------ > > Key: WFLY-11540 > URL: https://issues.jboss.org/browse/WFLY-11540 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 17.0.0.Beta1 > > > This should also review the classes the application server users as we will likely want to start considering these public API. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11538) Opentracing - SmallRye - IllegalStateException

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11538?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11538: ------------------------------------ Fix Version/s: 17.0.0.Beta1 (was: 17.0.0.Alpha1) > Opentracing - SmallRye - IllegalStateException > ---------------------------------------------- > > Key: WFLY-11538 > URL: https://issues.jboss.org/browse/WFLY-11538 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 15.0.0.Final > Reporter: Alessandro Moscatelli > Priority: Major > Fix For: 17.0.0.Beta1 > > > Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-000713: Unable to inject ServletContext. None is associated with ModuleClassLoader for Module > The problem is the interaction between these two: > https://github.com/wildfly/wildfly/blob/master/microprofile/opentracing-s... > https://github.com/smallrye/smallrye-opentracing/blob/1.1.1/implementatio... > Those are delivered with Wildfly 15 out of the box in: > smallrye-opentracing-1.1.1.jar > wildfly-microprofile-opentracing-smallrye-15.0.0.Final.jar > I have an EAR with a EJB jar, WAR and a common JAR library. > To reproduce the issue I created a Stateless EJB in the EJB jar and then I injected a Traced ApplicationScoped bean from the JAR library in the Stateless EJB. > SmallRyeTracingCDIInterceptor triggers and it requires an Injected Tracer. > TracerProducer triggers and it has no active ServletContext and this leads to the error above. > My suggestion: > I don't think the ServletContext is a really good place to store the Tracer. > I think that the Tracer created by Wildfly should be registered into the GlobalTracer. > This should be done by: > https://github.com/wildfly/wildfly/blob/master/microprofile/opentracing-s... > If you don't want Wildfly to register automatically its Tracer in the GlobalTracer, this behavior could be disabled in the subsystem. > Also please be aware that SmallRyeTracingCDIInterceptor is dismissed in the last versions of the library and SmallRye states (https://github.com/smallrye/smallrye-opentracing) it has been replaced with: > https://github.com/opentracing-contrib/java-interceptors/blob/master/src/... > Also be aware that what I am suggesting is similar to the same behavior adopted in opentracing java-cdi (not yet integrated in Wildfly): > https://github.com/opentracing-contrib/java-cdi/blob/master/opentracing-c... > https://github.com/opentracing-contrib/java-cdi/blob/master/opentracing-c... > Also notice that opentracing java-ejb (not yet integrated in Wildfly) also requires a registration in GlobalTracing: > https://github.com/opentracing-contrib/java-ejb/blob/master/opentracing-e... > Thank you for your support. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11492) Quickstart http-custom-mechanism: documentation step fails

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11492?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11492: ------------------------------------ Fix Version/s: 17.0.0.Beta1 (was: 17.0.0.Alpha1) > Quickstart http-custom-mechanism: documentation step fails > ---------------------------------------------------------- > > Key: WFLY-11492 > URL: https://issues.jboss.org/browse/WFLY-11492 > Project: WildFly > Issue Type: Bug > Components: Documentation > Reporter: Alan Hantke > Assignee: Darran Lofthouse > Priority: Major > Fix For: 17.0.0.Beta1 > > > Step #3, entitled *Configure the Application Security Domain* has the developer executing the following CLI command: > {code:java} > $ {jbossHomeName}/bin/jboss-cli.sh --connect --file=configure-security-domain.cli > {code} > However, this results in the following error: > {code:java} > The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): > WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed: > Step: step-1 > Operation: /subsystem=undertow/application-security-domain=other:add(http-authentication-factory=application-http-authentication) > Failure: WFLYCTL0369: Required capabilities are not available: > org.wildfly.security.http-authentication-factory.application-http-authentication; Possible registration points for this capability: > /subsystem=elytron/http-authentication-factory=* > {code} > I am by no means an expert on this, but in looking at the standalone.xml file, I think that there needs to be a mate for the inserted *application-http-authentication*. I have attempted to continue without this changes installed by the CLI, but I am unable to execute the webapp even after providing the correct user/pass in the BASIC AUTH. > I have verified that the same problem-causing syntax exists on the quickstart 'master', although I have been using branch '14.x' because neither 15.x nor 'master' would build when I execute 'mvn clean build'. Finally, the I encounter the problem with fresh installs of WildFly versions 10.1.0 and 14.0. > Please change change the project if I have categorized the ticket incorrectly. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11489: ------------------------------------ Fix Version/s: 17.0.0.Beta1 (was: 17.0.0.Alpha1) > SFSB not sticky on a single cluster node when clustering of the bean is disabled > -------------------------------------------------------------------------------- > > Key: WFLY-11489 > URL: https://issues.jboss.org/browse/WFLY-11489 > Project: WildFly > Issue Type: Bug > Components: Clustering, Remoting > Affects Versions: 15.0.0.Final > Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_) > This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f). > Reporter: Joerg Baesner > Assignee: Richard Achmatowicz > Priority: Major > Labels: downstream_dependency > Fix For: 17.0.0.Beta1 > > Attachments: reproducer.zip > > > In case a stateful session bean is annotated with: > {{@Stateful(passivationCapable=false)}} > then the serialization is *disabled* and thus the bean is only available on a single cluster node. > When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception: > {code} > ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4] > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) > at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406) > at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565) > at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546) > at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349) > at java.lang.Thread.run(Thread.java:748) > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11214) Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11214?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11214: ------------------------------------ Fix Version/s: 17.0.0.Beta1 (was: 17.0.0.Alpha1) > Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used > ------------------------------------------------------------------------------------------- > > Key: WFLY-11214 > URL: https://issues.jboss.org/browse/WFLY-11214 > Project: WildFly > Issue Type: Bug > Components: Agroal, Transactions > Reporter: Ivan Straka > Assignee: Luis Barreiro > Priority: Critical > Fix For: 17.0.0.Beta1 > > Attachments: JPACrashRecoveryTestCase_commitHaltSecond_jta_server.log, JPACrashRecoveryTestCase_commitHaltSecond_jts_server.log > > > Scenario: > Halts server at commit phase ... > # enlist TestXA resource > # enlist XA resource > # prepare TestXA resource > # prepare XA resource > # commit Test XA resource > # JVM crash > # recovery started > # commit XA resource > Periodic recovery does not recover xa resource. It looks like agroal subsystem does not register xa resource to xa recovery module. > Test outcome: > {code:java} > Running org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 109.002 sec <<< FAILURE! - in org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase > commitHaltSecond(org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase) Time elapsed: 102.976 sec <<< FAILURE! > java.lang.AssertionError: Incorrect data in database after crash recovery. expected:<2> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.test.JPABaseCrashRecoveryTestCase.checkAfterTestExecution(JPABaseCrashRecoveryTestCase.java:150) > at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltTest(TestBaseCrashRecovery.java:485) > at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltSecond(TestBaseCrashRecovery.java:418) > at org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase.commitHaltSecond(JPACrashRecoveryTestCase.java:76) > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11101) Add CredentialStore documentation

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11101?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11101: ------------------------------------ Fix Version/s: 17.0.0.Beta1 (was: 17.0.0.Alpha1) > Add CredentialStore documentation > --------------------------------- > > Key: WFLY-11101 > URL: https://issues.jboss.org/browse/WFLY-11101 > Project: WildFly > Issue Type: Task > Components: Documentation, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 17.0.0.Beta1 > > > The CredentialStore is a significant component within WildFly Elytron, however it is not really covered in the documentation. > We have a couple of different approaches to creating the store, we then have referencing the store. Finally we have custom implementations. > New features are also being developed so really we need a source of documentation to add descriptions of the new features to. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11783) Rewrite some WildFly EE services to don't use deprecated MSC API

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11783?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11783: ------------------------------------ Fix Version/s: 17.0.0.Beta1 (was: 17.0.0.Alpha1) > Rewrite some WildFly EE services to don't use deprecated MSC API > ---------------------------------------------------------------- > > Key: WFLY-11783 > URL: https://issues.jboss.org/browse/WFLY-11783 > Project: WildFly > Issue Type: Enhancement > Components: EE > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Major > Fix For: 17.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11759) Use LegacyKernelServicesInitializer to exclude problematic resources from UndertowTransformersTestCase

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11759?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11759: ------------------------------------ Fix Version/s: 17.0.0.Beta1 (was: 17.0.0.Alpha1) > Use LegacyKernelServicesInitializer to exclude problematic resources from UndertowTransformersTestCase > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-11759 > URL: https://issues.jboss.org/browse/WFLY-11759 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Minor > Fix For: 17.0.0.Beta1 > > > Revert this workaround using the exclusion feature added by WFCORE-4346: > https://github.com/wildfly/wildfly/pull/12098 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11720) Cannot invoke EJB over HTTP on JDK 11

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11720?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11720: ------------------------------------ Fix Version/s: 17.0.0.Beta1 (was: 17.0.0.Alpha1) > Cannot invoke EJB over HTTP on JDK 11 > ------------------------------------- > > Key: WFLY-11720 > URL: https://issues.jboss.org/browse/WFLY-11720 > Project: WildFly > Issue Type: Bug > Components: EJB, Remoting > Affects Versions: 16.0.0.Beta1 > Environment: JDK 11 > Reporter: Jan Kasik > Assignee: Cheng Fang > Priority: Critical > Fix For: 17.0.0.Beta1 > > Attachments: classes.zip, client-app.zip > > > Run of client app calling EJB over HTTP fails on JDK 11 with following log: > {noformat} > Feb 14, 2019 12:49:30 PM org.wildfly.naming.client.Version <clinit> > INFO: WildFly Naming version 1.0.6.Final > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by org.wildfly.security.manager.GetAccessibleDeclaredFieldAction (file:/home/hudson/hudson_workspace/mod_cluster/client/wildfly-elytron-1.1.3.Final.jar) to field java.security.AccessControlContext.context > WARNING: Please consider reporting this to the maintainers of org.wildfly.security.manager.GetAccessibleDeclaredFieldAction > WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations > WARNING: All illegal access operations will be denied in a future release > Feb 14, 2019 12:49:30 PM org.wildfly.security.Version <clinit> > INFO: ELY00001: WildFly Elytron version 1.1.3.Final > Feb 14, 2019 12:49:30 PM org.jboss.ejb.client.EJBClient <clinit> > INFO: JBoss EJB Client version 4.0.2.Final > Feb 14, 2019 12:49:30 PM org.xnio.Xnio <clinit> > INFO: XNIO version 3.6.5.Final > Feb 14, 2019 12:49:30 PM org.xnio.nio.NioXnio <clinit> > INFO: XNIO NIO Implementation Version 3.6.5.Final > Feb 14, 2019 12:49:30 PM org.jboss.threads.Version <clinit> > INFO: JBoss Threads version 2.3.0.Beta2 > Feb 14, 2019 12:49:30 PM org.jboss.remoting3.EndpointImpl <clinit> > INFO: JBoss Remoting version 5.0.0.Final > Feb 14, 2019 12:49:30 PM org.jboss.threads.LoggingUncaughtExceptionHandler uncaughtException > ERROR: Thread Thread[XNIO-1 task-1,5,main] threw an uncaught exception > java.lang.ExceptionInInitializerError > at org.jboss.marshalling.river.RiverMarshaller.<clinit>(RiverMarshaller.java:1335) > at org.jboss.marshalling.river.RiverMarshallerFactory.createMarshaller(RiverMarshallerFactory.java:54) > at org.wildfly.httpclient.common.HttpTargetContext.createMarshaller(HttpTargetContext.java:132) > at org.wildfly.httpclient.ejb.HttpEJBReceiver.marshalEJBRequest(HttpEJBReceiver.java:367) > at org.wildfly.httpclient.ejb.HttpEJBReceiver.lambda$processInvocation$1(HttpEJBReceiver.java:185) > at org.wildfly.httpclient.common.HttpTargetContext$1.lambda$completed$0(HttpTargetContext.java:338) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1871) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1400) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: java.lang.IllegalStateException: No standard field found for reverse order comparator! > at org.jboss.marshalling.river.Protocol.<clinit>(Protocol.java:287) > ... 9 more > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11569) Port EESecurityAuthMechanismTestCase to WildFly Elytron

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11569?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11569: ------------------------------------ Fix Version/s: 17.0.0.Beta1 (was: 17.0.0.Alpha1) > Port EESecurityAuthMechanismTestCase to WildFly Elytron > ------------------------------------------------------- > > Key: WFLY-11569 > URL: https://issues.jboss.org/browse/WFLY-11569 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 17.0.0.Beta1 > > > Also ensure it passes with the security manager enabled. > Also see WFLY-11348 which is the failure with PicketBox. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 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 May 2019