WildFly context forwarding - jboss

Default installation of WildFly has only root context specified - for welcome pages
<subsystem xmlns="urn:jboss:domain:undertow:1.2" instance-id="main">
<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>
<servlet-container name="default">
<jsp-config/>
<websockets/>
</servlet-container>
<handlers>
<file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
</handlers>
<filters>
<response-header name="server-header" header-name="Server" header-value="WildFly/8"/>
<response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
</filters>
</subsystem>
I have web app available on /webapp and I'd like it to be available from root.
I'm ok with forwarding so I've set it in welcome content so far.
<META HTTP-EQUIV="Refresh" CONTENT="0; URL=/webapp/"/>
I'm not ok with having web app moved from it's context (e.g. directly to root). Also I'd like to avoid referencing app via file system as it is done now.
It should be possible to replace default file handler to have direct forwarding. Is there ~url handler? Maybe it is possible to specify relative address on location or something else? I'm having troubles finding reference docs for these things.
Edit: you see disturbing stuff after you get it posted

1.If you have EAR, you need to just set context-root for web module to "/" in your application.xml.
<module>
<web>
<web-uri>webapp.war</web-uri>
<context-root>/</context-root>
</web>
</module>
2.If you have WAR, you need to add jboss-web.xml next to web.xml with content:
<jboss-web>
<context-root>/</context-root>
</jboss-web>
(EDIT)3.You can set default-web-module attribute for default-host
<subsystem xmlns="urn:jboss:domain:undertow:1.1">
<server name="default-server" default-host="webapp">
<host name="default-host" alias="localhost" default-web-module="webapp.war">
</host>
</server>
</subsystem>

If you want to keep the context you've got two ways that I know of. You could deploy a ROOT.war with just a single page that forwards. It doesn't have to be called ROOT.war, but that's the default for the /subsystem=undertow/server=default-server/host=default-host. You can change the default-web-module attribute to whatever though.
The other option which might be wrong, but works is to change the $JBOSS_HOME/welcome-content/index.html page. The first approach is probably safer since it should make upgrading easier.

Related

Blazor - how to use brotli compression

Blazor WASM supports gzip/brotli compression. Official documentation shows example web.config
however this web.config is not using hosted model.
If I merge example web.config with root web.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\app.Server.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
</system.webServer>
</location>
</configuration>
Javascript files, css, images becomes unreachable. I also tried put example web.config into wwwroot/_framework folder, however no change at all.

WAR not accessible after deploy second

My Wildfly development environment was set up ok and working. I was able to access my application using https://127.0.0.1:8443 and life was good.
I then deployed a second WAR file for a second application and then my first application became unreachable (either through https://127.0.0.1:8443 or via https://127.0.0.1:8443/WARNAME). The second (new) WAR was accessible via https://127.0.0.1:8443/WARNAME2.
I tried numerous things to get the first WAR to be reachable again (mentioned below to keep this post cleaner) and ultimately decided to back everything out to try and get back to square one to try again - I reset my standalone.xml, web.xml and jboss-web.xml and deleted all the WARs out of the deployment directory, in Eclipse I did a maven->update project, redeployed and no luck. After trial and error, if I delete the jboss-web.xml file, update project and redeploy (using mvn clean package -Dmaven.test.skip=true), I can now access the original app using https://127.0.0.1:8443/WARNAME, but now all my rest calls expect the WAR before the rest name.
Are there other files that Wildfly generates that may not be being cleaned? I googled this and found some temp files to delete for jboss 5 (I am on wildfly 9.0.1.final). I am certain that removing the jboss-web.xml file is not the right answer, but I've spun my wheels for a couple days on this.
Here's some additional information if it helps:
The jboss-web.xml in my original WAR:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.jboss.com/xml/ns/javaee
http://www.jboss.org/j2ee/schema/jboss-web_5_1.xsd">
<context-root>/</context-root>
</jboss-web>
web.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
<display-name>hatteras</display-name>
<session-config>
<session-timeout>30</session-timeout>
</session-config>
<mime-mapping>
<extension>ico</extension>
<mime-type>image/x-icon</mime-type>
</mime-mapping>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
<error-page>
<error-code>404</error-code>
<location>/errors/404.html</location>
</error-page>
<error-page>
<error-code>503</error-code>
<location>/errors/503.html</location>
</error-page>
<security-constraint>
<web-resource-collection>
<web-resource-name>WARNAME</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
</web-app>
Snippet from standalone.xml (after I backed out the second deploy.... diff confirms this is how it looked a month ago before I did this experiment):
<subsystem xmlns="urn:jboss:domain:undertow:2.0">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" socket-binding="http" redirect-socket="https"/>
<https-listener name="default-ssl" socket-binding="https" security-realm="SslRealm"/>
<host name="default-host" alias="localhost">
<location name="/" handler="welcome-content"/>
<location name="/reports/" handler="ifsreports"/>
<filter-ref name="server-header"/>
<filter-ref name="x-powered-by-header"/>
</host>
</server>
(.....)
Other things I have tried:
Adding a default-web-module tag to the default host name entry shown above
Removed the <location name="/" handler="welcome-content"/> handler

Deploy Java EE application as root context on WildFly

I'm using Eclipse Mars IDE + JBoss AS (WildFly 9.0.1). Then I launch the server and all is OK. I would like to know how to set an applicatioin as root context?.
To run my application I have to do:
http://localhost:8080/demoApp, but I wanna just do: http://localhost:8080/
Below you have a fragment of the code of the file: standalone.xml.
I modified it as you can see below but I get: 403 - Forbidden when going to: http://localhost:8080/. Remember that the WildFly server is launched with the Eclipse debugger because I'm on development mode.
...
<subsystem xmlns="urn:jboss:domain:undertow:2.0">
<buffer-cache name="default" />
<server name="default-server">
<http-listener name="default" socket-binding="http"
redirect-socket="https" />
<host name="default-host" alias="localhost">
<location name="/" handler="demoApp" />
<filter-ref name="server-header" />
<filter-ref name="x-powered-by-header" />
</host>
</server>
<servlet-container name="default">
<jsp-config />
<websockets />
</servlet-container>
<handlers>
<file name="welcome-content" path="${jboss.home.dir}/welcome-content" />
<file name="demoApp" path="${jboss.home.dir}/standalone/deployments/demoApp.war" />
</handlers>
...
a better option would be adding
<context-root>/</context-root>
into jboss-web.xml
Just deploy as ROOT.war and disable the default root web app in standalone.xml, the logger tells you the name of the config attribute to change

Disable Jboss wildlfy welcome content

I am running wildfly using domain.sh and am unable to disable the Wildfly welcome content even after deploying a ROOT.war with joss-web.xml having
context-root / context-root
In domain/configuration/domain.xml:
Remove <location name="/" handler="welcome-content"/>
Remove
<handlers>
<file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
</handlers>
I disabled welcome-root and welcome-content in wildfly for web application by removing the following sections in the ..\standalone\configuration\standalone.xml file:
remove location
<location name="/" handler="welcome-content"/>
remove handler
<handlers>
<file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
</handlers>

Override logging in WildFly

I used tomcat and simply override default logging system. How to enable logging with logback on wildfly in my spring app?
My Logback.xml owrking on tomcat
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<filter class="ch.qos.logback.classic.filter.LevelFilter">
<level>ERROR</level>
<onMatch>ACCEPT</onMatch>
<onMismatch>DENY</onMismatch>
</filter>
<encoder>
<pattern>%-4relative [%thread] %-5level %logger{35} - %msg %n</pattern>
</encoder>
</appender>
<logger name="org.springframework" level="WARN" />
<logger name="com.citronium.planstery" level="INFO" />
<logger name="org.apache.http.impl.conn.tsccm" level="ERROR" />
<root level="INFO">
<appender-ref ref="STDOUT" />
</root>
</configuration>
You can use logback to configure logging in your application. You can't use logback to configure logging for the server.
To use logback in your configuration you'll need to change the add-logging-api-dependencies to false or create a jboss-deployment-structure.xml that excludes the subsystem. You'll also need to include logback and slf4j in your deployment.
The first option of changing the add-logging-api-dependencies is a global setting for all deployments. The follow CLI command will change the value:
/subsystem=logging:write-attribute(name=add-logging-api-dependencies,value=false)
This option simply doesn't add any of the implicit logging dependencies to your deployment.
The second option of using a jboss-deployment-structure.xml will disable the logging subsystem for your deployment only. The following is an example file:
<jboss-deployment-structure>
<deployment>
<!-- exclude-subsystem prevents a subsystems deployment unit processors running on a deployment -->
<!-- which gives basically the same effect as removing the subsystem, but it only affects single deployment -->
<exclude-subsystems>
<subsystem name="logging" />
</exclude-subsystems>
</deployment>
</jboss-deployment-structure>
Here is how we do this, by the way, we are using wildfly-8.1.0-Final.
First, make a jar file containing this class:
https://gist.github.com/xiaodong-xie/219491e0b433f8bd451e
Then put this jar file into "wildfly-8.1.0.Final/modules/system/layers/base/org/jboss/logmanager/main", and add a reference to this jar file in the module.xml file in the exact same folder.
Then put "logback-classic-1.1.2.jar" and "logback-core-1.1.2.jar" (You can use any version of logback you choose) into "wildfly-8.1.0.Final/modules/system/layers/base/org/jboss/logmanager/main", and reference those 2 jar files in the module.xml file.
Add the following to the "subsystem:logging" in the standalone.xml you are using:
<custom-handler name="logback" class="org.slf4j.bridge.SLF4JBridgeHandler" module="org.jboss.logmanager"></custom-handler>
And reference this handler in the root-logger element following:
<root-logger>
<level name="INFO"/>
<handlers>
<handler name="CONSOLE"/>
<handler name="logback"/>
</handlers>
</root-logger>
Here is an example of logback.xml:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator"/>
<appender name="LOGFILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${JBOSS_HOME}/standalone/log/server-logback.log</file>
<append>true</append>
</appender>
<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">
<appender-ref ref="LOGFILE"/>
</appender>
<root level="INFO">
<appender-ref ref="ASYNC"/>
</root>
</configuration>
And put this logback.xml file into "wildfly-8.1.0.Final/standalone/configuration" folder.
Add the following to the "standalone.sh" or equivalent in the "wildfly-8.1.0.Final/bin" folder.
-Dlogback.configurationFile=file:$JBOSS_CONFIG_DIR/logback.xml
Just under "-Dlogging.configuration=file:$JBOSS_CONFIG_DIR/logging.properties" line. There are 2 places in "standalone.sh" file.
=================================================================================
Or you can do it in a simpler way. :)
Put the 2 logback jar files to the "jboss.logmanager" module, and add "-Dorg.jboss.logging.provider=slf4j" to the "standalone.sh" file, the same position.
I found there are some logging missing if going this by the way, since Wildfly itself still using its own logging facility if going this way.
Have fun. :-)