[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-8954:
------------------------------------
>From the output that you have gathered, it appears to me that you have identified an ordering difference between what your application sees on WebLogic versus what you are seeing on WildFly.
Just to summarize what you posted above, on WildFly, after clicking on the web page to to trigger event B, we first see the CDI observers event getting hit. Then, org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.mergeChangesIntoParent() is reached. Then the second JTA transaction is reached (for the second call to org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.mergeChangesIntoParent()).
[https://javaee.groups.io/g/jpa-spec/message/8] may also be relevant to this discussion. For issues like this, it may be better to start with a discussion on [https://developer.jboss.org/en/wildfly?view=discussion], as it is not yet clear exactly as to what the root issue is and it may of helped to have more input from others. At this point, since we are still not yet understanding the exact root cause and solution, it might be okay to keep the discussion going here for now, until it is a little more focused on the root issue.
Having said that, some possible outcomes (or paths forward) might be:
# Arrange for EclipseLink afterCompletion to run before to CDI EJB observers, so that the EclipseLink second level cache is cleared.
# Or determine that the application is assuming too much about which occurs first, the CDI EJB observers or the EclipseLink clearing of the second level cache. I'm not yet personally on this path but would like to consider that this may be the outcome, from the point of view of the involved standards (Java EE, CDI, JPA, JTA).
I already have looked in the latest EclipseLink source and see that it is not using the TransactionSynchronizationRegistry to register its Synchronization. We need to verify whether the CDI EJB observers on WildFly, are using TransactionSynchronizationRegistry (perhaps setting a breakpoint in org.jboss.weld.event.TransactionalObserverNotifier.notifyTransactionObservers and see if TransactionSynchronizationRegistry is being used.) Perhaps the code is elsewhere that needs to be checked, I'm not 100% sure yet.
I wonder if [https://github.com/wildfly/wildfly/tree/master/testsuite/compat/src/test/...] could be updated to recreate the same issue (EclipseLink second level cache updating and CDI observer events).
Thank you for discussing this issue, definitely an interesting one!
Regards,
Scott
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9003) RemoteFailoverTestCase.testSecureStatelessFailover fails due to authorization
by David Lloyd (JIRA)
David Lloyd created WFLY-9003:
---------------------------------
Summary: RemoteFailoverTestCase.testSecureStatelessFailover fails due to authorization
Key: WFLY-9003
URL: https://issues.jboss.org/browse/WFLY-9003
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: David Lloyd
Priority: Critical
On the server, the authentication information seems OK. PicketBox is rejecting authorization, probably due to some change in Elytron integration.
The stack trace looks like this:
{noformat}
2017-06-26 21:45:30 testSecureStatelessFailover(org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase) Time elapsed: 5.765 sec <<< ERROR!
2017-06-26 21:45:30 javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment() of bean: SecureStatelessIncrementorBean is not allowed
2017-06-26 21:45:30 at org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:134)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256)
2017-06-26 21:45:30 at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
2017-06-26 21:45:30 at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
2017-06-26 21:45:30 at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
2017-06-26 21:45:30 at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:380)
2017-06-26 21:45:30 at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:480)
2017-06-26 21:45:30 at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:475)
2017-06-26 21:45:30 at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:183)
2017-06-26 21:45:30 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
2017-06-26 21:45:30 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
2017-06-26 21:45:30 at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9002) RemoteFailoverTestCase.testSecureStatelessFailover fails due to authorization
by David Lloyd (JIRA)
David Lloyd created WFLY-9002:
---------------------------------
Summary: RemoteFailoverTestCase.testSecureStatelessFailover fails due to authorization
Key: WFLY-9002
URL: https://issues.jboss.org/browse/WFLY-9002
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: David Lloyd
Priority: Critical
On the server, the authentication information seems OK. PicketBox is rejecting authorization, probably due to some change in Elytron integration.
The stack trace looks like this:
{noformat}
2017-06-26 21:45:30 testSecureStatelessFailover(org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase) Time elapsed: 5.765 sec <<< ERROR!
2017-06-26 21:45:30 javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment() of bean: SecureStatelessIncrementorBean is not allowed
2017-06-26 21:45:30 at org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:134)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256)
2017-06-26 21:45:30 at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
2017-06-26 21:45:30 at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
2017-06-26 21:45:30 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
2017-06-26 21:45:30 at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
2017-06-26 21:45:30 at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
2017-06-26 21:45:30 at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:380)
2017-06-26 21:45:30 at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:480)
2017-06-26 21:45:30 at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:475)
2017-06-26 21:45:30 at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:183)
2017-06-26 21:45:30 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
2017-06-26 21:45:30 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
2017-06-26 21:45:30 at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3016) Undertow CLIENT_CERT via Elytron and HTTP/2 does not work
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3016?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved JBEAP-11805 to WFCORE-3016:
--------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-3016 (was: JBEAP-11805)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
(was: Web (Undertow))
Affects Version/s: (was: 7.1.0.DR18)
> Undertow CLIENT_CERT via Elytron and HTTP/2 does not work
> ---------------------------------------------------------
>
> Key: WFCORE-3016
> URL: https://issues.jboss.org/browse/WFCORE-3016
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: eap7.1-rfe-failure, eap7.1-risks-mitigation
> Fix For: 3.0.0.Beta28
>
>
> When I setup CLIENT_CERT authentication for an application (see Steps to Reproduce) and utilize HTTP/2 protocol, I get always 403 Forbidden even in case I use correct client certificate that should allow me access to a secured content.
> I can see following TRACE messages in server.log:
> {code}
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) X500 principal [CN=client] decoded as name [client] (attribute values: [client])
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Principal assigning: [CN=client], pre-realm rewritten: [client], realm name: [ksRealm], post-realm rewritten: [client], realm rewritten: [client]
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Role mapping: principal [client] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [gooduser]
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Authorizing principal client.
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Authorizing against the following attributes: [] => []
> 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Permission mapping: identity [client] with roles [gooduser] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Authorization succeed
> 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Authentication succeed for principal [CN=client]
> 2017-05-23 10:58:31,117 TRACE [org.wildfly.security] (default task-10) Handling MechanismInformationCallback type='HTTP' name='CLIENT_CERT' host-name='localhost' protocol='https'
> 2017-05-23 10:58:31,117 TRACE [org.wildfly.security] (default task-10) CLIENT-CERT no SSL session
> {code}
> Authentication seems that it succeed just fine. But notice the last line - {{CLIENT-CERT no SSL session}}.
> When I disable 'http2' in https-listener:
> {code}
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enable-http2,value=false)
> reload
> {code}
> I can now access secured content as expected. Also trace log contains different (more healthy) messages now.
> This happens both when I utilize HTTP/2 with EAP 'alpn-hack' mechanism and also with ALPN provided by OpenSSL library.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3016) Expose principal-decoder as principal-transformer and support conversion to X500Principal
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3016?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-3016:
-------------------------------------
Summary: Expose principal-decoder as principal-transformer and support conversion to X500Principal (was: Undertow CLIENT_CERT via Elytron and HTTP/2 does not work)
> Expose principal-decoder as principal-transformer and support conversion to X500Principal
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-3016
> URL: https://issues.jboss.org/browse/WFCORE-3016
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: eap7.1-rfe-failure, eap7.1-risks-mitigation
> Fix For: 3.0.0.Beta28
>
>
> When I setup CLIENT_CERT authentication for an application (see Steps to Reproduce) and utilize HTTP/2 protocol, I get always 403 Forbidden even in case I use correct client certificate that should allow me access to a secured content.
> I can see following TRACE messages in server.log:
> {code}
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) X500 principal [CN=client] decoded as name [client] (attribute values: [client])
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Principal assigning: [CN=client], pre-realm rewritten: [client], realm name: [ksRealm], post-realm rewritten: [client], realm rewritten: [client]
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Role mapping: principal [client] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [gooduser]
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Authorizing principal client.
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Authorizing against the following attributes: [] => []
> 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Permission mapping: identity [client] with roles [gooduser] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Authorization succeed
> 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Authentication succeed for principal [CN=client]
> 2017-05-23 10:58:31,117 TRACE [org.wildfly.security] (default task-10) Handling MechanismInformationCallback type='HTTP' name='CLIENT_CERT' host-name='localhost' protocol='https'
> 2017-05-23 10:58:31,117 TRACE [org.wildfly.security] (default task-10) CLIENT-CERT no SSL session
> {code}
> Authentication seems that it succeed just fine. But notice the last line - {{CLIENT-CERT no SSL session}}.
> When I disable 'http2' in https-listener:
> {code}
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enable-http2,value=false)
> reload
> {code}
> I can now access secured content as expected. Also trace log contains different (more healthy) messages now.
> This happens both when I utilize HTTP/2 with EAP 'alpn-hack' mechanism and also with ALPN provided by OpenSSL library.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3016) Expose principal-decoder as principal-transformer and support conversion to X500Principal
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3016?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-3016:
-------------------------------------
Fix Version/s: 3.0.0.Beta28
> Expose principal-decoder as principal-transformer and support conversion to X500Principal
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-3016
> URL: https://issues.jboss.org/browse/WFCORE-3016
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: eap7.1-rfe-failure, eap7.1-risks-mitigation
> Fix For: 3.0.0.Beta28
>
>
> When I setup CLIENT_CERT authentication for an application (see Steps to Reproduce) and utilize HTTP/2 protocol, I get always 403 Forbidden even in case I use correct client certificate that should allow me access to a secured content.
> I can see following TRACE messages in server.log:
> {code}
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) X500 principal [CN=client] decoded as name [client] (attribute values: [client])
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Principal assigning: [CN=client], pre-realm rewritten: [client], realm name: [ksRealm], post-realm rewritten: [client], realm rewritten: [client]
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Role mapping: principal [client] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [gooduser]
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Authorizing principal client.
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Authorizing against the following attributes: [] => []
> 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Permission mapping: identity [client] with roles [gooduser] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Authorization succeed
> 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Authentication succeed for principal [CN=client]
> 2017-05-23 10:58:31,117 TRACE [org.wildfly.security] (default task-10) Handling MechanismInformationCallback type='HTTP' name='CLIENT_CERT' host-name='localhost' protocol='https'
> 2017-05-23 10:58:31,117 TRACE [org.wildfly.security] (default task-10) CLIENT-CERT no SSL session
> {code}
> Authentication seems that it succeed just fine. But notice the last line - {{CLIENT-CERT no SSL session}}.
> When I disable 'http2' in https-listener:
> {code}
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enable-http2,value=false)
> reload
> {code}
> I can now access secured content as expected. Also trace log contains different (more healthy) messages now.
> This happens both when I utilize HTTP/2 with EAP 'alpn-hack' mechanism and also with ALPN provided by OpenSSL library.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months