Hot Swapping Webapp Files - intellij-idea

I am running my application in production mode (war is not exploded) on a Glassfish server and I want to know if it's possible to hot swap my front end files?
Currently when I do a hot swap, it only does it in the backend (it being Java). Is it possible to also do it for files under the webapp directory?

The Run/Debug Configuration window for Glassfish-within-IntelliJ supports hot deployment:
For exploded artifacts, the available options are:
Update resources. All changed resources are updated (HTML, JSP, JavaScript, CSS and image files).
Update classes and resources. Changed resources are updated; changed Java classes (EJBs, servlets, etc.) are recompiled.
etc
Looks like you need to choose the Update Resources option.
More details in the docs.
Update 1: for packed (i.e. unexploded) artifacts the available options are:
Hot swap classes. Changed classes are recompiled and reloaded at runtime. This option works only in the debug mode.
Redeploy. The application artifact is rebuilt and redeployed.
Restart server. The server is restarted. The application artifact is rebuilt and redeployed.
There is no support for hot deploying 'front end files' in a unexploded artifact.

Related

AEM+Filevault+Intellij integration

I am working on AEM 6.2 with crx mapped to local file system using filevault. I also have my code in svn for ui.apps which is in intellij.
Problem: If i change any component dialog, first i need to sync my crx with local file system and then copy changes from file system to svn folder.
I tried to integrate intellij using vlt commands but getting message
File is under version control
Is there a way i can club all three together so from IDE i can update code repository?
You can use the IntelliVault plugin to push content to or pull it from CRX.
In such a setup it doesn't matter where your CRX actually sits. You keep a set of files under version control and the IDE plugin allows you to push/pull to/from CRX whenever you want to. It uses the Vault command line tool under the hood.
It's probably not exactly what you're asking about but it works for me.
Another option is to use AEM Sync from the command line. It's a Node package that you can use to listen to file changes. Have it running in the background and changes you make in your IDE will be automatically reflected in AEM. Be careful about large changes such as switching Git branches. These can kill AEM Sync and potentially interfere with AEM itself if you happen to change a very large number of files while AEM Sync is running.
Aem sync works like a charm - https://github.com/gavoja/aemsync
Go to Terminal> CD to the directory where you have installed aemsync via npm > hit the command provided at the github page.

Is hot reload possible in Glassfish at least for development purposes?

I had this question ever since I learnt about Erlang and it's possibility for hot replacements of separate modules and even functions on a production server.
We are developing a project in Java for Glassfish 2.1. It's basically an .ear file consisting of a bunch of .war modules.
So, every time, I make a minor change in the code of one of the modules, in order to check that change I have to redeploy the whole ear on my development server. Is that really how it's supposed to work?
Basically we have several levels of replacement - are they even possible?
The war module. Happens during a big number of commits by several developers. Is it possible to replace just this module on the working server without redeploying the whole ear file.
The java classes (action handles and etc). Is it possible just to replace the bytecode of the classes that were changed?
The jsp pages. I think they are launched indepently by the special jsp interpreter in glassfish. So this one definitely should have the possibility of the hot reload of a single changed page.
I know I can perfectly replace the different parts of HTML design, such as css or js files, or image files. But what about the bytecode files described above?

DropWizard testing

As I am using eclipse and just set up a dropwizard server. On the command prompt I typed in java -jar target/hello-world-0.0.1-SNAPSHOT.jar server hello-world.yml and is running. Yet when ever I make a change to my eclipse file, like changing the yml file for example it doesn't update. I have to crtl+c and re-run what I typed in above. My question is, is there a faster way of testing so that it updates every time I change something or I just have to deal with the testing. Thanks.
Run from within the IDE
Different Java IDEs permit more efficient workflows. For example, in an IDE you can run up your application using a Runtime Configuration that executes your Service.main() method with parameters of server hello-world.yml. This will save you endless Maven builds.
Unfortunately, with Eclipse the hot swapping of code changes is often cumbersome, so I would recommend that you consider Intellij which is more reliable when it comes to hot swapping code. Even then hot swapping can be risky.
Sometimes a restart is unavoidable
That being said, in your situation hot swapping won't help. You are changing the startup configuration file which is only read at startup. You will have to restart to see the changes unless you create your own dynamic-refresh-on-file-hash-change mechanism (not advised).
One alternative is to put much of your configuration testing in unit tests and verify that your code is responding as expected.
Static assets give an optimal workflow (no restarts)
You may encounter a situation where you only want to change static assets (like JavaScript files) in which case Intellij will allow you to simply recompile on the fly and will copy the changed assets into the /target directory and have them immediately picked up by Dropwizard without a restart.
If you wanted to go one step further you could enlist the services of Grunt.js so that it continuously monitored the src/main/resources/assets (or similar) for changes and then automatically update your /target for you. Again, Intellij will autosave on focus change so this would lead to an optimal workflow where you change the asset, wait one second, refresh browser and see the immediate result.
I wrote a lengthy blog article covering Dropwizard and Ember Data a while ago if you want more details on this approach (and single page web application development in general).

Where Jboss7.1 take war application to deploy

I've deployed the jboss-as-helloworld-errai application in my standalone jboss7.1 instance, and I deleted it later ( in the */standalone/deployments folder). But every time I restart my server it redeploys that application.
Is there another place where jboss reads the application to deploy?
Best regard
Did you delete the file while the server was running?
Probably, JBoss still finds a deployment information in one your /standalone/configuration/standalone*.xml files (at the end of the file). JBoss unpacks its deployments in one of the /standalone/tmp/vfs/temp* folders. As long as it finds a deployment in your configuration file, it will start the application.
The deployment binaries are located under the standalone/data/content. These would also need to be deleted. The best solution is to properly undeploy the application via CLI, the maven plug-in or the web console.
This does not sound like expected behaviour. Can you please confirm the steps that you are taking when using the deployment folder? For example:
Deploy
Copy application file to /standalone/deployments folder
Deployment Scanner creates a .dodeploy marker file
Deployment Scanner picks up application and creates a .deployed marker file
Application confirmed as deployed (checking the Management Console to confirm)
Undeploy
Application deleted from /standalone/deployments folder
Delete application (or) delete .deployed marker file
Deployment scanner undeploys the application and creates .undeployed marker file
Confirm application removed in console
Restart server
Confirmed removal is persistent
The README.txt file in the deployments folder shows the simple undeployment workflow in one easy step in the command line.
rm $AS/standalone/deployments/example.war.deployed
Documentation
You can read more about the deployment scanner in the official docs. There's a topic about the scanner marker files, as well as a parent topic about the scanner and deployments in general. If you are finding issues with the scanner, it's a bug. You might like to test the expected behaviour, and also try the Management Console.
Red Hat Docs - Reference for Deployment Scanner Marker Files
Red Hat Docs - About Application Deployment
Potential Issues
Don't confuse the Deployment Scanner subsystem (which watches the Deployments folder for the Standalone server instance) with the Management Console or Management CLI deployments process. You might be better off using one of the Management tools instead of the hot deployment capability to allow for more control over the state and presence of your application.

When a class file change, Can I make the glassfish server not restart but still reflect the change?

When a class file change, Can I make the glassfish server not restart but still reflect the change ?
I mean the glassfish sever doesn't redeployment(or publish) the application, but only redeployment the class that has changed.
There are a number of ways to redeploy an application onto GlassFish 3.1 that do not require that you restart the server.
The method I would recommend is 'asadmin redeploy --name foo --keepstate=true foo.war' (or use directory deployment for the web app...)
You can look at the man page for the redeploy subcommand of asadmin to learn more about the details.
I hardly ever create a deployable archive file.... I usually do directory deployment, which eliminates the time that would get used up creating and then exploding the archive file.
By using directory deployment I can also apply tweaks to jsp files and other static content to test them without a rebuild/redeploy step.
I like to use the keepstate option while I am doing development.
Another important step that you should take to avoid unnecessary restarts is to move to an open-source OS like Linux or Solaris (away from Windows) which has few file locking problems.
If this is meant to be done while development, you can give a shot to JRebel.