Environment: WinXP.
RAD: Version: 7.5.3 (Eclipse 3.4.2)
Websphere 6.1
I have two web projects on my local RAD environment and 4 or 5 sub jar projects. When I change classes in debug and regular start mode, the files don't get copied to the server for runtime.
So, normally I have to restart the server completely or add/remove the project all together.
I may make a change to Servlet.java
When I do "publish", the ear/application seems to restart, but my changes are not there. So I normally restart the server. This is a productivity killer.
Additional settings:
* Publish automatically turned off.
* Minimize resources. Use workspace.
What can I do to make sure that the classes get copied over.
My theories:
I have parent_first/application for the class loader/war settings. Is that an issue?
Maybe I should remove the ear and add it back to websphere
I did a clean on the server?
Delete your application from the server.
Restart the server
Go to the admin console and ensure the application is not listed in the list of applications, if it is then delete it.
Restart the server
Deploy/publish again.
Unfortunatelly, RAD with WebSphere are very unstable environment.
From my experience, debug mode is causing a lot of problems. It's mainly what you describe, changes not being seen after republish, additionally very quick memory depletion. I'm using debug mode as last report.
In normal mode everything should (read: in most cases) work correctly. You add/change some classes and make 'republish'. Sometimes it's necessary to do clean on project before republishing it.
But when the Websphere is running longer together with RAD, I observe that often something get stuck. You have there clean option on the server, with is expected to clean the cache (which included also compiled classes). You should also observe memory usage. If it's nearing the limits of JVM (memory leaks are heavy) Websphere stops to function correctly, and you must restart it.
However, I sometimes get serious issues where the clean isn't helping, and then it's necessary to remove all applications, stop the websphere (close all projects and open then again) and then start Websphere and add all applications, restarting RAD in the meanwhile. But it's not everyday, maybe every month or so...
If you are really unlucky, RAD can break your workspace, which will force you to delete all project, delete project files (or do a fresh checkout) and import everything once again, or even start a new workspace (happens also with 'normal' Eclipse, ~1-2 years).
You are using the latest RAD so do I... here is my guide for solving this issue:
Enable the error log to see if you get intuitive info on internal RAD errors, in 7.5 it is available on "Show views"
If your changes are not deployed Clean project
If your changes are not deployed yet Rebuild project
If your changes are not deployed yet Redeploy project
If your changes are not deployed yet Clean server
If your changes are not deployed yet Restart server
Or:
- Use ant or maven to make deployments straighforward and ignore the pain due to websphere and eclipse having internal bugs (which you may see in the error log if it is fully enabled).
Regards.
Are your JSPs copied correctly? That is, when you make a change in one JSP, can you see change immediately upon browser refresh? If this works, then I see no reason why classes aren't also published. JSP auto refresh should work in normal and debug modes.
Now, is "build automatically" enabled? If no, your classes won't get compiled and transferred. Parent_first/application for class loading shouldn't be an issue.
Is the local app. server running in development mode? If not, it should be.
While developing, use debug mode. Hot deploy will assure changes to your methods are seen immediately. Changes in classes won't be seen (i.e. adding a method will require application restart).
Is your app. server using global security? I have it turned off and auto redeploy works without problems.
Class reloading has always been a problem while developing Java EE applications. Try do erase that ear file from your WAS and redeploy it again.
If all else fails, try JRebel.
Related
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.
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.
Whenever, WL is stopped it doesn't delete its temporary directories .. i.e.
domains/mydomain/servers/myserver/tmp/_WL_TEMP_APP_DOWNLOADS
/domains/mydomain/servers/myserver/tmp/_WL_user/
/domains/mydomain/servers/myserver/stage
and because of this, when we deploy new application, it doesn't deploy some JSP or some classes and it keeps the old version of those files. resulting in lots of business errors + runtime error.
Is it a known issue ? How can we tackle it?
In general WL will cache your deployment and won't redeploy unless it is asked to. But it depends on how you deployed your application and if the server is in production or development mode. See development deployments and production deployments.
One easy fix, go to the /domains/mydomain/servers/myserver/ directory and delete:
tmp
cache
logs
and leave the data and security directory. Then restart. This will force WL to redeploy.
My original answer included a delete of the data directory but as #g-demecki and #j23 point out below, that can mess up an admin server. I believe it is OK to delete the data directory on a managed server.
I never run into such issue in production mode, if you are running in development mode and using auto deploy, please follow best practices documented
You must touch the REDEPLOY file (alter its timestamp) any time you
wish to trigger redeployment of an auto-deployed application. Even if
you modify an application while a server is shut down, you must touch
REDEPLOY to ensure that changes are applied when the server next
starts up.
Redeploy should update the tmp - maybe your timestamps are not ok ?
Stop and start will not refresh tmp as it is still used after restart.
From my experience it is enough to delete tmp when server is down to force unpack WAR (it is a matter of unpacking WAR to tmp by Weblogic, this is the main task done during deployment).
e.g. in your case
/domains/mydomain/servers/myserver/tmp/
In my case, a simple reboot of the Linux machine fixed the issue.
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.
I used to run Tomcat separately on my machine. I had an Ant script that would rebuild my project, deploy it locally, and restart Tomcat. That all worked ok, but I wasn't able to debug the web app inside Eclipse.
So I learned how to setup Tomcat inside Eclipse and got my web app running. Now the problem is that I don't understand fully how to manage it this way. Eclipse is set to automatically build my project on changes, but those changes don't seem to always be reflected in the web app. Sometimes I have to manually build the project and manually "clean" the server for the changes to be reflected.
Are there rules somewhere about how to manage this setup? For instance, if I only change a JSP then will it automatically be synchronized? If I change a servlet class, then I need to manually rebuild the project? Are these rules consistent, or should I just manually rebuild and clean every time?
I would really appreciate it if someone could give me the best practice rules or point me to a good resource to learn how to manage this environment.
PS. I am using Eclipse 3.4.1 Java EE package and Tomcat v5.5
You can use Eclipse and Tomcat in the way you mention. First the basics of how to set it up:
In the Servers view setup a new Tomcat server pointing to your TOMCAT_HOME
Make sure your project is an Eclipse "web project". You may need to create a dummy one and copy over some of the files in .settings (look at the wst files).
Deploy your project to Tomcat by right clicking on the server in the Servers view and "Add and Remove Projects..." to add your project to the server.
You can run your server and test it out just like you were running Tomcat outside of Eclipse. If you run the server in Debug mode you can set breakpoints and step through the code.
As for when you will need to restart the server Eclipse is usually pretty good about auto-deploying the changes. You will pretty much never need to restart for changes to jsp pages. If you change a class it will auto-deploy the change (usually) if you change the body of a method. If you change the signature of a class (add or remove a method or change args for it) you will almost always need to restart. Any changes to configuration files (web.xml or similar) will also almost always require a restart.
To restart just click on the "Debug" or "Run" button in the Server view. All your changes will be redeployed into Tomcat.
One thing to watch out for is that in the default configuration your "webapp" directory in TOMCAT_HOME will not be used. Instead it will use a folder under your Eclipse workspace directory (WORKSPACE/.metadata/.plugins/org.eclipse.wst.server.core/tmp0).
Normally you should republish the application to get latest changes, don't forget to synchronize with file system first in case your files modified extrernally.
You can specify that your application is automatically reloaded when modified, look for Auto-reload attribute in server.xml of your server configuration project. When set to true, tomcat will automatically reload your application. It's not always a good idea by the way.
Modified JSP's should work automatically, no need to restart the applciation.
If you change the structure of a class that has already been loaded and used (add/remove members, change method signature etc.) your code changes will not be reflected. This is not an eclipse issue but a JVM issue. If you make simple code changes, like logic changes inside an existing method, your changes will take effect after the class is compiled and re-deployed.
Regardless of that, if you change a public constant, you have to rebuild your project(s).
I found two things important to understand:
Eclipse does not automatically realize if files were changed outside of Eclipse. clicking Refresh on a project does that, so does F5. You can also change a setting to refresh automatically, which, however, does not detect changes instantly (my gut feeling says up to 10 secs delay)
Working with servers has the concept of "Publishing" files to Tomcat. This normally happens automatically within a second after any change. Changing many classes can cause many server reloads, which can be a drag if a context reload takes some time (as complex Spring apps certainly do). So I changed a setting to not publish automatically (double-click Server instance)