I'm working with Java and I've been asked to Hotreload a jar file to an ejb-server.
So my question is (and yes I've googled it!), what is the definition of Hot reload anyway?
It is hot deployment and not hot reload of ejb, which means, updating an EJB without having to stop and restart the application server. Few application servers support this few don't. You don't have to worry about it, its application server that provides it for your use.
Few application servers does it seamlessly, for example, In weblogic, you can just copy a modified jar file into your applications directory, and changes will take place immediately.
Related
I'm trying to understand the model that Apache Tomcat adheres to, and the documentation apparently doesn't make sense to me.
As I understand it, Tomcat is a server for hosting a wide variety of services - so it's pretty generic. I've got this application that I'm trying to understand how to host, and its main method of deployment appears to be as a Tomcat-hosted web service - the application is called Camunda (its on github). After going through the docs for Camunda, my Tomcat directory becomes absolutely filled with Camunda-related jars, and config files, etc. The docs say to just plop everything right into the Tomcat lib folder, conf folders, etc.
Most of my experience with other "platform" / "service" style host applications has been that the application itself, in this case Tomcat, stays pretty untouched in its own directory. Through config files, etc, it knows how to host whatever it needs to host.
In the case of Tomcat, it seems that it's customary to basically "pollute" the Tomcat dir with a bunch of libs for the hosted content?
This is why I made the title "is Tomcat meant to be one install per application", because for all intents and purposes once you host something in Tomcat the directory becomes so coupled with that something that the Tomcat directory IS that something.
Is this normal? Just looking for some clarification in perhaps other terms that the docs put it, because the docs don't seem to be very clear to me.
Here is a link to the install process that I am following and referring to: https://docs.camunda.org/manual/latest/installation/full/tomcat/manual/
It's been a while since I've used Tomcat, but not only is it not one-install-per-application, it's not even one-install-per-virtual-host.
Tomcat is (amongst other things) a servlet container. The directory layout and such for servlets was standardized in the Java Servlet Specification v2.2. You can download the latest servlet spec here.
The docs say to just plop everything right into the Tomcat lib folder, conf folders, etc.
Hopefully they're talking about the ones in a .war file or similar, or shared libs in the shared locations. You can put shared libraries in a location where they can be reused across applications (or even virtual hosts), which was probably useful back when disk space was more expensive, but these days I assume most people put the libs for an app in the /WEB-INF/lib directory in the application's .war file.
This page talks about the "directory" layout of a .war file (which is basically a .jar with a particular structure).
It's true that typically .war files are expanded into subdirectories of the Tomcat installation directory, but as indicated in the answer that Dan_Maff linked to in a comment, you can modify the server.xml file to have it look elsewhere instead.
You can install a webapp called Manager that helps with installing, activating, deactivating, and managing web apps via .war files. (There's also a Host Manager for managing virtual hosts.)
All that said, you certainly could do one application per Tomcat install if you wanted. You'd need a reverse proxy in front of it (Apache, Nginx, etc.) so the same port (e.g., 80) could be used for the external URL of the various applications, and you'd need to assign each Tomcat install its own internal port for the reverse proxy to talk to.
Even if we enable "deploy on save" with our IDE, we still need to wait some time to propagate changes. This can be annoying espacially when we deploy small changes.
So, is it possible to run some servlet container in-memory with IDE-compatible deployment to speed up deployment and development time? Or even run whole container in-memory with server dependencies (JSP compilator etc.).
(I know that I can install Tomcat on RAMDisk, but looking for "more native" solution)
According from their site
JRebel is a JVM-plugin that makes it possible for Java developers to instantly see any code change made to an app without redeploying. JRebel lets you see code changes instantly, versioning classes and resources individually and updating one at a time instead of as a lump application redeploy. When developers make a change to any class or resource in their IDE, the change is immediately reflected in the deployed application, skipping the build and redeploy phases and preventing an average of 5.25 work weeks per year in redeploys!
http://zeroturnaround.com/software/jrebel/
The first thing you can do is to set the deployment path to your webapps directory. This way you deploy the application "exploded" without copying the whole app to another deployment directory. Make sure to let the classes be compiled into the WEB-INF/classes directory.
A second, more problematic thing is, the class loader. When the JVM runs in debug mode, some code changes made within methods will be recognized by the class loader and you would see the changes immediately. But some changes, like method signature and structural class changes will not be detected, so a restart of the JVM will be necessary. You can provide a self brewed class loader which will be able to reload anything when the underlying class files changes.
The tomcat container is loaded in memory when you start it. And tomcat loads all the applications available in webapps directory. Later as and when application classes are required are loaded. And application may load some other resources as required.
If you open the task manager on windows or similar thing on other OS, you can see that tomcat java process is always runnning once started. You may also check its current memory footprint . So it is not unloaded and re-loaded on demand.
I'm new to JBoss Seam and Java web app development in general. One thing that I cannot figure out while going through a few tutorials is how to redeploy beans that I've made changes to in an EJB project without having to restart the JBoss Application Server (6.0) that is hosting the JBoss Seam web project which uses the beans. The JBoss AS takes about 2 mins to start up, and it is painful making changes to the project and redeploying at present.
Some suggestions that I've read on the web include:
Using the jmx-console eg. go to http://localhost:8080/jmx-console/ ... ok, but how? What do I do exactly?
creating a build.xml file for ant, and get some sort of autodeploy thing going... are there any good examples around?
How do the rest of you more experienced JBoss Seam web app developers deploy your projects more rapidly?
Any help much appreciated, thanks.
This can be due to a number of reasons:
An application attempting to maintain state.
The new deployed application having a different classloader than the old one.
Other random causes. In our case, the jboss-classloading.xml configuration was not correct and this caused the hot deployment not to work.
Did you make any changes to your JBoss configuration? This can also lead to hot deployment issues.
Good luck.
Use JBoss hot redeploy feature: just remove your EAR (WAR) from deploy directory and copy there your new version.
Start JBoss in debug mode from your IDE (Eclipse). Then some code changes can be hot swapped directly into the JVM. If the hot swap fails, then do 1. hot redeploy.
Try great JRebel plugin. Much more powerful than 2. JVM hot swapping. You can combine Jrebel with 1. hot redeploys - when JRebel plugin fails, then do hot redeploy.
Just beware, hot redeploying may reveal memory leaks in some libraries (e.g. Jasperreports). If so, do restart your server. But you need to restart JBoss very rarely.
Another option that I have been told is to use the "Touch Descriptors" button (which is like a "quick redeploy" option) in JBoss.
Dev Studio 4.0 has it, not sure about earlier versions though. Apparently it creates a new timestamp on the server and forces the web.xml file to be re-read, thus redeploying.
We package our application as a .war file, we advertise support for JBoss AS5 and instruct our clients to copy the .war into their JBoss 'deploy' directory, and start up their application server in order to deploy the .war.
We are introducing support for JBoss AS7, so our deployment instructions for AS7 will have to change to something like
-copy the application.war to $JBOSS_HOME/standalone/deployments
-touch $JBOSS_HOME/standalone/deployments/application.war.dodeploy
-start JBoss AS7
This deployent method seems awkward to me, and possibly fragile, as failure to successfully create the *.dodeploy file would cause the deploy to fail. Also JBoss startup problems may cause the deploy to fail, causing the *.dodeploy file to be renamed *.failed - so it would have to be renamed back to *.dodeploy before attempting to redeploy. We are thinking the process seems a little awkward for some of our clients, who may not be familiar with JBoss AS7.
Is there any way to automate this deployment process so that it is smoother for deployers who may not be comfortable with how things work with JBoss AS7? How are other people handling this type of situation? thanks for any suggestions.
There is a web interface that's fairly easy to use. You can access it after JBoss AS7 has been started by going to http://localhost:8080. There is a link on that page that takes you to the administration console.
You could also write scripts for deployments using the CLI interface. There is some information here https://docs.jboss.org/author/display/AS7/Management+Clients about how to use it.
Lastly you can always write your own Java client to deploy applications. I wrote a blog post a while back on how to write a custom deployment CLI interface.
If you're aware of the marker files then you might have made a conscious choice to disable the automatic deployment mode for the deployment folder, which ships enabled by default. Autodeploy is great for everything but exploded files, and removes the need to manually manage the marker files. With autodeploy enabled, you can use the "touch" command on the application itself, which will update the timstamp and trigger the application for deployment (or redeployment). So you can still script if need be, but focus on the file rather than the marker files.
Just for reference, there are five ways to deploy files, of which three will be common to the typical administration setup. These are the graphical Management Console, the Management Command Line Interface (CLI) and the deployment folder you mention. The other two are via an IDE (such as JBoss Developer Studio or Eclipse with JBoss Tools), and even via Maven.
For people that may not be comfortable with the scripting as you say, then you can't go past the Manage Deployments section in the Console GUI. The Console deployment does not move/copy the application to the deployment folder, so using both the Console and the Deployment folder can make for some effort in file management.
For bash-savvy users, the CLI is great, and is often recommended by the AS7 team as a preferred method of deploying and managing applications. The user guide section on the CLI is located here: https://docs.jboss.org/author/display/AS7/Admin+Guide#AdminGuide-RunningtheCLI.
An example of all deployment methods can be found on this YouTube video by one of the developers: "5 ways to deploy your application to JBoss AS 7". Hope that helps.
You only need .dodeploy for exploded deployments. If your deployment is a zipped war,ear,etc. then it will be picked up automatically.
Change your deployment mode from manual to auto which does this deployment automatically.
Steps :
1) Open your jboss configuration file : standalone.xml.
2) Look for deployment-scanner and add auto-deploy-zipped="true"
<deployment-scanner scan-interval="5000" relative-to="jboss.server.base.dir"
path="deployments" auto-deploy-zipped="true" auto-deploy-exploded="false"/>
3) Restart your Jboss.
Now it will automatically pick your zipped version of ear/war/jar/sar files for deployment.
You can still use your old scripts without using any markers.
This can be changed in the standalone.xml by changing the "auto-deploy" attributes on the deployment-scanner element in the standalone.xml configuration file.
More details can be found in the deployments folder README.
I have an application which is a portal application and I want to allow other users add their applications to it. In order to do this I need some way to be able to access their applications in mine. Is this possible?
You cannot put WARs inside of other WARs. You need an EAR file to contain WARs, EJBs, etc. One way to implement inter-WAR communication is to package that logic directly in the EAR. It all depends on what you're trying to do.
the way to do inter .WAR communication is by the method
http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletContext.html#getContext(java.lang.String)
ServletContext.getContext(URIOfOtherWAR_resource)
I've used this succesfully for doing what you're talking about.
Maybe you need a plugin system or portlet, so your user will not develop a war application but include their portlet inside your application (war). There's a standard : JSR 168 and several implementations :
http://developers.sun.com/portalserver/reference/techart/jsr168/
As others have pointed out, embedding WARs inside WARs is not an option. However, I may have a workaround for you.
Most Web containers I'm familiar with have a "test deployment / auto deploy" mode / capability, where they will automatically deploy an application if the WAR is copied into the right directory.
Your portal application could certainly allow uploading WARs, and it could store the uploaded bytes in a given directory under a given file name. Your Web container could do the rest. You could then link to the new application from your portal, or whatever. All this is relatively easy to do.
However, be advised that this is a horrible idea if there is any security concern whatsoever. You are essentially allowing your users to execute arbitrary code on your server. Unless you completely trust all potential users to be both non-malicious and perfectly competent (think infinite loops), you are asking for a lot of trouble here.