I am working on a java ee web application in NetBeans. I am trying to debug the behavior of the application but the behavior I'm seeing is confusing.
I am running the application through NetBeans in Tomcat. Within NetBeans, I select "Debug" from the root of the Project Tree and I can send one request to the application I've written. Breakpoints are hit and I get unique results from the application.
However, every subsequent time I try to send a request to my application, I get the exact same incorrect result (even if I clear the cache on Chrome) and the Netbeans IDE doesn't stop at any of the defined breakpoints. Is this to be expected? Does a Servlet get mangled in memory once it runs through the debugger once? Do I need to stop and restart/reattach the NetBeans debugger every time I want to debug the application? Is there something I'm doing wrong when using the debugger? Does this indicate a problem with the code I've written in my Servlet?
Thanks,
Jason Mazzotta
rjsang's point on the cache might be valid, and is worth investigating.
However, it might also be that something is breaking earlier than you expect, causing you to never even reach the break pointed lines.
I would suggest:
Look into liberally sprinkling your code with debug logging statements (using a good logging framework such as Log4J with SLF4j)
Throw more breakpoints at the problem - start with the very first line you expect to be hit from your request. And the go even higher/earlier, if possible.
Tail that Tomcat log (catalina.out) - you might spot something catastrophic happening there.
Good luck.
Related
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.
I'm working on a very big java/servlets/web project and i find it hard finding which classes and and methods is being called. sometimes it takes hours to find the right class. if there an application or plugin or technique that helps a little? im using eclipse.
edit: I'm using apache and tomcat
Regarding your comment to Bozhos answer: use a profiler on your server instance. You start profiling right before you click on a link in your client application ("the browser") and stop right after you have the correct response. Then just examine the profiler logs/views to find out, what actually happend on the server.
The Eclipse Test & Performance Tools Platform Project is worth a try.
CTRL + ALT + H, or right-click > open call hierarchy (when on a method declaration) will give you all callers, with their callers, and so on. You can also reverse the hierarchy
Right click > references > project will give you where a given class is used.
From your comment on Bhozo's answer I conclude that you do NOT mean at development time, but at runtime.
I suggest you connect a debugger to your application and pause it. You can then inspect the callstack at that time, which will usually give you an idea where to look.
To do that, run your java app with the following settings:
-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
Then in eclipse, add a debug configuration for 'remote' to port 8787 and execute it. Your debugger is now linked to your application. Put eclipse into the debug perspective.
Now click a link in your application, and immediately click the pause button in the debugger. You can now see the callstack. Usually, once you have a clue, you can quickly find good spots to put breakpoints. But this technique helps you get a clue :)
You might want to consider the use of AOP to add a tracing/logging aspect to certain parts of your code. This way you don't have to update your code and can simply write an aspect that logs a line for every method that is called with in example the name of the method, the class and the parameters. This aspect can of course be 'turned off' when building your production version to prevent the trace logging on production machines. If you're familiar with AOP, you can easily tweak the aspect and the pointcuts a bit to for instance only log calls to certain methods in your controller classes or something like that.
If you need more information on this solution, feel free to comment on this answer requesting more specific information or simply google for AOP and logging.
I'm having some problems tracing the reason that I can't load a java(fx) applet.
The java plugin console for the browser has always been my sole source of information for problem solving. The reason it isn't much help at the moment is that the applet starts to load, downloading the jar files and outputting a percentage to the console along with the occasional statement to say it's on the next jar file. At some point in time (different percentages each time) the console just closes unexpectedly and the applet stops loading. I know this isn't much to go on but I was wondering if there was any way that the output from the console could be stored to a file on the local machine. To debug this particular problem, changing security permissions temporarily would be acceptable.
The problem has occured on every pc i've tried, however if I keep refreshing after failure it seems to cache the jar files previously downloaded and thus get further through the loading process until it eventually works. My issue now is that on a particular customers network refreshing does not resolve the issue. I thought it may be a permissions issue writing to disk but I've tried an administrator account and still no luck. I've also tried a variety of browsers. It might also be worth noting that they go through a proxy server - when the applet tries to load it asks for the credentials for logging on to the proxy which seems to authorise fine.
If anyone has a suggestion on what I could try it would be gratefully received.
Thanks,
James
Two points:
You should be able to get a stack trace through the applet console viewer (which runs in the system tray on PC's) and if you open that up it will show you your stack trace for debugging.
Can you reproduce this problem using the Java Applet Viewer tool? This will allow you to write unit tests, and debug much more easily.
I forget where it is, but somewhere in the java control panel (one of the options under the advanced tab I believe) there's an option to turn on logging. This will log all output to the java console to a file as well. I've used this when trying to debug issues similar to this.
There's some info here on where the files will appear:
http://download.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/tracing_logging.html
The problem ended up being some JS code that was making calls to the applet before the applet had initialised.
Recently two of our clients have reported problems with our applets. Looking at the java plugin console it is full of ClassNotFoundException so none of our code is executed.
I've been able to reproduce the stack trace using a virtual pc image with 0 free space on disk, but the problem goes away as I restore some disk space, and the users tell me that their disk is not full; they are able to create new files.
Our applet requires java 6, and the problem has appeared with updates 1, 10 and 14 of the jre. We have also tried different browsers (IE and Firefox), clearing the browser and java caches, ...
How can I debug or trace what is the jvm doing to load our applet?
I suppose that the problem lies on some security directive on windows so I'm using Sysinternal's Process Monitor to log the activity but I don't really know where to look at.
The Java cache is most likely messed up. Open Java in the Control Panel and get rid of all temporary files to see if it goes away.
Logging in the Java Console for loading applets can be enabled which helps quite alot (even if the plugin is extremely cryptic). See http://java.sun.com/javase/6/docs/technotes/guides/deployment/deployment-guide/tracing_logging.html
I've been looking at the plugin source from the JDK and I've found that there is additional debug info available in the logs setting the environment variable JPI_PLUGIN2_DEBUG.
Unfortunately I still only see ClassNotFound exceptions.
I've found a piece of the plugin code that swallows all exceptions, so maybe my users problem is there...
had similar problems a while ago. In our case, the problem seems to be how the applet tag is set up on the web page. If it is in a wrong order or contains the codebase attribute, it fails with 6u10+. This works for us:
<applet name="DMGANTT" archive="DMGantt.zip" code="dm.applet.DMGanttApplet"
width='100%' height='100%' mayscript="mayscript">
We had a similar problem with one of our clients. We discovered that it was a strange bug in some versions of Java related to proxy configuration on the client. See this article for the details
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6723715
Also, our applet failed with new versions for a different reason.
Now, in similar cases I ask them to check javatester.org, so that I can see if applets (in general) load OK in their browser. If that page loads OK, its a problem on our applet (or page). Else it's a problem in their configuration. I help them anyway but it's easier to debug.
Is it possible to debug a Rails application in a similar way to a Java application - setting breakpoints and stepping into the code?
What are the best tools for this?
I have a hybrid Java/Ruby on Rails application which I can run in Eclipse or Netbeans.
I would like to step into some code in this app and try to figure out the cause of a problem I'm having.
In Eclipse if I set a breakpoint in my blog_controller and then choose the 'Debug' button, it seems to use the ruby-debug-ide gem to execute the code but I get this unhelpful output and no option to step into any source:
Fast Debugger (ruby-debug-ide 0.4.5) listens on localhost:56726
./war/WEB-INF/app/controllers/blog_controller.rb:1
C:/Ruby18/lib/ruby/gems/1.8/gems/ruby-debug-ide-0.4.5/lib/ruby-debug.rb:101:in `debug_load'
C:/Ruby18/lib/ruby/gems/1.8/gems/ruby-debug-ide-0.4.5/lib/ruby-debug.rb:101:in `debug_program'
C:/Ruby18/lib/ruby/gems/1.8/gems/ruby-debug-ide-0.4.5/bin/rdebug-ide:82
C:/Ruby18/bin/rdebug-ide:19:in `load'
C:/Ruby18/bin/rdebug-ide:19
Uncaught exception: uninitialized constant ApplicationController
I'm not sure if I'm doing something wrong or if this is all I can expect.
The debugger I use the most is the ruby-debug gem, which is a gdb-esque command line debugger. Once you learn a few commands it is very quick and effective, and provides you with some handy features like being able to fire up irb in the context of your program and make on-the-fly changes.
And being command line based it comes in handy when you need to debug a on a remote server.
You can expect more. I have used Aptana's RadRails version of Eclipse to debug a Rails app as you describe--setting breakpoints and stepping through the code.
You may be doing something wrong. It looks as if it is trying to debug an individual controller file, rather than debugging the Rails app. When I try to execute a controller file from the command line, I get a similar message:
C:\workspace\myapp\app\controllers>ruby users_controller.rb
users_controller.rb:1: uninitialized constant ApplicationController (NameError)
In Aptana RadRails, I choose Run > Debug As > Ruby Application to debug the app.
For the vim users I strongly recomend looking into the vim-ruby-debugger, which fits in great with Tim Pope's rails.vim scripts.
It gives you a handy :Rdebugger command, allows you to set breakpoints and open a split window to display variable values.
maybe not relevant, but I wanted to post somewhere: got the error: "undefined method `run_init_script' for Debugger:Module" running the debugger in rails 2.3.2. Did a sudo gem install ruby-debug and the problem went away.
I'd recommend just setting up breakpoints (I actually just puts to console) for 99% of debugging with RoR - this method is simple and usable across any IDE, so you never need to learn how a new debugger works.
Actually, I had the same problem with Aptana. Run > Debug As > Ruby Application just doesn't work. I finally made the debugger work by going to the Servers tab, and then start the server in debug mode. After that, set some breakpoints and trigger the corresponding action. Hope this helps.
Debugging? That's just knowing where to look in the case of Ruby (and by extension, Rails) most of the time.
The problem in this case is that you probably still have your ApplicationController called application.rb where it should be renamed to application_controller.rb.
Debuggin in rails is simple if you know how to read the error stacktrace!! But if you need to explicitly watch out the values during the runtime then u can use the rails breakpointer.Below is the link to how-to on breakpointer ..hope this helps!!!
http://destiney.com/blog/rails-breakpointer
I can't speak for Eclipse (never worked well for me) or Aptana (not tried) but from experience I can say that both NetBeans and RubyMine will do what you want. I both cases you should probably make sure that the ruby-debug-base and ruby-debug-ide gems are up-to-date: RubyMine in particular didn't work for me until that was done.