Develop Reference

Servlets in separate WARs - partially sharing their context root

For a web service project, I need to install two API versions of a Java EE web on my web server at
example.com/myservice/v1 and
example.com/myservice/v2
The safest way to separate the different versions seems to be deploying them in different WAR files, one for v1 and one for v2.
I created and deployed two JBoss 6 Java EE 6 Web Profile applications with these entries in jboss-web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<context-root>/test/v1</context-root>
</jboss-web>
and
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<context-root>/test/v2</context-root>
</jboss-web>
Both war files deployed and ran without errors. JBoss did not complain that they use the same root context part /test.
Is this a standard behaviour of a servlet container (specified) or just a JBoss feature and not guaranteed to be portable?

For example, Oracle docs for Glassfish say that A context root must start with a forward slash (/); and end with a string - no restrictions of slash inside the context root.
Another example is JBoss docs where there is an example of two web applications with nested context roots (paragraph 1).
Tomcat also supports nested context paths - see Naming section of Apache Context Configuration doc.
There is no requirement of not having slash inside the context root in the specification also. I think it means that as well as any other feature you may assume that it works on your application server, but the way it is configured may differ, and of course you have to test your application before moving to another container.

Regarding context root JBoss says:
The context root of a web application determines which URLs Tomcat
will delegate to your web application. If your application's context
root is myapp then any request for /myapp or /myapp/* will be handled
by your application unless a more specific context root exists. If a
second web application were assigned the context root myapp/help, a
request for /myapp/help/help.jsp would be handled by the second web
application, not the first.
Two context root that you have defined in jboss-web.xml are i) /test/v1 and ii) /test/v2. These two are entirely different since they specify two different URLs.
So your apprehension that:
JBoss did not complain that they use the same root context part /test.
does not hold good as they are different from one another.

Migrating an Enterprise app from JBoss to WebSphere

I am trying to migrate an enterprise application from JBoss to Websphere 8.5. The application is configured with Spring MVC and tiles. The application is hosted in the server root of the JBoss Server, i.e. to access the application we just type https://localhost/ in the browser.For this reason all the links and association in the applications are currently written as follows:
<link href="/resources/jQuery.js" .../>
...
Home
etc.
But in WebSphere the application needs to be in a context root viz. https://localhost:9443/MigratedApplication.
The problem is that all the links and resources mapped in the application now are inside https://localhost:9443/MigratedApplication/resources but they are still looked for in https://localhost:9443/resources resulting in errors on the application throughout.
Any ways to resolve the issue by configuration in WebSphere?

Unfortunately you have hardcoded paths in your application, so you have 2 choices:
change the context root of the application on WebSphere to / as in JBoss (probably easier one, as doesnt require changes in application)
change all links to relative ones (this should be done in the first place during application development to make it independent of context root)

tomcat disable access to application from root application

I have a domain(say 'maindomain.com') pointing to root application of tomcat, and another domain(say 'addondomain.net') pointing to addondomain application in tomcat.
Both are functioning well.Now I want users to access the addondomain application only from addondomain.net. But it is also accesible from maindomain.com/addondomain url.
How can I prevent this?

Setting fixed context root of a Tapestry app deployed on Glassfish

I was wondering if there is a way to make Tapestry application to always have the exact same context root when deployed on Glassfish server?
For example, I'd like to always access my app as localhost:8080/myApp instead of localhost:8080/myApp-1.01-SNAPSHOT or localhost:8080/myApp-2.01-SNAPSHOT.
I have made a glassfish-web.xml with the following property in there:
<glassfish-web-app>
<context-root>/admin</context-root>
</glassfish-web-app>
but it doesn't do the trick.

Apparently, an oversight was done on my part. If I want Glassfish to use the context root I provided, I have to leave the Context Root field blank when deploying from web admin console.
Everything else is fine, including WEB-INF/glassfish-web.xml file.

How to set context path in Tomcat so one could enter the site without appending the deployed folder name?

I read about this on Tomcat guide here and some SO questions. And I think I'm pretty much doing the same thing. But in some way cannot manage to succeed.
First of all I have to say that my application is deployed on a shared Tomcat server that I have no control over. I just drop my .war file and it gets deployed.
I tried to package my application as ROOT.war but didn't work. The admin told me to package it as whatever the name I want and they would take care of it.
I packaged it as my-application.war and it got deployed but I have to enter http://my-host/my-application to get to the website.
After contacting the admin they told me that they have put a context elemnt in my host in Tomcat config file like:
<Context path="" docBase="path of my-application deployed folder"/>
which was supposed to set my-application as default application for all the requests coming to my-host. But it didn't and whenever I enter http://my-host I get:
HTTP Status 404 - / The requested resource (/) is not available
But again when I enter http://my-host/my-application it all works fine. Any suggestion on what might be wrong is definitely appreciated.
Updates:
I tried to follow the steps described in tomcat documentation on how to make the application default. 3 ways are described and I tried all three ways and could successfully deploy my application as ROOT on localhost.
I also tried to reproduce the problem I'm facing on remote server so I could find the reason and report it to admin. I find couple of problems.
In server.xml fragment that admin sent me autoDeploy and deployOnStartUp are set to true, whereas they should be false if explicitly defining Context element in server.xml. This will cause double deployment which creates a ROOT folder and a folder with the name of the .war file. Deleting the .war will delete it's corresponding folder and undeploys the application but ROOT remains and must be deleted manually and requires a Tomcat restart. Until it's restarted any deployment of ROOT.war will fail.
I figured there are some reasons preventing ROOT.war from deploying. One could be that a ROOT.xml exists in conf/{engine-name}/{host-name} or a ROOT folder exists in appBase of the host or as I described above a ROOT application from previous deployment is not undeployed and requires Tomcat restart.
Either way I couldn't exactly pinpoint what exactly is preventing ROOT.war from deploying since that requires the access to Tomcat log files and conf files to check the cases I described above.
Also from all I see my the admin seems incapable of maintaining a Tomcat server and finding the problem. So I decided to go with a dedicated Tomcat server after struggling with the shared one.

In your question, you state that the admin set the context as:
<Context path="" docBase="path of my-application deployed folder"/>
Based on the comments above, I would suggest trying to use the relative path of your application rather than the absolute path.
I tried this on my tomcat server with:
<Context path="/" docBase="my-application/" />
and that did the trick.
The Host element which contains the Context element does actually set some parameters that might also impact the context. If it's the default settings, then a relative context should simply point to the webapps folder. If it's been changed, the results may vary.

Usually this can be achieved by the following steps:
Define a ROOT.xml context file in conf/Catalina/localhost
Name your webapp WAR “ROOT.war” or containing folder “ROOT”
However, i doubt you will be able to do that on a shared Tomcat instance. Only one application can run as the default application. The hosting company will probably not allow it as otherwise which application will they allow to be the default out of the many people sharing the same Tomcat instance?
See this link : http://staraphd.blogspot.com/2009/10/change-default-root-folder-in-tomcat.html

The Tomcat Wiki has a section on putting applications into default context.
However, in order to do this it implies some control over the Tomcat server that may not be possible in the shared context you describe.
If you have the ability to install other systems on the server, one alternate solution would be to use a proxy server like NGINX. This is way more complicated than simply naming your war file ROOT.war, but sometimes it's the only option.
If you have NGINX listening on the server and you have your own url, you use the HttpProxyModule with setting such as:
server {
listen 80;
server_name my.domain.com;
location / {
proxy_pass http://my-host/my-application;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
}
}
Also in order to make this work, you'd have to own the "my.domain.com" url and it would need to be separate from the one everyone is using for the shared Tomcat server.
The nginx portion of the solution is free, but if you need to register a new url and then use something like no-ip.com to redirect it to the tomcat server it would cost money.