Intershop code deploy workflow - java

I'm not sure if this is a valid question, but what is the least amount of code change before you need to stop the application server, run gradlew publish, gradlew deployCartridges and then start up the application server?
It's not clear to me to what extent can I make code changes.
What would be the preferred development work flow?

First, make sure you have intershop configured correctly for code reloading. You should have these settings set:
# switch auto reload on for all Intershop artifacts
intershop.extensions.CheckSource=true
intershop.queries.CheckSource=true
intershop.pipelines.CheckSource=true
intershop.pagelets.CheckSource=true
intershop.webforms.CheckSource=true
intershop.template.CheckSource=true
intershop.template.CheckSourceModified=true
intershop.template.CompileOnStartup=false
intershop.template.PrintTemplateName=true
intershop.template.PrintTemplateMarker=true
intershop.template.isfilebundle.CheckSource=true
intershop.localization.CheckContent=true
#let intershop run on all cpu cores
intershop.cpu.id=
#dont let session timeout so quickly
intershop.session.TimeOut=60
# switch all preload functionality off
intershop.pipelines.PreloadFromCartridges=
intershop.pipelines.PreloadFromSites=
intershop.pipelets.PreloadFromCartridges=
intershop.webforms.Preload=false
intershop.queries.Preload=false
# Monitor the urlrewrite.properties files for modifications
# and refresh when needed.
intershop.urlrewrite.CheckSource=true
# The time interval in seconds, after which a lookup should be performed
# if CheckSource is "true". 0 means every time (not recommended).
intershop.urlrewrite.CheckSourceInterval=5
These setting are usually in the development.properties file under eserver/server/share/system/config/cluster.
Also make sure that your environment is set to development. The file eserver/server/share/system/config/cluster/environment.properties should have this configured : environment=development. This setting makes intershop load your settings in the development.properties file.
Disable the page cache (in SMC), including the SLDSystem (urlrewriting is cached here). I have fallen into this trap more than I like to admit.
With this setup, you can just edit/save and refresh the browser for isml/pipelines/pagelet,query file,webforms,filebundles,urlrewriting and localization labels. Everything that is not java basically. When it comes to java things get a bit complicated.
For a simple pipelet you can run gradlew publish and it should reload. However, it won't reload other classes that it depends on that has been modified. Sometimes it doesn't reload at all, I have to admit, I don't know why this happens. For new pipelets and changes in the component framework, u always need to compile/restart intershop.
Like Rainer mentioned Jrebel can reload your plain java classes and I can also highly recommend it. However, you would need a license for this.

With code change you mean Java code?
In Development mode you can enable the reloading of pipelet code. There is a special classloader from Intershop for this.
You need to restart the server if you modify any other classes unless you use JRebel, or some other classloader which can detect code modifications.
You of ofcourse have to compile the code with "gradlew publish" for all this.
You also need to restart the server if you made changes in the configuration framework.
While developing you don't need "gradlew deployCartridges" for code changes since the server is reading code from your project directory.

Related

How to hot deploy code in Tomcat running in debug mode

How to configure Tomcat server in debug mode for Eclipse to support hot deployment? Hot swap or hot code replace without restarting the Server, which can speed up the development.
We can make some changes in tomcat to support hot deploy, there can be different ways to achieve that.
One of the simplest way is making change in tomcat setting in eclipse/STS,
Double click on the Tomcat plugin, refer to publishing tab, make sure "Automatically publish when resources change" is selected.
In the Tomcat Plugin page, click on the Module view, make sure Auto Reload is Disabled. Default is enabled.
**NOTE: **
This is applicable in case of debug mode only
Only method code changes is supported, new added method,class, database script,tomcat is required to be restarted.
Reference:
Click here for mkyong.com link
I'm not sure that it is possible without redeploy and without external tools. For case to update only updated classes/resources I use HotSwapAgent tool
But this tool have some limitations and I wouldn't recommend it for prod.
Hot swap will change the modified class byte code on disk, which will trigger tomcat redeploy. Also hot swap supports only simple changes within method body.
So hot swapping on tomcat is not working out of the box.
There are third party solutions for this, like JRebel.

How to run some code as soon as Eclipse has started?

I'm developing an Eclipse plugin that needs to figure out the amount of time that it took for Eclipse to start.
I can get the amount of time since JVM startup in my plugin by using org.eclipse.ui.startup extension point and recording the time by using ManagementFactory.getRuntimeMXBean().getUptime() or eclipse.startTime system property.
However, during startup, Eclipse might ask the user for workspace location and this will be counted in the JVM startup time. As my plugin is trying to measure the non-user-interaction time, this makes the above approach rather useless (unless user has selected a default workspace location but there is no guarantee that this is the case).
Ideally, I would like to know the moment in time when user dismissed the "choose workspace" dialog (or, if user was using default workspace then equivalent moment). Or some other moment as close to that as possible.
I've done a bit of research and there does not seem to be any official extension point for such a thing.
I have a feeling that something like that might be possible with a custom OSGi bundle running at early enough start-level (2). However, I'm not sure if it will actually work:
maybe workspace selection dialog is shown from some Eclipse core plugin, started at start-level 4 like the rest of the plugins?
even if I manage to write such a bundle, do I need to modify Eclipse config.ini to list it there? Or how do I guarantee that it will be started at certain start-level (if it is not a real Eclipse plug-in but a custom bundle)? This article mentions p2.inf but my experiments with it have not been successful yet.
As I do not have much experience with OSGi and Eclipse plugin development, maybe I have missed something rather obvious and the solution is much simpler than what I envisioned?
UPDATE
After a bit more research, I found an early extension point: StartupMonitor service (usually used to customize the splash screen or provide some other sort of startup progress monitor, see here for more details). That could be a possible candidate for my needs, now I just need to figure out, how to make Eclipse aware of it (I suspect I need to add it in config.ini).
Another option I'm considering is to implement a JVM agent and instrument Eclipse IDEApplication class, adding some code snippets that I need. And then add that JVM agent in JVM arguments in eclipse.ini. Could actually be the easiest.
I took the JVM agent approach. Luckily P2 has ability to perform some extra actions via touchpoints -- I can use that to add the JVM agent option automatically at plugin install time and remove it when plugin is uninstalled.
Sample p2.inf file (goes inside META-INF):
instructions.install = \
addJvmArg(jvmArg:-javaagent:${artifact.location}/agent/my-agent.jar);
instructions.install.import = \
org.eclipse.equinox.p2.touchpoint.eclipse.addJvmArg, \
org.eclipse.equinox.p2.touchpoint.eclipse.removeJvmArg
instructions.uninstall = \
removeJvmArg(jvmArg:-javaagent:${artifact.location}/agent/my-agent.jar);
instructions.uninstall.import = \
org.eclipse.equinox.p2.touchpoint.eclipse.addJvmArg, \
org.eclipse.equinox.p2.touchpoint.eclipse.removeJvmArg
(above sample assumes that you have bundled your JVM agent inside the plugin, in agent subdirectory).

Does GWT 2.6 Super Dev Mode supports hot swap (recompile) and how?

Recently I started to use Super Dev Mode to get look&feel of it. It took me couple of hours to get it up but I didn't find out how and actually can you use SDM for faster development using hot swapping.
Using Dev Mode all I had to do is save my changes in IDE and refresh the browser page. Now my code changes needs to get transferred to the code server to be recompiled? Am I right or am I missing something obvious?
All you have to do is click the DevMode On bookmarklet and Compile button. This is for client-side code only though.
For server-side code, whereas DevMode can serve your webapp and you can reload it with a single click to get your changes in, CodeServer only deals with the client side, so you have to deploy your webapp to a server (that said, you can use DevMode if you want). You then need to re-deploy your webapp when you make changes to your server-side code.
See https://stackoverflow.com/a/18333050/116472 for a detailed step-by-step howto.

Refreshing Swing application with Eclipse/MyEclipse

Say that we are writing a Java Swing application and we use Eclipse or MyEclipse to develop it. In web applications, you make code changes, you save and your ant deployment file takes care of the deployment of the changed files. Then you just refresh or hard refresh the web page and the changes appear there. Can we do the same thing for a Swing applications so that we don't have to close and open the program from the beginning every time we make a change?
I don't think so because you need hot code replacement ! Maybee using another framework.
You can't simply do that because once JVM is started, it loads the class files once and will not reload it untill next loading request. But you can use ClassLoader to load modified class files dynamically.
The following two articles may help:
IBM article on "hot class swap"
"Who Said Runtime Class Reloading Is Hard in Java?"
The first one is in Chinese, but you can look at the code and the result. I think the second article is more helpful for a GUI application.
In MyEclipse you can start your application in debug mode instead of run mode and changes you make will be pushed to the target VM; if changes you make cannot be replaced you'll see a dialog informing you the replace failed and you will need to restart your application. You don't need to place any breakpoints in the application, just starting in debug mode is sufficient.
As Guillaume states above, changes to the class structure will typically not be hot-synched, but changes within existing methods should be fine.
Obviously, how successfully hot-synched changes affect your running application would depend on your application design.

Can I set GAE's dev_appserver to automatically reload context when I change .class files?

I'm using Google AppEngine with their built in web server. My development goes about in a simple way: I make changes to my .java sources or .jsp and compile using ant and to see the changes I have to restart the development server.
I'm wondering if there's a way I can avoid this last step of restarting my development server - somehow refresh the cached classes context of my web-server. The options provided by Google on this dev server are quite limited and am wondering if there's a better way.
I would like to avoid using something like JRebel which I could buy, but for this simple project I'm just wondering if I can remove the burden of restarting my web-server... otherwise I'll live with it.
I realized that you can just touch
appengine-web.xml to force server context reload. Also loading the
page under /_ah/reloadwebapp will reload the servers context - even if
it gives you a 404, it will still reload the context.
In debug mode, the JVM can perform some hot swapping - I know and Intellij IDEA does it, i m sure other debuggers in other IDE's does it too.
Start the app server with the debug flag (-Xdebug -Xrunjdwp:transport=dt_socket,address=127.0.0.1:8000 for example), then connect the debugger to the app server.
Then, make a change to the source that is not a method signature or class field change. Recompile, and voila, the debugger hot swapped the class into the jvm being debugged!
This only really works semi-well. But it may just be enough.

Categories