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.
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.
Let's say I have:
foo.war
bar.war
Is it possible that I deploy them both somehow to the same deployment path? E.g., to access it at:
http://localhost/baz
Are the content of the war files merged somehow? How are file conflicts handled (e.g., let's say both of them has an index.jsp file)?
Thx in advnace!
The servlet specification explicitly forbids this. Deployed web applications may not have identical or overlapping context roots. From the Servlet 3.0 specification, section 10.5:
Since the context path of an application determines the URL namespace of the contents of the Web application, Web containers must reject Web applications defining a context path that could cause potential conflicts in this URL namespace. This may occur, for example, by attempting to deploy a second Web application with the same context path.
Yes & no.
I don't think it's possible to somehow merge them into the same file system path within a servlet container like Tomcat (unless you were to write some kind of complicated, intelligent script to do so). For starters, each .war will have a WEB-INF/web.xml file, and each will rely on the contents of its own file to function -- which would win?
But you conceivably could...
Deploy to 2 different contexts (or containers, or hosts), and employ some kind of load balancer (hardware or software) to route some requests to one, other requests to the other.
Use an "overlay" strategy (such as Maven Overlays) to make a second (and final) .war that is a derivative and extension of another .war file
Is there a way of deploying a tomcat webapp with different web.xml (different name and context)?.
The problem:
I have a web.xml which i constantly have to modify (comment out and uncomment) stuff as i develop things - and this makes it a little annoying. Want i want to have is lets say two files:
web.xml
web-dev.xml
And I want my tomcat on my local machine to use web-dev.xml. Ofcouse for production release (i.e. Hosted server Tomcat will be using normal web.xml - web-dev.xml won't even be published). Its just for the development.
Any ideas where i can specify within tomcat to use web-dev.xml instead of web.xml ?
Thanks
Similarly to #HumbertoPinheiro, I think Maven profiles are a way to go.
Alternatively, this seems like a possible solution (Reference link : Specify a custom web.xml to an embedded tomcat):
Context webContext = tomcat.addWebapp("/yourContextPath", "/web/app/docroot/");
webContext.getServletContext().setAttribute(Globals.ALT_DD_ATTR, "/path/to/custom/web.xml");
Tested on Tomcat 7.0.42.
I am not clear on the following:
If we have a web application named: SomeWebApp under Tomcat's webapp directory, the url to access it is:
http://localhost:8080/SomeWebApp
My question is, is it possible to configure Tomcat so that other URLs would point to that web application?
E.g.
http://localhost:8080/ADifferentApp will also point to the SomeWebApp?
From the web.xml I think is not possible since it is about the url patterns when you are inside the SomeWebApp scope.
So what is the proper way to do it? If it is possible that is.
The approach I found to work best is to install Apache2 on the server and proxy all requests. Tomcat is surprisingly difficult to configure in other ways than intended. In my experience, Tomcat doesn't provide this functionality declaratively.
I'd rather recommend Nginx than Apache as proxy. I'm recently working on a project that incorporates tomcat and nginx works as proxy.
Once you've got nginx you can acctualy map as many url's to access the same web application as you want.
Yes,its possible to map different context path to single application edit conf/server.xml file
> **> <Context docBase="D:\Servers\apache-tomcat-7\webapps\SomeWebApp"
> > path="/SomeWebApp" />
> > <Context docBase="D:\Servers\apache-tomcat-7\webapps\SomeWebApp" path="/ADifferentApp "/>**
Access application with 2 URL's
I am developing a small web application application. The objective is to create one welcome index.html page with Ajax + one servlet to handle ajax requests.
Although I thought I would be fine with a web.xml only, I don't want to deploy to /, but to /MyApp. NetBeans's project properties offers options to set a context path, which helps me deploying to /MyApp. However, it automatically adds a /META-INF/context.xml file, which is a bit confusing.
My questions are:
1) Do I really need a context.xml file do deploy to /MyApp instead of /?
2) If answer to 1) is no, how to accomplish the same with web.xml only?
3) What is exactly context.xml to web.xml?
/META-INF/context.xml is a Tomcat-specific config file. It's used to configure how your app is deployed to Tomcat, including, among other things, the context path at which it exists. Other containers have similar files that can be included in a WAR for container configuration. To answer your questions:
No. The embedded context.xml is only one way to set the context path, and as I indicated, it'll only work in Tomcat. In Tomcat, default behavior is to deploy webapps to a context that has the name of the war file, without the ".war" extension.
You can't set a context path in web.xml. That's your application's deployment descriptor. It configures your application, and the context path is external to your app. It belongs to the server/container you're deploying the app to. Configuring a context path is always done in the container's configuration.
If by "config.xml", you meant "context.xml", then I think I've already answered that. If not, clarify your question.