I am trying to debug a simple DropWizard application in Eclipse, in an attempt to familiarise myself with it. I can start the jvm from the command line like this:
java -Xdebug -agentlib:jdwp=transport=dt_socket,address=9999,server=y,suspend=n -jar dropwizard-0.0.1-SNAPSHOT.jar server config.yaml
And then connect to it as a remote java app.
Or I can find the application class (containing the main method) in eclipse and launch the application in debug that way.
Both these methods appear to successfully start the application in debug, and sure enough, if I set a break point somewhere, it gets hit.
My problem, however, is that Eclipse would normally at this point give me some control over the application but in this case is rather oddly not allowing me to resume, or use any step commands. I can't do anything other than terminate the application.
Perhaps I am having a stupid morning, but I cannot fathom why this is happening.
Can anyone shed any light on this and how I can gain the control required to debug?
I cannot be certain, but I believe this may have been due to an unintended mix of 32bit and 64bit components.
I had the same problem with a project I was much more familiar with a few days later, and in that case it was resolved by changing the buildpath to use the 64bit JDK. I was previously deploying it to a 64bit tomcat with the 32bit jdk on the build path when this happened.
Clearly the situation is a little different with dropwizard as its deployment is self-contained, but similarly altering the build path there seemed to resolve this for me.
Related
I'm currently looking into what better ways there are for deploying/setting up webapps locally after code changes and database changes.
So far I've seen the following tools/ways come by, and attempted each of them:
ANT build target that compiles, makes a jar, a war file and deploys that to the tomcat folder
Gradle build in combination with the tomcat plugin, which already does a bit of a better job than option #1
Good ol' fashioned command line
Setup run configuration within Intellij to do the deployment for you
Write shell script and call this via command line (haven't tried this)
To be honest I'm not finding each of these the ideal solution. I find option #4 the easiest as it allows me to, via a short-cut, easily deploy my changes and continue. This has however not given me an option for database changes yet, probably just me that missed it.
My question is mainly what tools/ways are you guys using in order to achieve an easy and maintainable development environment? What considerations come with those?
Well, let me tell you what I do for local web app setup.
In your favorite IDE(eclipse in my case) i'll configure the application server plugin(tomcat or webpshere) from Eclipse marketplace.
This setup will help to auto publish code changes to the server whenever I make a change in the application. I use Maven build tool for the application packaging. However I'm not sure about the database side.
For the people that were wondering how I ended up doing and found the best to work for me.
I currently have configured my IntelliJ IDE in such a way that the tomcat instance is linked and can be properly controlled and deployed, including debug, from within IntelliJ itself. This allows me to, via an easy shortcut, instantly populate any resources changes (css, javascript, front end) or redeploy or even restart the server. Especially with a small application this works very well.
It is yet to be determined whether this would still work with a multi-module setup and a larger project size.
Should you want more information on how this configuration can be achieved, feel free to send me a direct message.
I am using Selenium and Java to write tests. I was wondering if there is any way that I can run my code in debug mode and then if there is any issue in the code, I pause the application, fix it, recompile it and then run it from the spot that it was paused. My IDE is Eclipse Mars.
Yes, but only in limited cases where the changes to the code are minor. What you are talking about is called hot code replace. The following explanation is taken from the Eclipse Wiki.
Hot code replace (HCR) is a debugging technique whereby the Eclipse
Java debugger transmits new class files over the debugging channel to
another JVM. In the case of Eclipse development, this also applies to
the VM that runs the runtime workbench. The idea is that you can start
a debugging session on a given runtime workbench and change a Java
file in your development workbench, and the debugger will replace the
code in the receiving VM while it is running. No restart is required,
hence the reference to "hot".
HCR has been specifically added as a standard technique to Java to
facilitate experimental development and to foster iterative
trial-and-error coding. HCR only works when the class signature does
not change; you cannot remove or add fields to existing classes, for
instance. However, HCR can be used to change the body of a method. HCR
is reliably implemented only on 1.4.1 VMs and later, or using any
version of the IBM J9 VM. J9 is available in IBM products such as
Websphere Studio Device Developer™.
If HCR does not work for you even in a simple Java application and you
have confirmed that you are running the application on a supported VM
(taking note that the JVM that runs Eclipse may not be the same as the
JVM that is running your Java application), you may not have automatic
building turned on. Make sure that 'Project > Build Automatically' is
checked.
So I have just packaged my JavaFX 8 application using the zenjava maven plugin in eclipse. Unfortunately my application performance outside of Eclipse is abysmal. The application connects to an online database that I have set up and allows users to query items in the database. When I run the application in Eclipse it takes 3-6 seconds to start up, but when I am running commands in it the response is almost instant. Now that I have my jar packaged and running on my terminal it takes at least 10 seconds to start up and responses are frustratingly slow.
I have seen that the option -Djavafx.autoproxy.disable=true has helped many people overcome what seems a similar problem, but when I run
java -jar -Djavafx.autoproxy.disable=true application.jar arg
it is not any faster than it was originally. Most of the other ways I have seen to deal with this is done in Netbeans, which I do not use. Curious if anyone has dealt with this in Eclipse and can provide any insight? Thanks!
Reading through Eclipse debug topics I did not find an answer to my specific problem. I wonder if anybody else has seen it. I only experience this since switching to Luna, I used Kepler and Indigo before.
I usually debug Tomcat, but it happens for any one-class test app. When the app hits the first breakpoint, Debug view is shown, then I have to wait 20-30 seconds for the debugger to initialize, and only then is the code line highlighted in the editor. From that point on every break is immediate. Other kind of slowness is not experienced. In Tomcat any subsequent request stops quickly. The problem is that it's restarted often when hot code replacement is not feasible.
Anybody knows how to tweak it? There is no building or validating process going on at that time, and I tried to allocate various amounts of memory to Eclipse. -Xms256m, -Xmx2048m usually works very well for me.
Clearing all breakpoints worked for me too. Probably it was because of that breakpoint in jar files it would be taking more time for generating line numbers for those files.
I don't know how to tweak it, but in experiencing the same problem I found an Eclipse bug ticket already created for this along with duplicates: 440470 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=440470).
Starting Eclipse with "-consolelog -debug" hasn't showed any additional errors related to this.
I am working with a large core Java project and have also installed EMF (Eclipse Modeling Framework) and GEF (Graphical Editor Framework) plugin packages and dependencies via update site. I have installed these in previous versions of Eclipse without the debug delay issue. I tried closing this project and created a new test project with a simple Java class. There was no delay when debugging this class.
I found this post trying solve my issue: Very very slow to initialize tomcat, hibernate, etc. If you fall down here for similar problem I would suggest you what resolved to me. Try:
Clear all breakpoints, mainly those in API's, clear expressions too.
That's what worked for me.
My issue was fixed in Luna SR1.
I'm trying to figure out a way to add a self-update feature to a Java/Swing application I'm working on.
Basically I've got a bunch of jar files with extra functionality to be re-deployed to the installed users when they change. Nothing complicated, just check if a new version has been released, download them over HTTP, and then optionally offer to restart the app to the user.
I had a look at webstart, and it could work. But this particular app does some funky stuff with classloading and GC memory settings that don't look like they are supported via webstart, or will at least complicate matters. (It's a tweaked build of JMeter)
I also went down the road of adding in this plugin handler http://swing-fx.blogspot.com/2008/06/add-auto-update-and-plugins-to-your.html, but it is very alpha, and tries to do too much with the usual bugs you get with alpha stuff.
I did the exact same thing. But that was long back so there are probably better tools today.
What I found out I needed was a loader. The loader main program did not have the app jars in classpath. It first downloaded an update if required and then created a custom classloader with the app jars in class path and invoked the main method of the application main class. It is not very complicated. IIRC I needed to do this because the jars could not be overwritten in windows if they were already in classpath.
Hope this helps.
we had a swing app 6 years ago that had self-update. like you suggested,
1)it downloaded the latest jars over http,
2) copied them to a folder.
3) since the swing app is launched using a .BAT file, after user said YES, we would shut down the swing app and look for any files in the update folder. if yes, launch another .BAT file to copy the NEW JARs to the required directory.
4) then re launch the swing app.
Updates, plugins, separation of concern etc. are exactly what OSGi is about - you might want to take a look at this. It won't come free (read: with a steep initial learning curve, especially when you are currently using classloading tricks) at least there are good open source implementations (felix - see felix.apache.org, equinox - see www.eclipse.org and others)
For these implementations autoupdaters are available - if you write your modules correctly it's possible to update at runtime without restarting.
I believe you should look again at Java WebStart, or at least detail the "funky classloading" which you think is going to cause problems (as it might also cause problems with any solution proposed here).
IIRC, you can set command line parameters using Java WebStart ( http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources ).
I would definitely first try out Webstart. We've had lots of success launching even the early Eclipse RCP apps using Webstart, and you can probably not get more funky classloading issues than with the OSGI framework (Eclipse Equinox).
Could you perhaps give some more detail in your question about you classloading approach?
Regarding the GC and other VM settings: these are easy to specify in your JNLP (Java Network Launching Protocol) files used by Webstart for launching apps.
The Java Web Start is good choice. The GC stuff is not important. Classloading could be problem. But when you got trusted by user you can grant AllPermisions and you will be able to do custom classloading. Maybe it will be good to reconsider funky stuff with classloading. It is really necessary? Or look at NetBeans. There should be found inspiration for auto-update.