I am writing and small app using Java EE. I am using Apache Tomcat v 7 and Eclipse as IDE. When I Run the project (Run on server) I get :
http://127.0.0.1:8080/java-web/lis
(That's fine)
But I don't know If there is some way to rewrite the [java-web] dir just to get :
http://my-local-app.dev/list
I suppose there is some way like in Apache Server using confing files and enabling
the mod_rewrite.
I'll apreciate your help. Thanks
In short: All of the pieces you want to change are components of your deployment environment. Unless you have a specific need to override them, it's usually easiest during development to use the URLs that are a little less pretty.
If you do want to alter them, you need to familiarize yourself with what the various parts of an HTTP URL mean. What you have in your test environment is this:
http:// 127.0.0.1:8080/java-web/list
protocol host port path
You could insert an entry into your hosts file listing my-local-app.dev at 127.0.0.1, but that would not change the port or the path.
The port is determined when Tomcat starts up and is 8080 by default. The general port for HTTP is 80, but specific permission is required to bind to ports below 1024. On Linux, the authbind package makes this pretty easy; on Windows, the necessary steps will depend on your version and configuration (e.g., if you have a Group Policy).
In Tomcat, Web applications are prefixed with their names in the path; it looks like your (hypothetical?) application is named java-web.war. You can install an application as the "root application", but this requires a little bit more configuration and is generally skipped in development.
All of this can indeed also be done using something like mod_rewrite, but that seems like overkill to have slightly prettier URLs for your dev machine.
If you want your application to respond to the my-local-app.dev, you need to purchase the "my-local-app.dev" domain and get a Java web hotel running on it.
If your web application is named "java-web" and you do not want the URL to reflect that, you need to tell Tomcat that you want your application deployed at the ROOT location where the name of the web application is not present in the URL. This is typically done in the deployment stage but unfortunately there is no standard location to say this for WAR files so this is vendor dependent. For example does Glassfish use an extra XML file in your deployment.
I believe Tomcat supports this for ROOT.war files. If not, you probably needs to set the META-INF/context.xml file. See https://tomcat.apache.org/tomcat-7.0-doc/config/context.html for details on what to put in this file - especially the context path.
Related
I have a large collection of different independent (stateless) web services written in Java and compiled as WAR files. I want to deploy them to a single web application server.
If the URIs handled by the services in each WAR file began with a prefix I could use as a web app name, then this would be easy. I could, for instance, have
SALES WAR FILE: contains code for the following:
GET http://example.com/sales/widgets
POST http://example.com/sales/widgets
GET http://example.com/sales/sky-hooks
MARKETING WAR FILE: contains code for the following:
GET http://example.com/marketing/widgets
PUT http://example.com/marketing/sky-hooks
...in which case I would simply deploy two WAR files under the names "sales" and "marketing". However, I am not that fortunate. Instead, the URI paths handled by the components overlap. Something like this:
SALES WAR FILE: contains code for the following:
GET http://example.com/widgets/sales
POST http://example.com/widgets/sales
GET http://example.com/sky-hooks/sales
MARKETING WAR FILE: contains code for the following:
GET http://example.com/widgets/marketing
PUT http://example.com/sky-hooks/marketing
My question is how (if at all) I can deploy these on a single web application server.
I am open to suggestions that require a significant amount of work. For instance, my best-so-far idea is to build services that expect a component-name prefix before the regular URI path, then pipe all incoming traffic through a different server that knows what component each URI pattern falls into and modifies the URI to add that prefix. The difficulty with this approach is that tools like Swagger that read my source code will have a mistaken idea of what the URIs look like.
Any ideas?
If you're willing to put apache in front of your web container, you can use apache's mod_proxy to forward request to the right place.
One way this could work, would be deploy the separate wars at separate prefixes as in your first case (sales and marketing) and then use ProxyPass to send the requests to the correct place:
ProxyPass /widget/sales http://example.com/sales/widget
ProxyPass /sky-hooks/sales http://example.com/sales/sky-hooks
ProxyPass /widget/marketing http://example.com/marketing/widget
ProxyPass /sky-hooks/marketing http://example.com/marketing/sky-hooks
Its probably a better idea to just refactor your routing though - it might be hard to maintain.
(EDIT: I originally suggested mod_rewrite, but I wanted to make my answer more specific, and it looks like this could be done purely with proxying)
If I understand your question correctly, one of the solutions would be (I am assuming Tomcat is used but this should apply to most of the modern servlet containers):
1) Deploy your sales and marketing wars with different prefixes. I.e., using your example, they should be able to serve the following urls:
GET http://example.com/sales/widgets/sales
POST http://example.com/sales/widgets/sales
GET http://example.com/sales/sky-hooks/sales
GET http://example.com/marketing/widgets/marketing
PUT http://example.com/marketing/sky-hooks/marketing
2) Use UrlRewriteFilter to craft lightweight web application that will be deployed to your servlet container root prefix (for Tomcat it is called ROOT.war) and will rewrite urls in incoming requests to point to relevant web application.
In other words, incoming request like:
/widgets/sales
will be transformed to:
/sales/widgets/sales
... and delivered to sales webapp.
Similarly, in response urls like:
/sales/widgets/sales
will be rewritten to:
/widgets/sales
3) Deploy this war to root of your servlet container.
This approach is somewhat similar to the one suggested by #nont but does not require apache as a frontend as the rewriting functionality will be handled by root web application (UrlRewriteFilter basically implements mod_rewrite functionality).
In other words you'll be able to deploy all your applications (including this rewrite application that is deployed to the root prefix) to single server alleviating need for extra intermediate proxy/rewrite servers.
First, Determine How the Deployments may be Configured
Are you sure the absolute URIs must overlap? The context root will prefix the path supported by each service, unless the absolute path has somehow been coded into the application itself. The first step is to enable direct access to each WAR file, either through unique context roots or application instances.
Option 1: Set the Context Root for each WAR File Explicitly
The context root for a war file is set at deploy time. For some servers, this can be set outside of the web application using an external deployment descriptor. For Tomcat, it may embedded within META-INF/context.xml. See http://tomcat.apache.org/tomcat-7.0-doc/config/context.html for more information.
Option 2: Separate the Context Root Instances using Multiple Containers
Alternatively, deploy each war file to a separate instance of a Java EE servlet container, each running on a different port. This will solve the deployment conflict in the case of a hard-coded absolute path.
Finally, Set up a Virtual Host and Proxy the Requests via Apache and mod_jk
Once the context roots instances have been made uniquely accessible by one of the previous methods, configure an instance of Apache to serve as a reverse-proxy. First, set up a virtual host to handle requests for the externally visible URI. Next, configure mod_jk to route the requests to the correct WAR file deployment. See http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html for more details.
Afterthoughts
The above solution approach is generic for this type of problem and will require some knowledge of Apache and Tomcat configuration, which were chosen as example reverse-proxy and Java EE servlet technologies for its implementation. Additional detail on the deployment constraints would help to determine an optimal solution. In general, identifying the hard constraints on what may be changed versus what may not be changed should guide you quickly to a solution.
The obvious slotuion is to rename the wars, or refactor so that the appropriate mappings are in the correct place.
Anything else is going to be a bit hacky, you can't change the war name, even to soemthing like below :
SALES WAR FILE: contains code for the following:
GET http://example.com/webapp1/widgets/sales
POST http://example.com/webapp1/widgets/sales
GET http://example.com/webapp1/sky-hooks/sales
MARKETING WAR FILE: contains code for the following:
GET http://example.com/webapp2/widgets/marketing
PUT http://example.com/webapp2/sky-hooks/marketing
You could also create another war for routing/filtering, that redirects everything appropriately - but that also relies on altering url somewhat.
This is a use case for Reverse Proxy. If your web server is Apache, as suggested by #nont proxy_mod can be used to create a reverse proxy.
I know that IBM Http Server (IHS) also allows this mod.
I'm trying to deploy my first servlet to my server. There are, of course, many tutorials online. But most of them are very detailed and complicated, and I only need to deploy a few simply servlets to this server.
I found what I think to be the shortest method of deployment: Deployment on Tomcat Startup. I moved my .WAR file (FirstProject.war) into $CATALINA_BASE/webapps folder, but when trying to access it (ServerIP/FirstProject) I get the "The requested resource is not available." error.
Is there anything I forgot in the process of deployment?
I know that deployOnStartup has to be set to true, but I didn't change anything with the server's hosts, so the current host is localhost. I didn't change its settings, so deployOnStartup should be true (It's said that true is the default).
What am I missing?
You are using easiest way but I don't know what you are missing. Here what I would suggest is run your server and access through localhost:8080 then click manage app then enter username and password then you can deploy your war.
If you have any query post command.
Even i used to face this problem while deploying my first web application on Jboss and Apache ..
Even though your code is working properly with all your servlet mappings and paths using in your content files ...some times they kick back in real time environment ..So we have to know the proper deployment folder structure and accordingly we have to change our paths in the code
what i am concluding is check the below lines of code
Examples, assuming root is http://foo.com/site/
Absolute path, no matter where we are on the site
/foo.html
will refer to http://foo.com/site/foo.html
Relative path, assuming the containing link is located in http://foo.com/site/part1/bar.html
../part2/quux.html
will refer to http://foo.com/site/part2/quux.html
or
part2/blue.html
will refer to http://foo.com/site/part1/part2/blue.html
I want to be able to deploy my app using ANT to Tomcat.
I don't want the process to be any different for dev and prod. However the two use different databases i.e. myapp and myapp-dev
How can I make this happen? Can I store a variable in the different tomcat containers and make the application call the name of the database from Tomcat.
Or if what I am asking is ridiculous what is the generally accepted way to achieve deploying to dev and prod with the same process.
The generic way is to put the configuration string in a JNDI entry.
If JNDI is not a possible solution, then a property file in the right location (so it shows up in the classpath of the WAR files) is also useful, but needs careful documentation.
Have you considered letting the web container manage the database connection pool, so you only need a single one pr container, which then can be retrieved through JNDI?
I have following situation of deployment:
application_one.war
application_two.war
application_three.war
When I deploy it in Jboss, I get three url contexts:
http//myserver/application_one/
http//myserver/application_two/
http//myserver/application_three/
Is it possible to change (prepend) globally an additional path to all deployed webapplication in a single setting, so that my new path would look like this?
http//myserver/globalprefix/application_one/
http//myserver/globalprefix/application_two/
http//myserver/globalprefix/application_three/
I do not want to change the war by using jboss-web.xml, but I am looking to do this in a general way on a central position, so even new wars will get this context prepended.
This is slightly off topic, but in a lot of production environments you'd have a web server such as Apache "in front" of your appserver (in this case JBoss), which you would be able to set up with a path (check out mod_rewrite, though don't quote me on that).
I have a set of EJBs and other Java classes which need to be configured differently based on the system environment in which they are deployed: production, test, or lab. The configuration information includes stuff like URLs and database connection information.
We'd like to deploy the same exact product (EAR file) in each environment, and have the code then figure out where it is and what its configuration should be, without having to reach out to each deployment server in each environment to make changes.
What is the best way to configure all these components in a centralized, reliable, easy-to-maintain fashion?
Thanks for your thoughts.
The best, IMHO, is to use JNDI entries.
You may have to recode some parts of your application in order to use theses entries instead of plain vars, but with this setup:
Configuration is server-independant: each vendor provides its own implementation, but spec is a standard.
In a clustered environment, config can be persisted in a cluster-wide JNDI tree (see JBoss)
Configuration can be changed thru webadmin without restarting server.
How database connection pool information is stored / configured depends on the app server vendor. Put other variable stuff in property files on the classpath.
If you are deploying the exact same EAR to three different instances of a certain container than you will have to edit the deployment settings as there is no way that the deployment process could have any idea about which one of your three versions you would like to use at a particular deployment.
Deployment settings should go into JNDI entries as Piere-Yves said above.
If I were you, I would have my deployment-script (Ant?) properly populate the JNDI entries depending upon which environment you are deploying to.