I am asking the correct way of debugging a Dynamic Web Application in Eclipse.
I have two sort of files:
the view: jsp
the controller: Spring Controller
When I changed a jsp file, whether in debug mode or not, the change will be reflected seamlessly.
But whether in debug mode or not, if i change controller's content, all the application will be redeployed to tomcat. Even some time, the tomcat fails to redeploy (restart).
Is there a more appropriate way to debug such an application?
What JDK implementation are you using? I had a similar problem when using the standard Sun HotSpot JDK 1.6. It was fixed when I switched to using JRockit JDK. I believe Oracle plans to integrate these two implementations in the foreseeable future.
Related
I work with a Spring 4 project on Eclipse and IBM Liberty as Application server. Well, every minimal JSP edit I have to restart the whole server and it take almost 3 minutes.
Application is an EAR container with seven web projects (only one is spring) and others java libraries
Auto deploy is configured, indeed all java class editing is immediatly deployed.
anyone know as extending auto deploing to jsp?
It would be helpful if you mentioned which Liberty features you have enabled on your server. Regardless, I think I know the answer. You most likely have either javaee-7.0 or at least cdi-1.2 enabled...or some other feature that requires cdi-1.2.
The issue you are describing sounds a lot like the issue fixed in APAR PI58316:
http://www-01.ibm.com/support/docview.wss?uid=swg1PI58316
During a JSP request, your Spring jar(s) are likely causing the JSP request processing to invoke the cdi-1.2 code which had this problem. This resulted in changes to a JSP file to not show up on a new request...the server had to be restarted. You would not see this issue with a very simple JSP project that did not contain Spring or other code that would have a dependency on CDI. Also, this issue is specific to a JSP request, which is why you see your other Java class editing being reloaded without any issue.
This issue is now fixed with APAR PI58316 which is included in WebSphere Liberty fixpack 16.0.0.2. I would recommend that you upgrade to that level to see if your issue is resolved.
Yeah! I found this is a bug of WebSphere Liberty 8 version.
On Liberty new version (16) there is a fix.
See this link http://www-01.ibm.com/support/docview.wss?uid=swg1PI58316
Here another topic of this problem Websphere liberty profile jsp changes are not reflected using Spring data jpa library
I am newbie with jboss-eclipse. I have to work on javaEE5 with JBoss AS 5.1.0.GA. I don't want to use JRebel at the moment.
I installed "Eclipse Java EE IDE" with "JBoss Tools". I added the JBoss 5.1 Runtime server on eclipse and added a new ear project with :
an EJB3.0 class in ejb project;
a javabean class and index.jsp in web project.
I noticed when I make a modification in the jsp file, I can see instantly the changes after refreshing the web browser. That's ok.
When I modify EJB and javabean classes, there is no instant hot deployment. I have to restart the ear application (without restrating jboss server) or "full publish" the ear via eclipse to see changes.
Is there any way to have instant hot deployement for EJB and javabeans?
PS: I tried "incremental" publish but it hasn't worked.
Thank you!
You do need 3rd party tools for that, the most notable being JRebel. Without advertising I have to say this tool has saved me lots and lots of hours already while developing EE applications.
In jboss AS 7.1.1 you just have to go to the as admin console at localhost:9990 and select: Profile -> Core -> Deployment Scanners -> Auto-Deploy Exploded . You might also want to change the scan interval to something smaller. Afterwards, you may deploy your application for the first time by selecting "Run on Server". From this time on, your application will get automatically deployed whenever you change a file and it manages to compile.
I do not know if Jboss 5.1 has this feature, and if I were you I'd consider using 7.1.1 for development when it does not have it.
The hot deployment works fine with JBoss when publishing new files in your deploy folder, only class exchange will not happen in your currently deployed application.
That's why you see changes to all static content like HTML files immediately, but not changes to your java code.
In order to do activate them, you'll have to restart your application (not the whole JBoss, only your application, done for example in JBoss server view).
I have no practical experience with JRebel and I do believe that it saves you time, but you have to be careful with such tools, as they can introduce new problems which you spend much times in debugging, ending up in restarting the container and everything works fine.
I'm setting up a project to use MySQL as the datasource and I'm running into a couple problems.
It appears the MySQL drivers for the Java side are incompatible with the built in GWT Jetty instance. Really?
I can configure a TomCat instance and get MySQL Driver working, but I can't debug inline (Client & server together) like I normally would be able to do using the Jetty instance in dev mode, according to Google Docs.
I spent quite a while deciding between a PHP or Java backend, and one of the main advantages besides the GWT RPC mechanism was the fact that GWT provides a nice Development environment if you use Java.
Has anyone encountered the need to use a data source other than appEngine? How did you setup dev environment?
I do believe the MySQL JDBC driver is "compatible" with the embedded Jetty; but maybe you were in an AppEngine project, in which case the embedded Jetty server forbids the use of classes that are not compatible with AppEngine (so you have at dev time a behavior as similar as possible with the production environment on Google's servers).
To debug your server code running in Tomcat, you either need to launch it (the server code) using Eclipse WTP (or equivalent if you don't use Eclipse), or launch your Tomcat instance with the appropriate debug arguments e.g. -agentlib:jdwp=transport=dt_socket,address=8788,server=y,suspend=y, and then debug it as a "Remote Java Application" (in Eclipse, I don't now how they name it in other IDEs).
You can then launch your DevMode in -noserver mode (and in debug) to debug your server and client at the same time (yes, you'll actually have 2 debug sessions).
Note that the doc you refer to (whose latest version can be found here) doesn't deal with debugging the server-side code, as it's highly dependent on the server you use, how and where it's deployed, etc. GWT code on the server side is just a standard servlet, so there's nothing specific to GWT re. how to debug the server-side code.
FYI, we do use a standalone Jetty instance (not the embedded Jetty server) for more than a year using the above setup.
You can use GWT and Tomcat and still be able to debug both client and server side. Look at the jetty startup parameters in Eclipse.
I have been in a similar position few years ago and decided to use Jetty for development and tomcat for testing.
I am using the JBoss Tools to deploy a seam application to a JBoss server from within eclipse. I am consistently seeing a strange behavior. Every time the .xhtml files are changed the seam application is auto-deployed as expected. However, the entity manager instance is becoming null and I am forced forced to restart the seam application by removing it and adding it through the eclipse server view. The whole process is taking more time than I can afford. Is there a workaround to this problem?
If you change a xhtml file only that single file should be copied and the entitymanager should not be affected. Are you refreshing the browser ? Triggering some specific action on that page ?
I'm guessing you use JBoss 5.1.0 server? If yes, there are a bunch of problems with this server while working with Seam especially in version 2.2.0. You may also read about general problems with deployment to JBoss5 container.
The other thing you must remeber is to set debug mode for Seam and development mode for facelets. Whitout this two configurations hot deployment won't work.
I have an existing, fully functional Spring web application based on Spring 2.5.6 - developed using SpringSource Tool Suite 2.1.0.SR1.
Because I'd like to use REST I decided to upgrade to Spring 3.0.0.M4. After editing the dependencies in pom.xml and changing my code to reflect the API changes in Spring 3.0 I tried to publish my web app to a local server (SpringSource tc - a Tomcat derivate).
The result is an almost empty web app folder and therefore a non-functional app. The app's folder only contains WEB-INF/lib with all libraries required by the Maven dependencies.
After realising that something's broken, I created a new Spring MVC project (based on the default 2.5.6) and published it to the same server. No problems. I tried to adapt my project's files (.settings/*, .project, .classpath, .springBeans), but this didn't change anything.
I'm pretty lost right now. My guess is that STS doesn't handle 3.0 apps correctly. Any suggestions?
PS: I don't want to revert to 2.5 if it's not absolutely necessary. I don't need STS and tc so I don't have a problem using other tools, but it worked fine so far.
I run into this all the time using Eclipse Galileo and m2eclipse 0.9.8 and Tomcat with WTP. I think it is m2eclipse that is the culprit. The problem seems worse after switching from Ganymede. The work around is to run mvn to create the war and then copy the war contents from "target" to WTP's "wtpwebapps" directory. You can conveniently find this horribly long path by double clicking the server in the Servers view, and choosing "Open Launch Configuration" from there click on Arguments(?) tab I think and copy the catalina.home java property that is defined as an argument there.
The problem vanished with newer versions of STS. Additionally my development environment changed a bit since I posted this question, so I can't really tell what caused the problem.
For me, it looked like a weird hiccup inside STS.
Spring Tool Suite 2.1.0 claims partial support for Spring 3.0, though not for the REST features. According to the release, future releases will add full support. From the release statement:
Features
Support for milestones of Spring 3.0 including XML editing and validation, support for #Configuration and #Bean annotations
Future
Complete Spring 3.0 support including tools for developing RESTful web applications
Try deploying your app to embedded jetty. 'mvn jetty:run' with help you confirm if that there's nothing wrong with your build (that all the right manifests and deps are in place)