If I take a look at Hot redeploy in Play and Automatic restart in Spring Boot, it seems very similar. Is there any principal difference between implementation of these features in these projects?
In Play it's out of the box, while in Spring Boot you have to install the Dev-tools.
In Play you have to hit the reload button of your browser in order to reload but there is an awesome plugin made by James Ward which triggers a reload when you make changes to a file.
Warning personal opinion:
Working on both frameworks, using both plugins, the Play version is much cleaner and works better, save changes, see how the browser refreshes, immense productivity boost.
Also in performance, if your Spring application is a little bit bigger than usual, it takes a little bit longer, while in Play it's always fast.
They are essentially the same in terms of implementation in that they both create a new application classloader to load in the new changes and discard the previous one.
Note that here are a couple of options for running a Play application to trigger reload:-
The following will trigger a rebuild and reload of classloader when a new request is received by the application, namely when you hit refresh in your browser. James Ward's plugin just saves you have to hit refresh.
activator run
The following will monitor your source directories for changes and will automatically re-compile any modified source on the fly. Although the server has recompiled the source and setup a new classloader you still need to do a refresh in your browser to see the changes (or use an extension like James Ward's).
activator ~run
Related
Currently I'm developing a Web App with Spring MVC and Spring Security using Maven to build the application and Tomcat as a webserver.
When I'm making changes in my JSP files, I can immediately see the changes (when the application is running) when I do a reload in my webbrowser.
However, when I make changes in my Java files (for instance in a Controller class), I have to redeploy the application (which takes 10 to 15 seconds) to get the changes working.
So my question is: Is there a way how to NOT do a redeploy every time when I perform changes in my Java classes?
Thank you very much!
We call what you would like to achive is Hot Deploy.
There are many different way to apply Hot Deploy, so the best way is to google for it.
If you use IntelliJ + Tomcat then this article can help you:
Intellij IDEA – Auto reload a web application (hot deploy)
If you use Eclipse IDE this can help: How to configure hot deploy in
Eclipse
You can find some info here as well: how to enable hot deploy in
tomcat
Thanks for your responses. I tried some more options and this is working fine for me:
Go to Run / Edit Configurations / “Deployment” tab, clicks + icon / select an “exploded artifact”
Select “Server” tab, update the following options :
On ‘Update’ action -> Update classes and resources
On frame deactivation -> Update classes and resources
Run web application in Debug mode. Try to modify some codes or resources (Java files, ...), the modified classes and resources will be reloaded automatically without any redeploy or something like that.
You can do a hot deploy using this plugin JRebel but if your build is only 10-15 seconds I think that a hot deploy is overkilling
I'm using the Liferay platform to develop a company portal (version 6.1.1). This portal already have a considerable implementation and database size (174 tables).
As expected, from the beginning the build services and deploys were getting slower as the project were growing.
The problem is that with the current implementation it takes like 20 minutes to perform the 'build services' and about 3/4 minutes to perform a deploy which happens even if i change a simple string in the code. And for every 3 deploys it´s necessary to restart the server because it seems to froze.
My machine specs are:
Intel core i5-3210M
8GB RAM
64bits
And this are the memory args of my liferay server:
-Xms1024m -Xmx1024m -XX:PermSize=1024m -XX:MaxPermSize=1024m
As you know this waiting times have a huge drop of performance in the implementation.
My questions are: is this normal? If yes, what kind of alternatives do i have in a future portal implementation?
Thank you.
174 tables are quite a lot - more than Liferay itself brings. I'd recommend to spread out your application into separately deployable plugins - they don't (technically) need to be in the same plugin, service builder allows you to use the services across different plugins.
Proper dependency management should help you to isolate the functionality that you'll extract into separate applications. Declare which application needs which other application deployed before, and you can access the services cross-context.
To answer your comment-question, sampling with only two projects: Create them, both with service-builder. Let's call them common-portlet and app1-portlet. Obviously, app1-portlet uses components (and services) from common-portlet.
In app1-portlet, edit docroot/WEB-INF/liferay-plugin-package.properties and add the line
required-deployment-contexts=common-portlet
This will make sure that app1-portlet is only deployed when common-portlet is available. Also, common-service.jar, the API of common-portlet, generated with service-biulder, will automatically be put on the classpath of app1-portlet, in other words, you can call the services that you implemented in common-portlet.
Assuming your more abstract portlets have a more stable interface (typically this indicates a proper architecture), changes to app1-portlet (or app2-portlet etc.) will only affect the portlet where you make a change in. Even if you have a change in common-portlet, service-builder will be relatively quick, however, on interface changes you still need to recompile everything, but that's the nature of dependencies. If you don't change your interfaces, you'll only need a redeploy.
I want to get a development experience like I get with Play! framework with JAX-RS (with Jersey for example). More specifically I want to use some kind of background compilation and run the compiled code immediately so that I have almost no waiting time.
My first attempt was to use NetBeans background compilation and Maven with plug-ins for Tomcat and Jetty which are restarting the application in the running container. But restarting took too long. I'm wondering if I need to restart the application if code changed or if something like Grizzly or Netty instead of a Servlet container would help.
Any ideas how to get fast reloads with JAX-RS?
Try this,
you need to add the dependencies. It uses jreloader (open source).
ant archetype
Edit:
People are still visiting this post after two years. Now there's a complete alternative for hot reloading and the project is active again http://dcevm.github.io/
You may need to use this as well https://github.com/HotswapProjects/HotswapAgent
Take a look at gretty: https://github.com/groovypp/gretty
It should work with jersey and you should see fast runtime reloads.
JRebel does this: http://zeroturnaround.com/jrebel/
I'm wondering is it possible to "hot develop" spring application.
For example. In Play framework when I change something in template or even controller or configuration I don't need to republish the application or restart server. I just refresh the page.
Is this kind of quick and easy work is possible with spring framework ? Does it depend of server?
If you want true hot (re)deployment you'll probably need to use something that modifies Java class-loading like JRebel.
Spring itself doesn't tell much about redeployment and stuff, but in most cases you can reload your templates without restarting depending on your ViewResolver.
Furthermore in some environments (for example in OSGi) it is possible to hot-deploy classes, resources and nearly everything. Having a properly configured SpringSource Tool Suite and eg. Virgo WebServer it is possible to achieve hot deployment and as such you can reload the running classes as you save them.
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.