I have a RichFaces WAR file that deploys itself to http://mytestserver:8080/mywarapp/index.jsp. I deploy it on the Wildfly Application Server.
Now I would like to access the WAR file not through this long http-address, but through the main server address: http://mytestserver/
How would I have to do that?
You should change context path of your application.
To do this you need to create file jboss-web.xml and place it in WEB-INF directory. jboss-web.xml should contain:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<context-root>/</context-root>
</jboss-web>
If you want to change port of your application from 8080 to 80 you can do this in few ways.
1) [not recommended] change port in your standalone/domain.xml from 8080 to 80 and run wildfly as a root/administrator
2) run nginx/apache or any other webserver and create there proxy redirect eg. in nginx you need to add to your configuration file something like this proxy_pass http://mytestserver:8080/; (if you didn't add jboss-web.xml you need append here mywarapp to this URL ) and your application will be available via URL http://mytestserver/
Related
Excuse me, I'm new to this. I have developed an application with maven, and when I run the application in my wildfly it opens the following path: "127.0.0.1:8080/myapp-1.0.0" and everything runs perfect, but I simply want that:
x.x.x.x/ point to: x.x.x.x:8080/myapp-x.x.x
I do not know if it is a configuration in standalone.xml as it redirects or something more complicated.
If you only have a single web application, the simplest way is to have jboss-web.xml file in your web application. Put a file like:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web version="10.0"
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_10_0.xsd">
<context-root>/</context-root>
</jboss-web>
in your WEB-INF directory. This will make your application run at the / context. Note that this isn't redirection - it's permanently there. Additionally, if you have many webapps running on your Wildfly server they will all need a unique context root.
I tried to deploy a war file on Wildfly (commandline) by changing the name of the old file (say app.war to appOld.war) and copying a new file with the name app.war to the deployment folder.
On my other terminal, I can see the auto deploy scanner running and deploying the new file but when I try to access the app via URL, I get a 404.
No error shows up in the logs so I don't realize what is happening or what to do.
Thanks.
I think there is problem with your context root.
Because if you don’t set context root wildfly takes filename as your context root.
When you deploy file you just renamed try access <hostname>:<port>/appOld instead of <hostname>:<port>/app
Context root can be manually set set in /WEB-INF/jboss-web.xml
Here is the example of jboss-web.xml whit context root:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<context-root>/my-web-app</context-root>
</jboss-web>
So when you set it you should be able to access yout app at: <hostname>:<port>/my-web-app
Hope it helps.
so my question is how can I set up a Tomcat Server to use this configuration file conf/Catalina/localhost/MyApp.xml?
It works like a charm if my application is named like this: MyApp.war so tomcat will extract the archive to MyApp.
But I want to use a name with the version inside like MyApp##1.0-SNAPSHOT.war.
Is it possible to configure the tomcat so it will use the MyApp.xml anyway?
You can set path and docBase attributes of Context element as described in the docs.
Create a directory outside $CATALINA_HOME/webapps and place war files there, let's say /opt/tomcat/wars/. Then set docBaseattribute to the full path to your war. Make user tomcat user has read permissions on that directory. If war is inside webapps directory you could end up with a double deployment depending on deployOnStartup and autoDeploy attributes of Host element.
<Context path="/MyApp" docBase="/opt/tomcat/wars/MyApp##1.0-SNAPSHOT.war">
...
</Context>
You can try also naming the xml the same as the war file.
I have a Java web application using Wicket 6, Spring 3.2 and WildFly 8.2.0. Right now i'm setting the context root of my web application in the jboss-web.xml file like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 5.0//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd">
<jboss-web>
<context-root>/myCustomContextRoot</context-root>
</jboss-web>
The jboss-web.xml file is compiled into the war. Now some clients want to change this context root to an empty context root. So i hace to recompile a version of my app per different context root. Is there a way to set the context root of my application from outside .war, programatically from a .properties file, or any other way for example in standalone.xml of WildFly 8.2.0?
Set the runtime name when deploying your web application. Suppose your WAR is called myapp-1.0.0-SNAPSHOT.war. Using a runtime name of foo.war, the context root will be /foo.
Using a runtime name of ROOT.war, the context root will be /.
The runtime name can be set when deploying via the Web Console or via the CLI.
Thanks for your Answer Harald Wellmann. It answers the question and pointed me into the right direction!
Some things I had to find out on my own and which may help others:
the exact syntax in jboss-cli to specify a runtime-name is:
deploy path_to_war_file --runtime-name=wantedName.war
This leads to a context-root of /wantedName/ for the webapp.
The runtime-name does not have any effect on the context-root, if the war file contains a jboss-web.xml in WEB-INF which in turn contains a context-root tag.
That is, if you want to control the context-root of your web-app in WildFly at deployment time, you must not specify any context-root in jboss-web.xml.
It is ok to have a jboss-web.xml without a context-root tag if you want to take advantage of the runtime-name to control the context-root.
I tested this on WildFly 9.0.1 and 9.0.2:
Hope this helps!
I'm developing a web application, which consists of two independent parts - the authentication and the real application part. Both parts are WARs which are deployed at (currently) one Tomcat 7 instance.
So, I have the following two WARs in my webapps folder:
webapps
|
+- BloggofantAuthentication
|
+- Bloggofant
until now they are available at http://127.0.0.1:8080/BloggofanAuthentication and http://127.0.0.1:8080/Bloggofant. Is it possible proxy the WARs at Tomcat directly (so that I don't have to use Apache httpd and its mod_proxy module)? So that in the end, the WARs at the server are reachable as follows:
http://127.0.0.1:8080/BloggofantAuthentication -->
http://127.0.0.1/bloggo/
http://127.0.0.1:8080/Bloggofant -->
http://127.0.0.1/bloggo/fant/
Any suggestions on this topic are highly appreciated ;)
EDIT
Here are the context.xml files of the two unpacked webapp WAR folders:
webapps/BloggofantAuthentication/META-INF/context.xml
<?xml version="1.0" encoding="UTF-8"?>
<Context path="">
<!-- Comment this to enable session persistence across Tomcat restarts -->
<Manager pathname=""/>
</Context>
webapps/Bloggofant/META-INF/context.xml
<?xml version="1.0" encoding="UTF-8"?>
<Context path="/bloggofant">
<!-- Comment this to enable session persistence across Tomcat restarts -->
<Manager pathname=""/>
</Context>
If I now want to access my apps via http://127.0.0.1:8080 or http://127.0.0.1:8080/bloggofant I get a 404 - Page Not Found error ...
You can configure the path at which Tomcat serves a web application using a context.xml file. You can put this in the WAR's META-INF directory, with the content:
<Context path="/bloggo/fant" />
And it will serve it there instead of at the default /Bloggofant path.
Note the warning about automatic deployment in the documentation:
When autoDeploy or deployOnStartup operations are performed by a Host, the name and context path of the web application are derived from the name(s) of the file(s) that define(s) the web application. Consequently, the context path may not be defined in a META-INF/context.xml embedded in the application
Elsewhere, the documentation tells us that these both default to true. Thus, you will need to set them to false for these settings to be respected.