Thursday, October 23, 2008

Converting legacy Rails apps to Grails (with NetBeans) : General Project Setup

It is hard to describe the pleasure of writing the title above, especially the "legacy" part :-) Although lately the jumping up and down of Ruby & Rails fanboys has subsided a little, after people started realizing that Rails is not going to kill anything (much less Java, hell if PHP people start going back to PHP that says A LOT!!!). So, a few years later I got a chance to chime in on the subject.

Anyway, the specific reason for writing this post is that I had a chance to take an existing Rails app, and move it to Grails. Some of the reasons for even attempting is that as much effort and hype has gone into Ruby and Rails, the (C)Ruby is not even close in being able to integrate with everything else like Java can. When you throw into the mix that even JRuby is starting to be faster than (C)Ruby, and that Groovy kicks the pants out of JRuby, there's also a performance story to be told for Grails. Finally, when you throw in the existence of a clear migration path in performance sensitive Groovy/Grails components directly into java (e.g. moving Groovy controllers to Spring MVC controllers, or Groovy services to Java services), migrating from Rails to Grails for integration for performance purposes is just a no brainer.

Anyway, enough of this high level stuff. I'm sure that if some Rails fanboys get a hold of this article, I'll probably get flamed with claims how Ruby & Rails can perform, and who knows what else, but I'll just leave the high level stuff at what I said above, and I'll focus on on comparing what I saw in Rails from the point of view of a Grails (and long term Java) developer. Additionally, I will be using a daily NetBeans 6.5 build (very close to RC1) to illustrate the steps I take along the way.

So, let's get started.

1. First, getting started with a project. In both Grails and Rails it's very simple to get started with the facilities NetBeans provides. For both Grails and Rails , NetBeans 6.5 provides wizards for creating a new project.




Now, a few comments on the contents of the screenshots. First of all, NetBeans 6.5 ships directly with Groovy & Grails support for the "Java" packaged download (e.g. from http://download.netbeans.org/netbeans/6.5/rc/). In contrast, for the Ruby/Rails support, you have to either download the Ruby package from the same location, or after downloading the Java installer / package, you have to go to the plugin center and install the Ruby/Rails plugin (either way, quite easy). Secondly, when you look at the options for Ruby/Rails projects, you might think that there are more options w/ Ruby and Rails, but it is actually quite deceiving. The reason that there are no separate options to create a "new Grails app w/ existing sources" is that NetBeans totally rocks and can directly open an existing Grails project without having to add any additional project data. On the Groovy front, you can just add Groovy scripts and classes into any Java project, so the extra options in the project menu are just not needed.

So, at first glance, very marginally and despite the outstanding NetBeans Ruby/Rails support, Grails scores the first point for me.

2. Second, I had to figure out what the general setup of a Rails app. Here's what a typical project structure looks like in both Grails and Rails:




Now, comparing the two project structures, it's very easy to get around the Rails app if you're familiar w/ a Grails project layout. A couple of things to note in the Rails project structure :
* The root of the web app is in the "Public" directory in the Rails app, while in the Grails project it's in the "Web Application" project folder.
* There is a "helpers" folder in the Rails app, which initially puzzled me. In most general terms, the helpers folder contains "controller helpers". Roughly speaking, the functionality that existed in "helpers" in the Rails app eventually founds its way in taglibs in the Grails app. Although I'm not 100% certain of the convention and usage of these helper methods in the Rails app, it seemed like the Rails active scaffold seemed to use some parts of what's in the helpers (however, i could be wrong).
* There is the "Migrations" folder in the Rails project, which seems to be generally useful and not present in the Grails app. Now, I would imagine that such a database centric functionality might not be that relevant in a Grails app, as a Grails app really isn't as aware of the database (as it deals w/ the domain model and not database columns as the Rails app does). Still, it seems like because Grails apps end up very much data driven, some method of managing the schema modifications could be generally useful (although, I really don't have any specific suggestions of what such a tool might be).
* (although you don't see this in the screenshots) If you had plugins installed into your Grails app, you would have a "Plugins" folder, which is roughly equivalent to the Rails "Vendors" foler.
* Finally, the Grails app has a folder called "Services" for creating transactional services , for which the Rails app doesn't have an explicit counterpart. More on transaction handling later.

All in all, in the rest of the project layout, they're very similar, and if one knows the one framework, it's pretty straightforward to grok the other one.

Alright, this is the general setup stuff so far. I have a lot more to write about : plugins, ajax support, services, transactions, the whole nine yards. Just to give you a sneak preview, the bottom line is that migrating a Rails app to Grails works very nicely, although not without a few minor hurdles to jump over. More on that in the next post, stay tuned...

Tuesday, July 08, 2008

Switch your test to Groovy ? Maybe not (yet).

When I attended the No Fluff Just Stuff conference last year, all speakers were pushing Groovy as an excellent choice for everybody's unit testing needs. And it is true that Groovy does bring a number of cool features to the testing party : expressiveness, ability to test private methods, mocks are almost built in the language.. So it's cool, no question about it.


In order for a tool to be effective as a unit testing tool, two things need to be true of the tool:

  • The tool has to be expressive when reading and writing the tests. In other words, the way the test are written should clearly express the purpose of the test.


  • When tests fail, the failures should very clearly pinpoint the reason for the failure and should help the developer immediately know the cause of the failure




Now, how does Groovy measure up ?

One of the big advantages of using an integrated framework like Grails (when I say integrated, I mean a framework that give you out of the box the whole stack : Ajax, web layer / controller, service layer, persistence) is that it is extremely easy to start writing tests. You just write "grails create-test" on the command line, and you already have the shell for the test. Then, when you want to run the test, you can easily run the test by just running "grails test-app", and voilla, all your unit and integration tests are off and running.

So, on the first criteria, Groovy really shines. Expressing the intent of the test with Groovy or verifying a particular test condition is way much better than doing the same in plain on Java. Often, reading a test written in Groovy is so much easier to understand what the test writer had in mind, it takes way less code to write and maintain. All in all, Groovy rocks here.

Now, the second part, pinpointing the cause of the error, I can't say much beyond what the stacktrace below says. Here are a couple of questions on the stacktrace below:

1. Can you make out where exactly the test fails ?
2. If this was a stack trace out of an error, would you be able to make out where the error occured ?
3. Can you figure out what classes are collaborating in your test ?

I think the answer to all three questions is probably a "no", or "it's not easy". For me, this is quite a show stopper for moving all my tests to Groovy (which might have previously been in Java). One thing about plain Java is just that : it's plain and simple to follow along. You see a stacktrace, and you immediately know what, how, who went wrong. Now, I could certainly agree that if you take Java, weave in some aspects, or throw in some interceptors (as in the case of EJB), the stacktrace can easily resemble what's below.

P.S. One final thing about NFJS and the push to use Groovy everywhere : it really bugs me that all of smart people who spoke in favor of using Groovy as a testing tool, just kept quiet about things like this. It bugs me very much that when an alternative like this was suggested, I was just given the positive side of the story, and the negatives were not mentioned at all (and mind you, there were definitely questions like "When would you not use Groovy for testing?). So, there seem to be two disappointing options here : either the speakers had not really used Groovy for testing and were pushing without having done any testing in Groovy themselves, or even worse, knew about these warts but intentionally kept shtumm on it




Cannot cast object 'com.company.foobar.RandomClassToTest@194e3fe' with class 'com.company.foobar.RandomClassToTest' to class 'java.util.List'

org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'com.company.foobar.RandomClassToTest@194e3fe' with class 'com.company.foobar.RandomClassToTest' to class 'java.util.List'
at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:340)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:628)
at config.foo.WorkflowConfigTests.transitionsWithStatus(WorkflowConfigTests.groovy:90)
at config.foo.WorkflowConfigTests.this$5$transitionsWithStatus(WorkflowConfigTests.groovy)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:77)
at config.foo.WorkflowConfigTests.validateSingleTransition(WorkflowConfigTests.groovy:64)
at config.foo.WorkflowConfigTests.this$5$validateSingleTransition(WorkflowConfigTests.groovy)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:867)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:77)
at config.foo.WorkflowConfigTests$_testExistingTransitionRules_closure1.doCall(WorkflowConfigTests.groovy:56)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.Closure.call(Closure.java:292)
at groovy.lang.Closure.call(Closure.java:305)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:1041)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:1018)
at org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:51)
at org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:54)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at org.codehaus.groovy.runtime.InvokerHelper.invokePojoMethod(InvokerHelper.java:765)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:753)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167)
at config.foo.WorkflowConfigTests.testExistingTransitionRules(WorkflowConfigTests.groovy:55)
at org.codehaus.groovy.grails.support.GrailsTestSuite.runTest(GrailsTestSuite.java:72)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at org.codehaus.groovy.runtime.InvokerHelper.invokePojoMethod(InvokerHelper.java:765)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:753)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167)
at TestApp_groovy$_run_closure8_closure18_closure19_closure20.doCall(TestApp_groovy:222)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:77)
at TestApp_groovy$_run_closure8_closure18_closure19_closure20.doCall(TestApp_groovy)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.Closure.call(Closure.java:292)
at groovy.lang.Closure.call(Closure.java:287)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:777)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:757)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeClosure(ScriptBytecodeAdapter.java:598)
at TestApp_groovy$_run_closure10_closure27_closure28.doCall(TestApp_groovy:353)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.Closure.call(Closure.java:292)
at org.codehaus.groovy.runtime.ConvertedClosure.invokeCustom(ConvertedClosure.java:48)
at org.codehaus.groovy.runtime.ConversionHandler.invoke(ConversionHandler.java:72)
at $Proxy20.doInTransaction(Unknown Source)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:128)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at org.codehaus.groovy.runtime.InvokerHelper.invokePojoMethod(InvokerHelper.java:765)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:753)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167)
at TestApp_groovy$_run_closure10_closure27.doCall(TestApp_groovy:365)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:77)
at TestApp_groovy$_run_closure10_closure27.call(TestApp_groovy)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:777)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:757)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeClosure(ScriptBytecodeAdapter.java:598)
at TestApp_groovy$_run_closure8_closure18_closure19.doCall(TestApp_groovy:220)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.Closure.call(Closure.java:292)
at groovy.lang.Closure.call(Closure.java:305)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.withStream(DefaultGroovyMethods.java:8161)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.withOutputStream(DefaultGroovyMethods.java:7738)
at org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:51)
at org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:54)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at org.codehaus.groovy.runtime.InvokerHelper.invokePojoMethod(InvokerHelper.java:765)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:753)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167)
at TestApp_groovy$_run_closure8_closure18.doCall(TestApp_groovy:195)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.Closure.call(Closure.java:292)
at groovy.lang.Closure.call(Closure.java:305)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.withStream(DefaultGroovyMethods.java:8161)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.withOutputStream(DefaultGroovyMethods.java:7738)
at org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:51)
at org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:54)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at org.codehaus.groovy.runtime.InvokerHelper.invokePojoMethod(InvokerHelper.java:765)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:753)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167)
at TestApp_groovy$_run_closure8.doCall(TestApp_groovy:194)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:77)
at TestApp_groovy$_run_closure8.call(TestApp_groovy)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:777)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:757)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeClosure(ScriptBytecodeAdapter.java:598)
at TestApp_groovy$_run_closure10.doCall(TestApp_groovy:338)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:79)
at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:94)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:77)
at TestApp_groovy$_run_closure10.doCall(TestApp_groovy)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:79)
at groovy.lang.Closure.call(Closure.java:292)
at groovy.lang.Script.invokeMethod(Script.java:87)
at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:934)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:881)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:79)
at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:94)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:77)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrent0(ScriptBytecodeAdapter.java:109)
at TestApp_groovy$_run_closure3.doCall(TestApp_groovy:116)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:79)
at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:94)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:77)
at TestApp_groovy$_run_closure3.doCall(TestApp_groovy)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:79)
at groovy.lang.Closure.call(Closure.java:292)
at groovy.lang.Script.invokeMethod(Script.java:87)
at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:934)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:881)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:79)
at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:94)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:77)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrent0(ScriptBytecodeAdapter.java:109)
at TestApp_groovy$_run_closure1.doCall(TestApp_groovy:62)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:79)
at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:94)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:77)
at TestApp_groovy$_run_closure1.doCall(TestApp_groovy)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:79)
at groovy.lang.Closure.call(Closure.java:292)
at groovy.lang.Closure.call(Closure.java:287)
at groovy.lang.Closure.run(Closure.java:368)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:79)
at org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:777)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:757)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethod0(ScriptBytecodeAdapter.java:195)
at gant.Gant.dispatch(Gant.groovy:271)
at gant.Gant.this$2$dispatch(Gant.groovy)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:675)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:777)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:757)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167)
at gant.Gant.invokeMethod(Gant.groovy)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:77)
at gant.Gant.processTargets(Gant.groovy:436)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:77)
at gant.Gant.processArgs(Gant.groovy:372)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:946)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
at org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:777)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:757)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167)
at org.codehaus.groovy.grails.cli.GrailsScriptRunner.callPluginOrGrailsScript(GrailsScriptRunner.groovy:204)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1094)
at groovy.lang.ExpandoMetaClass.invokeStaticMethod(ExpandoMetaClass.java:957)
at org.codehaus.groovy.runtime.InvokerHelper.invokeStaticMethod(InvokerHelper.java:800)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeStaticMethodN(ScriptBytecodeAdapter.java:212)
at org.codehaus.groovy.grails.cli.GrailsScriptRunner.main(GrailsScriptRunner.groovy:124)
at org.codehaus.groovy.grails.cli.support.GrailsStarter.rootLoader(GrailsStarter.java:140)
at org.codehaus.groovy.grails.cli.support.GrailsStarter.main(GrailsStarter.java:169)

Thursday, May 15, 2008

Tapestry5 NetBeans Quickstart

I have been following the development of Tapestry 5 closely for the last couple of months, and I even got the first Tapestry 5 book that came out. I'm a big Tapestry fan, and I've been looking forward to the new Tapestry 5 release. I even lucked out and had a chance to talk to Howard in person:



One of the cool things that keeps drawing me towards Tapestry is the goal to make it really easy and intuitive to work with. One of the goals that I remember hearing for Tapestry 5 was to make it that easy, that it would compete more w/ Grails & Rails and not so much w/ traditional Java Web app frameworks (e.g. Struts, Struts2, etc)

However, when I first took a look at Tapestry 5, I was a little disappointed by the six line Maven command that one had to type in when starting a new project (e.g. see http://tapestry.apache.org/tapestry5/tutorial1/first.html):

mvn archetype:create
-DarchetypeGroupId=org.apache.tapestry
-DarchetypeArtifactId=quickstart
-DgroupId=org.apache.tapestry
-DartifactId=tutorial1
-DpackageName=org.apache.tapestry.tutorial


Compare that with Grails:


grails create-app

Welcome to Grails 1.0 - http://grails.org/
Licensed under Apache Standard License 2.0
Grails home is set to: /usr/local/java/grails
Application name not specified. Please enter:
FooApp
---------------
[propertyfile] Updating property file: /home/polrtex/temp/FooApp/application.properties
Created Grails Application at /home/polrtex/temp/FooApp



It is true that one doesn't create an application all that often, and copy-and-pasting
these initial 5-6 lines would not be that big of a deal. However, for a newcomer, the Tapestry 5 experience has to be really smooth and starting a new app should be a breeze.

So, you would say, what does this have to do with NetBeans ?

Here it comes. As usual, NetBeans rocks everyone's socks, by lowering the entry barrier into starting an application. Here are the first steps (equivalent to the first two pages of the Tapestry tutorial : http://tapestry.apache.org/tapestry5/tutorial1/env.html). Here is what you need to do:
( Assuming that you already have a good install of NetBeans 6.1).

  1. Install the NetBeans Maven plugin by going into Tools -> Plugins . Type "maven" in the upper-left corner search box and install the plugin. The result should look something like this:
  2. Create a new Maven project
  3. Expand the "Archetypes from remote Maven repositories" and scroll down to find the Tapestry5 quickstart archetype . You might want to pay close attention to the description and select the latest archetypes (in my case, for 5.0.11)
  4. Now that you have the nice wizard, fill out the configuration attributes to specify the group id, the location of the project, the name of the project, etc.
  5. When you hit Finish, Maven will start downloading all the dependencies and setting up your project.
  6. Your new and shiny project is ready to go. Go into the project Properties and select your desired server to deploy to:
  7. Run the project from the project context menu and you're up and running !!!!



One very cool option that makes the Tapestry 5 setup almost identical to the Grails setup is the ability to run the application in Jetty by going to the command line and running:
mvn jetty:run

The upside of doing this is that after you run it, there is no deployment step. Tapestry supports reloading of the page templates as well as the page classes. As a result, whenever you make a change to a page, you can save it, refresh the browser and see the changes . Similarly, when you make a change to a class, compile it and the changes are immediately visible to the application. Such a setup really cuts down on waiting for the app to deploy.

So now, looking back a little bit, this setup is indeed very competitive w/ the Grails setup. In Grails, you would download the Grails distribution, and then would run the "grails create-app" command to create the new project. Grails would then prompt you for some properties (e.g. project name) and you're done. For Tapestry, it's quite similar; however, instead of downloading the Tapestry distribution, you would simply download Maven2 (or in the case of NetBeans, you would install the NetBeans plugin). Even better for Tapestry, if you already have Maven install, then starting a new app becomes a zero cost operation : you just specify the command line args (or better yet, use NetBeans to create the new app) and you're on your way, all dependencies already in place.

So, so far it's a tie between Grails and Tapestry. Grals vs Tapestry = 1:1

Enjoy your shiny and new Tapestry 5 app in NetBeans !!!

Friday, May 02, 2008

Quick File Chooser in NetBeans 6.1

I'm on a roll today, but I thought I'd drop this tip as well.

I'm a big fan of the NetBeans Quick File Chooser plugin, it makes it oh-so-easy to open up a file without having to detach my fingers from the keyboard. So, if you Google for the plugin, you'll find Tor's recommendation of the same; however, you can't find it on the Plugin Center . So, what if you really wanted to use the Quick File Chooser, in NetBeans 6.1, what should you do ? In the past, I've always copied the plugin with my netbeans preferences from the previous version that I've used, and it's worked OK. However, I decided on a clean NetBeans install on my home laptop, and I couldn't get my hands on it.

So, I followed a tip from Octavian's blog , added the Netbeans Latest Build update center, and ... voila, the Quick File Chooser is in the list of available plugins. Since it doesn't depend on any of the features of 6.1+ code, it works great in 6.1 as well.

Groovy HTML Encode

I kinda thought that in the past I had used a special Groovy method to encode something as HTML. I mostly need that when I need to post something to Blogger (which completely baffles me - why isn't there a better way of copy-and-pasting html/xml in blogger content ???) . I do know that in Grails, there are a couple of special methods that you can use if you want to encode something as html, json, or something else. However, I'm not using Grails right now, so that's not always the best option.

After wasting 15 minutes trying to remember exactly how I did it in the past, I realized that I was using StringEscapeUtils from Apache commons-lang. So, having remembered that, it just works like magic, here is what I use to convert my xml/html samples in order to post them on Blogger:

this.class.classLoader.rootLoader.addURL(new File("/usr/local/java/grails-1.0/lib/commons-lang-2.1.jar").toURL())


xml = '''
<module id="id" version="0.0.1" package="package"> </module>
'''
org.apache.commons.lang.StringEscapeUtils.escapeHtml(xml).split("\n").each() {println it }

, which outputs the following :
&lt;module id=&quot;id&quot; version=&quot;0.0.1&quot; package=&quot;package&quot;&gt; &lt;/module&gt;

, which is what I paste into blogger and it works like magic !!!

No more running around like a headless chicken trying to find some service online that will convert my html/xml snippets !


Freeform projects NetBeans JUnit test results : binding output to source code

As I had mentioned in a prior post a while back, it is pretty straightforward to bind the output of a Freeform Project JUnit task to the NetBeans JUnit test results. However, there are a couple of minor tweaks that I find myself making and forgetting, so, I thought I'd drop a blog entry, even just as a reminder for myself.

First, make sure that the JUnit task as a showoutput="true" attribute and has a formatter that explicitly states that doesn't use a file, e.g.

<formatter usefile="false" type="brief"/>

Emphasis on not using a file : e.g. you can use an xml formatter and it would work; however, if you don't specify the usefile="false" attribute, everything goes to the file and NetBeans doesn't get a chance to capture the output and display the results in a nice JUnit test results tree. As a result, the best combination ends up being a combination of a xml formatter that outputs to a file, and a brief formatter that doesn't, e.g. :


<junit fork="yes" printsummary="withOutAndErr" showoutput="true" errorProperty="test.failed" failureProperty="test.failed" filtertrace="false">
<formatter type="xml">
<formatter usefile="false" type="brief" />
<classpath refid="whatever-path-id">
</classpath>
</junit>

The second important part of working with the JUnit results in NetBeans is to make sure that when a test fails, when you click on the failure in the JUnit results, you want NetBeans to take you to the right line in the source code:

In order to accomplish that, make sure that you properly set the output directory for your test cases in your NetBeans project with the UI or project.xml:

  • In the Project Properties UI


  • In the nbproject/project.xml
...
<java-data xmlns="http://www.netbeans.org/ns/freeform-project-java/2">\n ....
<compilation-unit>
<package-root>test/integration</package-root>
<unit-tests/>
<classpath mode="compile">${test.completion.classpath}</classpath>
<built-to>dest/test/unit</built-to>
<source-level>1.5</source-level>
</compilation-unit>
....
</java-data>
....

Saturday, April 26, 2008

Symantec Horror Story : "The Symantec Experience"

After a 6 months hiatus in the antivirus subscription of one of the laptops at the house, I finally decided to bite the bullet and either get the upgrade or subscribe to the antivirus updates. I was quite reluctant to do it for quite a bit ( I just absolutely hate being blackmailed into buying a product), but after listening to Security Now, I finally decided that it's not worth risking a security breach of the windows machine (btw, I'm entirely embarrassed to admit that I do own a Windows machine) . My Better Half is too attached to her ICQ client (despite the million better alternatives) and a few other pieces of software that she never uses, and so far I haven't been able to convince her to switch to Linux. On the positive side, my son has been a Linux user since he's 3 years old and he's happily playing a whole bunch of nice games like SuperTux, PPRacer, and many more others..).

Anyway, I digress. So, I finally decided to bit the bullet and part with 50 of my hard earned dollars. So, I go to the Symantec website (I did have a trial version that came with my access point), and here my woes really started.

First, while I'm ordering the software, they try to sell me "A Service" where they'd keep my download for a year. I figured, hey, I could download it and burn it to a CD, and I don't need to shell out $10. So , I happily click on the link and download an executable, I get a setup.exe and I start it up. Lo and behold, it's not the software, it's a "Download Manager" !!! In a later part of the saga, I asked their tech support what the service is all about and I can store the little download manager and reinstall the software 6 months from now, and they gladly told me that I could just download the trial version and use my registration code and I'd be good. So, WHY did they recommend the "Download Service" for 10 bucks ??? Hm, first signs of fishiness start showing...

Alright, so I downloaded the software, and started it up. As I mentioned before, the download manager started doing its job and in about half an hour the whole deal was downloaded. Now, while I was waiting for half an hour for the download to finish, why not make myself useful and see if I can clean up some of the old software from the machine. At one time the Norton Internet antivirus decided that it was done downloading and it has to start installing now! Well, as bad luck would have it, at the same time I was uninstalling an older JRE version. So, Norton decides to die and tell me that it can't install while something else is installing. I said fine, continued w/ my JRE uninstall, thinking that, stupid me, I'll just restart the Download Manager and it will resume the install.

Not that easy !!! I start the setup.exe again and it just tells me that the download is finished and just closes. WHAT?!!??? Did I just pay fifty bucks for this?? I didn't exactly order a download manager, I just wanted the damn software, but hey, they're smart and decided to give me a download manager instead. Alright, that works too, but at least make sure that the download manager knows how to start the installer, puh-puh-please !

So, next action. What can I do ? Phone, internet suport forum, online chat ? I decide to go with the online chat. However, Symantec decides to be fresh again ! Instead of just firing up some AJAX little gizmo to just exchange a couple of words with their technician, what do I have to do ? Of course, I have to download and install an application, that would install and register an ActiveX in my system, so that when I go into their "live chat" feature, it can look as if it is running in the web browser. Not only that, but the little piece of crappy software only happens to work in Internet Explorer !!! Is this coming from a company that is claiming that will protect my security ? "Oh, just install this little piece of software, we're just going to chat, disregard all the security warnings about ActiveX and such". What a bunch of losers !!

So, I once again stoop to their level and download the ActiveX and install the thing. By now, I'm quite pissed, I'm running IE, allowing ActiveX garbage on my machine. I finally get to the chat page, and you'd think with the ActiveX it would be something really fancy and slick. Nope. Just a text field for me to enter my comments, and a text area for the current conversation. The crown jewel of this work of art are three radio buttons to select what the technican can do "Nothing", "View Only" and "Full Control". You might think that a security company would be concerned and would give the users some choice to protect themselves . No such luck. The default is on "Full Control". And I thought that best practice in security would have been to give the user a choice and let them choose if someone else would poke around their machine, and worse off, I thought Symantec would have thought of that. Another level of disappointment reached !

So, I start talking to the dude (Krishnan) who takes his sweet time to answer my questions. I type in 5 things, wait for 10 minutes and only then he decides that I'm worth his attention. First, I ask him a couple of things about how disappointing the experience is so far, and then I get to the meat of things : I ask him why I can't install the product. The solution turns out to be "easy" : I just go to the Symantec site and download and run a tool (yup, an .exe), and what do you think it does ?? Ta-da !! It cleans up whatever the Download Manager downloaded so that I can start the Download Manager again and let it download for another half hour. Isn't this brilliant ?? Anybody with a brain stem would have figured this out : hey, why not include the "Download Cleanup" functionality into the Download Manager ? I mean, it's not like they shipped the product to me 6 months ago and don't have a chance to patch in this functionality : I downloaded the Download Manager 10 minutes ago !

Alright, next phase in the saga. I clean up my download, start the download again (yep, another 30 minutes down the drain) and I'm chattling w/ Krishnan about how I can leave some feedback to Symantec to help them improve their product. I could certainly just bitch about it (like I'm doing now) and and let them continue having a crappy product, but hey, I decided I'll give them a shout. So, while I'm still chatting w/ the dude, I went to their feedback page (of course still in IE7) and then... IE CRASHES and BURNS !!! Now, I'd guess it wasn't just a fault of IE, for some reason it's the ActiveX that I was using (of course, this is just speculation, I was so mad I didn't go digging through logs and such). Now I'm just flipping out : I'm using IE, ActiveX running, with a product that just goes out of its way trying to prevent me from using it, after being blackmailed for fifty bucks to run a shitty OS on my sweetheart's laptop, and it just died !!!

At this point, I'm lost for words. On one side, I could go and talk to tech support again, and possibly lose another hour dealing with them, or I could just try doing it on my own. But I'm suffiiently disappointed and I really want to try and ask them if I can cancel my order. Note, I said "ask them if I can", not "tell them to cancel". So, I go back into their online chat support center (ActiveX and all), and I start talking to a new dude (hm, was it Prasad??). I explained the problem that I had and I ask him to tell me what the options are to cancel my order. I specifically told him "Don't cancel the order yet, just tell me what the options are". I give him address and order number to look up the info. Once again, Dude takes his time, no hurry for him, he's getting paid for his time. Just as I'm about to ask him what's going on, he cheerfully informs me that... I'm all set, my order is cancelled and that it might take a few days for the refund to process. WHAT ???!!?? I specifically told the dude, DON'T cancel the order. Just as I'm explaining to the dude that I didn't want to cancel the order, he disconnects and reconnects from the chat session a couple of times, not mentioning a thing about it (no sorry, I got disconnected, nothing).

So, let me recap here. I'm working in Windows, that sucks. I part with my money to fix the crummy OS and prevent it from being 0wn3d every other day, and the antivirus company tries to take my dough for a useless download service (by default), so I'm even more bummed out. Then, I try to install something that should be a total no brainer, it doesn't care about installing the software, it cares about downloading it only. Hm... I'm fuming ! Then, the security company makes me jump through 100 insecure hoops including installing ActiveX-s who want full control by default of my desktop, running executables just downloaded from the web (albeit from their site, supposedly secure), and giving full remote control to a dude I don't know sitting somewhere in India. I'm starting to flip out now !!! How many times did I give somebody a chance to r00t my machine, I wonder ? Somewhere along the way, the antivirus company's software crashes my browser, and to top it off, the customer support people just blow me off, take their sweet time in addressing my issues, and in the end just cancel the order despite the fact that I told them not to !!!!

So, I ask , WHY ? I can see that my fifty bucks are not going to break a billion dollar company (or however big it is, it is big). But is that a reason to totally dis me and let it be known that they don't care ? Is that a reason to introduce glaring security issues along the way (ActiveX, executables, giving full control to my box by default) just based on the fact that they are "the security experts" - e.g. what if someone compromised THEIR site, how many of their customers would be compromised along the way ? Is that a reason for the customer support to not pay attantion to what I'm saying and disrespect me by just answering once every 5 minutes ?

Anyway, that's my story. I just blows me away that such a large industry is built on the side of a bug ridden OS, and to make it all more perverse, the culprit of the whole situation is also in the same industry (e.g. Microsoft OneCare product charges for services that prevent attackers from exploiting bugs in the OS that Microsoft itself built). Now, wouldn't it make sense that if one bought a Microsoft product, such protection would come as a part of the OS, instead of selling you a faulty OS, and then selling you a service to fix it. It's an interesting conflict of interest : would Microsoft make more money if they fix the OS and make it less exploitable (thus losing money on Antivirus support), or would they make more money selling a crummy defect-ridden OS and then selling Antivirus products for it ?

This is the end of my story. My conclusion : I'm so glad I use Linux !! Rock on Fedora, I'm looking forward to Fedora 9 !!

Monday, April 07, 2008

Apple Brainwashing puzzle

I write software for a living. As a result a lot of my favorite software developers at work and in my communities (e.g. Tapestry, Grails, NetBeans) are Mac users. On one hand, I accept the fact that, hey, they like their Mac, just as much as I am passionate and like my NetBeans for example. However, there are a couple of things that I haven't been able to grasp yet.

All of the people I'm talking about are very smart and very independent. Yet, at the same time, Apple has managed to run some kind of brainwashing trick, where anything Apple comes up with and anything Apple says is taken at face value. Here are a couple of glaring examples:

  • A year or however long time ago, Apple decides to do their iPhone thing. Great, nice device, cool glitzy graphics, all that. All of a sudden, everyone from a large number of my coworkers to the people on the Oscars buys an iPhone. That is all well, but the more puzzling part is how most people just swallow the garbage coming from Apple without questioning it. For example, I bet that 90% of the iPhone users still think that iPhone was the first device that had a full blown browser that doesn't need the content to be specifically formatted for mobile devices ( while I've been happily browsing on my Nokia E61 for 1-2 years before the iPhone came out, mind you with the E61 happily running a KHTML derived browser, the same browser that Safari extends as well).
  • Apple decides to release their SDK and to allow 3rd party Devs to distribute their apps for iTunes. That is all great, nice thinking, good way to screw the walled garden of the network operators (ironically, by creating a new walled garden, this time controlled by Apple). So, all of a sudden, everyone believes ( I spoke to a very smart coworker of mine, listened to the Java Posse) that this is the first attempt where a non-operator sets up a distribution mechanism where 3rd party devs can certify and distribute their apps. Rewind to 2-3 years before the iPhone SDK launch, and I was happily exploring the Nokia Catalogs (on my phone) that has a whole bunch of free and commercial applications for download (that have nothing to do with the operator, the same "independent" software distribution channel that Apple claims to have invented).

The list can go on and on. What really puzzles me is that Apple can throw these outrageously false claims, and all of these smart and independently thinking people that I know just eat it up, without questioning it for a second. What drove me over the edge was when I was listening to a Java Posse interview where they were discussing the release of the iPhone SDK and how Apple supposedly "owned" the device and that Apple was within their right to lock the device as much as they want and go to great lengths to restrict what kind of software could be on it (e.g. starting from the "locked" phones, going through the clauses in the iPhone dev kit that prohibits its usage for creation of VMs, including Java). That is the biggest steaming pile of BS that I've heard . Yeah, I know that when you get the software you don't actually "own" it, you license it, but I can't believe my ears : if I had spent $400-$500 on a device you better believe it that I will want to have as much control over it, I OWN the goddamn thing. Now, if it was someone other than Apple (e.g. think Microsoft), all of these smart people would be up in arms calling for boycotts of the device and the company and who knows what else. But when it's Apple, people just suck it up.

So, people, let get our senses back and start thinking a little bit more critically about the garbage that comes out of Apple's brainwashing machine. I know they make nice products and all, but let's not lose our senses every time they say something and examine it for what it really is : a company pushing their products and very selfishly looking out for its own interests.

Thursday, February 28, 2008

Thesis presentation

Below is the content of the presentation that I gave on my thesis about a year ago. It clearly is missing a lot of the content to explain what each slide is all about, but it nicely gives the general idea of what the solution is like:










Tuesday, October 16, 2007

Starting to publish thesis

After a long time for thinking and deciding what I'm doing with my thesis, I decided to go ahead and start publishing it little by little. Overall, I could post the whole thing in one swooop; however, I have to do some conversion into HTML; thus, I plan to publish it chapter by chapter.

Here (as a test) is the content of the thesis abstract:

Friday, September 14, 2007

Grapestry view and controller resolvers

This is a posting that I had started quite a while ago (right when I was starting w/ Grapestry), and I never posted it. Anyway, I thought that the content might be useful to someone trying to use hivemind with Tapestry 4. It would be very interesting when I will get a chance to try the same using the new and shiny Tapestry 5.

--------------------

The first couple of steps from the Grapestry wish list is to make the templates and pages be located in the same spot where the standard Grails gsp-s and controllers are (e.g. in grails-app/views and grails-app/controllers respectively).

First to set up the stage to what I'll talk about. For starters, I knew that HiveMind is what makes Tapestry tick. Secondly, I knew that Tapestry is very flexible and customizable, and I expected to fairly easy be able to make it look in all the right places.

So, first stop was the Tapestry User Guide configuration section. At the bottom of the page it says that there is a "configuration point" for org.apache.tapestry. specification-resolver-delegate and org.apache.tapestry. template-source-delegate - the explanations seem to point out that this is exactly what I need. So, I start thinking : how hard could it be to implement a couple of interfaces to just point to the directories I want and have it do it's magic. Well, it turns out, not as easy as it sounds.


  1. So, for the template resolver, I only need to implement this one interface, that should be easy

    public ComponentTemplate findTemplate(IRequestCycle cycle, IComponent component, Locale locale) { }






  2. Alright, I got right on it. Now, I only need to figure out how to produce a ComponentTemplate. I start digging through the Tapestry core source code, So, the constructor for ComponentTemplate looks like this:


    public ComponentTemplate(char[] templateData, TemplateToken[] tokens) {}


    OK, I can figure out how to produce a char array from a file, but these TemplateToken-s... At this point, I started realizing that this is not something that I should try to figure out from the top of my head, but rather go out and find an example that already implements the ITemplateSourceDelegate interface, surely somebody has done this before.



  3. So, I start digging around for an example. This is where it started getting scary. The first couple of links that come up talk about how nobody has really posted a good example of how this is done. Overall, the problem is that there is a boatload of "helper" objects (e.g. DefaultParserDelegate, TemplateParser, ComponentSpecificationResolverImpl, etc. the list goes for quite a bit) that you need to create before you can actually create an instance of this ComponentTemplate. On one hand, it all makes sense: Tapestry is a very modular framework, and you could potentially replace each one of it's pieces with some other component that implements the contract. On the downside, if you don't know much about the guts of Tapestry (e.g. for someone like me), digging into the guts is not that much fun.



  4. So, I say, I'll give the code that was posted on the mailing list, that should certainly work, especially since the responders say that they do work. Great, I copy-paste-compile.. and when I run my test Tapestry app (with a similar structure to a grails app - e.g. with WEB-INF/grails-app/views, etc)... a NullPointerException.. Luckily, Tapestry is open source, I dig into the source and I realize that I get the NPE when it's trying to log something.. So, do I need to inject a log into every object that I create ???



  5. This is when I realized that I just need to use the facilities that Tapestry uses to inject it's dependencies - namely, Hivemind. The thing is, I know nothing about it.. After reading up about it, it turns out that it uses these configuration points that you can use as well. So, my task moved from "copy and paste an example from the mailing list" to "figure out how this HiveMind thing works and then make it work for my ITemplateSourceDelegate implementation. I have read 2 books on Tapestry, but neither of them says anything about HiveMind (I admit, one was older, on Tapestry 3.0, the other one more focused on Tapestry itself, not its infrastructure). So, here is what I ended up using for my hivemind config file:
    <module id="id" version="0.0.1" package="package">
    <implementation service-id="tapestry.page.SpecificationResolverDelegate">
    <invoke-factory>
    <construct class="com.troymaxventures.grapestry.framework.ViewsSpecificationResolverDelegate">
    <set property="pagePath" value="grails-app/controllers"/>
    <set property="componentPath" value="grails-app/views"/>
    </construct>
    </invoke-factory>
    </implementation>

    <implementation service-id="tapestry.parse.TemplateSourceDelegate">
    <invoke-factory>
    <construct class="com.troymaxventures.grapestry.framework.ViewsTemplateSourceDelegate">
    <set property="grailsAppPath" value="WEB-INF"/>
    <set-service property="parser" service-id="tapestry.parse.TemplateParser" />
    <set-object property="contextRoot" value="infrastructure:contextRoot" />
    <set-service property="componentSpecificationResolver" service-id="tapestry.page.ComponentSpecificationResolver" />
    <set-object property="componentPropertySource" value="infrastructure:componentPropertySource" />
    <set-object property="rootOverride" value="app-property:grapestry-webapp-root-override" />
    </construct>
    </invoke-factory>
    </implementation>
    </module>


This hivemind configuration almost works for what I needed it to do in Grapestry. Unfortunately, it didn't get too far as the Grails test / development configurations work slightly differently than in production.

The general conclusion on the technology / Hivemind : it definitely seems like a cool dependency injection solution, especially in the way that it can dynamically aggregate modules and create a configuration on the fly (e.g. compared to Spring, where you have to explicitly say what goes into the config and how the different configs will interact). However, as with anything else, the high level of decomposition, where each class does only one job, and the many dependencies between the classes, make it sometimes difficult to figure out : e.g. if for a simple change like this, you have to track down 10 dependencies, that might have dependencies on their own, it sometimes makes you wish that the software you're trying to use wasn't as clean.

Saturday, September 08, 2007

Grapestry progress and wishlist

I've been making some progress in making the Grapestry Grails plugin more integrated into Grails. Overall, it hasn't been quite a walk in the park, mostly due to the way Tapestry works. Here are a couple of things that would really be nice-to-have before Grapestry can really be usable as a Grails plugin:


  1. Tapestry templates (pages and components) should show up directly under the grails-app/views directory. Overall, the idea is that that's where Grails GSPs typically show up, and it would be most natural for Grapestry to do the same

  2. Tapestry page and component classes should live directly under grails-app/controllers. Overall, in Grails, the controllers are what process the requests. Since the page and component classes have the corresponding duty in Tapestry, so it would make sense to keep them there

  3. Since Grails emphasizes convention over configuration, creating pages should default to no page specification files. Everything that a page spec does should be accomplished using annotations (totally acceptable in regular Tapestry)

  4. Add groovy scripts and templates that would set up a default page template and page classes, e.g. something like 'grails create-grapestry-page' and 'grails create-grapestry-component'

  5. Add scaffolding similar to the one that exists in Grails controllers. It seems totally possible that there could be default methods like 'list', 'edit', etc on a grapestry page that would do the equivalent job of the Grails controllers with dynamic or static scaffolding

  6. Have some NetBeans support (hopefully coming in NetBeans 6.0) for Grails and Tapestry to make editing the Tapestry components in Groovy at least on par with doing them in Java



I did make some progress in accomplishing the first couple of bullets above. I kinda thought I had that down; however, it turns out that the "Development" grails configuration doesn't quite obey the same rules (it uses some resouce loaders that load resources directly from the ${app_dir}/grails-app/view and controllers directory), so I'm working on some workarounds for that.

Just yesterday, I got the Grails plugin account, but I still need to take a look at a standard grails plugin structure before I put anything out there.

Monday, August 27, 2007

Grails + Tapestry = Grapestry ? Part 1 (of n)

I've been quite intrigued by the approach Grails takes to developing web apps. It really is very nice that Grails offers and end-to-end solution that provides the framework for the front end, services, and back end.

At the same time, I've been a big Tapestry fan, as it seems that it is the best web framework that I know about. I did read up about how Grails handles the front end, and although it provides decent support for developing the front end (with some cool integration into the whole Grails framework), but still not as nice as what Tapestry has. After all, the Grails front end is just a part of the puzzle; whereas, with Tapestry, that is it's primary goal (not to mention the whole difference between developing a "page-oriented" application with Grails compared with developing an application with a component based framework like Tapestry).

The bottom line is that Tapestry is perfect for quickly developing the front end of the app, and Grails is excellent in quickly developing everything else. The primary draw of Grails is it's use of GORM; yet, the whole integration with Spring, is also very nice. So, bottom line is, I need to have a Tapestry front end and a Grails back end.

I kinda had this idea in my head for a while, but the lucky event was that I stumbled on a blog post by Grame Rocher about integrating Wicket into Grails. It seemed straightforward enough, I asked him if he thought if Tapestry would be much different, he said "no", so, I thought, "Great, I'm going to rock on and build a cool Tapestry plugin for Grails".

As usual, it's easier said than done. It's probably been a couple of weeks since I've been able to get even close to having Grails and Tapestry work together. So, here are the steps, that I took along the way. When I come close to rounding this up, I'll probably release it somewhere (dev.java.net, sourceforge, google code, I'll have to see, I'm open to suggestions). Btw, my preliminary name for the plugin is Grapestry, it's temporary, but I have this idea about a logo that has a big juicy grape on top of a cake or something like that (get it, "Grape Pastry"? :-) ) . Btw, just to mention that the work so far really did take about half an hour to do (just like Graeme said). The "other stuff" is what took me much longer that I thought it would: maybe another couple of hours to understand where each grails-app subdirectory ends up when the app is packaged, a couple of hours on researching existing Grails plugin and figuring out how the whole Grails magic works , and then a LARGE number of hours actually doing the integration between Tapestry and Grails (the stuff that I'm going to blog about in the next posting)...

So, first things first. I followed Graeme's instructions on how to set up a plugin and how to do the basic plugin setup.

  1. Do the grails create-plugin to set up the basic directory structure, etc.

  2. Add the jars from the tapestry distribution into the plugin lib directory. Interesting problem that I had to deal with there was that Grails (the actual distribution, inside of $GRAILS_HOME/lib) had some common jars with Tapestry. Unfortunately, Tapestry 4.1.2 required later versions of those jars, so I had to copy those particular jars from the tapestry distribution into $GRAILS_HOME/lib, and remove (or temporarily rename the jars inside of the Grails lib directory). From the feedback that I got on the Grails forum, it seems like Grails doesn't have a way to dealing with dependency conflicts between what the plugin requires and what Grails requires. I am slightly negatively surprised by this, as Grails comes with a whole bundle of dependencies (it's 20+ Megs), and the chance that Grails might conflict with another jar version seems quite high. Oh, well, moving on for now, this is just one more item on my Grapestry ToDo list

  3. I edited the canned Groovy file that configures the plugin, and gives it a chance to do it's modifications inside of web.xml, the spring config, and whatever else (there are a bunch of ToDos here as well, I'll write more about this later). A couple of things to point out in the source:

    • The ejection of the controllers plugin : I'm not sure if this is necessary, it implies that if someone is using this plugin, they are totally not interested in using the Grails standard action handling. It seems that most Grails plugins are complementary to Grails, so, is this the right way to go ? I don't know, I'm not convinced.... Also, it seems that if this is a correct assumption, the whole Grails web layer (e.g. controllers, taglibs, AJAX) can be ripped out since it will not be necessary any more, all handled by Tapestry

    • The setup inside of web.xml is pretty standard, it's just a translation of a standard Tapestry web.xml into the Groovy xml builder format

    • The other interesting method that will most likely get some action is the doWithApplicationContext and doWithDynamicMethods. I looked at the controllers plugin, and that's where a lot of the Grails magic happens (e.g. dynamic scaffolding, a lot of default methods, etc), all things that are a must for my Grapestry plugin.





    class Grapestry2GrailsPlugin {
    def version = 0.1
    def dependsOn = [:]
    // This removes the Grails standard controllers plugin, which means that standard Grails actions and such would not work anymore.
    def evicts=['controllers']

    def doWithSpring = {
    // TODO Implement runtime spring config (optional)
    }
    def doWithApplicationContext = { applicationContext ->
    // TODO Implement post initialization spring config (optional)
    }
    def doWithWebDescriptor = { xml ->
    def servlets = xml.servlet[0]

    servlets + {
    servlet {
    'servlet-name'('tapestryapplication')
    'servlet-class'('org.apache.tapestry.ApplicationServlet')

    'init-param' {
    'param-name'('org.apache.tapestry.disable-caching')
    'param-value'('true')
    }


    'init-param' {
    'param-name'('org.apache.tapestry.application-specification')
    'param-value'('tapestryapplication.application')

    }


    'load-on-startup'(1)
    }
    }


    def mappings = xml.'servlet-mapping'[0]
    mappings + {
    'servlet-mapping' {
    'servlet-name'('tapestryapplication')
    'url-pattern'('/app')
    }
    'servlet-mapping' {
    'servlet-name'('tapestryapplication')
    'url-pattern'('*.html')
    }
    'servlet-mapping' {
    'servlet-name'('tapestryapplication')
    'url-pattern'('*.direct')
    }
    'servlet-mapping' {
    'servlet-name'('tapestryapplication')
    'url-pattern'('*.sdirect')
    }
    'servlet-mapping' {
    'servlet-name'('tapestryapplication')
    'url-pattern'('*.svc')
    }
    'servlet-mapping' {
    'servlet-name'('tapestryapplication')
    'url-pattern'('/assets/*')
    }
    }

    def filter = xml.filter[0]

    filter + {
    'filter-name'('redirect')
    'filter-class'('org.apache.tapestry.RedirectFilter')
    }

    def filterMapping = xml.'filter-mapping'[0]
    filterMapping + {
    'filter-name'('redirect')
    'url-pattern'('/')
    }



    }



    def doWithDynamicMethods = { ctx ->
    // TODO Implement additions to web.xml (optional)
    }
    def onChange = { event ->
    // TODO Implement code that is executed when this class plugin class is changed
    // the event contains: event.application and event.applicationContext objects
    }
    def onApplicationChange = { event ->
    // TODO Implement code that is executed when any class in a GrailsApplication changes
    // the event contain: event.source, event.application and event.applicationContext objects
    }
    }




  4. The next step is to actually, build some Tapestry artifacts to get the puppy going: a Tapestry page in Groovy, a page specification, and an html template

    • First, the Tapestry page implementation. Not much to talk about, just one persistent property to make sure that the annotations work, one simple action that makes sure that event dispatching works OK, and that one last action to make sure that GORM style object retrieval, etc works. Here is the pudding:

      package com.troymaxventures.grapestry.pages;

      /**
      *
      * @author akochnev
      */
      import org.apache.tapestry.annotations.Persist;
      import org.apache.tapestry.html.BasePage;



      public abstract class Home extends BasePage {
      @Persist
      public abstract int getCounter();
      public abstract void setCounter(int counter);


      public void doClick(int increment) {
      int counter = getCounter();

      counter += increment;

      setCounter(counter);
      }

      public void doClear() {
      setCounter(0);
      }

      public void saveSomething() {
      /*
      def b = new Foo(name:"Foo",url:"http://foo.bar.baz")
      b.save()

      println "Saved Bookmark2: " + Foo.get(1)
      */
      println "Called saveSomething"
      }
      }




    • The Tapestry page template , just some trivial markup with something to call into Tapestry:


      <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

      <html>
      <head>
      <title>My First Tapestry Page</title>
      </head>
      <body>

      <h1>My First Tapestry Page 3</h1>


      Date: <div jwcid="@Insert" value="ognl:new java.util.Date()">June 26 2005</div>
      <p>
      The current value is:
      <span style="font-size:xx-large"><span jwcid="@Insert" value="ognl:counter">37</span></span>
      </p>

      <p>
      <a href="#" jwcid="clear@DirectLink" listener="listener:doClear">clear counter</a>
      </p>

      <p>
      <a href="#" jwcid="@PageLink" page="Home">refresh</a>
      </p>

      <p>
      <a href="#" jwcid="by1@DirectLink" listener="listener:doClick" parameters="ognl:1">increment counter by 1</a>
      </p>

      <p>
      <a href="#" jwcid="by5@DirectLink" listener="listener:doClick" parameters="ognl:5">increment counter by 5</a>
      </p>

      <p>
      <a href="#" jwcid="by10@DirectLink" listener="listener:doClick" parameters="ognl:10">increment counter by 10</a>
      </p>

      <p>
      <a href="#" jwcid="saveSomething@DirectLink" listener="listener:saveSomething" >Save Something</a>
      </p>
      </body>
      </html>





    • Finally, the page spec:



      <?xml version="1.0" encoding="UTF-8"?>
      <!DOCTYPE page-specification PUBLIC "-//Apache Software Foundation//Tapestry Specification 4.0//EN"
      "http://jakarta.apache.org/tapestry/dtd/Tapestry_4_0.dtd">
      <page-specification class="com.troymaxventures.grapestry.pages.Home" >
      <!--property name="counter" persist="true" /-->
      </page-specification>








  5. Add a tapestryapplication.application application specification file to the web-app/WEB-INF folder, here's what it looks like for me:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE application PUBLIC "-//Apache Software Foundation//Tapestry Specification 4.0//EN"
    "http://jakarta.apache.org/tapestry/dtd/Tapestry_4_0.dtd">
    <application name="tapestryapplication">
    <meta key="org.apache.tapestry.page-class-packages" value="com.troymaxventures.grapestry.pages"/>
    </application>





  6. OK, so far so good, this is all the right stuff we need to get it up and running. I was initially not looking forward to the magic that I'd have to do in order to get Tapestry work with the Groovy classloaders (as the Groovestry project (that might be dead) seems to do). Fortunately, Grails takes care of all that by compiling the Groovy classes into Good-Old-Java .class files, and so Tapestry doesn't have to know that the page is done in Groovy. Beautiful, isn't it ?

    I'm just going to wave my hands at this a little bit and just say that temporarily, we'll place the Home.java class in the com.troymaxventures.grapestry.pages package (and also mentioned in a tapestryapplication.application application config file). We'll also drop the Home.page specification, and the Home.html template into the $GRAPESTRY_HOME/web-app/WEB-INF directory. I know, that doesn't sound particularly fitting to the Grails philosophy of putting pages in the grails-app/views and controllers in grails-app/controllers , but there will be more on that in another blog post.



  7. Finally, do 'grails run-app' on the command line to get the app running, and go to http://localhost:8080/grapestry/app . That should pop a window that looks like this:


    Beauty divine !!! The standard Tapestry app should work, you should be able to click on some links, and see the persistent counter being updated.


Saturday, August 04, 2007

Groovy + Jemmy GUI automation

This is something that I came up at work, I thought other people outside of work could make use of it as well. If you're wondering about the obscure references to BizApp and such, this is because I removed the name of the actual app from the text.

OK, so we established that Groovy rocks. Now, I've worked at the company long enough to know that there exists a GUI application that kinda does what I need. I know it works, since I can build the GUI app, run it, push the buttons on it, and it creates all the outputs that I need. Now, the only problem is that I'd like to generate a decent amount of these outputs so that I can have a realistic testing scenario.

Now, I'm certain that there is a "cleaner" and "more proper" way of creating these test outputs. However, my colleague who wrote the BizApp app already figured out how to accomplish what the application needs to do (including all the nitty gritty technical details). Would it be nice if I had access to a simple action that does that ? Certainly. Do I have it now ? Nope. When do I need the outputs to test my client app ? YESTERDAY !! So, what should I do ???

Enter the combination of Groovy and Jemmy. We know what Groovy is, now what is Jemmy??? From their site, it's a library that allows GUI driven testing. In effect, it allows me to programmatically specify the actions that I need on the GUI, and execute them. Great !! Step 1 compete !

Now, step 2. Jemmy is a Java library, I don't quite know exactly how to use the API, and I don't quite know the exact sequence of actions that I'll need to perform through Jemmy. So, if I had to write a Java app to exercise BizApp through Jemmy, there'll be a lot of trial and error hindered by compilation. So, what should I do ?? Groovy is an excellent way to explore a particular API, but how can I plug in Groovy and Jemmy together in order to get this job done ?

Alright, alright, enough of the round-about way of explaining things, here is what to do:

* Setup a NetBeans Groovy scripting project. For that, you need a recent NetBeans setup, with the Coyote plugin installed. The same can certainly be achieved with an Groovy Eclipse plugin as well, but since I don't dig Eclipse, I'll show it in NetBeans. After Coyote is installed, you just set up a new project


* Add the BizApp dependencies in the project. In my case, they're in d:JDevelopBuildsBizApp Add all jars from that directory into the project build. Notice the Jemmy libary at the bottom of the screenshot : it can be added either using the NetBeans update center, or by just downloading the Jemmy library and adding the jar as a dependency in the project.



* Add the Groovy/Jemmy bootstrap script and add the content below, inserting the correct main class for the application. This script will launch BizApp, and will then fire up a blank Groovy console where we can execute our little script in. Right click on the Coyote project, and select "Run Project".


import org.netbeans.jemmy.*;
import org.netbeans.jemmy.explorer.*;
import org.netbeans.jemmy.operators.*;

// Fire up the BizApp Application
new ClassReference("com.mycompany.MyAppMainClass").startApplication();

// Get a reference to the BizApp JFrame and put it into the console's script binding.
mainFrame = new JFrameOperator("BizApp");
def bind = new Binding()
bind.setProperty("testScript",this)
bind.setProperty("mainFrame",mainFrame)


// Fire up the Groovy console.
def console = new groovy.ui.Console(this.class.classLoader,bind)
console.run()
Thread.sleep(600000)


* Now, we have both BizApp and the Groovy Console running side by side. Inside of the Groovy console, we can use Jemmy to programmatically manipulate the GUI (e.g. press buttons, select from checkboxes, etc). The Jemmy statements would look something like the script below. You can sometimes get away without firing a new thread, but if you don't the Groovy console script might block the UI and prevent Jemmy from executing it's input on BizApp


t = new Thread() {
// do whatever you need to do with Jemmy, push buttons, select combos, type into text fields, etc.
}
t.start()




* Finally, figure out what you need to do with the GUI app you're working with and script it. Pseudocode looks like this:


select from merchant dropdown
select from vendor dropdown
hit the "Process" button
hit the "Back" button twice (to get to the main screen)


* The Groovy setup script looks something like the one below. I usually execute this first, so that my Groovy console has references to the combos and buttons so that I don't have to import the Jemmy classes every time (e.g. the Groovy console doesn't remember the imports that you might have done in previous executions, but it will remember the variables that you might have declared


// Import Jemmy specific classes
import org.netbeans.jemmy.*;
import org.netbeans.jemmy.explorer.*;
import org.netbeans.jemmy.operators.*;

// Get references to all UI widgets so that we don't have to re-import
// the Jemmy classes every time. The names of these variables will be
// stored in the "binding" and can be accessed in subsequent script/snippet
// executions
merchantOp = new JComboBoxOperator(mainFrame,0)
vendorOp = new JComboBoxOperator(mainFrame,1)
processButtonOp = new JButtonOperator(mainFrame,"Process")
backButtonOp = new JButtonOperator(mainFrame,"Back")


* Write put the script that will actually do the work. The script is typically derived by executing the statements one by one and seeing that they do the right things. The script below processes an order for the first merchant and vendor and then comes back. See the Jemmy API for details on available widgets operators, etc.


t = new Thread() {
merchantOp.selectItem(0)
vendorOp.selectItem(0)
processOpButton.push()
backButtonOp.push()
backButtonOp.push()
}
t.start()


* Finally, the last step is to typically put something together that will do what you need repetitively. My script is below, I have it saved in the Coyote project directory, and I load it up from the Groovy console when it fires up. Note that I typically just hightlight and run the first part of the code first (to get references to all the buttons, etc), and then only run the second part when I need to run BizApp for a long time.


// Import Jemmy specific classes
import org.netbeans.jemmy.*;
import org.netbeans.jemmy.explorer.*;
import org.netbeans.jemmy.operators.*;

// Get references to all UI widgets so that we don't have to re-import
// the Jemmy classes every time. The names of these variables will be
// stored in the "binding" and can be accessed in subsequent script/snippet
// executions
merchantOp = new JComboBoxOperator(mainFrame,0)
vendorOp = new JComboBoxOperator(mainFrame,1)
processButtonOp = new JButtonOperator(mainFrame,"Process")
backButtonOp = new JButtonOperator(mainFrame,"Back")




// Creating orders for a merchant involves creating orders for each vendor for the merchant.
def processMerchantVendor(count,merchants) {
t = new Thread() {
count.times {
try {
merchants.each { merchantIndex ->
merchantOp.selectItem(merchantIndex)
if (merchantOp.selectedItem == "some_merchant") return
(0..vendorOp.itemCount).each { vendorIndex ->
if (merchantOp.itemCount > merchantIndex && vendorOp.itemCount > vendorIndex) {
Thread.sleep(50)
vendorOp.selectItem(vendorIndex)
Thread.sleep(50)
processButtonOp.push()
Thread.sleep(50)
backButtonOp.push()
Thread.sleep(50)
backButtonOp.push()
}
}
}
} catch (Exception e) { }
}
}
t.start()
}

// This creates test orders for all merchants, 10 times in a row.
processMerchantVendor(10,(1..merchantOp.itemCount))