Im working on a Tomcat application. I just updated from Tomcat 7 to Tomcat 8 using the migration guide.
After I did this, I recognized that the context path of the applications deployed on the server behaves different now.
I am requesting the context path in a jsp. deployed in the ROOT directory using:
application.getContext("app").getContextPath()
The result is the context path of the application: /app
The context path is always the same, if the application is running or stopped.
After upgrading to Tomcat 8.0.33 the behavior is different.
When the application is stopped, the context path that I get is an empty path (which results in pointing to ROOT).
The context path of the runnnig application is still the same: /app
I studied the migration guide and change log but I did not find any change which explains the different behavior.
I also googles a lot and have no clue what explains this behavior.
Can anybody help me finding out what the problem is?
I think I did not clear enough explain what I am doing. I do not want the current context path of the application.
On the Tomcat are various numbers of applications deployed (let the names be /app1, /app2, ..., /app10). Inside the jsp, deployed in ROOT, I want the to find out which applications are actually deployed on the server. I am doing this by asking for the ServletContext of the other applications:
application.getContext( "/app1);
application.getContext( "/app2);
...
When I then asking for the context path of the application it is either empty (application is not deployed) or I get the actual path (e.g. /app1) for a deployed application (started or stopped):
application.getContext("/appX").getContextPath()
Thats how I create a list of deployed applications.
But now on Tomcat 8 I get an empty context path not only for applications which are not deployed, but also for applications which are deployed but stopped. This is a different behavior as it was on Tomcat 7.
I hope I could make clearer now what´s my problem.
Unfortunately I could not find out what´s the issue. Instead I rewrote my code to use the tomcat manager endpoints.
Related
There's a web application and a number of environments in which it works. In each environment it has different settings like DB connection and SOAP ends-points that in their turn are defined in properties-files and accessed in the following way:
config.load(AppProp.class.getClassLoader().getResourceAsStream(
PROPERTIES_FILE_PATH + PROPERTIES_FILE_NAME));
Thus the WAR-files are different for every environment.
What we need is to build a unified WAR-file that doesn't contain any configuration and works in any environment (for now, Tomcat instance) getting its configuration from outside its WAR-file.
The answer Java Web Application Configuration Patterns, to my mind, gives the full set of common approaches but with just few examples. The most attractive way is configuring JNDI lookup mechanism. As I can guess it allows to separately configure web-applications by their context paths. But couldn't find a simple (step-by-step) instructions in both the Internet and the Tomcat's docs. Unfortunately cannot spend much time on studying this complicated stuff in order to just meet so seemingly simple and natural demand :(
Would appreciate your links at the relevant descriptions or any alternative suggestion on the problem.
If its a case of simply deploying your WAR on different environment (executed by different OS user), then you can put all your config files in the user's home folder and load them as:
config.load(new FileInputStream(System.getProperty("user.home") + PROPERTIES_FILE_NAME));
This gives you the isolation and security and makes your WAR completely portable. Ideally though, you should still provide built-in default configuration if that makes sense in your case.
The approach we've taken is based on our existing deployment method, namely to put the WAR files in the filesystem next to the Tomcat, and deploy a context.xml pointing to the WAR file to Tomcat.
The context descriptor allows for providing init parameters which is easily accessible in a servlet. We've also done some work on making this work with CDI (for Glassfish and TomEE dependency injection).
If you only have a single WAR file deployed to this Tomcat instance, you can also add init parameters to the default global context XML. These will be global and you can then deploy the WAR file directly. This is very useful during development.
How can I configure jetty to deploy only one specific web application, and disable hot deployment (disable monitoring webapps directory, disable checking this single application for changes) ?
I would use the context provider only, and just disable the webapp provider. Then you have no scanning of the webapps directory, just a context file that points to your webapp.
edit the start.ini file and make sure you have the jetty-deploy.xml and jetty-contexts.xml files active, and comment out the jetty-webapps.xml line. Then you just need a file in the contexts directory that points to your webapp.
more on the context provider here:
http://wiki.eclipse.org/Jetty/Feature/ContextDeployer
If i get your question right then it means you want to to embed jetty in your application as compared to deploy your web application in jetty.
If that is the case the read this: http://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty else tell me exactly what you are stuck with.
I have a requirement that I need to use a single server machine to run 2 totally different applications.
The server machine has Apache Tomcat 6.0 installed. 1 of the applications is deployed on it and is running successfully for a long time. Initially, the clients used to connect to it by invoking the url "http://machine-name/1stProjectName/initialPage". I have also mentioned the "initialPage" as the Welcome Page in web.xml of this project. But somehow, later some ports or relating things were changed by the server maintenance team, and to connect to the application, now one has to use the url "http://machine-name" or "http://machine-name/initialPage", i.e. the machine name has started behaving like the project name folder because now if I invoke the url "http://machine-name/1stProjectName/initialPage", it gives 404 error saying that "/1stProjectName/1stProjectName/initialPage" resource not available.
Now, when I deploy the WAR of the second application into the webapps folder of Tomcat (just like I did for the first application), it unpacks it properly. But, the issue is how do I connect to this second project. If I use "http://machine-name", it takes me to the 1st application and if I use "http://machine-name/2ndProjectName/initialPage", it gives me an error that "/1stProjectName/2ndProjectName/initialPage" not available.
Kindly help or guide me in some direction.
Thanks in advance.
Your URLs should look like this if you did things properly:
Project 1: http://host:port/war-name-1
Project 2: http://host:port/war-name-2
That means no changes to content.xml to modify the path.
I would talk to your "server maintenance team" and let them know what you are trying to do (since they are the ones who made these changes in the first place). But it sounds to me that they just mapped a path to a specific location, that is your machine-name root is mapped to 1stProjectName.
I have a web application project which is deployed in tomcat 6.
I can access my application using the url:
http://localhost:8082/MyApplication
I also wan't to be able to access this application by another url like:
http://localhost:8082/myapp
Is this possible ? if yes what alternatives do i have ?
Off course, I don't want to change the original name of the application('MyApplication').
Thanks,
Abhishek.
If you add the Context within server.xml it will work as you want. Give the path attribute you wish.
<Context docBase="MyApplication" path="/myapp" />
Though it works, this approach is not recommended by the Tomcat docs, since any changes to server.xml means restarting the server disturbing all the web apps.
But, on the flip side, the practice of keeping this in Catalina_Home/conf/Catalina/localhost/context.xml (which is recommended by the docs) has some unreliabilities as others have reported - when you redeploy the war you can lose the context.xml too
See Why-does-tomcat-replace-context-xml-on-redeploy and
Why does tomcat like deleting my context.xml file?
Is there anyway of configuring tomcat to point more than one context at a webapp?
I need to point these two urls:
http://server.com/abc
http://server.com/def
to a webapp running under the context abc.
Tomcat does not allow direct configuring of multiple <Context> elements to point to the same path.
So your options are either deploying the same web app twice with different Context (Not great idea)
or create a webapp called def that has one custom servlet filter declared in the web.xml that re-writes all requests to abc.
If your requirement is for a production app, I would recommend having an Apache Web Server before the tomcat so that you can do this and more.