Thursday, November 15, 2012

Debugging GWT using eclipse and tomcat

Everything I've heard and read online indicated that setting up my eclipse to debug the client side portions of a GWT app is super easy ... so of course I end up flailing around helplessly into the wee hours trying to debug a supposedly simple client side bug.  My process up to this point has been to insert a crazy amount of ridiculous log statements into the code, compile, deploy, repeat.  I know that this is messy and sloppy, but I was adamantly against using the GWT debugger because of a prior attempt to get it going a year and half ago that turned into a huge time-suck and frustrations.  After having spent an exceedingly long night trying to debug something a few months ago that ended up taking as long as it did because of the multiple repetitions of inserting log statements, compile, deploy, repeat, I conceded that I had to get the GWT debugger working.

First off, I am deploying the application in a local tomcat, so I need to be able to debug what eclipse considers an external server ( as opposed to having eclipse / gwt spin up a server within eclipse ).  A quick google search for the keywords of interest brings up as the first result a very helpful stackoverflow answer:


  1. Get google plugin for eclipse
  2. The in eclipse, right click on your project and choose Debug as -> Web Application (running on external server)
  3. Enter URL of your web app on tomcat (like http://localhost:8080/YourApp/YourApp.html and eclipse will give you new one - it will add stuff like ?gwt.codesvr=127.0.0.1:9997

Simple, right?  Sadly step 2 did nothing for me.  I select it, and nothing happens.  So what I ended up doing was to set up my own debug configurations.  When I did this, I kept getting this annoying error:


Working directory does not exist: /Users/myStuff/Documents/workspace/myProject-TRUNK/webapp/helloWorld/target/helloWorld-webapp-1.7-MS2.01-SNAPSHOT


I thought that perhaps this may have been related to the fact that we use maven and maybe that was throwing another complication into the mix.  As it turns out, if you don't provide a location of the deployed war to the configurations, GWT tries to access what it thinks the location.  The directory does in fact not exist, nor is it where my deployed war lives.  After some random clicking around and setting the directory to different places that may make sense, I figured out what it was looking for.  So, in summary, this is another way to get the GWT debugger to work by manually configuring things:

  1. In eclipse, right click on your project and choose Debug as -> Debug Configurations ...
  2. In the left hand panel, scroll down to "Web Application", select it and then click new.
  3. Click on the New_configuration to edit it
  4. In the Main tab, change the name of the configuration to something meaningful to you so you know what this configuration is for.  The project should be pre-filled with the name of the GWT app that you right clicked over. If it isn't, or it is not correct, click on the browse button to select the project.  This was a slight point of confusion for me, what project should I use? The code base I work on is very large with many modules. I chose the entry point into the application for the client as the GWT project ( and I chose correctly it seems ). I didn't know what main class to use or read up on what my options were, so I just left the default value.
  5. Now go to the Server tab.  Because I am running tomcat locally on my machine, I do not want to use the embedded server, so uncheck this option.
  6. Now go to the GWT tab.  Type in the name of the URL you would use in a browser to access your application. If you don't see the URL field, you probably forgot to uncheck the use embedded server in the previous step.  In my case, my application is running on https and the url needs to reflect this.  Additionally, note that the class that has your entry point should show up here.
  7. Now go to the Arguments tab.  Here's where I ended up flailing for a bit.  At the beginning of the program arguments, add the following:
    -war /opt/tomcat6/webapps/helloWorld/
    You should use the fully qualified path to the your deployed application folder (not the *.war file)
  8. Finally, you should probably add all the source for your project if you want to step through the debugger to the Source tab.
And that's it!  When you click on debug, you should see a tab on your screen where your console is that says "Development Mode".  One other probably obvious thing is that you want to start up tomcat first before clicking debug.  After this, you'll see in the Development Mode console a URL you can copy and paste into a browser and use for debugging the client side.

Yes, I know, this should be simple and straight forward, but I figured if I was having trouble ... I'm sure (hopefully) someone out there on the interwebs is having similar troubles.

Tuesday, March 20, 2012

The quest for the upgrade continues ...

After my last post, I was confident that things would go smoothly, having assumed that those were the most deceptive issues I would encounter.  Sadly, that was not at all the case.  Upon doing a mvn install on the command line, I got this error:
(Listing 1)
|Loading Grails 2.0.1
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7.298s
[INFO] Finished at: Sat Mar 17 19:22:13 EDT 2012
[INFO] Final Memory: 20M/81M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.grails:grails-maven-plugin:2.0.1:exec (default-cli) on project caffiendFrog-webapp-service: Unable to start Grails: java.lang.reflect.InvocationTargetException: Provider for javax.xml.parsers.SAXParserFactory cannot be found -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

A quick google search for the error, in various combinations of keywords, didn't produce anything that helped.  I turned to the footnote in the error, which suggests an article that may help.  It basically says that there is something wrong with your pom.xml file, specifically some configuration is done correctly or something else is wrong.  It's a rather general article, but it did help in that I was able to focus my efforts digging through my pom.xml.

Here are some red-herrings (i.e. false leads) that I tried:

  • The message mentions something about my grails-maven-plugin, so I spent a lot of time commenting out various bits of it.  
  • Tried a mvn clean install and got a similar message, only instead of (default-cli), I got (default clean).
  • And many more combinations of commenting things and searching for the plugin's information online to see if my configurations were incorrect.
As a last ditch effort, I created 2 dummy test applications, using the grails instructions for creating a maven-ized project, to take a look at their poms.  Up until now, I had assumed that most of the stuff in my pom.xml was stuff we had intentionally put in there (keep in mind as I said, it's been awhile and I can't remember what we added and what grails put in for us).  So I created a blank project using Grails version 1.3.7 and a blank project using Grails 2.0.1.   And lo and behold ... the poms are very different indeed:
Given the vast difference, what I did next was:
  1. Compare our original (v1.3.7) pom.xml to the generated one above.
  2. Noted the differences between them, these difference would be items that we had put in.
    • i.e. We added an additional exclusion to the dependencies from org.grails:
    • (Listing 2)
      
         jcl-over-slf4j
         org.slf4j
       
    • i.e.We had an additional dependency in our original file:
    • (Listing 3)
      
       org.slf4j
       jcl-over-slf4j
       ${slf4j-version}
      
      
    • i.e. We had a "hack" in place to synchronize the app.version in Grail's application.properties file with the version in our POM. See MAVEN-79 and MAVEN-128, as well as an additional execution in our configuration of the grails-maven-plugin:
    • (Listing 4)
      
       org.grails
       grails-maven-plugin
       ${grails-version}
       true
       
        
        
         sync-versions
         validate
         
          set-version
         
        
        
        
         grails-clean
         clean
         
          set-version
          clean
         
        
        
       
       
  3. Changed the pom.xml to look like the v2.0.1 (i.e. the dependencies, plugins, repos, etc.)
  4. Inserted the differences into the new pom.xml.
    • i.e. Inserting the additional exclusion from Listing 2, note that in the v2.0.1 pom.xml, there is only one dependency to org.grails and it contains none of the exclusions that were listed in v1.3.7:
    • (Listing 2a)
      
       
       org.grails
       grails-dependencies
       ${grails-version}
       pom
        
        
         jcl-over-slf4j
         org.slf4j
        
        
      
      
    • i.e. Added in our additional dependency:
    • (Listing 3a)
      
       
       org.slf4j
       jcl-over-slf4j
       ${slf4j-version}
      
      
    • i.e. Upon further investigation, the tickets have been resolved and the hack is no longer needed. Inserted the additional execution into our new plugin definition:
    • (Listing 4a)
      
       org.grails
       grails-maven-plugin
       ${grails-version}
       true
       
        
        
         grails-clean
         clean
         
          set-version
          clean
         
        
        
       
      
      
You get the idea.

Some other things to note:

  • The plugin JAXRS & Hibernate have a dependencies on org.restlet*.  This is no longer available via maven central.  You will need to add:
mavenRepo "http://maven.restlet.org"
    To your BuildConfig.groovy file and/or your pom.xml file as an external repository.
  • I initially had trouble getting the archetype for v2.0.1.  For some reason the command mvn archetype:generate just would not pick up the new version, even though it is there and available.  To resolve this, I trashed my .m2 folder and when the dependencies were pulled in, it pulled in the new version of the archetype.
As always, I think there were some issues I ran across, but at the moment I can't think of them.  Also, at this point, the upgrade still isn't complete, and I'm getting errors, but at least the errors seem to be related to the code and possible re-naming and re-factoring that occurred in the new version.

Saturday, March 17, 2012

Oh un-holy grails ...

It has been a while... which isn't to say I haven't been running to a myriad of issues, but I just haven't had the time to update.  But this one, egads. I could not help but describe and hopefully save someone out there in the interwebs many hours and tears.

Our adventure today begins with a seemingly simple task.  Upgrading the Grails version for a project.  The project was previously on Grails 1.3.7, and we are upgrading/updating/whichever it to 2.0.  For a point of reference, here is the setup/environment :
  • This a fairly large code base containing many other modules.  
  • We are using maven
  • My IDE of choice is Eclipse Helios (64bit)
  • We have a 'local' nexus that proxies stuff for us
In addition to the base Grails, we have the following plugins installed:
  • Spring-Security-Core
  • Spring-Security-Ui
    • Mail
    • JQuery
    • JQuery-ui
    • famfamfam
  • tomcat
  • hibernate
  • jaxrs
And we also have the following dependencies:
  • Spring-Security-Core 
  • Spring-Security-Web
Note that there are two separate Spring-Security-Core, one is a plugin and one is a dependency to be added in the pom.xml.  Another note, it has been many months since we set up our Grails project, and my memory just isn't what it used to be.

Here's an overview of what this blog entails:
  • Where are the jars?
  • Multiple versions of grails in the same workspace
  • Wait, I need to INSTALL grails as well??
  • Grails "upgrade" command doesn't work with maven-ized projects
  • Trouble re-installing the JAXRS plugin
  • Some final thoughts
Issue #1 - Where are the jars?
My first problem will probably be moot for most people now.  I could not get the updated jars from our local nexus.  It took a little searching and I came across this:  Grail 2.0 jars not available through maven central.  Which of course explains why our nexus didn't pull it in.  The reason this is moot now is that Grails 2.0.1 is available through maven central.  So I was able to grab the jars for 2.0.1 fine.  But for future reference, if you experience trouble pulling in the jars for new versions of Grails ... check to see if they even exist in your nexus or maven central.  If not, you can grab them from Grails' repo: http://repo.grails.org/grails/core.

Issue #2 - Multiple versions of grails in the same workspace.
Since this is a major release of Grails, there are many things that have been changed and therefore our code needs to be changed to work with the Grails.  Grails does provide a nice* write-up of how to upgrade your code here: Upgrading From Previous Versions of Grails.

*Since I have only just resolved my issues with getting started, I haven't yet had a chance to follow their write-up, but at a glance, it looks fairly detailed.  Whether or not it is detailed enough, I will find out soon.

Because this is potentially going to perturb our code base with all the changes, I am working the upgrade in a branch that contains only this module.  Seems like a sound plan, right?  At this moment, I have our entire code base open in eclipse and I have this branch open.  As soon as I change the POM to reference 2.0.1, and eclipse does its auto build thing to pick up this change ... the bad thing happens.  Namely, eclipse exits all by it's lonesome, with no message or anything.  Just, one minute it's building ... next minute it's gone.

What happened?  Since I'm on a Mac, I opened up the console to take a look at what it says.. and it says a lot:
(Listing 1)
ar 16 11:31:16 dhc019746 [0x0-0x1f51f5].org.eclipse.eclipse[5701]: /Users/frog/Documents/workspaceNew/caffiendFrog-webapp-service-BRANCH/plugins/spring-security-core-1.2.7.2/src/java/grails/plugins/springsecurity/DigestAuthPasswordEncoder.java:88: cannot find symbol
Mar 16 11:31:16 dhc019746 [0x0-0x1f51f5].org.eclipse.eclipse[5701]: symbol  : variable Hex
Mar 16 11:31:16 dhc019746 [0x0-0x1f51f5].org.eclipse.eclipse[5701]: location: class grails.plugins.springsecurity.DigestAuthPasswordEncoder
Mar 16 11:31:16 dhc019746 [0x0-0x1f51f5].org.eclipse.eclipse[5701]:   return new String(Hex.encode(digest.digest(s.getBytes())));
Mar 16 11:31:16 dhc019746 [0x0-0x1f51f5].org.eclipse.eclipse[5701]:                     ^
Mar 16 11:31:16 dhc019746 [0x0-0x1f51f5].org.eclipse.eclipse[5701]: /Users/frog/Documents/workspaceNew/caffiendFrog-webapp-service-BRANCH/plugins/spring-security-core-1.2.7.2/src/java/org/codehaus/groovy/grails/plugins/springsecurity/AbstractFilterInvocationDefinition.java:179: cannot find symbol
.... (Lots more errors along the same lines, cannot find symbols) ...
Mar 16 11:31:16 dhc019746 [0x0-0x1f51f5].org.eclipse.eclipse[5701]: 100 errors
Mar 16 11:31:16 dhc019746 [0x0-0x1f51f5].org.eclipse.eclipse[5701]: 1 error
Mar 16 11:31:16 dhc019746 com.apple.launchd.peruser.503[184] ([0x0-0x1f51f5].org.eclipse.eclipse[5701]): Exited with exit code: 1
It took me quite a lot of frustration, many hours, to realize that the problem was that because the two versions of grails is so different, they can not coexist happily, at least not without some tweaking.  There is a nice little script available here that does the switching automagically based on what version of grails your project needs.  You only need to a little bit of setup, namely setting an environment variable to point to a default version of grails, and to have both versions of grails in the same folder.  For example, this is what I did:

  1. I decided to use 1.3.7 as my default, so I set my $GRAILS_HOME to point to that in my ~/.bashrc file:
    • (Listing 2)
      export GRAILS_HOME=/opt/grails-1.3.7
  2.  I unzipped and placed both versions under /opt:
    • (Listing 3)
      frog@hostname:/opt$ ls
      total 16
      drwxr-xr-x  14 frog   staff   476 Mar 16 14:37 .
      drwxrwxr-t  37 root   admin  1326 Mar 16 14:20 ..
      drwxr-xr-x  20 frog   admin   680 Nov  2 15:40 grails-1.3.7
      drwxr-xr-x@ 21 frog   staff   714 Feb 14 16:22 grails-2.0.1
      drwx------@  8 frog   staff   272 Mar 16 14:37 grails-docs-1.3.7
      drwx------@ 16 frog   staff   544 Mar 16 14:36 grails-docs-2.0.1
      drwxr-xr-x   3 frog   staff   102 Mar 16 14:27 multi-grails
      
  3. I put the script in it's own folder (multi-grails) in the same folder with the grails version and added that information to the $PATH environment variable in the ~/.bashrc file:
    • (Listing 4)
      export PATH=/opt/multi-grails/:$PATH
    Maybe this is obvious to more experienced developers, but I've never had this problem before and I know I've worked with multiple versions of libraries opened in the same workspace before.  Well, as it turns out ... this is because of my next issue.

    Issue #2a - Wait, I need to INSTALL grails as well??
    This is a painful thing for me to admit, and maybe it's obvious in the documentation on grails and I was just trying to do things too quickly and didn't notice.  But I completely forgot I had installed grails on my machine.  I just assumed it was a plugin like any other. No, no, no. You need to install grails.  And by install grails, I mean:
    1. Download the binary zip of the version you want (http://grails.org/Download)
    2. Unzip.
    3. C'est Fin.
    Face, palm, anyone?
      Issue #3 - Grails "upgrade" command doesn't work with maven-ized projects
      Alright, now that I can actually VIEW my code in eclipse, I can start the upgrading process.  Grails provides a nice "upgrade" command to make life easier.  It is simply "upgrade".  To use this command on the command line with the mavenized grails commands:
      (Listing 5)
      mvn grails:exec -Dcommand=upgrade
      Simple, right? Ah, but no. Again, that would be too easy.  What you end up with if you try this on the command line is something along the lines of, after lots of downloading of whatever other dependencies your project has:
      (Listing 6)
      NOTE: Your application currently expects grails version [2.0.1], this target will upgrade it to Grails 1.3.7 ...
      
              WARNING: This target will upgrade an older Grails application to 1.3.7.
              Are you sure you want to continue?
                          (y, n)
      y
         [delete] Deleting directory /Users/frog/Documents/workspaceNew/blog/target/classes
         [delete] Deleting directory /Users/frog/Documents/workspaceNew/blog/target/resources
         [delete] Deleting directory /Users/frog/Documents/workspaceNew/blog/target/test-classes
      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD FAILURE
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 1:29.344s
      [INFO] Finished at: Sat Mar 17 19:25:48 EDT 2012
      [INFO] Final Memory: 32M/81M
      [INFO] ------------------------------------------------------------------------
      [ERROR] Failed to execute goal org.grails:grails-maven-plugin:1.3.7:exec (default-cli) on project caffiendFrog-webapp-service: Unable to start Grails: java.lang.reflect.InvocationTargetException: : /Users/frog/Documents/workspaceNew/blog/null/src/war not found. -> [Help 1]
      [ERROR] 
      [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
      [ERROR] Re-run Maven using the -X switch to enable full debug logging.
      [ERROR] 
      [ERROR] For more information about the errors and possible solutions, please read the following articles:
      [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

      If you look at the end of line 17 above, you can see it is looking for: /blah/blah/null/src/war.  What the heck, why is it looking for null, and where did that even get specified?  According to this blog, there is some problem with resolving the environment path and maven and grails.  Long story short, it doesn't work.  You can't (at this time at least) use the upgrade grails command on a maven-ized project.

      So now what?  Now you do the upgrade manually.  The above mentioned blog entry has instructions as well.  Here is what I did, in a little bit more detail.  Note that some of the steps I'm not sure are 100% necessary, but I was getting tired of eclipse choking on me.

      1. Exit eclipse.
      2. Navigate to the directory of your project
      3. Using your favorite text editor, manually edit the pom.xml file to change the grails version to 2.0.1.  Note that in our case, we have declared a property at the top of the pom.xml that is used in all the grails related dependencies for consistency.
      4. Using your favorite text editor, manually edit the application.properties to change the app.grails.version to 2.0.1.
      5. Make a note of all the plugins that are listed in the application.properties file.  For example, here are the plugins that our module uses:
        • (Listing 7)
          plugins.famfamfam=1.0.1
          plugins.hibernate=2.0.1
          plugins.jaxrs=0.6
          plugins.jquery=1.7.1
          plugins.jquery-ui=1.8.15
          plugins.mail=1.0
          plugins.spring-security-core=1.2.7.2
          plugins.spring-security-ui=0.2
          
        • As I mentioned earlier, it has been a while since we first set this up, so I didn't even remember all the plugins we were using.
      6. Using the command line, uninstall each of these plugins. The name of the plugin to pass in for the command is what appears after the '.' in your list.
        • (Listing 8)
          mvn grails:exec -Dcommand="uninstall-plugin" -Dargs="famfamfam"
      7. Now, install the very same plugins, this time the install will pull in the updated versions of your plugins.
        • (Listing 9)
          mvn grails:exec -Dcommand="uninstall-plugin" -Dargs="famfamfam"
      Issue #4 - Trouble re-installing the JAXRS plugin
      One of the plugins that we use is jaxrs ...which has a dependency on some restlet.org packages.  For some odd reason, when trying to re-install the plugin, I keep getting errors about inability to resolve the dependency.  As it turns out, the restlet version that is needed by the plugin is NOT in maven central.  To fix this, I added a repository to the pom.xml
      (Listing 10)
      
       restlet.org
       restlet.org
       http://maven.restlet.org
       
      Some final thoughts ... for now...
      At this point, you should be able to do a mvn clean install on your command line for the project and open both projects up in Eclipse without eclipse having a heart attack and falling over.  Keep in mind that your mvn clean install will fail, since you haven't yet changed your code to adhere to the new 2.0.1 ways.  This is far as I was able to get to:

      [ERROR] Failed to execute goal org.grails:grails-maven-plugin:2.0.1:clean (default-clean) on project eagle-i-webapp-identity-service: Unable to start Grails: java.lang.reflect.InvocationTargetException: Provider for javax.xml.parsers.SAXParserFactory cannot be found -> [Help 1]
      

      Another thing to mention is be wary of messing around with your maven-ized pom.xml file.  If I remember correctly, you had to issue a specific command to turn the grails project into a maven-ized one and that the command also created/edited the pom.xml file.  One of the motivating factors for us to upgrade is that we have been seeing our CI builds hang for no explicit reason when building this specific project..  Where it hangs varies, but it seems to be hanging while trying to resolve dependencies (another long story, maybe for another time).  I tried to do some "cleverness" by cleaning up what I thought were now obsolete/unused dependencies ... which I should have known better than to do.

      I hope this has been helpful for someone out there.  I tried to document this as best as I could, but it was a long, frustrating process.  I may have missed some steps, if I did and it's causing you issues, please let me know and I'll try to help out.