Deploying war file to Tomcat with a different path - java

If I deploy a war file to Tomcat, called for example foo-bar-1.1.2.war, how can I deploy it so that it is extracted to webapps/bar and its URL root is /bar/...?
My intention here is to keep the war file in the webapps server with its version information so that I know which version is installed but have it overwrite a previous version of the app.
I could deploy the war file using PSI Probe. This would allow me to specify a target context for the web app. However, it means that I would lose any version information in the war file name.

Tomcat will always extract the contents of a war file, to a folder of the same name (when it's configured to deploy wars - as default etc.).
You can extract it to a folder name of your choice. So if you unzip the contents of foo.war to a folder called bar/ manually, instead of just dropping the war into the web apps folder, it'll still load the web application.
However, this is totally unnecessary as you can specify the URL pattern of the application without messing with the folder / war file name at all by overriding the context root element for your application:
This is often set in the Tomcat server.xml - but that practice is fairly widely discouraged. Instead, I'd suggest you use context.xml in the META-INF folder of your web application / war file:
<Context path="/bar" .../>
When the application is deployed, the context.xml should be copied to /conf/Catalina/localhost but renamed to foo.xml
Note that conext roots must be unique and there are some additional considerations if you're using the autoDeploy or deployOnStartup operations (Source http://tomcat.apache.org/tomcat-7.0-doc/config/context.html).
Other options include:
Clean the web apps folder each deployment and drop your new foo-1.1.0 war in.
Include the version number in a flat file. foo/version1
Or simply include the version in a config / XML file.
You could also use Ant (or an equivalent tool) to automate your deployments (and perform any of the above).

There is an important point to emphasize about the path attribute of the context fragment definition. To cite the documentation on the topic:
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.
deployOnStartup is the default behavior of Tomcat hosts.
To follow the documentation, this has a very important consequence:
the context path may not be defined in a META-INF/context.xml
According to the ways of defining a Tomcat context, this lets only two solutions:
In individual files (with a ".xml" extension) in the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory
Inside a Host element in the main conf/server.xml, which is a discouraged solution in a production environment as it requires restarting the server
Another solution takes advantage of the unpackWARs attribute.
In my point of view, for these reasons, the general and easy way to implement a subtle path in a production environment is taking advantage of the naming of war files (what could include versions management and be a solution to your problem). A single sharp (e.g. test#path.war) in the war file names implies a segment in the context path (e.g. /test/path). A double sharp introduces the version number (e.g. test#path##112.war). This works whether or not unpacking war files, hot deployment or not, is deployment agnostic (manager or file system) and manages multiples versions of a same archive.
But if there is the need to have a path distinct from the archive name, it seems the only solution is the descriptor in the /conf/[enginename]/[hostname]/ directory or the server.xml file. For these, you need an access to the server filesystem.
The relevant solution is highly related to the way Tomcat is configured and managed in the everyday.

If you just want to include a version info in your war file name, you can name it like: my-app##1.2.3.war. It gets unpacked to the directory my-app##1.2.3 but the context will be just my-app (i.e. http://host/my-app/).
Works at least with Tomcat 7.0.55

Related

How to use external jars without adding them to the project

Hi In my project I have many many jars.
Every time I change code and need to upload it to the server takes very long time, because I m adding the jars to the war to be deploy on tomcat.
I m trying to put all the jars in the server, in some folder and to upload the rest of the project only, to speed the cycle.
What will be the best way of doing that ?
I m using tomcat 8.5 also for production deployment without any build tool.
I would like to set an ABSOLUTE path in the classpath but when doing that in my local machine it won't work after deployment to the unix server.
I never saw where or if I can set an absolute path for the jars (NOT OF THE LOCAL MACHINE)
Thanks in advance
You can read about this in Tomcat docs: Class Loader HOW-TO.
The most simple case and way - put these commonly used jars into $CATALINA_BASE/lib dir - they will be loaded by Tomcat class loader.
But, it doesn't seems to be very nice practice, as mentioned tutorials claims:
Normally, application classes should NOT be placed here.
Personally me, in practice purposes, I would ignore this hint and still place jars inside this folder. But if you want to be accurate, you could create separate path on server (or even inside CATALINA_BASE folder) and place jars there. After that you have to specify this path in $CATALINA_BASE/conf/catalina.propertiesfile in common.loader property:
common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar"

Tomcat updates context.xml but should not

Tomcat documentation (http://tomcat.apache.org/tomcat-6.0-doc/config/context.html)
Only if a context file does not exist for the application in the
$CATALINA_BASE/conf/[enginename]/[hostname]/, in an individual file at
/META-INF/context.xml inside the application files. If the web
application is packaged as a WAR then /META-INF/context.xml will be
copied to $CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to
match the application's context path. Once this file exists, it will
not be replaced if a new WAR with a newer /META-INF/context.xml is
placed in the host's appBase.
Text in bold is clear. But I notify as not true. (I need exactly this behaviour)
Here are steps:
aaa.war with context.xml included into META-INF
copy to webapps. tomcat deploys. File conf\Catalina\localhost\aaa.xml OK
change aaa.war by changing META-INF/context.xml
copy to webapps
File conf\Catalina\localhost\aaa.xml is changed!!!
What is wrong? Is it a bug or a hidden feature?
Background - the issue I want to resolve:
Configuration independent build and installation. I plant to ship war file. Client per-configures his Tomcat using his own settings. when I ship a new release I just delivery the war without config and when deployed it will use client specific configuration.
By documentation the best place is the context.xml But if it overwritten each time it make no sense to use at all. (why would I use JNDI and such a things if new deliverable has to created? Changing something in build-time is not a big configuration advantage.)
Environment: windows, tomcat 6.0.33
I've run into the same problem and the documentation is at least inadequate, if not directly misleading.
The problem is, that if you copy a new version of an already deployed WAR file to the webapps directory, Tomcat will not redeploy the existing application but undeploy the old application and then deploy the new application. The difference may first seem insignificant, but the problem is that during undeployment of the old application, any context files in conf/Catalina/localhost are deleted as well. Then, the new context file from the current WAR file will be copied to conf/Catalina/localhost during deployment of the new application.
The only feasible solution I've found is not to deploy the new application as a WAR file, but to replace or overwrite the expanded directory, e.g. not to copy aaa.war to webapps/ but to unpack aaa.war directly into webapps/aaa/.

log4j is not working in weblogic server?

I am using weblogic 10.3.4, I am trying to write log with log4j. but at runtime my application is not getting any log4j.properties. even this is not generating any warning as "initialization of log4j has error".
I have tried my properties file to put in src folder, classes folder and then I created one jar and put it in domain lib. still its not picking. even when I am writing log with same jar in standalone application, its working fine.
please help me with valuable suggestions.
I tried the solution proposed at Oracle forums.
Excerpt from that link at Oracle forums:
I've only modified the scritp startWebLogic.cmd:
set LOG4J_CONFIG_FILE=log4j.xml
set SAVE_JAVA_OPTIONS=%JAVA_OPTIONS% -Dlog4j.configuration=%LOG4J_CONFIG_FILE%
#REM set SAVE_CLASSPATH=%CLASSPATH%
set SAVE_CLASSPATH=%CLASSPATH%;C:\Oracle\Middleware\user_projects\domains\domain\config
In this way I've put all the config folder inside the classpath, and I can use it in future to hold other libraries configuration files (for example oracle coherence config).
I tried this approach on a different properties file as well and that worked well!
You need to either specify where the application should find its log4j.properties, or put it onto the classpath of the application. Where the classpath is varies, but in general WEB-INF/classes should work. Other options depend upon how you're deploying the application.
A better long term strategy is to configure your system so that you can change the log4j.properties depending upon the environment. When you're in production, you won't want all of the debug information to appear. Look at the answer to this question or this question for more ideas. One strategy is to define a variable on the command line which gets picked up and defines a directory which contains your configuration files. This works for Tomcat, but there may be other, better, strategies for Weblogic.
It is not a good idea to change the configuration of your server, in particular, don't replace the log4j.jar or log4j.properties in your server directories. The server will depend upon the version that it was designed to use, which may or may not be the same as your version. You can do everything you need to do by changing the war that you're deploying.
I have used this code:
ClassLoader cl = this.getClass().getClassLoader();
URL log4jCfg = cl.getResource(configFile);
if (log4jCfg != null) {
DOMConfigurator.configure(log4jCfg);
}
log.info("log4j is now working on Web App.");
In my case, we used XML configuration:
log4jCfg = "mylog4j.xml";
In WebLogic, we were able to place such file (mylog4j.xml), equivalent to your log4j.properties file, at WebLogic's domain path (specific to the domain were we deploy). This means that domain folder belongs to your application's path. I just tested it with Web applications, I'm not sure if with SOA or EJB projects it works the same way.
When you deploy any application on any server that application should use servers log4j jar.
So if you have added any log4j jar in your application jar/tar/ear, remove it and copy log4j.properties file in the conf folder of the server from where server is picking its configuration files. Or just copy your log4j property content in servers log4j property file.

Installing Solr onto a hosted tomcat server

I have installed and configured tomcat+solr on my personal linux machine and windows as well. I was able to get them working fine. I'm very new to Java and how the file structure works. (i.e. knowing where to put war files and what WEB-INF is) So now that I am ready to install solr and configure it on my clients shared hosting plan, the directions are different from what I did before. I dont want to mess this up and apparently the webserver reboots daily and I dont think I can do it manually which means I have one shot at this every day.
Here is the directions for installing a tomcat servlet on his hosting provider:
http://www.apluskb.com/scripts/Where_do_I_put_my_answer1186.html
As you can see I need to install solr under the html/WEB-INF directory, but read what it says.. its very confusing:
"All Servlets should be uploaded in the /html/WEB-INF/classes directory. Any unpacked custom classes and resources should be uploaded in the /html/WEB-INF/classes directory, while classes and resources packed in Jar files should be uploaded to /html/WEB-INF/lib."
uhh... so which is it? /classes? or /lib? I dont think they explain that very well and I'm a little confused by this statement. Also what exactly do I install? With a normal solr install, solr is put somewhere else, the war file is copied into tomcat and the rest of solr is referenced using some kind of XML configuration file.
Also, since I'm a little new to Java and servlets, can someone explain the tomcat file structure to me (in great detail will definitely get you a +1 from me) and where things should go and why?
Thanks in advance!
Web application structure is defined by J2EE spec, it's not limited (or specific) to Tomcat per se. Here is a detailed tutorial covering its layout. Briefly, however, it's as follows:
There a base (root, home, whatever you want to call it) folder which serves as root of web application, everything else goes under it.
All public stuff (html, images, CSS, javascript, JSP, what have you) goes under that folder (directly or via subfolders).
There's one special folder, also located directly under root, called WEB-INF. It contains non-public stuff, like application descriptor (web.xml), classes (which go into WEB-INF/classes folder), libraries (WEB-INF/lib) and possibly configuration files.
Application can be deployed either using expanded structure above or as WAR (web archive) which is basically an archive containing everything above starting at root folder level (but not including root).
The distinction between classes and lib folders is simple: all packaged libraries (JAR files) need to go into lib; all unpackaged classes (and resource files that need to be in classpath) have to go into classes preserving their directory structure (e.g. com.mypackage.Blah class should go into classes/com/mypackage/)
In your case, it looks like you can only have one web application deployed and it has to be deployed to /html folder. If you're deploying a war file, you need to extract it to that directory (e.g. from within that /html folder run jar xvf solr.war or whatever it's called).

different configuration files for different server

Hi How would you solved that?
I have one application in which I have a few configuration files, I make war file and deploy it on the tomcat.
But at the same time I have to make the war file and deploy the same application under different context and/or a server with modified configuration files.
I can create my own task in ant, and replace needed paramaters but there can be possibility of moving to maven, and anyway I'm not sure about it. Or can I use something like spring's property place holder configurer or jgroups
Spring can handle this quite well in a variety of ways. The approach I found most useful and flexible is to setup in each environment a system variable that specifies trhe environment name e.g. test, dev, int, prod, etc.
Spring can then use this system variable to load the correct property files. Depending on your needs these property files can be bundled with the app or loaded from an external location. Theres an example of a similar approach here:
http://www.developer.com/java/ent/print.php/3811931
I'd deploy Spring apps packaged as a WAR to either Tomcat or WebLogic without any changes. It would contain both the META-INF/context.xml for Tomcat and weblogic.xml for WebLogic. No worries, no changes.
What we did was create a folder structure for the properties that were environment specific. Under that folder we created folders for each specific environment targeted for deployment, including local development. It looked like this:
Project
\
-Properties
\
-Local (your PC)
-Dev (shared dev server)
-Test (pre-production)
-Prod (Production)
In each folder we put parallel copies of the properties/config files and put the different configurations only in the file in the appropriate folder. The secret was to control the classpath of the deployment environment. We defined a PROPERTIES classpath entry on every server. On Prod, it would be set to "$ProjectDir/Properties/Prod" while on Test the same variable would be set to "$ProjectDir/Properties/Test".
This way we could have database connection strings for the dev/test/prod database preconfigured and not have to checkout/in the property file each time we wanted to build for a different environment.
This also meant that we could deploy the exact same .war/.ear file to Test and Prod without rebuilding. Any properties that weren't declared in the properties file we handled in a similar way by using the same JNDI name in each environment but using values that were specific to that environment.
http://www.gifnoc.com/config could help as it stores configuration on a central place and the client is pulling from it for different environments

Categories

Resources