I've got an Maven-WAR-packaged JavaEE6 project here which has an EJB service layer and a JSF2-based web layer.
Every time I try to update source by JRebel plugin (Netbeans 8.1) it takes almost the same time than a full redeployment (considering even a Glassfish restart).
Does anyone here faced this kind of problem? Any tips, guidelines for a quick solution?
In NetBeans, the automatic deployment of the changes is automatically enabled. Make sure that the checkbox is unset if you want to use JRebel. Chances are that this is the reason why updating the app takes time.
Right click on the project -> Properties -> Run -> unset "Deploy on Save"
If this is not the case, shoot the email at support#zeroturnaround.com - they should help.
Related
I have recently started developing an Eclipse plugin (which is basic stuff for now) and I am struggling with "default" way to run Eclipse plugin ("Run as Eclipse application").
The Eclipse is starting another instance with my plugin already installed in it (this is default behaviour).
The problem is that when I want to re-run my plugin project and I press "run" button again (or Ctrl + F11) (and the another Eclipse instance still running) I get following message:
"Could not launch the application because the associated workspace is currently in use by another Eclipse application".
The error makes sense, and when I close "testing" Eclipse instance I am able to run my plugin again.
The question is - "is it normal routine for plugin development?". Maybe I am missing something, e.g. special arguments for Eclipse?
This seems all pretty normal. The error message is since the run configuration is specifing a workspace and when you start a second instance using the same workspace it is locked and considered in use.
What I usually do when testing a plugin is to create a run configuration (click "Run...") where I disable all the plugins I wont need when testing. This makes sure that the test starts up a couple of seconds quicker. Make sure you save that run configuration as a *.launch file aswell, that makes it quicker to test the next time. Or it can be used to share the configuration.
There's a lot you can configure in the run configuration, such as eclipse arguments, vm argument, if you want environment variables set, etc. So be sure to experiment a little.
In your run configuration. Main tab->Workspace Data ->Location text box add this:
${workspace_loc}/../runtime-EclipseApplication${current_date:yyyyMMdd_HHmmss}
Note the suffix ${current_date:yyyyMMdd_HHmmss} by this every time you launch your application new workspace will be created. So you will not get any error message saying workspace is locked.
But be careful as the folder .metadata will be different for different instances as their work-spaces are different. Thus preferences stored/retrieved by different instances are NOT in sync.
You are probably missing one important point: Eclipse supports the Java hot code replacement. Therefore in many cases you can modify your Java code while your application Eclipse instance is running, save the code and continue without restarting.
If hot code replacement is not possible, Eclipse will tell you, so you always know whether the editing changes are applied to the running instance.
This works best with more recent versions of the JVM, so consider upgrading to the latest Java 7 version, even if you write code to be compliant with Java 1.5 or 6.
I'm working in a JSF project with Eclipse and Glassfish 3.1.2.
Every time I did a minor change and save it, Glassfish do the hot deployment, but is taking too much time to do that, about 20s, at least.
Can I do something do deacrease this time ? Is horrible develop something where you have to wait all time time everytime I change something.
UPDATE
This is how my project settings.
Just open the folder below, this surprise me, is this so many .jar files, is this correct ?
And this one:
My Glassfish configuration :
Any idea ?
There are several ways to deploy a GlassFish application. To speed up development/debuging we need a way to instantly deploy web applications. One of the ways is to use hot deployment feature, another lesser known feature is ‘directory deployment’. You simply point GlassFish to your development directory and let it pick up and deploy application from there. No packaging and re-deoploying hassles. The catch is whenever you want to re-deploy your application you just need to touch a file called .reload which should be present in your web folder.
Following is the command and directory structure you can use.
–|myproj
–|–|src
–|–|web
–|–|–|WEB-INF
–|–|–|–lib
–|–|–|–classes
–|–|–|–web.xml
–|–|.reload
GLASS_FISH_HOME/bin/asadmin deploydir full_path_to_you_web_folder
I have started a new job from a couple months, I work as front developer in a company where up until now everyone was using classic development patterns, but the goal is to move to a new ajax/rest services approach and that's what I do.
In our local development environment our apps run on Resin which runs inside Eclipse and get deployed as war files to C:\Resin\resin-pro-4.0.27\webapps
My problem is that I work mostly on css html and js files, static resources so I shouldn't need to restart Resin and wait 15 seconds (when it doesn't crash) to see the effect of every little piece of code I change.
Other problem is that I need to edit some files in external editors (sublime text for js, Crunch for LESS); I managed to make Eclipse open the external editor but even with the "Refresh using native hooks or polling" build option it takes a while to realize files have changed and restart Resin.
I also tried just working on the unpacked war in C:\Resin\resin-pro-4.0.27\webapps\appname but even there it takes like one minute before you can see the changes on the browser (is there some caching going on the server? can I disable it?)
I welcome any suggestion as all this is really hurting my productivity
inside Resin.xml <host><web-app> add:
<cache-mapping url-pattern="*.js" expires="0s"/>
<cache-mapping url-pattern="*.css" expires="0s"/>
<cache-mapping url-pattern="*.htm" expires="0s"/>
<cache-mapping url-pattern="*.html" expires="0s"/>
This used to work for me (in resin.xml)
<!--
- For production sites, change dependency-check-interval to something
- like 600s, so it only checks for updates every 10 minutes.
-->
<dependency-check-interval>2s</dependency-check-interval>
Also check resin.properties for a variable definition in newer versions.
However I'm currently having problems picking up changes without a full redeploy.
We use Eclipse (Indigo, with STS). Certain of our projects take inordinately long to build. Often the progress indicator sticks on, say, 87%, for 30 seconds.
I'm trying to find out what Eclipse is spending it's time on during the build cycle. I hope to be able to optimize the build or disable components that are causing it to be so slow. I'd like to see a log file saying ("compiling java code", "processing resources", etc).
I've poked around the log files in the .metadata directory. I've looked on the Eclipse site for tips. I've tried using "-debug" when starting Eclipse. I still can't find the information I'm looking for.
Is there any way to get Eclipse to spit out a log of what activities it is spending its time on when it builds a project?
What kind of projects are these? Java? Dynamic Web? Two things to look at for hints about what's going on are in the project Properties dialog; look at the Builders section and the Validation section. Try disabling the validations to see if that makes a difference in your build times.
To get some insight into what's happening at the times when the build seems to hang, try setting the -debug and -consoleLog options, as described here.
Disable your virus scanner software for your workspace and project directories. I increased the speed of my build in that way.
You can go to edit Windows->preference->general->workspace->build order to edit the default that exist according to your project need.
And check the maximum number of iteration when building with cycle.
I hope it works.
Since eclipse is a Java application, the usual debugging tools are at your disposal. In particular, you might try connecting to eclipse with JConsole and inspect the thread dump taken when the build "hangs", or run eclipse within a profiler.
You might find out things like a validator trying to download an xml schema, and waiting for the timeout since eclipse is not configured to use the corpoate proxy server - something which is very hard to find out by other means ;-)
Look into Apache Ant build scripts. Eclipse has support to auto generate them as a starting point instead of coding the whole thing by hand. The shop I worked in used tuned ANT scripts to optimize and control build order. We then piped output to log files using shell scripts.
You can try and replace with this aapt . My build for a particular project went from 3 minutes to 41 seconds....
This is an old post but thought of sharing my solution. I was using eclipse Luna and I noted that when you keep on working on a GIT branch without checking into git over the time the build becomes very slow. In my case I just deleted the folder .git and the file .gitignore and the build was very fast. Please note that this will disconnect eclipse from git, therefore use this aproach only if you know how to connect back to git branch using git commands.
I am getting a lot of errors when starting RAD7. The server doesn't respond to class changes. Sometimes the server won't start. Sometimes RAD will not acknowledge modules that I added to the server. It is kind of buggy.
I know there is metadata in the workspace, are there safe ways to clean the metadata or RAD in general?
Where RAD = Rational Application Developer
Another tip is to remove all projects in your Servers view in Eclipse, stop your server, start your server, open the admin console of your server and see that everything is gone in there as well. If you still see configured apps, remove them in the admin console. Shutdown server, start again and check for a clean startup. This ensures that your Eclipse server plugin and the server are in sync. Now you can add your projects to the server again; maybe this will improve the stability.
If not, a more drastic measure is to remove your server config in Eclipse (don't remove the server itself) and add it again in the Servers view.
You can also try to disable automatic publishing. You can go to Preferences->Server and uncheck the "Automatically publish..." If you are using WAS you additionally can double-click on your server in the Servers view, and go to the "Automatic Publishing" section and check "Never publish automatically". This might give you more control over when stuff gets published to your server, although it sometimes has a mind of its own and keeps publishing automatically in some cases.
eljenso has posted a good half of the answer. For the server not picking up resources, verify you are publishing. Right click the server and hit publish (I personally leave auto-pub off) The admin console / uninstall ear / then re-adding the ear is another way to go, however in RAD I've never needed to do this. In WID you need to do this as the publish is hopelessly broken in that God-forsaken tool.
RAD fixes:
Another half of the puzzle that you haven't touched on is making sure your project workspace is all up to date. Sometimes you will get bleeding (build errors) even though you know it's crabbing about nothing. When this occurs, close all the projects, optional step: shut down rad and re-open rad, re-open projects, refresh all projects, then do another build/clean.
ClearCase fixes:
If you happen to be using clearcase you're really in a world of hurt when things bleed for no reason. Before you do what I listed above, you'll need to do an update, restore (yes I'm aware update is supposed to do what a restore does and more - but it doesn't because it operates off of cached data, so it only updates what it thinks it needs to update. Unfortunately the caching algorithm is flawed), then refresh. This will guarantee all the files have been pushed to your file system properly, now you need to do the aforementioned step to make RAD pick up the [possibly new] file changes that just got pushed to your file system.
If you're working with a large project and you have RAD + clearcase, sit back and relax, it's going to be a while to let that restore finish. It's best to try just update, refresh + RAD fixes and see if that fixes the problem first. Restore should be your last ditch effort on a large project. (If you have a small project just do everything every time).
Eclipse can take a -clean parameter on startup. Perhaps this is what you are looking for?
If you really need to wipe all of the workspace meta, deleting the .metadata directory within the workspace should do the trick. Note that this wipes out settings, workspace layout, and even which projects are available (you will need to re-import all of your old projects, despite the fact that they are still in the workspace dir).
If you need to purge your metadata settings, try just deleting .metadata/.plugins/org.eclipse.core.resources first! That saved me quite a bit of trouble...