I am trying a spring MVC application on tomcat server..
I am always getting the error as resource not found(please see the question if you have time)..I think there is some problem with the view resolver..
I want debug this application to know where i am doing wrong...
Is that possible?
I don't know if it is a lame question for senior developers :)
I would set the logging level of DispatcherServlet to DEBUG and see what it says. Spring contains mostly good logging at DEBUG level to tell you what's going on (despite that it's INFO level is nigh-useless).
If DispatcherServlet's logging doesn't say much, try some of the other classes you have configured in your application (do one at a time or you'll get overwhelmed with log messages)
If you are using Eclipse, you can add Tomcat runtime in preferences and add new server in servers view in eclipse. Then you can run the server in debug mode.
Also you can attach source code for jar files(in your case spring jars) in eclipse so that when you debug it will load proper source files.
Related
I am working on a web-app front end (spring mvc) which depends on war file (created also by me).
Both module web and core communicate via REST (Jersey).
Both modules are separate maven projects.
On some occasions during development I screw up something in the core and exception is thrown. Many times I need to setup a breakpoint there and trap the issue.
The problem is: I start the debug when running the web-app fine. But will never stop on any breakpoint in core (doooh). (core is build using maven package command, to generate war file).
I could start only the core and debug it. Problem some complex functions expect many attributes (form object json format).
Any ideas?
Tnx
Start the core on debug mode, if you can do this in your IDE then you are all set, otherwise you can set up your IDE for remote debugging, There are instructions to do this for popular Ide's. Set up for eclipse, Set up for Intellij
You can debug the core and start web-app regularly and make it send the request you want to debug on the core side.
Have the core source code open in your IDE. Configure it for remote debug of the JVM that the servlet container/app server is running the app. Enable remote debugging on the servlet container/app server. Start the server, start the remote debugging in the IDE. Set a break point and enjoy.
I have a Java EE 5 application which consists of three web projects. I'm using JBoss 5.1 web server and NetBeans 7.2 IDE.
I have the following problems:
I cannot start application in Debug mode. That I know of, there are two (best) approaches in NetBeans and Java: Remote debugging and debugging via shared memory. I read this post How to debug JBOSS application in netbeans? and I set debug parameters in Jboss configuration(I also know there are different parameter sets for shared memory and remote debugging), but when I go to attach debugger I got following errors:
If I use remote debugging I got error "Connection refused";
If I use shared memory I got error similar to this text "dt_shmem:file path could not be found".
These errors occur when I start JBoss by running run.bat file. If I start JBoss from Netbeans IDE, I can attach to remote process (still have problem with shared memory approach), but then I have other problems, regarding variable primitives and model binding in page life cycle (I will not write about that now).
How can I solve these problems so I can debug application? At least, how can I find a better error message when it fails. I could not find too much on the Net by looking for "Connection refused" error only.
Why I cannot just press run main project(or web project) and that netbeans start application, open it in new browser tab(as localhost) and start debug mode? I'm coming from .net background and VS is offering this as out of the box tool (called ASP .NET development server). Why I have to use external web server and with every change deploy new application and then attach to it? Why Netbeans cannot by default use JVM for running application, and later when I deploy application I will choose which web server to use!?
I hope someone will make this clear to me :)
Thanks
added Note at 03.01.2013.
Well, when I changed VM options in project.properties file of web project (added run.args.extra=-J-Xms256m -J-Xmx756m), I succeeded to debug application and heat breakpoint when executing the code. However, I still have strange problem with Managed Bean properties. I have select list on page, and it is connected to Boolean property. When nothing is selected it should be set to null value by default (and it is when I start JBoss server by running run.bat file), but its value is by default set to false! I checked parameters post values in firebug and there is no problem in posting parameters to bean. It looks to me that problem is when JSF framework is trying to map post values to Managed Beans properties, but I cannot find out why this is happening. I also checked faces-config.xml, but did not find any specific rule for mapping to this specific property. Any tips?
I have a web application consisting of severals modules. All the modules are packaged together in one single ear.
One of them is a brand new groovy app, while others are more old school. This new grails app is not under my responsibility.
Notice that grails is not using any log4j.[properties|xml] file, but it as its own DSL which interact directly with log4j at runtime. This configuration is located inside a config.groovy script, packaged with the application.
Log4j is configured using an external file and the -Dlog4j.configuration option for the JVM.
The problem is the grail configuration is containing a very liberal config:
- set the root level to info
- add a console appender
The result is that the external configuration is hijacked by grails:
now there are two console appender (logging twice the same info) and lots of useless info data are logged.
Is there another solution than a programmatic approach, to tell grails to stop being rude ?
You could just turn off the grails logging so it uses the external logger
http://blog.saddey.net/2010/02/07/grails-how-to-use-native-server-logging-configuration-eg-tomcat-glassfish-jboss/
I'm developping a filter to handle all request made to my GlassFish v3.01 so I added a configuration in the default-web.xml Everything is working fine, but I'm not able to start debugging session in Eclipse. The compiled jar file is under domain1/lib.
Does someone have an idea on how I could achieve this?
Thank you, have a nice day.
I found a solution to the problem. To be able to debug a GlassFish Global filter with eclipse, we need to create a new debug configuration. This must be a remote java application config with port 9009. You must activate the Debugger in the JVM Setting on the admin page. Then we're able to start the debug configuration and the break points will work just fine.
I found the information here:
http://www.shareyourwork.org/roller/ralphsjavablog/entry/debugging_glassfish_with_eclipse
Thanks.
Enviroment: JSF 2.0, RichFaces 3.3.3, Facelets 1.1.15B1, Spring Framework 3.x, WebFlow 2.1, MyBatis 3.0.1, Oracle 10/11 g backend, SLF4j into Log4j. Well thats probably TMI since my issue is only a logging problem but better to be too thorough than not.
Anyways... I just setup SLF4j & log4j so now all of the internal facelets log msgs are being dumped into log4j & I can actually see them. In addition I setup Tomcat to also dump to log4j instead of it's custom version of JULI. Upon doing this everything appeared to be working great.... until i shut down the app.
Midway through the shutdown process my app started barfing up errors left 'n right because (which makes sense) Tomcat is trying to grab a logger instance AFTER spring has already cleaned up the logger bean.
Anyone familiar with this? I imagine it must be a common problem for anyone who has Tomcat using the non-standard logging mechanism. What is the best way around this?
I thought maybe if I just raised the log level then Tomcat wouldn't even try to log msgs because of the level req.s but the problem occurs when tomcat is trying to retrieve a logger instance so that didn't work.
I would move the Logger higher in the food chain.
I personally never configured log4j with spring relying on its own configuration mechanism (and hunting for where the heck it finds the properties file it is using in the process).
If you can you can opt to completely remove log4j from your war and rely on the log4j in the common tomcat library classpath. Then of course you are at the mercy of the tomcat configuration and you cannot access the log from inside your app, but it is always there during the complete lifecycle of your app.