I want to start Tomcat 6 with special configuration sometimes, not using the "server.xml". So I created another xml file named server_test.xml. Now I want to tell tomcat to use this configuration. How is this done?
I found nearly nothing searching the web. Only that:
"Use different server.xml file in Tomcat configuration: ./tomcat.sh start -f /var/tmp/server-${USER}.xml"
This is exactly what I want. Maybe this is working for linux systems but not for windows. Any ideas out there?
I've got it. I took me the half night, but it works :)
At first I also thought of symbolic links, but under Windows it's not a thing you would like to use. My second thought was modifying catalina.bat, but that's not that easy. And different CATALINA_HOME's is not what I really want.
So what have I done? I've provided the server.xml as a parameter to catalina.bat.
catalina.bat start -config \conf\server_test.xml
Nice and easy :)
You can have a lot of server configuration files and provide the one you need to the start and stop script. The tricky thing was that the Catalina class gives you the wrong usage information :
usage: java org.apache.catalina.startup.Catalina [ -config {pathname} ] [ -nonaming ] { start | stop }
But if you exchange the parameters and first provide "start" or "stop" and then the "-config ..." argument, everything works.
Also very nice is that you can use this solution the create different run configuration in IntelliJ IDEA. I have one where the Tomcat connects to a local database and one connecting to a development database. For each I have a different server.xml.
I hope this helps.
Regards,
Sebastian
It doesn't look like there is a (documented) option you can pass to startup.sh or catalina.sh to change this.
Perhaps you can set server.xml as a symlink to the file you actually want to use, and just change the symlink prior to starting the server when you want to change it?
Otherwise you can play around with using different values of $CATALINA_HOME but this would require you to duplicate the entire directory structures.
tomcat.sh hasn't existed since 3.x and, to be honest, I don't recall it having '-f' option back then either.
You have two choices here:
A) You can setup multiple tomcat instances as described here and switch between them by pointing CATALINA_BASE to the one you want.
B) You can create multiple server.xml files named differently (e.g. server-1.xml, server-2.xml, etc...) and write a simple batch script that would copy the one you specify as command line argument to the actual server.xml and then start Tomcat.
Related
We have a tomcat server up and running.
We want our application to run as 5 independent instances on this tomcat server.
Each instance needs a different set of command line arguments to run properly.
How can we pass those arguments per instance?
We run the current version of tomcat server.
We have a Spring-Boot-Application which needs to run as 5 instances on this tomcat server. This is so that each instance takes care of a single port and on the business-level serves a different environment (dev, test, ...).
We are using different spring profiles per environment and therefore need to pass those to each instance running on tomcat.
Thing is: We cannot figure out how to pass those arguments.
There seems like no configuration to do this per instance.
We know about the JAVA_OPTS which are used on the entire tomcat.
We thought about declaring those arguments envrionment variables, but:
- potential other applications shouldn't know about those configurations.
- the configuration is pretty specific per instance and therefore a lot of 'noise' is produced which might be hard to maintain in the future.
As we look for the right place and right way to do that, there is no code yet.
Expected result:
5 instances of the same application are up and running on a tomcat server, each configured individually.
Hoped for:
A way to alter the config.xmls or alter a batch script to pass command line args.
You can't give parameters when deploying a war, so that's out of the question.
You'll have to do 5 builds, but then you can set the profiles to be used in application.properties. Shouldn't be too hard to automate, and technically you only need to build once, if you then make copies of the war and replace the property file.
Update:
What we finally came up to:
We have an individual context.xml for each instance and each environment. The differenct context.xmls are managed in a repository.
During deployment the respective context.xml is copied next to the war-file.
We are pretty happy with this solution, as we were able to automate the entire process and even have a context repository in place.
Short version
How do I configure the icedtea-plugin package for ubuntu precise in such a way that it executes all applets with a specific memory limit by default? Preferrably using command line tools and no graphical user interface.
Long version
I'm building a kiosk setup using java applets, and would like to increase the default memory limit for all these applets. The kiosk is based on ubuntu linux, using the icedtea-plugin package as a browser plugin. As building the kiosk is automated and headless, I'd rather configure it from the command line if possible.
Here is what I've found out so far:
I'll probably have to specify a -Xmx… command line argument which will be used when starting the java virtual machine for the plugin.
It is possible to pass such arguments using a parameter in the HTML code, i.e.
<param name="java_arguments" value="-Xmx…">.
But that would mean modifying all my HTML files, which I'd rather avoid. And there is a good chance that I'd have to sign my code to make this work, which adds quite a lot of problems in other places of my project.
On my desktop system, using the Oracle VM, there is an application ControlPanel which I can use to set these command line switches. It seems that the configuration gets written to a file ~/.java/deployment/deployment.properties, where it is associated with the key deployment.javaws.jre.0.args.
That key name is not described in the specs for that file. The number 0 seems to refer to one specific JVM, as represented in one row of the table in the control panel. For each JVM, there are several values besides this args value, all sharing a common index number.
According to this wiki section, IcedTea supports a similar file, located at ~/.icedtea/. Not sure whether that means ~/.icedtea/deployment.properties or rather ~/.icedtea/deployment/deployment.properties. IcedTea does not seem to come with a ControlPanel.
As you can see, there are many hints as to how this might work, but so far I haven't seen any definite answer as to what will work. There are still many open questions:
Do I have to create this icedtea deployment file?
Do I have to include a directory named deployment in the path?
Which is the minimal set of keys that I need to specify to make this file work as intended?
Is the args value even supported by OpenJDK, even if it is not described in the corresponding specification?
I guess I could try out all possible combinations to see whether one of them works, but doing so will take considerable time. So I'm asking here, to see if someone has experience in this, and can provide a quiecker answer. If not, I guess I'll answer my own question eventually, once I've tried things the hard way.
as oracle says: http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-Desktop/html/plugin.html.
following environment variable should be set to add additional arguments to applets:
_JPI_VM_OPTIONS=-Xmx…
Moreover as the reffered site says:
Please note that you need to restart your browser after you set the environment variable. If you are setting this environment variable in the command shell, then you must use the same command shell to launch the browser so that the browser inherits the value of environment variable.
However if you doubt how to set environment variable in ubuntu, following post might be helpful: Make $JAVA_HOME easily changable in Ubuntu
I just had a look at the source code of the icedtea-web plugin. The part of the code which builds the command line seems to have no provision at all for including custom arguments, no matter their origin. So it does not matter which config files, HTML files or environment variables I edit, the code there will build the same command line to call java, disregarding all my whishes.
So if all configuration fails, what remains is hackery. One approach would be to patch the source code of the plugin, and make it include additional words into its command line. For a static addition, i.e. a single size change, this would be fairly easy. A more general fix would include the content of some environment variable, the way Peter's answer suggests. That would mean word-splitting the environment variable in question, and allocating the space for the array of words dynamically. Quite a bit of work at the C level.
As an alternative, one could tackle this at the level of the executed binary. The plugin apparently has the path of the executable hard-coded into it. In my case, this path is /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java. One can rename that binary to java.orig, and put a shell script in its place, with the following content:
#!/bin/bash
for i in "$#"; do
if [[ "${i}" == sun.applet.PluginMain ]]; then
exec "$0.orig" -Xmx512m "$#"
fi
done
exec "$0.orig" "$#"
One consequence of this approach is the fact that ps will no longer print these applets as java but instead as java.orig. Should not be a problem in most cases.
Right now my team deals with about 4-5 different servers and about 2-3 different DB servers and we're using environmental variables to decide which server we're on and what server configuration to use.
Is there a better way to do this as my team continues to expand? I've considered compiler flags / args, but it doesn't seem as robust.
From my perspective, in java, you have basically 3 ways to crack this cookie:
Environment variables
-D JVM parameters (which are System Properties)
properties files
You've already discovered Environment Variables and that is pretty much "the unix way" to get the effect you are after; different configuration to common binary that customizes the running application for the environment it is executing on.
System Properties are really the Java "moral equivalent" of Environment Variables. They come in via -D parameters on your application's command line like...
java -Dlogback.configurationFile=/opt/dm/logback.xml -cp app.jar org.rekdev.App
Explicit Properties file processing http://docs.oracle.com/javase/tutorial/essential/environment/properties.html in Java is a third variant which you often see coupled with -D to get something like default behavior which can be overridden at runtime from the command line. That is what is basically going on with the logback.xml configuration above, the JAR file has a logback.xml inside it that will be used unless a System Property called "logback.configurationFile" exists, at which point the App will load it instead.
As you try to figure out how to keep this all in sync and working correctly in a multi-server environment, consider the use of chef http://wiki.opscode.com/display/chef/Home to do the deployments and put each specific environment's customizations under chefs control. Put the chef "recipes" in version control and, voila, full on configuration management.
SHIP IT!
I can see two scenarios
You embed all the different properties within your package (can be a war, ear, jar, or on the file system /yourapp/etc/)
You embed only one property file and this one is created during build (with ant or maven)
Say your app is named foo
Solution 1
It has the advantage that your app can be put as-is on any of the supported servers (all that have a property file in your app package).
Your properties will be named foo.dev.properties, foo.test.properties, foo.prod.properties, foo.damien.properties, foo.bob.properties.
One other advantage is that every developer working has its own dev file that he can safely push on svn/git/whatever and be sure that other developer won't destroy his config.
At runtime the application can check the -D parameter or even retrieve the hostname dinamycally, in order to load the correct property file.
Solution 2
It has the advantage that your package is not polluted by unnecessary properties files.
You must configure a lot of ant tasks/maven target in order to build for specific environment. You will have in your source directory the properties files for the environments also, but only one will be shipped with your app. This one foo.properties will only have placeholders for values, and values will be inferred within it using foo.ENV.properties with the right ant task/maven target.
At my actual job and the previous one also, we did use the solution 1, I think it brings flexibility.
Some parameter (like database user/password) were fetched directly from environment variables on the Unix servers though (so that only the server admins knew the credentials).
You can safely mix the solutions, in order to get where you feel there is the more flexibility for you and your team.
I am currently using tomcat 6 as my Web Server. I have a very small application which should not take long to deploy on server, but my tomcat is taking too long start.
It is taking most of its time in following step.
INFO: Starting Servlet Engine: Apache Tomcat/6.0.16
I don't know why it is taking much time. Same is the case with stopping the server. I tried almost everything I know. I also tried to delete server from the workspace and started from scratch. I don't know what is the problem.
You can find out which library consumes the time. When the server is being started in a debug mode, pause its thread several times and examine stacktraces. There may be possibly some library that populates its Spring application context, weaves advised objects, initializes file storage, whatever. If so, you will see it from stacktraces.
Have you removed all the default web applications that comes with the tomcat installation ?
Even though your webapp is a small one, there might be other applications that are taking time to be installed. You can check this from the server log files with the name catalina___.log files.
I know this post is old, even i wanted to share few check points on this because these are irrespective of tomcat version...
I was facing the same issue and i followed below steps and now my server is starting with in 130 ms.
First verify the console if you are using any IDE, there you can find time in milliseconds for each application. So you will come to know which one is taking long time.
To make sure, your finding is correct just remove that app from 'webapps' folder and start tomcat again.
Remove the default applications which you don't need. Usually we only use tomcat manager, so just keep manager app and remove other applications from 'webapps' folder
Make sure 'temp' folder is empty
Clean up the older log files. And don't write your application log files in server folder.
Start the server first and deploy the file later. So that you don't face timeout error.
This is what i tried any succeed.
Possibly this is due to a lack of availability of random entropy, which Tomcat requires.
See https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp#HowToFasterStartUp-EntropySource
and
Slow startup on Tomcat 7.0.57 because of SecureRandom
(Edit: first link updated)
I guess you have placed all your libraries (JARs) in the WEB-INF/lib folder. Instead move those to a separate directory and refer the directory or JARs using shared.loader in the catalina.properties
In my Java application I want to implement the option to dump/restore a PostgreSQL database. Some google research showed me that calling pg_dump/pg_restore via Java's ProcessBuilder is probably the best way to achieve this.
Now I'd like to determine the system's directory of pg_dump.exe/pg_restore.exe without asking the user to specify it manually. How can I find the PostgreSQL installation path through Java?
Thanks in advance and
all the best,
Matthias
You can't do that portably. I suggest that you just call the programs without path by default and rely on the user having set an appropriate path, and have a way for the user to configure the paths explicitly. You can also look in some likely directories for a default configuration. But it will be quite fragile in general, especially if you want to cover all of Windows, Linux, and Mac, say.
A good idea would be to simply define an environment variable called PG_HOME and use System.getEnv("PG_HOME"); to retrieve that.
Look inside the default directories first (probably somewhere C:\Program Files (x86)\PostgreSQL\...). Use different combinations to be as tolerable as possible.
If it fails, just search the file system. Nice example here.
Also see How to do a backup from a Postgresql-DB via JDBC?