I have a task to automaticly extend heap memory for our tomcat application. I know it isn't possible by JDK features, and I'm looking for any dirty(or not) hack to make that kinda feature. The main reason of that demand is minimal configuration of tomcat before start demo version of our application. In other word no user of our application will have any access to configuration of JVM/tomcat.
Application required ~1024M of heap memory, default value for tomcat8 is 256M, which isn't appropriate for our goals.
At this moment I have two possible solutions:
An a .sh/.bat script which will configure tomcat. pros - it will do the work, cons - it's another point of configuration demo stand(copying of a script)
An wrapper for our application, which goes in the same war file and configure tomcat if required. pros - it will do the work, and no new configuration point(Just install tomcat and copy the war file),
Is there another way to do that in more... common and simple way?
EDIT The main goal is to make installation of our application in following steps:
Install tomcat
Copy war file
Start tomcat
no any additional configuration, just copy war and start tomcat
That is commonly solved by wrapping the installation and configuration of tomcat in an installation script. Pros: the end user just download the installer and runs it; cons: the installation script must be tailored for the final environment (one for Windows, one for Linux) and can be hard to write. A sometimes simpler way is to provide a zip containing a readme.txt file and a install.bat (or install.sh)
An alternate way if the configuration is really complex is to directly configure a VM (VMDK is a de facto standard), and let the users install the virtualizer they prefere.
Related
As a novice to the world of Java programming, this question has always boggled my mind. I first believed that all Java files were compacted into applets and then ran, but I soon realized that this isn't always the case. Could someone explain to me how we actually interweave our Java applications into a real product of everyday life?
TL;DR: How do we implement our code for practical usage?
It depends on the application. There are many options depending on how you want your users to use your app. Usually it's packaged as a jar or a specialized jar (war, ear).
In theory, you could zip the raw directory structure with your .class files in it and provide a shell script/instructions that run the java command for the user. I don't recommend this because it's kind of unprofessional and requires you to maintain a shell script for each OS you want to be able to run the program on.
Jar files are used to package libraries but you can also have a manifest file in it that says, "When someone double clicks/executes this, run this class". That class can start up a GUI or be a headless task that responds to the parameters, etc.
You can have applets, like you said. These programs are run in the user's browser.
You can have a war file, which is a way to package a web application. You give this to a web server and it knows how to deploy it so that you can visit the web pages. An example web server/container is tomcat or jetty.
You can have an ear file which can contain other war files inside it. This is used for applications that need other parts of the javaee functionality (ejbs, jms queues, etc.). An example of an application server is jboss or glassfish.
There's also java web start apps. These are apps you can run by visiting a webpage, but they get downloaded to your computer and run on the user's computer (instead of on the server's backend, like in a war/ear).
There's also javafx. I don't know anything about that though. By skimming the FAQ, it appears to be Java's answer to Adobe's Flex. You configure UI components with an xml configuration. I'm not sure what format JavaFX apps use, but it does say, "Deploy on the desktop or in the browser".
As Sotirios Delimanolis mentioned in a comment below, you can build these files with build systems like Ant or Maven. You can also build them "by hand" with the tools that come with the java/javaee sdk. For example, you should have a jar command in your path if you installed the sdk. Here are some details of these build systems:
Maven
High level (you tell it what to build, not how to build it)
Much more than just a build system. It also has dependency management, etc.
Opinionated (it uses convention over configuration, each config file generates 1 artifact, etc.)
Ant
Low level (you tell it how to build things)
Flexible
Config files can do whatever you want, build as many artifacts as you want
Easy to learn
SDK tools
Always up to date. EG: Very rarely, maven/ant may not be able to set a configuration option
Difficult to remember commands
Very low level
By itself, not repeatable (EG: unless you build a script, you will have to type the jar command yourself each time)
Applets never really caught on and are very rarely used nowadays.
Simple applications can be deployed as "executable" JAR files , which are basically ZIP archives with additional metadata that tells the JVM which class contains the main method to run. They can be run on the command line using the -jar option, or in most desktop environments by double-clicking (this requires a JVM to be installed as well).
Desktop applications can be deployed via Java Web Start or installers like IzPack or Install4J, but Java desktop applications are not very common either.
Most Java software nowadays runs only on servers (web servers or app servers). They are typically deployed as WAR or EAR files, which are also ZIP archives containing classes and other resources. These applications then run inside a server component following the Servlet or EJB standards.
If the application is mean to run on a client, it is packaged as an executable JAR, then further packaged as an Application Bundle (Mac), maybe wrapped in an exe (Windows), or paired with an executable script that will launch the JAR and set any required VM arguments.
If it is part of a web application, then it will be packaged as a WAR or EAR and placed into the appropriate location on the web server.
If it is simply a library, then it is usually packaged as a JAR (non-executable) and distributed as such for integration into larger projects.
applets and then ran, but I soon realized that this isn't always the case
Actually, applets are rare nowadays and their use is discouraged.
Create an executable jar, a war which is dropped into a web server or a library that is used by another project that is one of the previous two.
I am using a profiling tool, which gets loaded as and when I startup Tomcat with the application war file placed in the webapps directory. So once I run startup, my classes get instrumented and everything works fine.
But for this, I am taking the war file generated as part of maven install ( which downloads tomcat and deploys the war file in it) , and placing it in another tomcat which I have downloaded manually. Then I need to do some editing in the catalin.bat file, to set the JAVA_OPTS property to the javaagent so that it gets started on startup.
What I would like to do is, setup the tool and integrate it with maven such that on a clean and install, the classes gets instrumented and the profiling tool starts running. I believe we can do some configuration changes in pom.xml to achieve this? Any help in this regard would be greatly appreciated! Thanks
This is only part of what you need, but you should configure your tomcat in a different way - maybe this eases your task sufficiently that you'll be able to solve the rest yourself:
You don't need to update catalina.bat - instead create a file named setenv.bat in the same directory: It's not included in tomcat, but if it's there, it will be taken into account during startup/shutdown of tomcat.
Speaking about startup/shutdown: The JAVA_OPTS that you set in this file will be used for startup as well as shutdown (there's a java process started when tomcat shall shut down, running for a brief time). If you have massive memory requirements, allocate JMX ports etc, these will apply for both processes, thus may be conflicting. You rather want to set CATALINA_OPTS - this is just used for starting tomcat, not for shutting it down.
So, the typical content for setenv.bat is
SET CATALINA_OPTS="-DyourSettings -DwhateverYouLike"
And, by the way, the same works for setenv.sh on other platforms
I use Eclipse Indigo (EE) to build applications in Java framework Vaadin,
using Tomcat 7.0 server. After changes in code I wont see result in a browser,
so I need to click option "Clean Tomcat Work Directory.." and wait until
Tomcat stop and start a server.
Otherwise, when I refresh app page, I don't see any changes.
Even when I restart server (and when eclipse automatically restart it when I save changes), without cleaning tomcat directory.
Option "Automatically publish when resources change" is enabled.
Is any faster way to do that? or can I automate that process?
Additionally to the answer of Kowser, it is possible do hot code changes when running tomcat in debug mode.
Otherwise you could investigate in JRebel
In your "Modules" tab of your Tomcat, you hace to clic on 'Edit' and uncheck the 'Auto reloading enables' option.
With that, several changes won't need a restart (as long as you start your server in debug mode).
If you setup your project to use ant for building and deploying, you can simply add Ant builder to your project Builders to run your ant build and deploy targets every time after you have saved a file. Then provided that tomcat is configured to support auto-deploy, this should achieve what you want, with two caveats:
If your project takes more than a few seconds to build, building after every save is not practical.
You may run out of memory for the tomcat instance if the same app is deployed to it repeatedly for a number of times. This can happen if tomcat is somehow unable to recover all the memory from undeployed resources.
It might be possible. But your setup is a bit different from what I use. I am just using tomcat+eclipse to do Servlet development using Velocity and Torque.
The following works for me where changes are visible in the browser as soon as I save in eclipse.
I assume that you have a project directory such as
apache-tomcat-7.0.11/webapps/$YOU_PROJECT/WEB-INF/classes/
Create a symbolic link with ln -s from your eclipse project directory and to the classes directory in WEB-INF.
Then configure eclipse to write all .class files to this directory. (Done by right clicking on the project in Eclipse and choosing Properties and then Java build path.
In your $tomcat/conf/context.xml config file first tag should be:
<Context allowLinking="true" reloadable="true">
Also add the following as a child to if it is not already there.
<WatchedResource>WEB-INF/web.xml</WatchedResource>
That is what I have done, but I am not sure it works with your EE tools.
ps: This solution assumes that you are using linux/unix. I don't know if it works with windows. The major problem is that eclipse can't write class files outside the project directory (Which is why that symlink is required).
btw: Tomcat may(Depending on class loader, used .jar files and other complicated details) leak a lot of memory when automatic reload is enabled so you may want to increase the allowed memory(Mostly permgen) to prevent out of memmory exceptions from tomcat.
I know this has been asked and answered very long ago. But use this info if it is helpful to anyone of you. I use Eclipse Kepler and configured Tomcat 7 server inside eclipse. I don't have to do any other configuration but to just uncheck Update context paths check box. That is all. Leave other setting as default.
In this way, changes to the resources files (xhtml pages, css files etc.) as well as the java source code files show up in the browser. Only for class files the web application would be redeployed (no server restart auto as well as manual required).
Location of Update context paths: Double click on the tomcat server under Server tab. Under Publishing tab you would find this Update context paths check box.
Absolutely no other change needs to be done for the auto publishing. This works both in normal and debug mode of tomcat.
Screen shot from my eclipse below:
No, there is no other way.
You will notice immediate changes only while updating a JSP/HTML/etc.... Classes will not be loaded/refreshed automatically. It will be contradictory to change a loaded/instantiated class when server is live, isn't it? At least it should not be possible.
It's better to perform Unit Test while developing something. It can help you to reduce the amount of annoying server restarts.
I am in the unfortunate situation where I need to deploy and upgrade packages and config files on machines with no root access and no ability to use or install a package manager. Are there any neat solutions that allow creation of custom install packages?
I am open to custom compiles of some software in a custom location on the servers if it helps the situation.
Im almost at the point where I might end up having to write my own java package management system :(
In case its relevant some further information. The installer needs to install and configure the following:
Apache Tomcat
WAR files into Apache Tomcat
ActiveMQ
Some JAR files with some corresponding Cron entries
This sounds a bit perverse. Why do you need to "deploy" Tomcat / ActiveMQ to (lots of) machines that you don't have root or sudo access to?
Anyway, I don't see the need for a custom installer to do this (* see note below).
The yum --installroot /home/whatever <package> should install <package> in a non-standard location. If you cannot use yum or whatever, you should be able to download a binary ZIP or TAR file and unpack it. And once you have installed / unpacked whatever, you can leap in and edit the configuration files using the relevant app tools ... or a text editor. Tomcat can be installed in any directory you feel like, and run using your own login account if you need. I imaging ActiveMQ is the same.
Deployment of a WAR file is simply a matter of copying it to Tomcat's webapp directory.
Creation of a cron entry is simply a matter of running the crontab(1) command.
And if you have to go through this process lots of times, you could write some shell scripts to do the repetitive work for you.
(* Note - there are a couple of possible roadblocks.
You will need root/sudo access deploy a startup file for Tomcat, etc to "/etc/init.d" to get it to start automatically when the system boots. There is no easy way around this. The "/etc/init.d" directory is only writeable by root.
If you want manually launch Tomcat to run on ports 80 / 443, you will need root/sudo access to launch it. Again, there is no easy way around this. Only a "root" process can listen on port numbers less that 1024.)
Take a look at InstallJammer. You can develop graphical or console-based installers for both platforms from a single project. They won't require root unless you need them to.
InstallBuilder is the tool we use to package Bitnami stacks including the Java ones like Alfresco which include JRE, Tomcat, etc. and do not require admin privileges
At the moment my build process consists of repackaging the war file with all required java libraries under WEB-INF/lib and then copying the war file to development/demo/production server to be redeployed by tomcat.
The packaged war file's size is about 41M and it has at the moment something like 40M of external java libraries. There has to be a better way. How have you solved this issue?
My development machine is a windows box with Eclipse as my IDE and Ant as my build tool. The servers are all linux boxes with Tomcat 5.5.
Should I maybe add the jar files to the war package at server side?
I can see what you are saying, and have had the same frustration with some of our webapps, but for consistency sake, I would suggest you keep things as they are. If copying the libraries to the tomcat/lib directory you may run into issues with the system classpath vs. the webapp classpath.
By keeping things as they are you are sure you are deploying the same stuff in development/demo as you are in production. Life sucks when you are manually tweaking stuff in production, or you have some crazy error because you forgot to update XYZ.jar from version 1.6 to 1.6.1_b33 in production and now it's behaving differently than what you believe is the exact same code on demo.
When working with something vital enough to have dev/demo/production systems, I think consistency is much more of an issue than .war file size.
We use the rsync tool for this (in our case, using cygwin under windows) to copy the deployments to the servers (which run linux). We use exploded WAR/EAR files (i.e. a directory structure called MyApp.war rather than a zip file called MyApp.war), rsync will only transfer the files that have changed.
In general use, rsync will transfer our 30-40 megabyte exploded EARs in about 5 seconds.
Tomcat has a shared/lib directory, which is the proper place for global application dependencies. However, these will be visible to all applications, which will affect dependency management and may have consequences for things like static variables. I'm not sure if you can configure anything better in Tomcat.
An alternative is to switch to a more sophisticated web container. For example, WebSphere Application Server Community Edition (a blue-washed version of Geronimo) supports per-asset libraries. Other free and commercial servers support this, too. I know WebSphere Application Server does and I'm pretty sure you can do it in Glassfish.
#McDowell, when mentioning those J2EE servers, you should precise that they are J2EE servers(servlet container + the rest).
Like #digitaljoel, I suggest to keep things like they are. It looks like you haven't done much web application deployment yet. The issues that you'll have are not worth the price(version conflicts, deployment errors, etc.).
Can you add the non-changing Jars to the Java Library Path on the server side, and only include the regularly changing Jars in your WAR?
you could include the external java libraries in the Tomcat/lib directory. That way they stay on the server.
You could just deploy as a JAR file, replicate your deployment environment locally and just copy over the files that have changed and the jar itself. The pathing is the only real issue.
Or you could look into setting up an EAR.
I work with the 'exploded web application' in the development servers, and occasionally in production as well. The deployment process (based on ANT) updates the JARs in WEB-INF/lib with our packages. Only in the development server, we activate Tomcat reloading which takes care of restarting the application when something changes. You should assign some extra permanent memory to these Tomcats and have a way to restart the server, as the reloading may crash Tomcat from time to time.
I know it's a weird configuration, but I can't understand how constantly repackaging the 30MB (and growing) of our typical application could do any better. May one day the development descriptor allow for external references to libraries which the container may download and cache. ??
Excuse my poor English.
What you need is a version control tool and a build process.
Use CSV,SVN,GIT or whatever fit you to keep your source under control.
use a build tool to build your application : Maven,ant,...
Now, when you want to deploy your application on your server ,you just have to commit your updates on your computer,update your source on your server,build your application and deploy it from the server.
This way , the server will just have to load your modifications and it should be much faster.