mod_pagespeed

There is a new mod from Google for Apache servers called mod_pagespeed that removes redundant HTML before sending it to the client.  Very neat idea.  Makes me shed a tear I am wanting to move our legacy php into a Glassfish appserver so I cant take advantage of this, but still would be useful in future.

Optimization Made Easy with mod_pagespeed.

A Grails rant.

I agree with most of the points on this blog: Why Grails Sucks Less Than Your Framework.

Except #1. “It works on your current environment.” based on what I’ve been trying to during the last couple of weeks.

Firstly, the point isnt wrong for the conventional cases (which is what Grails is great for looking out for).  I’ve worked with Grails apps in the past that integrate with existing apps. I’ve always been able to deploy them as wars to Glassfish using a shared Jndi datasource. However for integration we have generally kept a thin layer (one or two database tables) kept between each app for them to share data.

This week I’m taking that integration further. I’ve been trying to get an integration happening between Grails and our legacy app which has recently been given some JEE love (session beans for services and JPA annotations over the legacy domain classes, deployed in a Glassfish container).  I want my Grails app to be a consumer of those EJB services, which return these legacy domain classes.

You’d think this would be easy, these problems have been addressed and covered in tutorials, blogs and presentations on the web:

  • Having a container managed datasource with your Grails app having access to that is aok.
  • Having existing hibernate mappings and legacy Java domain objects, also solved.
  • I was also able to talk to local, remote and no-interface session beans deployed in the same Glassfish domain just using the initial context that is supplied by using an empty JndiTemplate and Springs JndiObjectFactoryBean.  Works a charm.

You’d think with all these things I’d be set.  I thought I was too.  But like any app using a new platform/framework, the developers go off and develop and the deployers (or the developers later wearing the deployer hats) have to deal with the implementation issues when it comes to deploy the production release many months later.  Thankfully as I was trying to build a proof of concept I came across these issues early, but I can imagine it would be a hard task for any deployer to try and get this to work.  I suppose thats why many large shops with separate systems teams ask for their Grails apps to be packaged as EARs instead of WARS to avoid any other surprises.  Insurance via forced isolation perhaps.

Whilst I can get the war to generate and deploy successfully, once deployed, I’m still having issues finding the legacy domain classes in the classpath.  One problem is that the domain objects have different versions of the libraries (hibernate, logging, spring etc) that are also used in Grails.  And so you end up with NoSuchMethod or ClassNotFound exceptions.  Jar hell clashes between the large Grails jars library base.  I know that with a bit more time and knowledge I could change our legacy domain class dependencies and our grails libs so that they match and then unit test everything so that it still works, but I just dont have the time.  Whilst this is not a problem with Grails per se, the amount of time spent resolving this erodes the promised productivity gains gotten from using Grails in the first place.

Also to keep things flowing, what I’d really like to do is put the war within an EAR file so that I can access the EJBs in the container and share the same classpath so I can get to all those legacy domain objects and their dependent classes that they require.  Again I run into the above Jar hell.    Additionally getting the web app to work has led to some interesting errors with Spring Web Application Context which look like Jar hell style error messages, but dont appear to have duplicate jars in the CP.

The other issue about trying to deploy a Grails war into an EAR is tooling support.  As an Eclipse shop, the tooling for our EAR with the Glassfish/JWT plugins only supports generating an EAR project that is assembled from other Eclipse projects with JEE facets attached to them.  Of course, the Grails project itself isn’t in the form that a Dynamic Web Facet requires.  To get around this, I built the war using grails war, then extracted the war into a new project called webapp_exploded that I setup as a standard Eclipse Dynamic Web Project, which I can then tell Eclipse to bake into the Ear project.  Its a lot of hoops but gives my the META-INF/applications.xml that I want and appears to have the correct classpaths generated.  (Side note: I think IntelliJ has better support for building such artifacts and it can fire off maven/ant scripts pre-and-post execution in order to get this to work in a nicer fashion but as 2/3 of our dev team prefer Eclipse over Idea, I have to get this working for them).  (And I’m still a Maven n00b).

Once I tried to deploy this though, I got exceptions about the Spring Web App context.  I’m not sure if this is because of my Eclipse hack above or some unfortunate Grails bug because not many people are trying to deploy Grails apps in this way.

I also found that the Grails plugin for Glassfish is old.  It only supported Grail 1.0 initially with embedded GF and shared-war command to reduce the size of wars.  But the grails 1.1 release of the plugin advises in its readme that those features aren’t currently working.  To add insult to injury, WinMerge tells me the glassfish/grails(1.1.2) is exactly the same as the Grails 1.1.2 you’d get from Codehaus.  This defeats the whole purpose of having a plugin in the first place.

That said, I’m still in love with Grails, but think I have to take some smaller bites before I tackle this one again (though just typing out this blog has given me a few more ideas of how to address the problem).  Also to be fair, I haven’t sought help through any of the Grails community lists due to time pressures.

If you are starting from scratch, or even if you have a domain object layer that you can bring in without worrying to much about the dependency tree and you are happy to deploy as a separate war, then of course, Grails is great.  I am sure if I had more time I would get it to work – try maven or IntelliJ to build the WAR – figure out why the Spring container’s ConfigurableWebApplicationContext.setId(String) cant be found when trying to deploy the app.

Rick Wagner’s Blog: How to find which .jar a class is in (easily)

Holy heck, I needed this earlier today

Rick Wagner’s Blog: How to find which .jar a class is in (easily).

Makes mention of JBoss’ tattletale utility.

The comments also mention the Java Class Finder plugin for Eclipse (I used the CTRL+SHIFT+T today personally which did the same job)

There is also LibraryFinder plugin for IntelliJ and classjarsearch command line tool to search a directory of Jars for a class.

Glassfish V3.0.1 and Update Tool

When installing plugins for glassfish at work I would receive a Premature EOF just after accepting the license terms for the plugin. This would occur regardless of method used, updatetool cli, gui or web.
Strangely it worked at home, but for me and my colleagues at work, we couldnt get through. I suspect some network issue on our end but didnt need to delve too deep as I found a workaround.

The simple thing to do is to install the latest version of the pkg command. I used pkg-2.3.2 from updatecenter (http://wikis.sun.com/display/IpsBestPractices/Downloads) site.

After extracting the archive, I ran this at a command prompt (in its bin directory)
C:DevEnvpkg-2.3.2bin>pkg install updatetool

The download is strangely very slow and it timed out about three times before I could install update tool. Thankfully running the same command again resumes from where it left off.

C:DevEnvpkg-2.3.2bin>pkg install updatetool
DOWNLOAD PKGS FILES XFER (MB)
wxpython2.8-minimal 1/2 915/929 7.5/7.9

Errors were encountered while attempting to retrieve package or file data for
the requested operation.
Details follow:

1: Framework error: code: 18 reason: transfer closed with 2028 bytes remaining t
o read
URL: ‘http://pkg.sun.com/layered/collection/dev’. (happened 4 times)
2: Framework error: code: 18 reason: transfer closed with 1901 bytes remaining t
o read
URL: ‘http://pkg.sun.com/layered/collection/dev’. (happened 4 times)

C:DevEnvpkg-2.3.2bin>pkg install updatetool
DOWNLOAD PKGS FILES XFER (MB)
Completed 2/2 929/929 7.9/7.9

PHASE ACTIONS
Install Phase 1092/1092
PHASE ITEMS
Reading Existing Index 8/8
Indexing Packages 2/2

You then can simply run updatetool from the command prompt to kick off the GUI app. Downloading plugins via here was slow and timed out also, but it found my local Glassfish install and worked to install plugins to it as I needed.

Java EE, Spring, and why I care

Finally a post that seems to be sticking up for the Spring framework. (nice change)

Java EE, Spring, and why I care « techscouting through the news.

Sure EJB 3.1 does make things easier, but it has taken a lot of time to catchup to where Spring was.  And as the blogger points out, as new versions of the technologies that JEE use like JPA come out, how long will it take for JEE to implement these.

Also, one thing that does bother me with all the ‘my JEE is better than your Spring’ articles is, and the blogger alludes to here, is that they compare annotations in EJB to Springs old XML config which just like EJB is seldom needed these days.  This is a little unfair.

As for myself, I’m technology agnositic, but easily develop biases based on the path of least resistance factoring in long sightedness too.  Like many, if a tool does what I want and is scalable, I’m going to use it.  I think both approaches are fine but they aren’t necessarily compatible.  Unfortunately we aren’t unified yet although the standards are in place to get it to work (eg Spring components <-> JEE components).  Getting a Grails app to talk locally to EJB components hasn’t been easy as I learnt last week primarily due to having the app log to the right place in a container its not used to, and thats just at the container level, but thats another post.

Deploying grails 1.3.x war to glassfish

This was a recent bug bear which may be a regression from 1.2.x line

When you deploy to Glassfish you get an error message

An error has occurred
There is no installed container capable of handling this application com.sun.enterprise.deploy.shared.FileArchive@1e46947

The fix is to include in BuildConfig.groovy

grails.project.war.osgi.headers=false

Maven users can also set the property when running the grails war artificat.

mvn clean grails:war -Dgrails.project.war.osgi.headers=false

via Grails – grails 1.2.2 and glassfish.