There Can Be Only One

Starting in Maven?

2011-12-16T17:31:00.000+13:00

It surprises me again and again when I meet developers who are using Maven and they don't have a local repository. For anyone using Maven, once the decision has been made to actually use it, the next thing you do is get a local Maven repository. Really, its at the top of my list for things to do.

If you are working on projects at home, open source or not, at work with a single developer, whatever, you should install a Repository Manager. If you have more than one developer using Maven, you are simply insane not to use a one. So why would you install a repository manager even if you are only a single developer? Surely its hard?

Well, no, it is incredibly simple, Sonatype's Nexus takes 10 minutes to set up for example. Here are a few if you don't already have one:

Sonatype's Nexus - this comes in a Pro and Free version. I use Free in three different places and it has served me very well.
Apache Archiva - I used this in my last job, and I didn't like it as much as I like Nexus. It seemed a little more complex to set up.
JFrog's Artifactory - I haven't used this, but they do a lot with the Gradle community and are going to do some work around Grails plugins.

So back to why? A few reasons

Unfortunately, not everything is in Maven Central. This means you have to edit your settings.xml to add each repo in as you need it. Don't, put them in your Repository Manager and just point to it - let it sort them out. Add a new repo? Just add it in the Repository Manager.
If you are doing Maven releases properly, you are using version ranges. Version ranges cause Maven to scan all repos in your settings.xml for updates on a regular basis - and you don't want this traffic going far if you can help it, it slows you right down.
If you don't have a Repository Manager, you are either (a) not releasing you artifact (a cardinal sin) or (b) only releasing to central (which is feasible for some projects, e.g. easyb).
It allows you to blow away your local repository when it gets untidy from snapshot builds which people use periodically. Note if you do everything using snapshot builds, you are using Maven in a broken fashion.
You can put a Repository Manager on your own machine as a proxy as well, if you want to keep as much network traffic local for example, but you have the main Repository Manager hosted elsewhere - on a slow VPN or in another country.

Releasing

I've known people working on projects who have never released - they just work with snapshots! Thats nuts! A release in maven is an individual artifact (your entire war would be one, as well as an individual api) - it is something that has been cleaned, started from scratch, compiled, verified, all tests run, tagged in the remote repository, checked out again to a different location and all that done again and then uploaded to your Repository Manager. You should be releasing very regularly. And be fine grained about your artifacts! As soon as you have done a significant lot of work, release it.

Version Ranges

Version ranges are important for two main areas of Maven usage.

You have chosen an open source project based on its functionality, license, code quality, whatever. But you choose a specific version. For example, in a recent project we chose SOLR - 3.3.0. Our use of the 3.3.0 means we use <version>[3.3.0]</version> as our version. This means I want 3.3.0 and nothing else. Not 3.3.1, not 3.3.5, not 3.4.0. Why is that important? SOLR when it released 3.4.0 caused the meta data in (Apache) Maven Central to get corrupted - this means the only version available was 3.4.0. If I had instead specified <version>3.3.0</version> - if Maven didn't have it locally, it would go pick up 3.4.0 and happily use it. If the corruption had caused only 2.3.0 to be available, Maven would have used that - it would have been a mess! Always specify exactly what ranges you are happy to include artifacts for - if stuff breaks, lodge JIRA tickets on Sonatype's JIRA, they are pretty quick about it and will be ensured actually using what you have chosen.
Generally projects decide on how they issue a new version number - some just use two (major.minor), where the major changes on a breaking api change, some use three levels. You should specify a range when you are happy so new releases turn up - and typically you will do this of your own artifacts. You start at version 1.1 (because thats how ranges work, don't start at 1.0 or 0.x, thats just nonsense) and keep releasing until you break. Release early and often. If someone then who is using your artifact says [1,2) or say [1.7,2) (if 1.7 is the start of your api having what they want) then they will just get new releases as they come out, ensuring they keep current. These kinds of version ranges make Maven use really nice and easy to use when it comes to dependencies (along with composites, another post).

Composites are just pom's that contain a collection of dependencies - we have composite-cxf, composite-spring, composite-jackson, composite-logging-api, composite-logging-api, etc. Composites keep your pom clean, they take out all of the stuff that isn't really specifically to do with your App, but the kind of App you are building. They become accepted building blocks - and they rev. like normal artifacts. Changing from Spring 2.5 to Spring 3.1? rev the major version of your pom - existing artifacts won't be broken, you can fix them as necessary. Composites can be great for public facing releases as well - if Wicket 1.6 was just a pom containing fine grained artifacts that were hard version ranged, then we they released bug fixes (early and often), you could override specific artifacts and bring in the new releases to get the ones you want.

And another cardinal sin - it happens, but rarely, do not put dependencies in parent poms. Except for the plugins which often need them (and try and use composites for them), but your parent poms should not have modules or dependencies defined. Put them in the composites.

(It sometimes happens when you are using projects that are so terribly broken you can't help it, but its rare)

Do yourself a favour, if you are using Maven, install a Repository Manager.

Initializing your Grails Services

2011-10-11T19:40:00.000+13:00

In one of my current Grails projects I need to do what I would normally use @PostConstruct for, but am unable to as usually GORM has not completed its additional methods by the time it comes to use them. So the general recommendation is to do it in the bootstrap - a technique I generally do not like as it means you cannot make it a best practice easily - just include a dependency and its always done.

Ideally I think I'll need to turn this into a plugin, but I hate source code plugins enough to just include the Bootstrap at the moment.

So this goes in your Grails conf, and its a slight modification of the one you find on Google - it checks the scope of the bean, singleton ones only are initialized.

import org.codehaus.groovy.grails.commons.GrailsClass
import org.codehaus.groovy.grails.commons.GrailsClassUtils

class BootStrap {
  def grailsApplication

  def init = { servletContext ->
    grailsApplication.serviceClasses.each { GrailsClass gClass ->

      String scope = GrailsClassUtils.getStaticPropertyValue(gClass.clazz, "scope")

      if (!scope || scope == "singleton") {
        def serviceBean = grailsApplication.mainContext.getBean(gClass.propertyName)

        if (serviceBean.metaClass.respondsTo(serviceBean, 'grailsInit')) {
          serviceBean.grailsInit()
        }
      }
    }
  }

  def destroy = {
  }
}

Grails and Maven - blue grails

2011-10-06T20:35:00.001+13:00

One of the things that has kept me away from Grails for a long time - even after spending a couple of years knee-deep in it has been the extremely poor support for a clean build and release.

The combination of Gant scripts and source-code plugin dependencies, the use of Ivy as a dependency manager, endless outstanding bugs and a tendency to just not understand why this was so important (I'm sure everyone had their list) led me to abandon using Grails or pushing Grails in any real way in my work life while working at Sky Television (NZ). I still used it in a side project, but not in any anger and long since left the developers discussion list.

As I prepared to take on a new job doing Grails development again, going back from an environment that focused on neat, tidy granular artifacts that were tested and released, wired cleanly with Spring and assembled with clarity and speed was something I didn't want to loose. I learnt a lot from the two guys I worked with in terms of the use of Spring, Maven and API design. I only hoped that Grails would be able to live up to it now it had moved on.

On jumping back into Grails I saw that essentially little had changed (even if it was about to with 2.0 and binary plugins). Application design still seemed to encourage big single projects where all controllers, domain objects, services and so forth were all in the one project, making it harder and harder to test, longer and longer to build and deploy. Knowledge of Spring by users was limited, consequences of Hibernate ignored, discipline around tagging and releasing artifacts almost non-existent. EDIT: I mean this in the context of the Grails community as a whole:

Spring encourages the use of interfaces. Grails encourages you to inject the service's actual class by its name (e.g. userService for com.bob.UserService) but by using a def you can mock it. Its Groovy, but its nasty.
Grail's finders ignore the consequences of the SQL generates and most developers appear to not look at the SQL Hibernate generates. Hibernate does a bad job with anything thats not basic, and createCriteria is a demon. Whether this is better or worse than any other usage of it I'm not sure.
Grails doesn't come with a "release" script - crazy in my opinion. The concept of clean, build, tag, checkout from tag in a different place, build is critical to knowing you have a reproducible clean build. Not having it is crazy and is an artifact of people who don't use Maven, or one of the many who use Maven who don't use properly.

So for the past few months I have been working with the University of Auckland and TEIQ to build a set of best practices around modular Grails development, using Maven in the sanest way possible (and it is sane, and nice, and clean). Sorting out the way we deal with the inevitable buggy plugins (including the Grails Maven Plugin), building composites that bundle together packages of artifacts that relate, standardising web services structures and looking always for opportunities to make things better and cleaner, faster and clearer, better tested and more robust. Its a great opportunity and I thank TEIQ and particularly the University for giving me the chance to make a difference. And great people - did I mention great people?

As part of this work, we are taking some of what we have learnt and pushing it out into open source - or probably more open documentation. To make the best use of what we have done, we really need to have the Grails plugins that we use available as Maven artifacts - and I can't see the Grails guys happy about us doing that. I'm going to document it here on my blog - to make sure I do it (document it that is) - I'd recommend taking what I write if it works for your team and putting it in your Wiki and augmenting it over time.

The first thing I'm putting out there which may be of some worth to people who come to Grails and consider using Maven is my set of scripts I use. Its growing - but it provides me with a great set of shortcuts to the commands I regularly use. Enjoy :-)

War against disinformation about Google

2010-12-29T18:18:00.001+13:00

Quyn Do posted an article entitled "War on the Google Giant: Engineers Defect, Then Rise Against". The incredible absurdity of this post so astounded me that when @gianouts re-tweeted @darrylgman's tweet that this post was actually *interesting* I was flabbergasted.

To begin with, this person didn't seem to realize, with all evidence to the contrary, that using the free Gmail with targeted adverts would in fact target adverts based on their email.

And then they make the assertion that "our information gets sold to advertisers". Really? Where can I buy the service? It targets your demographic, what you search for, what you are interested in and I buy those words - Google matches them up and serves ads based on them. Even the remotest amount of research would tell you this, so clearly not a clue here either.

And then Quyn talks about Disconnect - the tool for Google Chrome that blocks out cookies from various sites. Does Quyn not know that Disconnect was written to allow people to disconnect from Facebook peer sites? A little bit of searching (again) about Brian Kennish would have turned up Facebook Disconnect. It was so popular he left Google in a blaze of publicity and created Disconnect, a general purpose plugin for Chrome (when I last looked). Again, outstanding lack of insight or research on the topic.

And Adblock - adblock has existed for *eons*, it was a Firefox plugin for ever - this has *nothing whatsoever* to do with Google, what the hell is it even in the article for?

And finally about people leaving for Facebook - why, a completely different topic thrown in just so the heading vaguely matches? Seriously? People have been leaving for Facebook because they are willing to put something out and tweak it until it works, which is a different strategy than Google. They've had their pet projects cancelled and with their noses out of joint, have gone to Facebook. I'm sure there is more to it than that, people want a change of scenery, but what has it got to do with privacy at Google? Facebook if anything has a far, far worse track record than Google.

This post has to have been written by either (a) a person with an anti-Google agenda willing to bet people will be too stupid when reading it to realize what a appallingly badly written opinion piece it is or (b) someone who really is that stupid.

I'm betting on the first, there are a lot of anti-Googlers around at the moment.

For my own sanity

2010-09-23T08:30:00.001+12:00

Oracle XE and EC2/EBS instances was not a fun time. Oracle being at fault here.

So I needed an XE instance and rather than downloading and installing a VM specifically for this particular test, I figured an easier way would just be to choose an Ubuntu VM AMI image and set it up there.

So some things to remember:

Make sure you use a 32bit i386 AMI (or it won't install)
When it starts up, you won't have enough swap to install XE, so add more
Make sure bc is installed (sudo apt-get install bc)
Follow the instructions for installing Oracle XE here and here

So the last bit which is really the difficult thing to find is that the listeners will kill you. When Oracle XE installs, it hard codes the machine name somewhere. So if you shut down and start up again, you get it failing the listener.

So you need to go into $ORACLE_HOME/network/admin and edit tnsnames.ora AND listener.ora and change the hostname from ip-whatever to localhost. But that isn't enough - Oracle itself will still screw up as it registers with the original name as installed each time - so you won't be able to connect to the listener, even though diagnostics imply it worked. So you need to look into the log (which is in $ORACLE_HOME/network/log) and you'll see something like this:

22-SEP-2010 20:05:55 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=ip-10-203-55-158)(USER=oracle))(COMMAND=status)(ARGUMENTS=64)(SERVICE=LISTENER)(VERSION=169869568)) * status * 0

That HOST=ip-10-203-55-158 - thats the domain name originally registered against your machine. Take that name and edit /etc/hosts (sudo vi /etc/hosts) and add it into localhost's config:

127.0.0.1 localhost ip-10-203-55-158

Then restart your Oracle XE

sudo /etc/init.d/oracle-xe restart

By the way, I'm using a script to tunnel to the box (so Oracle is never exposed to the internet)

#!/bin/sh

ssh -i KEYNAME.pem -L 8080:localhost:8080 -L 1521:localhost:1521   ubuntu@$1

This shows up as

21-SEP-2010 10:05:20 * (CONNECT_DATA=(SID=XE)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))) * (ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=47502)) * establish * XE * 12505

TNS-12505: TNS:listener does not currently know of SID given in connect descriptor

failure when trying to use jdbc to connect using the typical url: jdbc:oracle:thin:@localhost:1521:XE when the IP address keeps changing.

(I added all that in for anyone using a search to find this page)

When tests go brown

2010-06-26T18:42:00.001+12:00

So I'm at Citcon 2010 in Wellington - and its after a morning session around BDD and Fit style testing that I'm writing this. People in the discussion use all sorts of frameworks - Cucumber, WebRat, Concordion and of course myself using easyb.

One of the interesting discussions I had last night was with Nigel Charman - part of the impetus behind the recent changes in easyb that I have done around turning it into a parse/run (instead of just run/evaluate). Nigel posited that they needed precondition checks - a third state basically that said that this test doesn't actually meet the qualifications required to run. Now you could just fail here - but that doesn't actually tell you anything, normally a failing test implies incorrect code, but in this case the code may be correct, but the data is wrong - so this mornings discussion further clarified that typically preconditions are around data being wrong or systems being unavailable. And knowing that separate from a failing test is a useful state.

As it turns out, the latest version of Junit (4.8.1) has an assume style clause [LINK] which supports the concept, but still only has the red/green colours. What I'm more interested in is reporting on it.

What does this have to do with easyb? Well, easyb also doesn't have this concept - and recently an issue was filed requesting shoulds be added to the given and when clauses (e.g. given "account is in arrears", { account = getAccount(1234); account.inArrears().shouldBe true }. I accepted the request but said it should be in a plugin as I don't think it fit with the use of should and the concept of a failure. Now I understand why I am unhappy about it being there, and particularly I understand the pain this person is actually having.

So perhaps its time to revisit this particular issue - should easyb support another state - perhaps "brown" whereby preconditions or assumptions about the state is not met. This should be reported on to allow for dealing with in another manner. I'll take it to the dev team and see what they think.

Goodbye, Java Posse

2010-06-15T17:45:00.001+12:00

So I can pretty much say I have listened to all the episodes of the Java Posse - I came in a bit late in the peace - around 150, but I went back and downloaded them all and they entertained and informed me. But now its time to stop - and I had a lot more to say (thats what a blog is for right?), but really, Joe - you have spoiled it so badly it is no longer listenable.

Dick, Carl and Tor, thanks for the good times. Good luck to you - I hope you keep enough of your loyal fans to keep it interesting for the next five.

Shaft me, I'm an iphone user

2010-06-10T20:08:00.001+12:00

Disclaimer: I believe the Cult of Apple has fractured, the Cult of Mac and the Cult of iPhone. There is an overlap, but many Cult of Mac people are deeply, deeply embarrassed by Steve Jobs.

So, why am I bothering posting this. I suppose its because I still can't believe that people can be so utterly stupid to consider using iPhones or even upgrading to that silicon turd, the iPhone 4. And I think I now understand what is behind the Jobs machine.

So, in his latest round of bizarre, Steve Jobs is banning pornography on the iPhone. Oh wait, no, he is "banning" pornography from iPhone Apps. Pornography will still be freely available from Safari, where most of the porn is anyway and so you can still see it on your iBone or iPad. Its not about his kids, even saying that is laughable. So its clearly not about pornography, per se - in reality, I don't think Steve has a problem even gonzo porn.

Consider common sense for a moment - there are a lot of other ways the iPhone team could prevent you from getting porn, parental locks on phones, categorizing iphone apps, getting Norton to get their fantastic (on Windows) Online Family product sorted out for Snow Leopard and available on iPhone/iPad among other things. But no. Its not about common sense. No, this faithful reader (yes, singular I'm sure is appropriate Mark) is not about porn, this along with all the other stuff (you can't show Ads on the phone if you also make a phone os, programming in Objective-C, and the list goes on) is simply about one thing.

iPhone/iPad users - Steve Jobs is using you for his personal pleasure in the most dubious way modern technology can provide him. Thats right, he knows he can make you bend over and shaft you again and again and you will take it and come back for more. You get drip fed features other phone vendors have had for years in hardware, and then other important liberties you simply wouldn't stand for having taken away from anyone anywhere else in software, and you take it. You beg for it. And Steve is clearly getting off on it, because you deserve it. He knows it, every person who things you are a fool knows you deserve it.

The only iPhone worth having is a jailbroken one. Those things are actually pretty good!

Thats all, I'm sure I'll post again even if I say I won't so I won't say I won't.

Maybe not the end of Scala

2010-02-14T21:01:00.001+13:00

A little more analysis needs to go into the last post. I perfectly understand there are people out there who like Scala - I don't understand it (why they like it), but they do and good for them. But I think the Scala world is split in two, those who are simply searching for a better Java that is statically typed, and those who actually think Scala itself is a sterling idea.

I think those who are looking for a better Java that is statically typed now have competition in their choices. A language very much like Java, interoperates almost perfectly with Java, can be eased into simply with Java and has a dynamic option if you want it, vs something that is really quite different. I just think Groovy++ will slow down Scala's adoption. People may examine both and decide Scala, I suppose that could happen.

Will Groovy++ spell the end of Scala?

2010-02-06T21:59:00.001+13:00

As much as we all "try to be friends", the successor to Java (and there clearly needs to be one) "battle" between Groovy, Scala and Clojure will IMHO, only heat up this year with the introduction of Groovy++. Groovy ++ adds to Groovy static typing with very little in terms of trade off (meta programming) - allowing mixing of static and dynamic code in the same application. Groovy++ apps are the same speed as Java - sometimes faster, sometimes slower depending on how the problem is expressed. IMHO, Groovy++ is really Java ++ and is thus a natural and easy path for the millions of Java programmers. Groovy not being controlled by the boffins at Snoracle hopefully means innovation in the platform can happen much faster and address real developer needs.

I personally don't see Clojure as a competitor for Groovy, Clojure seems to attract people interested in expressing primarily functional problems and can mix with other JVM languages easily. There is a place for it - I'm pretty sure it isn't everywhere (even though I am sure you can do everything in it) and it does my head in. I like Clojure, don't get me wrong, but I like it in the same way I like a regular trip to the dentist.

Scala on the other hand really decides to do things differently, and as I have said in the Illegal Argument podcast, I don't think its mixing of imperative and functional styles along with its weird, clearly academically experimental syntax will win out. Scala is an academic experiment built and designed by a very clever person. But... It is too different, it doesn't seamlessly interoperate with Java and it lends itself to unreadable code far too often. Clearly some people like it, but I can't for the life of me understand why they do. For me, it doesn't help that the primary Scala book written by Martin just reeks of language arrogance as well.

The argument i hear most often is "well, there isn't really a contender in Java.next for a statically typed language". Well, now there is - well almost - later in the year because of issues around open sourcing code.

Will Groovy++ spell the end of the use-case for Scala? Someone can take the Java spec and pretty much code in Java directly in Groovy++ - you can't do that in Scala. They can then be slowly introduced to type interference and all kinds of other programming concepts. Or they can take it the other way as a dynamic language and be introduced to the benefits of static typing. I certainly think it has a greater chance of supplanting Java than Scala does anyway.

iPhone delusions

2010-02-05T14:14:00.001+13:00

Its sad to see Josh Marinacchi go from Snoracle, especially for what reasons that I think of are simply fallacious.

If you haven't read it already, go read his Sun blog.

The argument I think he is making is that 90% of the people out there are essentially stupid and don't care about the restrictions iPhone/iPodTouch/iPodTouch300% (i.e. iPad) put on them. I don't see that demographic. I see the 10% of people who have iPhones as being that special kind of dementia known as Apple-fanboys/girls (you know who you are) or people who think this screen touchy thing is cool and Apple did a sufficiently better job than . That there are 100,000 Applications out there only helps because 80% of them are crap and all but the last 1% are games. Those same apps done with a decent phone platform (like Android, which may suffer from being too open in its App store) can really be quite awesome - as people with jailbroken iPhones attest.

Those who break their phones do so only because they know there is something better. And I think this is where the average iPhone user (not the fan-boys, we know thats an incurable disease) sits, once they know there is something better (and with the latest update for multi-touch in the US for the Nexus One, we know the hardware is better and the software is now at least as good) they will either (a) move when their term comes up to the new cool thing (and all the predictions show Android will be the Smart phone of choice, after RIM with iPhone a 3rd place with its dedicated... fanboy offering) or (b) Apple will now have to catch up.

Yes, I said catch-up. Apple is now behind, those things that Josh says apparently don't matter - replaceable batteries, better hardware, multi-tasking software are all very much visible to the "stupid" people and they make a difference. Everyone else is behind in "cool" but Apple always does cool better. I'm not sure what the iPad is, I'm sure it will sell but I'm not sure I'll have any respect for anyone who actually buys one.

Apple could change a lot of its restrictions - there is nothing inherint in the platform I believe that would stop it from competing with Android. The one thing that Apple really has under its belt is iTunes - the music library is available to people all over the world, not just the US like Amazon's one is. Get that sorted out Amazon.

I buy Mac OS for one reason - I want a good UI (which Windows 7 has IMHO) and a good underlying UNIX style OS (Windows doesn't have). Don't talk to me about Linux - that will never be a desktop OS for anyone other than the truly marginalized.

So if I can conclude - my essential reason why I believe Josh is wrong is simply that the only open phone platform from the ground up, Android is the only one really causing the iPhone serious dents and causing Steve Jobs to get his knickers in a twist. Apple is now behind in software and hardware innovation and with so many phone vendors getting on board, providing access to so many niche markets to address every different kind of phone user, an open and open source platform simply cannot be defeated. IMHO of course. Apple is just digging itself into a worse and worse hole, and the iPad is just a crowning example of the lack of innovation in the last 12 months.

Its just a pity Josh jumped from one dying company to another. I have enjoyed what you have done for JavaFX, I just hope you can make a difference to Palm.

Open JDK has a lot to answer for

2009-09-29T09:55:00.001+13:00

I have never been so disgusted with a podcast as when listening to the excuses coming from Alex and Joe in Episode 279 of the Java Posse Podcast. If there was ever a clear message from Sun that the value of Java code written and maintained in the future is less than the value of Java code today, this was it.

Alex and Joe seem to believe that since the Open JDK now exists, Sun can sit back and pick and choose from implementations that other people do instead of investing in its flagship product (the one its stock ticker is named after, how ironic). Not only this, but they seem to believe that they can do so and be completely fickle about it. Dick's comment about the JCP I think is superfluous, there is no JCP process for JDK 7 so they are putting it in what they will.

Whether Alex/Joe's opinion are a reflection of Sun's official policy I don't know, but I hope that on purchase Oracle dump this attitude (and anyone who holds it) and puts new life into the language. This complacency is simply not acceptable, you innovate or you become irrelevant. I know that the team have to solve modularity in JDK 7 and that it is a big problem to solve, but the messages that Alex and Joe are sending are completely wrong and they deserve a severe caning from PR. The implication is that while Sun spends its resources on JavaFX, its core language, Java languishes. Borland did this with Delphi and JBuilder and look where it got them! (Borland is now owned by a COBOL company, MicroFocus, Delphi is now owned by a database company, Embarcadero - oooooh now *that* is spooky).

IMHO Scala is clearly an academic dumping ground of ideas and the static camp are using it because they have nothing else to express their needs in. And please don't mention JavaFX. Sun clearly needs new and strong leadership in this team to bring Java forward.

After 24 hours I am no longer angry, just extremely disappointed that this situation has been allowed to develop. If ever there was a reason to fork the open jdk, this is it. Larry, its up to you now.

mor.ph and deployment fun

2009-05-11T21:19:00.001+12:00

So I use http://mor.ph for deployment of my Grails applications. The development account was great, fantastic to deploy to and try out your application. I didn't realize this transformed (database and all) into your deployed site otherwise I would have held it in dev mode until the customer had set up all their data, but then I wouldn't have discovered some other problems... Like that since you get two app servers, and it load balances, it serializes session state (how often, I don't know). But as I use the Acegi plugin for Grails, it generally (definately in my case) creates a User object - which isn't serialized..... Which means I have been getting persistence errors all through my logs.

Of course, I thought I had solved it with just User and Role, but I forgot I embedded an Address in there as well, and it would need the treatment. Wouldn't it be great if these sites gave you a bundle you could run in a VM on your own machine to mimic their deployment so you could fix your issues before you swap from single server, single db to the full cluster of mor.ph? Oh well, it is a great service in any case!

groovy tip #3534

2009-05-10T20:14:00.002+12:00

Don't do integer arithmetic in gstrings.


int time = 1730
println "${time/100}"

I know Mars Edit is going to screw up that code block. Anyway, although time is an int, it gets converted to a BigDecimal in the gstring, and you get a 17.3 instead of the expected 17.

And last but not least, our first Illegal Argument podcast has gone out. It hasn't shown up on iTunes yet, hopefully that will be soon.

Site Mesh and pageProperty in Grails

2009-05-10T12:31:00.003+12:00

So Grails 1.1 comes with SiteMesh 2.4 and uses the FastPageParser. If you go have a look in your web-app/WEB-INF/sitemesh.xml file you will see the following:


<sitemesh>
    <page-parsers>
        <parser content-type="text/html" class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
        <parser content-type="text/html;charset=ISO-8859-1"             class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
        <parser content-type="text/html;charset=UTF-8"            class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
        </page-parsers>
    <decorator-mappers>
        <mapper class="org.codehaus.groovy.grails.web.sitemesh.GrailsLayoutDecoratorMapper" />
    </decorator-mappers>
</sitemesh>

How many of you Grails developers have ever had to look in there? Cool isn't it that Grails shields you from this stuff - one of the many, many reasons why I love this framework.

Unfortunately, FastPageParser is actually deprecated and has bugs when using the <content tag="x"> constructs - HTML comments are output as raw text and <script> tags loose their <. Migrating to Site Mesh 2.4.1 (or .2 now with the GAE) fixes the <script> problem, but not the HTML problem.The partial solution (as emailed to me by one James) is to replace it with the HTTPPageParser - this is faster (by about twice) and is the recommended replacement for FastPageParser.

The only problem is that it has an outstanding bug - if you include an "<" anywhere in an HTML element (e.g. in the value) then the rendering goes haywire. It is a known fault in Site Mesh but no-one bothered to create a test case for Joe or investigate precisely where the problem is. Content tags are pretty important to anyone laying out their content in any kind of sophisticated manner (as is extractProperty, which isn't actually surfaced in Grails for some weird reason), so I gave Joe the test case and narrowed it down to the Lex rules. Unfortunately, I am not a Lex guru, so I had to leave it there.

I'll be putting up a screen cast of this stuff at some point in the near future. I'll link when its available.

More on Grails Mail

2009-04-12T21:55:00.001+12:00

Actually testing the grails mail plugin and having it sending email and then decoding the results were a little more difficult that expected. dumpster 1.6 (last updated in 2005) was buggy for MIME messages - it didn't obey the ordering of the message headers or keep the line feeds in emails.

Then it was finding a way to decode the message so I could spelunk through it and ensure it matched what was required. I'm almost finished now - the attachments file files and byte arrays work, but the InputStream is giving me a Bad file descriptor which I think might be related to trying to read the stream multiple times, but it happens in native code so I'm not sure.

I also have to check how to check JNDI data sources and then I thought I would check the JIRAs for other issues.

A sample method looks like this:

  void testSendMailViewWithTags() {
    def mailService = new MailService ()
    mailService.mailSender = mailSender

    def ctx = RequestContextHolder.currentRequestAttributes ().servletContext
    def applicationContext = ctx[GrailsApplicationAttributes.APPLICATION_CONTEXT]

    mailService.groovyPagesTemplateEngine = applicationContext.getBean (GroovyPagesTemplateEngine.BEAN_ID)

    mailService.sendMail {
      to "fred@g2one.com"
      subject "Hello John"
      body (view: '/_testemails/tagtest', model: [condition: true])
    }

    assertEquals 1, server.receivedEmailSize

    MimeMessage m = new MimeMessage ((Session) null, new StringBufferInputStream (server.receivedEmails[0].toString ()))

    MimeMultipart content = m.content
    assertEquals 1, content.count
    assertEquals 1, content.getBodyPart(0).getContent().getCount() // only 1, it should be text
    assertEquals "text/plain", content.getBodyPart(0).getContent().getBodyPart(0).getContentType().split(";")[0]
    assertEquals "Condition is true", content.getBodyPart(0).getContent().getBodyPart(0).getContent().trim()

    mailService.sendMail {
      to "fred@g2one.com"
      subject "Hello John"
      body (view: '/_testemails/tagtest', model: [condition: false])
    }

    assertEquals 2, server.receivedEmailSize

    m = new MimeMessage ((Session) null, new StringBufferInputStream (server.receivedEmails[1].toString ()))

    content = m.content
    assertEquals 1, content.count
    assertEquals 1, content.getBodyPart(0).getContent().getCount() // only 1, it should be text
    assertEquals "text/plain", content.getBodyPart(0).getContent().getBodyPart(0).getContentType().split(";")[0]
    assertEquals "", content.getBodyPart(0).getContent().getBodyPart(0).getContent().trim()
  }

Changing the new grails-mail

2009-04-11T21:19:00.001+12:00

So now that I have set up repositories on github and forked them, I am moving my changes into github for others to use. To ensure they are robust though, they need to have testing - and that is usually pretty difficult for SMTP based email servers - but I have come across a library called dumbster that is designed specifically for unit testing of such facilities!

I'll be creating tests for all of my own functionality as well as migrating the tests for Marc and Greame's tests and start to knock off all the defects that are in the repo for the plugin.

I have a post coming up that has detailed the method that I use for using the pageProperty tag in Grails, but I can't get MarsEdit to change my < symbols for me so I can paste XML/HTML into this document. It is extremely annoying! I might write a Griffon app just to try it out.

2009-04-10T17:57:00.002+12:00

I have just been updating the Groovy that comes with Grails 1.1 to Groovy 1.6.1 - and found out that there is a whole heap of Swing and Ant stuff in the file. Given this gets uploaded with your war file, this seems pretty silly. I am sure the Ant stuff gets used in Grails with Gant, but Swing?

There must be a way of getting a swingless Groovy. Useful for Griffon, but clearly not for Grails.

Grails many-to-many

2009-02-27T15:24:00.002+13:00

I am sure others have come across this and figured out, but just in case Google (TM) wishes to index it, I had the problem trying to figure out how to remove an item from the many part of one side of a many to many collection.

Here it basically was:

DanceStyle
static hasMany = [danceLevels:DanceLevel]
static belongsTo = DanceStyle

DanceLevel
static hasMany = [danceStyles:DanceStyle]

So the key here is that you can only remove/delete from the side noted in the belongsTo - you cannot take a dance style and remove a specific dance level from it, you have to find the dance styles on the dance level and remove the style - otherwise Hibernate (although it recognizes the dirty collection) does not do anything about it. No matter how you stuff about the cascade maping.

Grails plugins

2009-02-20T14:37:00.003+13:00

So I am working on a replacement website for a customer using Grails and I am using 7 plugins: acegi, easybtest, code-coverage, fck-editor, mail, morph-deploy and navigation. This is cool, the plugins are generally very good, but the only ones I have not had any problems with are easybtest, code-coverage and fck-editor. Why?

mail - mail has problems in that it isn't suitable for morph (mor.ph), it also has no support for attachements, has code that isn't reliable (when setting to/cc/bcc) and various other problems. I notice there is a mail-0.6-SNAPSHOT which adds support for headers - done by Peter Ledbrook, which has not yet seen the light of day.
acegi - when something goes wrong here, it is almost impossible to figure out what - there is little or no logging. This is really irritating. Other than that, it is an absolutely wonderful plugin that is mature and comprehensive and growing with the capabilities of the Internet (eg. Facebook and openId integration)
morph-deploy - this is an early work given the increasing popularity of morph amongst grails devotees, but it is missing the removal of the mail archive (which is understandable as you don't need to do it unless you have the mail plugin!). It is a pity it can't recognize plugins and remove their dependencies if morph doesn't want them
navigation - shipped this has blocking faults with requiring logging and occasionally loading before logging is loaded (which is now fixed by Marc Palmer in the latest snapshot) and also that when you have multiple navigation elements in a single controller it blows chunks (null pointers - which is as yet unfixed in the HEAD).

What does this mean for me? Well, I am using grails 1.1 (beta 3) now, and plugins are no longer included in the source tree (which is sensible, it is a good change), but it leads to a big pain in the backside problem - to use these plugins I have to fix them. To fix them - they are not in the local project, and managing them in a source code development environment when you have more than one developer and you need to share fixes is now problematic.

I'm going to need to figure out how to sort this out - and I've bitten the bullet and decided to join grails plugin dev to see if I can make a difference.

2008-11-22T16:46:00.002+13:00

Delphi 2009, Delphi Prism, InterBase 2009 and Delphi for PHP 2.0 seminars this week! Busy busy.

Grails 1.0.3 and BEA/Oracle Weblogic 10

2008-09-09T08:42:00.002+12:00

So I am working on a project that is using Oracle/BEA Weblogic 10 and we have been having really big problems trying to get a Grails 1.0.3 application deployed successfully on it.

It uses Apache CXF as its web services layer as well, which makes it even more tedious. So the lessons we learnt?

Weblogic hates non-serialable objects in its web Session object

Grails domain objects when they have constraint violations store themselves into the web Session and this creates problems for Weblogic as the objects are (a) not serializable by default, (b) any closures in them are not transient by default (e.g beforeInsert closures) and (c) links to Services often cause problems. We didn't have (c) (it is logged in the GRAILS bug parade).


class Order implements java.io.Serializable {
 def transient beforeInsert = {
   // do thing
 }
}

All objects referenced by your class also need to be tagged thus as well.

Weblogic has to be told to tow the line for classes

<weblogic-web-app>

  <context-root>/wls_app</context-root>
 <container-descriptor>
   <prefer-web-inf-classes>true</prefer-web-inf-classes>
 </container-descriptor>
 <charset-params>
   <input-charset>
     <resource-path>/*</resource-path>
     <java-charset-name>UTF-8</java-charset-name>
   </input-charset>
 </charset-params>
</weblogic-web-app>

We didn't end up having to deploy it as a EAR file.

CXF just wouldn't work unless....

We are using the web security handler and that creates a SAAJInInterceptor. That SAAJInInterceptor would always pick up weblogic one, and so we had to get the source code to both the WSS4JInInterceptor and the SAAJInInterceptor and force system properties to make them use the CXF implementations. Thank goodness for open source!

Weblogic 10 has a bug in its handling of the Content-Type field

The requirement under RFC 1521 is that Content-Type should look like:


Content-Type: type/type; param=value; param-value; etc

Under Weblogic, once charset= is found, it uses the entire rest of the line to attempt to set the charset! Under normal SOAP usage, this will also include the SOAP's action so the char set was (in our case) something like UTF-8;action="/blah/blah/blah" - which of course wasn't being handled properly.

So thats it. I think.

Conferences, Conferences

2008-08-16T20:38:00.001+12:00

So I have been trying to help organise our (Developers Inc Ltd's) participation in a couple of conferences in the last little while, but I really am simply not an organisation kind of person.

Developers Inc Ltd are going to be at two conferences coming up - TechEd 2008 (Microsoft's big love-in for developers and those unfortunate souls who we call "operations"). If I spent much of my development life looking down at Microsoft developers (whether warranted or not), I surely am a snob when it comes to operations staff (even though I know some very clever ones). Anyway, back to TechEd - we have a booth, and will be giving out Coke and developer stuff that relates to what we sell in the Microsoft space (Microsoft, CodeGear, Capable Objects and JetBrains).

The next event coming up after that is September 17th - the Java Emerging Technologies Conference, which is going to be less of a conference than a group of people who have lots of Java related tech to talk about getting together in one place and gabbing. I have had difficulty getting speakers (the speakers/sponsors is the chicken egg situation - we can get international speakers, but we have to have the money, can't get the money unless we have a decent number of attendees who would be attracted by speakers). So now I will possibly be speaking a number of times.

And in October there should be the Delphi 2009 launches, so that along with my work with TEIQ should keep me busy!