[JBoss JIRA] (WFLY-9496) WildFly 10.1 Final: Virtual Hosting
by I J (JIRA)
[ https://issues.jboss.org/browse/WFLY-9496?page=com.atlassian.jira.plugin.... ]
I J commented on WFLY-9496:
---------------------------
I see what you are getting at. The problem is externally browsers only ever point to 80/443 unless your links are exlicity employing nonstandard ports. No user...
I have domains that need to be seen and managed via a single public address. One that uses the standard external address: port 80. Routers, possessing a single public interface, understandably, can only map that port to a single internally homed machine. Ie. external port 80 must map to internal ip:port something. Given this if a browser chooses a non-ssl protocol and I want to force a redirect to an ssl protocol, I can't without affect all apps served from that server. Which would be fine if all my apps are externally exposed. Apps that are in development and may not currently have a domain name and dns record break the model because there is no external reference in the dns. When I set up a reference in the internal hosts file to access these dev stage apps wildfly https redirects force them to be external and since there is no dns for that placeholder name the mechanism fails.
Unfortunately I can't simply reference the hostname as referenced in the local hosts file appended with the https listener port binding, ie. Host1:8443, as that binding forces the browser to insert the https address line reference, again, an external reference.
This all being said, you have solved my problem admirably as I know a little more regarding Wildfly's operating methododolgy, I am able to move forward.
My solution was to remove the forced redirect reference in the web.xml file for apps under development. Not ideal as some of the app code tests the protocol before completing the task in question (ie. App login functionality that tests whether or not the protocol being employed is secure via tls among others...).
What I have done is created an unreferenced alias to one of my external apps and am testing the functionality as a component of that app. Once I am sure of the domain name and make the purchase I will secure the development app with some form of secure-auth integrating the modules that test for the secure condition before going live.
I went this route as, while kludgy, I am not sure if exploring the domain configuration will resolve this issue? (I don't believe is will - the problem I am facing is a https issue by design and that it is me that must change my methodology).
Thanks again Stuart! I have my path... :)
> WildFly 10.1 Final: Virtual Hosting
> ------------------------------------
>
> Key: WFLY-9496
> URL: https://issues.jboss.org/browse/WFLY-9496
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux
> JAVA_HOME: null
> java.version: 1.8.0_151
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.151-b12
> os.name: Linux
> os.version: 4.9.0-3-amd64
> WildFly: 10.1.0.Final
> Reporter: I J
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: new_and_noteworthy
> Attachments: Screenshot from 2017-10-30 19-25-12.png, wireshareNative.gz.pcap, wireshark
>
>
> My configuration:
> ========= standalone-full.xml ===============
> <subsystem xmlns="urn:jboss:domain:undertow:3.1">
> <buffer-cache name="default"/>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
> <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> <host name="host1" alias="domain1.com,www.domain1.com" default-web-module="domain1-war.war"/>
> <host name="host2" alias="domain2.com,www.domain2.com" default-web-module="domain2-war.war"/>
> </server>
> <servlet-container name="default">
> <jsp-config/>
> <websockets/>
> </servlet-container>
> <handlers>
> <file name="welcome-content" path="${jboss.home.dir}/www/welcome-content"/>
> </handlers>
> <filters>
> <response-header name="server-header" header-name="Server" header-value="WildFly/10"/>
> <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
> </filters>
> </subsystem>
> ============ /etc/hosts ============
> 127.0.0.1 localhost host1 host2
> =========== domain1-war/WEB-INF/jboss-web.xml =========
> <jboss-web>
> <virtual-host>host1</virtual-host>
> <context-root>/</context-root>
> </jboss-web>
> =========== domain2-war/WEB-INF/jboss-web.xml =========
> <jboss-web>
> <virtual-host>host2</virtual-host>
> <context-root>/</context-root>
> </jboss-web>
> [EDIT] ============================================
> Wildfly is launched as per: [opt/wildfly/bin] ./standalone.sh -b=0.0.0.0 -c=standalone-full.xml
> Thus socket bindings should not be an issue.
> Notes:
> 1. Server starts and all deploys and works as expected when access as host1:8080, host2:8080, localhost:8080
> Thus my webapps along with the wildfly default ROOT.war (welcome pages) work as expected.
> 2. Router port 80 is forwarded to 8080
> 3. When using the server aliases as defined in standalone-full.xml, in my case domain1.com or domain2.com the server times out and I get nothing.
> 4. I have intercepted the request headers for domain1.com and domain2.com and they are correct.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (WFLY-9492) Concurrent access timeout on StatefulBean when invoked via StatelessBean
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9492?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-9492.
----------------------------------
Resolution: Rejected
You need to use @Inject, and not @EJB. @EJB has its own lifecycle rules when used in EJB's, and as a result you will not get a CDI proxy injected into the SLSB but a single instance of the SFSB's whoes lifecycle is tied to the stateless bean.
> Concurrent access timeout on StatefulBean when invoked via StatelessBean
> ------------------------------------------------------------------------
>
> Key: WFLY-9492
> URL: https://issues.jboss.org/browse/WFLY-9492
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final, 11.0.0.Final
> Reporter: Thies Rubarth
> Attachments: sfsbLock.zip
>
>
> We are having issues with a stateful bean that is invoked serveral times in a request to calculate things. We have a StatelessBean, that is called via REST and calls another StatelessBean which calls the StatefulBean which is request scoped. When we have parallel requests it comes to ConcurrentAccessTimeoutExceptions on the StatefulBean, although we shoudn't have concurrent access since the Bean is request scoped.
> This is the stacktrace we get:
> Caused by: javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on StatefulBean - could not obtain lock within 5000 MILLISECONDS
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:94)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> ... 213 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (WFLY-7291) InfinispanCacheDeploymentListener throws ServiceNotFoundException when stopping
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7291?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-7291:
--------------------------------------
Fix Version/s: 12.0.0.Alpha1
Assignee: George Gastaldi (was: Scott Marlow)
Resolution: Done
> InfinispanCacheDeploymentListener throws ServiceNotFoundException when stopping
> -------------------------------------------------------------------------------
>
> Key: WFLY-7291
> URL: https://issues.jboss.org/browse/WFLY-7291
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Reporter: George Gastaldi
> Assignee: George Gastaldi
> Fix For: 12.0.0.Alpha1
>
> Attachments: demosrc.zip
>
>
> Deploying a WAR produced by the attached project produces the following error in the logs when shutting down the server:
> {code}
> [ERROR [org.jboss.as.jpa] (ServerService Thread Pool -- 38) WFLYJPA0007: Failed to stop persistence unit service demo.war#primary: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.hibernate."demo.war#primary" not found
> at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:669)
> at org.jboss.as.jpa.processor.secondLevelCache.InfinispanCacheDeploymentListener.stopCache(InfinispanCacheDeploymentListener.java:144)
> at org.jboss.as.jpa.processor.secondLevelCache.CacheDeploymentListener.stopCache(CacheDeploymentListener.java:96)
> at org.jipijapa.event.impl.internal.Notification.stopCache(Notification.java:107)
> at org.jboss.as.jpa.hibernate5.infinispan.InfinispanRegionFactory.stopCacheManager(InfinispanRegionFactory.java:80)
> at org.hibernate.cache.infinispan.InfinispanRegionFactory.stop(InfinispanRegionFactory.java:443)
> at org.hibernate.internal.CacheImpl.close(CacheImpl.java:266)
> at org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1074)
> at org.hibernate.jpa.internal.EntityManagerFactoryImpl.close(EntityManagerFactoryImpl.java:347)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$2$1.run(PersistenceUnitServiceImpl.java:237)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$2$1.run(PersistenceUnitServiceImpl.java:217)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$2.run(PersistenceUnitServiceImpl.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (WFLY-9479) SSL Resource Causing SSL is null
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9479?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-9479:
--------------------------------------
I think this must be some kind of race, the only way I can see this happening is if the connection was closed while processing a stream. What happens if you disable HTTP/2? Does everything work as normal?
> SSL Resource Causing SSL is null
> --------------------------------
>
> Key: WFLY-9479
> URL: https://issues.jboss.org/browse/WFLY-9479
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Final
> Environment: Linux CentoOS with Docker.
> Reporter: Jason Bruwer
> Assignee: Stuart Douglas
> Attachments: Screen Shot 2017-10-27 at 09.57.26.png, server_2017-10-27T05-58-24+0000.log
>
>
> 2017-10-25 13:28:42,865 ERROR [io.undertow.request] (default task-20) UT005023: Exception handling request to /fluid/javax.faces.resource/syntaxhighlighter.css.xhtml: java.lang.IllegalStateException: ssl is null
> at org.wildfly.openssl.SSLImpl.getSessionId0(Native Method)
> at org.wildfly.openssl.SSLImpl.getSessionId(SSLImpl.java:479)
> at org.wildfly.openssl.OpenSSLEngine.getSession(OpenSSLEngine.java:871)
> at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.getSession(ALPNLimitingSSLEngine.java:211)
> at io.undertow.protocols.ssl.SslConduit.getSslSession(SslConduit.java:638)
> at io.undertow.protocols.ssl.UndertowSslConnection.getSslSession(UndertowSslConnection.java:69)
> at io.undertow.protocols.http2.Http2Channel.getSslSession(Http2Channel.java:791)
> at io.undertow.server.protocol.http2.Http2SslSessionInfo.getCipherSuite(Http2SslSessionInfo.java:53)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:122)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2017-10-25 13:28:42,866 ERROR [io.undertow.request] (default task-32) UT005023: Exception handling request to /fluid/javax.faces.resource/layout/layout.css.xhtml: java.lang.IllegalStateException: ssl is null
> at org.wildfly.openssl.SSLImpl.getSessionId0(Native Method)
> at org.wildfly.openssl.SSLImpl.getSessionId(SSLImpl.java:479)
> at org.wildfly.openssl.OpenSSLEngine.getSession(OpenSSLEngine.java:871)
> at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.getSession(ALPNLimitingSSLEngine.java:211)
> at io.undertow.protocols.ssl.SslConduit.getSslSession(SslConduit.java:638)
> at io.undertow.protocols.ssl.UndertowSslConnection.getSslSession(UndertowSslConnection.java:69)
> at io.undertow.protocols.http2.Http2Channel.getSslSession(Http2Channel.java:791)
> at io.undertow.server.protocol.http2.Http2SslSessionInfo.getCipherSuite(Http2SslSessionInfo.java:53)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:122)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2017-10-25 13:28:42,865 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /fluid/javax.faces.resource/fa/font-awesome.css.xhtml: java.lang.IllegalStateException: ssl is null
> at org.wildfly.openssl.SSLImpl.getSessionId0(Native Method)
> at org.wildfly.openssl.SSLImpl.getSessionId(SSLImpl.java:479)
> at org.wildfly.openssl.OpenSSLEngine.getSession(OpenSSLEngine.java:871)
> at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.getSession(ALPNLimitingSSLEngine.java:211)
> at io.undertow.protocols.ssl.SslConduit.getSslSession(SslConduit.java:638)
> at io.undertow.protocols.ssl.UndertowSslConnection.getSslSession(UndertowSslConnection.java:69)
> at io.undertow.protocols.http2.Http2Channel.getSslSession(Http2Channel.java:791)
> at io.undertow.server.protocol.http2.Http2SslSessionInfo.getCipherSuite(Http2SslSessionInfo.java:53)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:122)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (WFLY-9496) WildFly 10.1 Final: Virtual Hosting
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9496?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-9496:
--------------------------------------
Why not just add a second HTTP listener to a different port (say 8081), and only use the external-http redirect on that one (and update the port forward)? That way if you connect to 8080 it will redirect to port 8443, while connecting to 8081 will redirect to 443?
> WildFly 10.1 Final: Virtual Hosting
> ------------------------------------
>
> Key: WFLY-9496
> URL: https://issues.jboss.org/browse/WFLY-9496
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux
> JAVA_HOME: null
> java.version: 1.8.0_151
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.151-b12
> os.name: Linux
> os.version: 4.9.0-3-amd64
> WildFly: 10.1.0.Final
> Reporter: I J
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: new_and_noteworthy
> Attachments: Screenshot from 2017-10-30 19-25-12.png, wireshareNative.gz.pcap, wireshark
>
>
> My configuration:
> ========= standalone-full.xml ===============
> <subsystem xmlns="urn:jboss:domain:undertow:3.1">
> <buffer-cache name="default"/>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
> <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> <host name="host1" alias="domain1.com,www.domain1.com" default-web-module="domain1-war.war"/>
> <host name="host2" alias="domain2.com,www.domain2.com" default-web-module="domain2-war.war"/>
> </server>
> <servlet-container name="default">
> <jsp-config/>
> <websockets/>
> </servlet-container>
> <handlers>
> <file name="welcome-content" path="${jboss.home.dir}/www/welcome-content"/>
> </handlers>
> <filters>
> <response-header name="server-header" header-name="Server" header-value="WildFly/10"/>
> <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
> </filters>
> </subsystem>
> ============ /etc/hosts ============
> 127.0.0.1 localhost host1 host2
> =========== domain1-war/WEB-INF/jboss-web.xml =========
> <jboss-web>
> <virtual-host>host1</virtual-host>
> <context-root>/</context-root>
> </jboss-web>
> =========== domain2-war/WEB-INF/jboss-web.xml =========
> <jboss-web>
> <virtual-host>host2</virtual-host>
> <context-root>/</context-root>
> </jboss-web>
> [EDIT] ============================================
> Wildfly is launched as per: [opt/wildfly/bin] ./standalone.sh -b=0.0.0.0 -c=standalone-full.xml
> Thus socket bindings should not be an issue.
> Notes:
> 1. Server starts and all deploys and works as expected when access as host1:8080, host2:8080, localhost:8080
> Thus my webapps along with the wildfly default ROOT.war (welcome pages) work as expected.
> 2. Router port 80 is forwarded to 8080
> 3. When using the server aliases as defined in standalone-full.xml, in my case domain1.com or domain2.com the server times out and I get nothing.
> 4. I have intercepted the request headers for domain1.com and domain2.com and they are correct.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (WFLY-9496) WildFly 10.1 Final: Virtual Hosting
by I J (JIRA)
[ https://issues.jboss.org/browse/WFLY-9496?page=com.atlassian.jira.plugin.... ]
I J commented on WFLY-9496:
---------------------------
Fantastic Stuart! Thx
The only problem with this is that it forces all requests, both internet and intranet to an external port. Which means I must use a different listener for intranet services.
I suppose this may be a good reason to use the domain configuration methodology along with <socket-bindings port-offset="250"/>?
I tried this with the standalone configs but was unable to add an additional server with the same listeners (and port-offset) -> got a dup services error. The domain configs and underlying code seems to allow this?
By the way I could not find a reference to your solution in the docs or I would not have bothered you. Apologies.
At any rate, thanks for taking the time to help me with this! Will mark closed and hope it helps someone else. :)
> WildFly 10.1 Final: Virtual Hosting
> ------------------------------------
>
> Key: WFLY-9496
> URL: https://issues.jboss.org/browse/WFLY-9496
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux
> JAVA_HOME: null
> java.version: 1.8.0_151
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.151-b12
> os.name: Linux
> os.version: 4.9.0-3-amd64
> WildFly: 10.1.0.Final
> Reporter: I J
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: new_and_noteworthy
> Attachments: Screenshot from 2017-10-30 19-25-12.png, wireshareNative.gz.pcap, wireshark
>
>
> My configuration:
> ========= standalone-full.xml ===============
> <subsystem xmlns="urn:jboss:domain:undertow:3.1">
> <buffer-cache name="default"/>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
> <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> <host name="host1" alias="domain1.com,www.domain1.com" default-web-module="domain1-war.war"/>
> <host name="host2" alias="domain2.com,www.domain2.com" default-web-module="domain2-war.war"/>
> </server>
> <servlet-container name="default">
> <jsp-config/>
> <websockets/>
> </servlet-container>
> <handlers>
> <file name="welcome-content" path="${jboss.home.dir}/www/welcome-content"/>
> </handlers>
> <filters>
> <response-header name="server-header" header-name="Server" header-value="WildFly/10"/>
> <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
> </filters>
> </subsystem>
> ============ /etc/hosts ============
> 127.0.0.1 localhost host1 host2
> =========== domain1-war/WEB-INF/jboss-web.xml =========
> <jboss-web>
> <virtual-host>host1</virtual-host>
> <context-root>/</context-root>
> </jboss-web>
> =========== domain2-war/WEB-INF/jboss-web.xml =========
> <jboss-web>
> <virtual-host>host2</virtual-host>
> <context-root>/</context-root>
> </jboss-web>
> [EDIT] ============================================
> Wildfly is launched as per: [opt/wildfly/bin] ./standalone.sh -b=0.0.0.0 -c=standalone-full.xml
> Thus socket bindings should not be an issue.
> Notes:
> 1. Server starts and all deploys and works as expected when access as host1:8080, host2:8080, localhost:8080
> Thus my webapps along with the wildfly default ROOT.war (welcome pages) work as expected.
> 2. Router port 80 is forwarded to 8080
> 3. When using the server aliases as defined in standalone-full.xml, in my case domain1.com or domain2.com the server times out and I get nothing.
> 4. I have intercepted the request headers for domain1.com and domain2.com and they are correct.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (WFLY-9496) WildFly 10.1 Final: Virtual Hosting
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9496?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-9496:
--------------------------------------
It is because when the app attempts to redirect to SSL it thinks the correct port is 8443, it does not know about the router and its port forward.
You need to add:
<socket-binding name="external-https" port="443"/>
Then change the HTTP listener:
<http-listener name="default" socket-binding="http" redirect-socket="external-https" enable-http2="true"/>
That way it knows to redirect to 443 instead of 8443
> WildFly 10.1 Final: Virtual Hosting
> ------------------------------------
>
> Key: WFLY-9496
> URL: https://issues.jboss.org/browse/WFLY-9496
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux
> JAVA_HOME: null
> java.version: 1.8.0_151
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.151-b12
> os.name: Linux
> os.version: 4.9.0-3-amd64
> WildFly: 10.1.0.Final
> Reporter: I J
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: new_and_noteworthy
> Attachments: Screenshot from 2017-10-30 19-25-12.png, wireshareNative.gz.pcap, wireshark
>
>
> My configuration:
> ========= standalone-full.xml ===============
> <subsystem xmlns="urn:jboss:domain:undertow:3.1">
> <buffer-cache name="default"/>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
> <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> <host name="host1" alias="domain1.com,www.domain1.com" default-web-module="domain1-war.war"/>
> <host name="host2" alias="domain2.com,www.domain2.com" default-web-module="domain2-war.war"/>
> </server>
> <servlet-container name="default">
> <jsp-config/>
> <websockets/>
> </servlet-container>
> <handlers>
> <file name="welcome-content" path="${jboss.home.dir}/www/welcome-content"/>
> </handlers>
> <filters>
> <response-header name="server-header" header-name="Server" header-value="WildFly/10"/>
> <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
> </filters>
> </subsystem>
> ============ /etc/hosts ============
> 127.0.0.1 localhost host1 host2
> =========== domain1-war/WEB-INF/jboss-web.xml =========
> <jboss-web>
> <virtual-host>host1</virtual-host>
> <context-root>/</context-root>
> </jboss-web>
> =========== domain2-war/WEB-INF/jboss-web.xml =========
> <jboss-web>
> <virtual-host>host2</virtual-host>
> <context-root>/</context-root>
> </jboss-web>
> [EDIT] ============================================
> Wildfly is launched as per: [opt/wildfly/bin] ./standalone.sh -b=0.0.0.0 -c=standalone-full.xml
> Thus socket bindings should not be an issue.
> Notes:
> 1. Server starts and all deploys and works as expected when access as host1:8080, host2:8080, localhost:8080
> Thus my webapps along with the wildfly default ROOT.war (welcome pages) work as expected.
> 2. Router port 80 is forwarded to 8080
> 3. When using the server aliases as defined in standalone-full.xml, in my case domain1.com or domain2.com the server times out and I get nothing.
> 4. I have intercepted the request headers for domain1.com and domain2.com and they are correct.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (WFLY-9451) Remove writeContentMethod from AppClientXml
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9451?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-9451:
-----------------------------------
Description: Once WFCORE-3362 is done, the base class for AppClientXml will no longer require subclasses to implement XMLElementWriter<ModelMarshallingContext>. So AppClientXml should drop its no-op implementation. (was: Once WFORE-3309 is done, the base class for AppClientXml will no longer require subclasses to implement XMLElementWriter<ModelMarshallingContext>. So AppClientXml should drop its no-op implementation.)
> Remove writeContentMethod from AppClientXml
> -------------------------------------------
>
> Key: WFLY-9451
> URL: https://issues.jboss.org/browse/WFLY-9451
> Project: WildFly
> Issue Type: Task
> Components: Application Client
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> Once WFCORE-3362 is done, the base class for AppClientXml will no longer require subclasses to implement XMLElementWriter<ModelMarshallingContext>. So AppClientXml should drop its no-op implementation.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months