[JBoss JIRA] (WFLY-9496) WildFly 10.1 Final: Virtual Hosting
by I J (JIRA)
I J created WFLY-9496:
-------------------------
Summary: 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
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)
8 years, 6 months
[JBoss JIRA] (WFLY-4001) Virtual host in jboss-web.xml doesn't work
by I J (JIRA)
[ https://issues.jboss.org/browse/WFLY-4001?page=com.atlassian.jira.plugin.... ]
I J commented on WFLY-4001:
---------------------------
Hi T. Cerar,
This does not work correctly in WildFly 10.1 Final:
The following is a post I just created in the forums. Could you please comment?
link: https://developer.jboss.org/message/977501#977501
Hi All,
A little help would be greatly appreciated.
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.
Questions:
1. Why does wildfly not take the alias reference for the local host1 or host2 domain, that being the request host token, and serve up the appropriate webapp?
2. What am I doing incorrectly here? Seems this should be simple to configure?
Thanks You in advance for any and all help!
> Virtual host in jboss-web.xml doesn't work
> ------------------------------------------
>
> Key: WFLY-4001
> URL: https://issues.jboss.org/browse/WFLY-4001
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Affects Versions: 9.0.0.Alpha1
> Reporter: Jim Ma
> Assignee: Tomaz Cerar
> Attachments: host.war
>
>
> Define the following configuration for undertow subsystem and deploy the attached host.war with virtual host "vhost2" metada in jboss-web.xml.
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:undertow:2.0">
> <buffer-cache name="default"/>
> <server name="default-server">
> <http-listener name="default" socket-binding="http"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> <server name="undertow-server2">
> <http-listener name="listener2" socket-binding="http2"/>
> <host name="vhost2" alias="localhost4">
> <location name="/" handler="welcome-content2"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> <servlet-container name="default">
> <jsp-config/>
> </servlet-container>
> <handlers>
> <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
> <file name="welcome-content2" path="${jboss.home.dir}/welcome-content2"/>
> </handlers>
> <filters>
> <response-header name="server-header" header-name="Server" header-value="WildFly/9"/>
> <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
> </filters>
> </subsystem>
> {code}
> Deploy is failed with error message :
> 14:37:27,092 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "host.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => [
> "jboss.undertow.deployment.default-server.vhost2./host is missing [jboss.undertow.server.default-server.vhost2]",
> "jboss.undertow.deployment.default-server.vhost2./host.UndertowDeploymentInfoService is missing [jboss.undertow.server.default-server.vhost2]"
> ]}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (WFLY-9354) Typo in error message WFLYAC0023
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9354?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-9354:
--------------------------------------
Fix Version/s: 12.0.0.Alpha1
Assignee: jaikiran pai (was: Stuart Douglas)
Resolution: Done
> Typo in error message WFLYAC0023
> --------------------------------
>
> Key: WFLY-9354
> URL: https://issues.jboss.org/browse/WFLY-9354
> Project: WildFly
> Issue Type: Bug
> Components: Application Client
> Affects Versions: 11.0.0.CR1
> Reporter: Wolfgang Knauf
> Assignee: jaikiran pai
> Priority: Trivial
> Fix For: 12.0.0.Alpha1
>
>
> When starting a JavaEE application client with invalid ear/jar name, the error message lacks a "not" ("could NOT find application client..."):
> C:\Temp>c:\Temp\wildfly-11.0.0.CR1\bin\appclient.bat some.ear#some.jar
> Calling "c:\Temp\wildfly-11.0.0.CR1\bin\appclient.conf.bat"
> JAVA_HOME is not set. Unexpected results may occur.
> Set JAVA_HOME to the directory of your local JDK to avoid this message.
> 12:35:47,789 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Final
> java.lang.RuntimeException: *WFLYAC0023: Could find application client* C:\Temp\so
> me.ear
> at org.jboss.as.appclient.subsystem.Main.main(Main.java:133)
> at org.jboss.modules.Module.run(Module.java:344)
> at org.jboss.modules.Main.main(Main.java:525)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (WFCORE-3391) Add compatibility tests of the 3.0.x client versions
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3391:
----------------------------------------
Summary: Add compatibility tests of the 3.0.x client versions
Key: WFCORE-3391
URL: https://issues.jboss.org/browse/WFCORE-3391
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Priority: Blocker
ClientCompatibilityUnitTestCase needs tests added for the client used in WF 11.0.0.Final and the closest equivalent for EAP 7.1.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (WFLY-9495) Create mod_cluster Quickstart
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-9495:
------------------------------------
Summary: Create mod_cluster Quickstart
Key: WFLY-9495
URL: https://issues.jboss.org/browse/WFLY-9495
Project: WildFly
Issue Type: Task
Components: mod_cluster, Quickstarts
Affects Versions: 11.0.0.Final
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Fix For: Awaiting Volunteers
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (WFLY-5529) Clustering Quickstarts Tracker
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5529?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5529:
---------------------------------
Component/s: mod_cluster
> Clustering Quickstarts Tracker
> ------------------------------
>
> Key: WFLY-5529
> URL: https://issues.jboss.org/browse/WFLY-5529
> Project: WildFly
> Issue Type: Task
> Components: Clustering, mod_cluster, Quickstarts
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: Awaiting Volunteers
>
>
> Tracker for clustering quickstarts.
> There are bunch of areas that could use a quickstart, see linked issues. Bunch of areas that might be interesting as well with no concrete plans:
> * Cross-site replication
> * remote-cache/remote-cache-container (HotRod client injection)
> * JGroups channel injection (community-only)
> * Infinispan cache injection (community-only)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (LOGMGR-177) Introduce delayed initialization strategy
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-177?page=com.atlassian.jira.plugin... ]
James Perkins reassigned LOGMGR-177:
------------------------------------
Assignee: James Perkins
> Introduce delayed initialization strategy
> -----------------------------------------
>
> Key: LOGMGR-177
> URL: https://issues.jboss.org/browse/LOGMGR-177
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Reporter: David Lloyd
> Assignee: James Perkins
> Priority: Critical
>
> h2. Synopsis
> The logmanager eagerly initializes as soon as logging is first used. In many cases this is undesirable because of circular dependency problems which do not allow the logging configuration to be fully available until other systems are booted for a variety of reasons:
> * WildFly logging configuration is done in a subsystem which is not available at first boot
> * Logging handlers may depend on other systems (which use logging) to initialize (like Elytron for SSL)
> * Java 9+ may make it difficult to initialize logging very early
> So we need a multi-stage initialization process.
> h2. Requirements
> h3. Requirement 1: Performance must not be impacted
> One of the primary reasons for the existence of the log manager is performance. Therefore, performance impact must be as minimal as possible during the initialization process and effectively zero post-initialization.
> h3. Requirement 2: Process in correct order
> Late initialization must allow all log messages to be processed in a correct order. Note that there is more than one possible correct order, however any log message B that was logged observably after log message A must appear in the log after A.
> h3. Requirement 3: No lost messages
> When initialization is complete, all log messages which occurred before initialization must be logged and none lost.
> h3. Requirement 4: No mutations
> Messages recorded during initialization cannot be mutated in any way compared to what would have been logged post-initialization; therefore, any log message produced before initialization is complete must have a full copy of its contextual information (caller and MDC/NDC). Note that this requirement is in natural tension with Requirement 1.
> h3. Requirement 5: Tracing
> Capturing full context on every log record, including those at TRACE level, will certainly impose too severe a performance impact for normal usage. A reasonable optimization would be to choose a "safe" level like "INFO" during the initialization process, thereby requiring full capture of only a small number of log records. However this would in turn make debugging during this early stage quite difficult. So, it must be possible to inform the log manager that boot logging must accept messages of any valid level, including TRACE or ALL. The default should lean towards performance, but it should be easily overridable (say, via a system property).
> h3. Requirement 6: Opt-in
> In most common cases, like unit testing, it is desirable to simply start logging from the properties configuration. So, delayed initialization should be opt-in as it is generally a container or advanced feature, and the application in question likely has to take action in order to complete logging initialization.
> h2. Implementation strategy
> A possible implementation strategy would be to create a layer of indirection, centrally managed through the log manager instance, through which all logging is dispatched. This could be done by way of one of the {{org.jboss.logmanager.Logger#logRaw}} or {{org.jboss.logmanager.LoggerNode#publish}} methods.
> h3. State machine
> The layer of indirection could have multiple stages:
> * Uninitialized:
> ** All log records are enqueued
> ** The root logger level is initialized to the level configured by the initial system property
> * Initializing:
> ** All log records are enqueued
> ** Loggers and handlers are configured by the container or user as they wish
> ** At the end of this stage, an "initializationComplete" method on the log manager is called, causing a transition to...
> * Starting:
> ** All log records are enqueued as long as the queue is not "clear", at which point log records are dispatched normally
> ** At the same time, the queue is played back in order and the log messages are dispatched according to their final configuration
> ** When the queue is empty, it is atomically tagged as "clear", and the state is changed to...
> * Running:
> ** All log records are dispatched normally
> Note that Requirement 3 can only be met if the configured initial log level is finer than the minimum level in the final configuration.
> h3. Safety checks
> The initialization message queue should have a configurable (via system property again) limit. A default of, say, 10,000 messages would not be unreasonable and would allow for fairly fine-grained logging. If the cap of enqueued messages is reached, the error handler should report (one time) that the cap was reached and that some messages were lost, and it should suggest that either the level system prop be made coarser, or the limit should be increased, in order to prevent the situation from occurring.
> h3. No delayed initialization desired
> A system property should be added to determine whether the log manager delays its initialization. Per requirements, it should default to false. If true, then default configuration should not be done at all; it is assumed in this case that the user will perform configuration tasks.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (JGRP-2231) Intermittent NPE in JGroups GMS#up on shutdown
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2231?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated JGRP-2231:
---------------------------------
Fix Version/s: 3.6.15
> Intermittent NPE in JGroups GMS#up on shutdown
> ----------------------------------------------
>
> Key: JGRP-2231
> URL: https://issues.jboss.org/browse/JGRP-2231
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.14, 4.0.8
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 3.6.15, 4.0.9
>
> Attachments: server.log, standalone-ha.xml
>
>
> During mod_cluster failover due application undeploy on Solaris 10 intermittently I can see NPE \[1\].
> I've seen it already several times during failover with HTTPD with mod_cluster as balancer and EAP 7.1 as workers where their communication works over SSL which is configured using elytron on EAP side. I have seen the issue on Solaris 10 sparc (two different slaves).
> \[1\]
> {noformat}
> 2017-10-27 12:12:07,546 ERROR [org.jgroups.protocols.pbcast.GMS] (thread-2) JGRP000027: failed passing message up: java.lang.NullPointerException
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:895)
> at org.jgroups.stack.Protocol.up(Protocol.java:418)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:487)
> at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:989)
> at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:919)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:851)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:611)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:325)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:292)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1657)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1872)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (JGRP-2231) Intermittent NPE in JGroups GMS#up on shutdown
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2231?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2231:
---------------------------
Affects Version/s: 4.0.9
(was: 4.0.8)
> Intermittent NPE in JGroups GMS#up on shutdown
> ----------------------------------------------
>
> Key: JGRP-2231
> URL: https://issues.jboss.org/browse/JGRP-2231
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.14, 4.0.8
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 4.0.9
>
> Attachments: server.log, standalone-ha.xml
>
>
> During mod_cluster failover due application undeploy on Solaris 10 intermittently I can see NPE \[1\].
> I've seen it already several times during failover with HTTPD with mod_cluster as balancer and EAP 7.1 as workers where their communication works over SSL which is configured using elytron on EAP side. I have seen the issue on Solaris 10 sparc (two different slaves).
> \[1\]
> {noformat}
> 2017-10-27 12:12:07,546 ERROR [org.jgroups.protocols.pbcast.GMS] (thread-2) JGRP000027: failed passing message up: java.lang.NullPointerException
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:895)
> at org.jgroups.stack.Protocol.up(Protocol.java:418)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:487)
> at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:989)
> at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:919)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:851)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:611)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:325)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:292)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1657)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1872)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months