One of the JDK APIs that has always thrown me for a spin is java.io with its gamut of InputStream and OutputStream classes. I never had a full grasp of how the API was meant to be used until recently. I knew just enough to get what I needed to get done without going down the rabbit hole. While reading the excellent Head First Design Patterns book, the chapter on the Decorator Pattern demonstrated how the java.io API is built on the Decorator Pattern. Once I made this connection, the complexity of java.io disappeared. This also explained why the API seems like a mess to begin with. If you’ve used the decorator pattern you can quite easily discern that the apparent API complexity is one downside to this pattern.

I intend to start a blog series on exploring the patterns that exist in the JDK APIs. The JDK APIs are fertile terrritory to see patterns as applied in the real world instead of the text book examples found in many design pattern books. The goal is two-fold. One to understand the APIs from our understanding of the patterns. And two to understand the patterns from our understanding of the APIs. Hopefully with this double-ended approach our understanding and appreciation of both the pattern and the API will be enhanced.

Please use the comments to point out any patterns/APIs that you would like to see in this series. My first post will be on the java.io APIs.

If you don’t have a Git repository that is linked up with a Subversion location, here are the Git commands that will bring down a project in Subversion into a Git repository on your workstation:

$ mkdir myproject
$ cd myproject
$ git svn init --trunk=http://my.svnserver.com/repos/myproject/trunk \
--tags=http://my.svnserver.com/repos/myproject/tags \
--branches=http://my.svnserver.com/repos/myproject/branches \
--username <your svn username>
$ git svn fetch -r <starting subversion revision # to fetch from>

Note: I’ve had much better luck using a more recent revision number in Subversion than trying to checkout the entire project history.

Now that we have our repositories laid out lets get to work. The key point to remember is we never commit to the master branch in our Git repository. Instead we use master to simply keep up with the project’s trunk in Subversion. So the only git commands that get executed on the master are git svn fetch followed by git rebase trunk. We’ll go into these in more detail below.

We have a bunch of changes to make in the project. Here’s what our workflow is going to look like:

Step 1: Create a separate branch (say local-dev) from master where we make our changes.
$ git checkout master # make sure you are on the master branch
$ git checkout -b local-dev # the new branch where we make all our changes

Step 2: Proceed to make changes on the local-dev branch
$ git add FileThatChanged
$ git commit -m 'your commit message'

Step 3: Now stash away any changes in our working copy that we haven’t committed into git and that we don’t want pushed up to Subversion
$ git stash

Step 4: Update our master branch with any changes that have happened on Subversion trunk since the last time we fetched from Subversion.
$ git checkout master #switch back to the master branch since that's what we use to track Subversion trunk
$ git svn fetch # pull down the changes from Subversion into the remotes/trunk
$ git rebase trunk # apply any changes from Subversion onto the master branch
$ git log # to view the changes we got from Subversion

Note: See this post for a sweet tip on customizing your git log messages to be more easily readable.

Step 5: Update local-dev with the changes from master
$ git checkout local-dev # switch to our local development branch
$ git rebase master # apply all the changes that were brought down from Subversion trunk into master into our local-dev resolving any conflicts
$ git log # notice how the Git rebase command moved our commit to be last commit on this branch

Step 6: Push our commit to Subversion trunk
$ git svn dcommit

Step 7: Bring back our changes that were stashed
$ git stash pop

Rinse and repeat. It probably reads like a lot more work that it really is especially once you’ve gotten the hang of the workflow. But this should avoid the merge hell …or impasse rather when syncing with Subversion. Now, what are you waiting for. Go Git that project from Subversion!

Step 1: Create the project folder in svn with the recommended layout
http://my.svnserver.com/repos/myproject
http://my.svnserver.com/repos/myproject/trunk
http://my.svnserver.com/repos/myproject/tags
http://my.svnserver.com/repos/myproject/branches

Step 2: Backup your project’s git repo just in case. From within your project’s root directory run
$ git branch master.bak master

Step 3: Link your git repo to the newly created svn location
$ git svn init -s http://my.svnserver.com/repos/myproject
$ git svn fetch

Step 4: Put all our commits onto the remote trunk repo
$ git rebase –onto trunk –root master

Strp 5: Finally commit everything to subversion
$ git svn dcommit

All git commits along with the commit history will make it to svn. Except the timestamp of the individual commits will not be preserved.

In spite of being a non-believer I stayed with Git and what seemed like the hype around it. I read up on it and I even got myself an account on github and setup a few projects there. Git seemed interesting but it wasn’t really solving any problems for me that Subversion wasn’t already. And then I had my first ah ha! moment yesterday.

So I was building out a new application at work where we use Subversion. Instead of checking in the initial project skeleton into Subversion like I normally would’ve I did a git init on the project and decided to use git till I was ready to commit it to Subversion (btw stay tuned for how easy this is in a later post). I noticed with Git I was committing much more frequently and much smaller changes. Probably because I knew that when I was ready to push the code to Subversion and share it with the rest of the team I could easily collapse my commits. This is nice but not my ah ha! moment yet.

After one such frequent git commit, I started working on a new feature and half way through realized I didn’t want to go that route and needed to implement it differently. But I didn’t want to lose all the things I put in place for this feature if I ever needed to come back to it or to refer to it in the future. And so here it comes – I used the git stash command to save away my uncommitted changes and revert my working copy back to the last commit. So now I had a fresh starting point and I also had all the work that I’d done saved away for the future if I needed it. I could not imagine doing this in Subversion as easily having to deal with it in the past. You could use branches in Subversion but it is a much more heavy weight solution for this.

So there you go, my first Git ah ha! moment.

1. Musings of a SpringOne 2009 Attendee Day 1
2. Musings of a SpringOne 2009 Attendee Day 2
3. Musings of a SpringOne 2009 Attendee Day 3

Read on for day 4.

OSGi and Groovy Jump Start

The presentation started with a 5 minute youtube video preview which I thought was pretty innovative.

The first half was around what is OSGi, some of which I’ve had experience with. I did pick up on a few key concepts that I didn’t know i wasn’t communicating earlier in my own presentations on OSGi.

We covered how a groovy POGO has groovy types in the public API. So if your groovy bundle has the groovylib in it’s classpath then it has to export the groovy package. Also when using Groovy in OSGi, if possible use POJOs for your applications type system since POGOs force you to expose couple groovy types in the bundle’s API.

The examples were done using gradle and this was my first live example of using gradle. This is a key benefit of conferences — being exposed to technologies you may otherwise not have the time to take a peek at.

I liked how the presenter took the path of not making things look complex but rather simplifying the concepts. He did this with concepts such as the OSGi bundle lifecycle.

Some of the tools covered in this session were:

• bnd to create a groovy manifest
• osgi bundle for gradle uses bnd
• junit4osgi

Expand your business with Groovy – Case Study

This session was a case study on how a monolithic application was extended to provide customizations using groovy. A major customer had approached HypericQ wanting a custom dashboard.

HypericQ developed a architecture around attach point’s which are places within the UI where plugins can connect to.

Custom UI was provided by gsp templates for customer specific dashboards.

Groovy templates was used as the templating framework that allowed clients to build their own using GSP pages.

A Web Services API was provided as part of the core platform that enabled several benefits:
- hqapi command line interaction
- allows integration testing of the application
- embedding a groovy console inside the application
- console gives you a HQL way to query the domain and not worry about the end customers database environment

The talk was an interesting exercise in how a dynamic plugin architecture could be implemented. Groovy categories was heavily used to enable this.

Re-factoring a Spring Application for SOA using Spring technologies in 40 min

The current focus of SOA is really software architecture. SOA is neither static nor predictable. The architectural pattern of any application must be reflective of the business. SOA is preparing the stuff that is critical to your business to stand the test of time.

Architecture involves the courage to be wrong while minimizing the impact of being wrong. It is about making educated decisions between speed and perfection. The longer it takes to deliver the software the higher the client’s expectations of that software is.

The foundation of SOA is highly cohesive, loosely coupled modules. One must practice

1. strategy first programming
2. process life-cycle dynamics
3. process collaboration
4. loose coupling promotes a network based architecture over a hierarchical one – composition over inheritance

SOA and OSGi enable embracing change by making versioning a runtime concept.

There is an argument to be made for deploying a process as a whole in BPEL. But what about flexible orchestration via simple messaging. We were given the American football analogy. Each play is scripted, but between plays we need to adjust strategy to meet the overall goal.

Modern event driven architecture was mentioned as a composite process linked together in a linear fashion through the use of rule based pathing.

The second half of this talk was the Spring booking demo from Spring Web Flow project. There are 3 OSGi bundles:

1. war bundle
2. service bundle
3. datasource bundle

The demo was using STS and it’s DM Server tooling. The entire development workflow was very seamless with SpringSource having done an awesome job of the tooling.

We saw an example of a transparent failover. So there is a need to take down the primary database for maintenance work without taking the application down. A backup datasource bundle is started and the primary datasource bundle is stopped. The datasource bundle is a simple datasource definition and an osgi service with ranking. Because of a higher rank the backup datasource bundle takes precendence and the primary datasource bundle can be safely stopped. Bundles can also take advantage of filtering besides ranking.

Spring Integration builds on pipes and filters. You can expose OSGi services as pipes. It provides the ability to change the behavior of a modularized application by changing how the modules are hooked up in the XML as opposed to modifying source code or in cases where the source code is not available.

Conference Wrap Up

Here are my key take aways:

• It is time for Grails
• Need to investigate Spring Faces
• Webgoat
• Spring Web Flow
• Spring Integration
• Spring DM Server

Overall it was a very productive conference and I would recommend it for anyone looking to attend it next year.

The fact that we even started a book club was a big positive because it is one great way to geek out with very smart people. You get the opportunity to voice your opinion on a certain topic and hear counter-points or similar views that expand your own perspective.

We went through 2 books in the span of about 6 months. The first book was Test Driven Development: By Example by Kent Beck. It’s a very good book by itself. But we found it didn’t make for very good book club discussion. The material didn’t really provide much fodder for critical thinking and exploration in my opinion. But it was a start.

We then picked up Effective Java by Joshua Bloch as our second book. Java is currently my bread and butter and this book was very appropriate with it’s tip based approach. The material was a little dense in some areas, but overall an extremely good book for a book club discussion because it provided enough room for critical thinking and discussion. Unfortunately though well intentioned I thought we fell off the wagon due to a few different reasons:

• We met in a cafeteria location which was noisy and had it’s own share of distractions making it difficult to have any sustained discussion
• Not a whole lot of discussion around the topic because each of us read a different chapter in the book and we didn’t really have common ground
• We had participants in the discussion who hadn’t read the book and would understandably drive the conversations off topic
• We didn’t have a standing meeting time which we were committed to. Sometimes I felt we were scrambling just to get a common meeting time organized. We did get better about this towards the later half of last year.

Going forward into 2010
Learning from last year, we are making some changes to derive more out of the book club this year.

• Meet in a quiet location – This year we will be meeting in a conference room with little distractions
• A once a week standing meeting – This way everyone in the group is aware of the weekly commitment and can be prepared
• Be more pro-active about our book selection – Maintain a list of potentially interesting books and select books at the regular meeting
• More structured discussion format – We all have views and opinions on what we’ve read. So all of us must have the opportunity to voice our thoughts
• Book review – This year we are going to attempt to publish a blog post reviewing each book that we discussed at the book club
• Limit the book club to a maximum of 6 members – any more and the 1-hour will be insufficient for everyone to participate fully

We’ve already had two meetings so far this year with the above format and I thought it went very well. And am looking forward to a more rewarding book club this year.

Some Google searches later I found that when it comes to LVM partitions the OS keeps references to it unless you explicitly tell it to unhook them. Only then can you tell the OS to hook the LVM partitions back up when you’ve plugged the drive back in. In my case I had to resort to rebooting the server in order for the OS to hook all the pieces together for the LVM partitions. Short of this I would have to manually delete certain files and move things around to get the LVM partitions to work again. So here are the magic incantations that will save you the headache.

Before you unplug an LVM partitioned USB drive, you must run the following commands:

#!/bin/bash
lvchange -an /dev/your_volume_group_name
vgexport -a

Use the man command to explore what these commands do.

Now you should be able to unplug the drive. When you are ready to plug it back in, stick it back in the USB port and run the following commands:

#!/bin/bash
vgimport -a
lvchange -ay /dev/your_volume_group_name

You should now be able to run lvs and see you LVM partitions on the USB drive without any errors and proceed to mount the partitions.

Hope you found this useful. Are there other or different ways of doing this? Please add your comments below and Happy Holidays!

Some of the questions this session set out to attempt to answer were

1. What is architecture?
2. What defines architecture?
3. What are architectural decisions?
4. Is architecture a forward only decision?

Several definitions of Architecture were quoted from prior literature. Such as architecture being the the shared understanding of the system being built. Shared understanding between a group of people who need to communicate about it — developers and architects, or technical and management etc.
Lean principles are you delay the decision till it is required and till after you have enough information to make an effective decision. Does this mean you should not make decisions based on incomplete information? I disagree on the “effective decision”. How do you even know what is effective decision? Something that is effective today more than likely will not be effective tomorrow. The world we live in is a naturally changing world. You delay the decision till the last responsible minute. But when you have to make the decision you do it based on the best available information at that point.
The goals of architecture were then discused. I thought this was a very insigtful analysis. We were first shown how the impact of change and the cost of change influence architecture and design. Hgh impact and high cost of change require architecture and design. If the change has high impact, but low cost then architecture may not be as important as long as you have measures to mitigate the change such as unit and functional tests. Or if the change has low impact but high cost, if you are prepared to absorb the cost, then architecture may not be as important either though this is more unlikely. The end goal of architecture is to reduce the impact and cost of change.
Are flexibility and complexity opposing goals? Higher flexibilty introduces higher complexity. It goes back to choosing your battles. If the impact of change is not significant then it doesn’t have to be flexible and thus not complex. So the question is which parts of the system needs to be flexible.
The release-reuse equivalence principle is that the unit of release is the unit of resue. We see this in daily practice. And consequently reuse fits nicely into modularity. In other words, what is modular can be released as a unit and reused.
So then what correlations can be made between agility and modularity?

• Structural flexibility which defines modularity
• Temporality or the ability of the system to accommodate future change which defines agility

(This stuff is good I’m thinking!)

A jar file

• unit of resuse
• unit of composition
• unit of deployment
• unit of management

So why not make jar files first class citizens on the java platform? Why do we have to package a jar inside a WAR or a EAR? Why are we flattening these modular units.
Increasing a system’s modularity leads to easier to maintain and extendable software. In a non-modular system, being afraid to make changes to the code base causes us to do things such a copy/paste, or write duplicate code which further degrades the codebase. Guilty as charged!
Modularity helps in assessing the impact and cost of change. When we know what other modules depend on the module that needs to be changed, we have a more clearer understanding of the risks, impacts and cost of that change. I wonder if the roadblock to modularity is our platforms.  What if the WAS and Glassfish and Weblogics of the world allowed us to deploy our applications as sets of OSGi bundles?

There was a comment about how WAS 7 has made giant strides towards being modular internally by adopting OSGi under the hood. Apparently it starts under 5 seconds for a non-ejb application. I had to recently run WAS 7 in development mode inside my RAD workspace. And I can vouch for the fact that startup time was certainly several magnitudes more than 5 secs. Maybe I’m missing something here.
So what are benefits realized in the runtime because of modularity?

1. Dynamic deployment
2. Multiple versions
3. Enforce dependencies

….and all at runtime.
Modular tension is higher ease of use of an artifact makes it more difficult to reuse. Higher ability for reuse (i.e. finer grained artifacts) makes it more difficult to use. Are reuse and use always inversely related?

A few thoughts around this:

1. Public methods shouldn’t necessarily be published methods. Currently this is enforced via Javadocs unless you are using OSGi
2. Interfaces should be close to their usage and not close to the implementations. This makes sense for framework APIs. It probably applies to business applications as well. What’s good for the  goose is  good for the gander.
3. Separate the interface from the implementations not just at the package level but also as deployment artifacts. You see this in framework apis now (javaee-api.jar is separate from its implementation jar). But not so much in business applications. If we did, it would aid in providing more predictable API evolution. We would be able to fix a defect or enhance an internal function in the implementation and then release just the newer version of the implementation built against the same old version of the API. The consumers of this API would not see any suprises since the API itself hasn’t changed. Instead when we package both the interface and implmentation as a single artifact, it is more difficult to avoid suprising the consumers of the API.
4. Exceptions should be close to where they are thrown. So they should be part of the API.

So is OSGi the holy grail of runtime modularity?
Yes and no. It forces runtime modularity but we are still required to design our apps modularily. A sample application (kcode.googlecode.com) that echoed these principles was demoed. Another tool that was mentioned was JarAnalyzer which gives us a visual image of our jar dependencies by analyzing the project. It can be included in the build script. The tool was built by the author.
Overall I really liked this session because of how it tied all the buzz and technical mumbo-jumbo around modularity and OSGi into business speak, something you can pitch to management.

That old Spring magic has me in its SpEL: DI Wizardy with the Spring Expression Language – Craig Walls

Spring Expression Language or SpEL is probably the most prevasive feature in Spring 3.0. From what I’ve seen so far it can be used in DI, in Spring Web Flow, in Spring Security, Spring Integration. So if you are looking at taking advantage of Spring 3.0 you should probably look at SpEL. A SpEL expression is provided within a #{ } similar to the JSF EL. The source code (http://spring.habuma.com/examples/SpEL-examples.zip) contains well documented examples of the different forms of SpEL expressions. Here is a sampling:

Instead of having to use environmentPlaceHolderConfigurer you could do:

#{systemProperties['region']}
#{systemEnvironment.region}

You can refer to the following:
#{bean.property}
#{request.getParamenter(”action)}
#{request.getAttribute(action”)}
You can inject these directly into bean properties instead of having to do it in code. Very cool! This is just scratching the surface. Go now and checkout the source. There are some amazing things you can do with collections similar to what you can do with the Bean predicate except more succintly. SpEL can be used as a configuration tool (both in applicationContext.xml as well as with Spring annotations) as well as a general purpose parser a la apache commons beanutils via the SpELAntlrExpressionParser.

SpEL is nice but there is no type safety or syntax checking. It seems to impart a funtional flavor when used with collections.
Craig had one test class with individual test methods that showcased each of the capabilities of SpEL. He would make a change in the test method and hit save and the test would be automatically run giving him immediate feedback on pass or fail. He was using Infinitest who are handing out free licenses for individual developers. It uses JUnit. I hope they also provide TestNG support.

Working with Spring Web Flow – Keith Donald

I was convinced to attend this session after the Spring Faces session. Spring Web Flow is a stateful web conversation framework. The flow persistence strategy is pluggable. By default it uses Session but it doesn’t necessarily have to be session. Useful in a multi-step progression type user interaction as well as in single page AJAXy interactions.
Keith showed how pages are bookmarkable and how the browser Back button works as it  should. Web flow uses an encrypted key in the URL parameter for the key. Example e5s1 where the 5 indicates the execution of time of this execution and the 1 indicates the snapshot or step in the flow. You can modify the key in the URL and the URL is still addressable.
The execution has a lifecycle and upon completion it is garbage collected which means it is no longer active. It does automatic session cleanup after the flow ends. Spring Web Flow can replace t:saveState and all the extra coding that goes with it to maintain state particularily in multi-page flows.
There was a question about where we can introspect the flow execution repository for use cases such as bread crumbs navigation. Apparently you can but it is still very involved and this is being addressed in the next version. Keith demonstrated the hotel web application sample from Spring and the flow for the booking scaenario. External flow definition modules are compiled and refreshed upon changing without app server restarts. Code completion is available in the editor (STS?)

Can use evaluate to execute some method and assign to a scoped varaible. SpEL can be used in Web Flow. The model attribute on view-state is used to bind form parameters to bean properties. I didn’t quite catch the validation part of it.

I definitely need to take a good look at Spring Web Flow and it’s integration with JSF.

Spring Integration 2.0 Preview – Mark Fisher

Spring integration provides an embedded message bus that lives within an applicationContext with all components being Spring managed objects. Many of the patterns from the Enterprise Integration Patterns books are implemented. A message wraps around a payload (XML/java Object) along with headers. A Message Channel is the communication link between producers and consumers and provides loose coupling.

This is another one of those core technologies that I think can underpin the architecture of a flexible enterprise application.

Case Study: SRM 2.0 – A next generation shared resource management system built on SpringSource dm Server – Matt Stine
This session was about how St. Jude Children’s Research Hospital rebuilt their Shared Resource Management System as a modular application to be extensible to meet growing business needs. The business need was to track samples as they progressed through the different stages in a laboratory. There are several labroatories and each usually has it’s own set of unique requirements.
The previous system consisted of:

1. Core domain model
2. Core services platform
3. Web platform
4. Laboratory specific extensions
   1. DB Schema – extendable by hanging tables of existing tables
   2. Domain model
   3. Services

Overall the shema had 200 tables that was becoming unmanageable. And they had to follow a monolithic deployment model. When it was decided that they need to rethink the application it was based around extensiblity

1. primarily by configuration
2. feature modularity

An EAV data model was chosen for it’s extensibility. The system was built around some core concepts such as a kernel and business activity source. Using OSGi as the underlying  platform, they were able to introduce new technologies behind an OSGi service without running risks of breaking other parts of the application. From a development perspective OSGi lets them ship the interface out to a 3rd party team and have them implement it.

Used 3 to 4 days of consulting work from SpringSource the team was able to ramp up on OSGi, Spring dm server and STS starting in January ‘09. They then spent the first 3 to 4 months working out the kinks since the tools were still in their 1.0.0 version. In their experience, adopting OSGi led to a short time fall-of in productivity as they ramped up on the technology but they are now reaping the long term benefits of modularity. Their reporting solution was implemented against a real time data mart that is relational and using messaging via Spring Integration and a databus architecture.

It was pretty awesome to see that they had developed a modular enterprise application based on OSGi leveraging Spring Integration. After the presentation I got the chance to talk to the technical lead on this project from St. Jude. He told me how respecting the small set of simple tenets of good application design enforced by OSGi, depending on interfaces, and use of shared bundles was really the reason for their success. OSGi is not complex and there is no need to make it complex. Wise words.

Grails Quick Start – David Klien

David walked through the creation of a Grails web application to track a JUG’s meeting schedule. I liked his presentation style or maybe because the room wasn’t very crowded things just registered better. Picked up a few tips such as the Bootstrap class. Grails still has a ways to go in the eclipse tooling. It would’ve been nice to have been able to File –> New Project and follow along. Too bad IntelliJIDEA CE doesn’t support grails though there has been plenty of buzz on the latest STS. Downloading this right now. Only 3 more hours for the download to complete!

I think I’m beginning to dig duck typing. All in all the presentation encouraged me to put my head down and hammer out a sample app to start building some grails knowledge. More homework!

XML and Web Services with Groovy – Paul King

XMLParser and XMLSlurper were covered. I’d attended a similar talk by Scott Davis at NFJS. So I wasn’t all oo-ahh about it. But I did pick up on a few things. Like the XMLSlurper’s lazy evaluation. Apparently lazy evaluation is more pervasive in Groovy and you see it in sql resultset processing as well. This actually makes groovy faster than Java in these use cases. We also saw how existing Java XML libraries such as DOM4J can be used within groovy.

For the web service half GroovyWS was shown. In literally three lines of code you can standup a POJO/POGO as a web service endpoint. Not likely to be used in production but this shows how you can easily take an existing Spring bean and expose it’s responsibilities as a web service for a proof of concept. A simple SOAP webservice consumer was shown in 4 lines too. Also learnt that Synapse and ServiceMix have groovy support built into them.

Simplifying Java Server Faces Development with Spring Faces – Jeremy Grelle

I probably got most out of this presentation. At times I felt like Jeremy was speaking directly to me. My day job involves JSF 1.2 and Jeremy was pointing out all the (anti) patterns we employ in order to overcome the limitations of JSF 1.2.

He pointed out two ways to integrate JSF with Spring

1. JSF centric – where Spring simply replaces the managed bean functionality of JSF. With the caveat that if you need to dynamically inject a Spring bean it is not possible using Spring 2.5. In those situations you’ll need to revert to JSF managed beans. You could still use the JSF managed beans for view action classes and inject Spring service beans into the action classes. The JSF centric approach is the one I’m familiar with.
2. The Spring centric on the other hand does all of the following:
   1. JSF plugs into Spring as the View layer
   2. Does not use the FacesServlet
   3. Spring MVC + Web Flow together replace the
   • managed bean provider
   • request dispatcher
   • navigation handler
   • state manager

Spring Web Flow provides the conversation scope (more than Request but less than Session scope) that is sorely missing in JSF.

In the Spring centric approach one would use the Spring MVC DispatcherServlet for Controllers for stateless intrerations (basically selecting JSF views for rendering) and Spring Web Flow for stateful interactions.

He demoed what I think was JSF 2.0 Custom components. And how one can wrap them with Spring Faces components to do client side validation etc. The Spring Faces components wrap Dojo under the hood and this same technique can be used by us to wrap other Dojo components that are not already available in Spring Faces.

Another issue we run into frequently in JSF 1.2 is being able to initialize a view. The framework does not provide a built-in way to do this. Spring Web Flow has a clean way to do this using on-Render in the flow definition. Web flow also has viewScope allowing you to do multiple interactions with the same page without having to go back to the database.

The big benefit of Spring Faces is it’s integration with Web Flow. And Web Flow makes the restarts due to changes in faces config a thing of the past.

There was a slide that compared the pet clinic application built using Spring Faces and pure JSF. The Spring Faces application used 1/3rd the lines of code — which was believable considering how the faces config was completely trimmed and how a lot of the workaround code was eliminated. Some of the new features requires JSF 2.0.

What about Seam? Not sure if and how Seam would work in a Spring web stack.

Grails Security – Ken Sipe

This session covered SQL injection attacks and XSS attacks. Made me wonder how many of us building applications that live behind the firewall really code for this. Ken also showed examples of how an enterprising hacker can discover the data structure of your application using SQL injection. O/R frameworks solve most of the SQL injection problems but apparently there are edge cases where these frameworks still spit out un-parameterized queries and how we need to always verify the SQL being generated. Another question about input validation and what is it that you are validating. This is still a hazy area and there was no definitive answer on this. Also Stories and Abuse Stories — are we writing code that prevents the user from breaking (nicer word for hacking?) the application? Does this need to be part of the story acceptance criteria.

We then got to look at security in Grails and how we need to add the html codec in the Config.groovy to escape out the HTML.

grails.views.default.codec = “html” in /conf/Config.groovy.

Ken mentioned the Command Object and treating the interaction with the data store as different from the interaction with the web. We then looked at Cross Field validation in Groovy which was pretty sweet.

It was mentioned that we should never show error pages to users which to me makes absolute sense in a public facing web application. But are there internal applications that we may need to expose the error message to the end user — such as when we cannot duplicate the issue in the  support or development environments and it is a fairly complex interaction that is quicker to have the user send you the stack trace or walk you through the steps to reproduce the issue. We are trading security for ease of troubleshooting. How big a risk is this in internal apps?

Ken said something interesting about handling session riding attacks — upon login expire the newly authenticated session and create a new one based on the expired session. For requests that are highly sensitive, using encrypted tokens with a timeout. So if the following request doesn’t provide the token and doesn’t meet the time expectation then you can invalidate it.

Few resources that were mentioned:

1. Spring security for Grails (SecurityConfig.groovy)
2. Apache Shiro
3. keylength.org
4. Writing Secure Code – best book on security as per Ken (believe it or not from Microsoft press)
5. Webgoat – learning tool to learn about securing Java EE applications. This looks like something I need to check out. More homework again!
6. EASPI from owasp attempts to solve the security concern at the framework level.

Case Study: RESTful Web Services at Orbitz – Alex Antonov

Alex talked about solving the problem of management of shared, versioned dependencies with serializable objects in a highly distributed environment. And the pain involved in keeping about 60 to 70 systems in sync during upgrades.

The original maze of systems were implemented in JINI. But since Sun is no longer behind JINI and JINI is no longer evolving they have had to ditch it. They actually won an award for their use of JINI. But they have migrated to a REST based architecture using Google Protocol Buffers for the messages across the wire instead of XML or JSON. I should  have paid attention during Octavian’s protocol buffers presentation! So protocol buffers is a substitution for java serialization. It is 7 to 10 times faster than JSON and even faster than JINI/JERI.

Protocol buffers provides transparent versioning where if a message needs to flow through System A –> System B –> System C, you can upgrade the message structure (upto a certain extent) in System A and  System C and not have to modify System B. Protocol buffers lets connected systems mesh both backwards and forwards at the joints without the developer having to put in any effort.

We were then introduced to REST API best practices. Didn’t see much new stuff that I hadn’t seen before. Speaks for REST which is supposed to be simple with a few guiding principles. One thing I did learn about writing REST APIs was to use query strings for optional filtering. Another was to let the client define what message format they will accept via the Accept header. You can then use plugins for protocol buffers to send down the message in the requested format.

TECHNICAL KEYNOTE – Adrian Colyer

Adrian Coyler’s keynote started of very entertaining when he walked acros the stage with just the handle of his new roll-on bag. Story about how his luggage got ripped out and disappeared on his way to SpringOne. We heard about some of the new things in Spring. But he moved quickly to showing SpringSource’s last acquisition, Crowd Foundry and it’s capabilities. Having seen Google’s App Engine before I wasn’t very impressed. Essentially Crowd Foundry provides a developer centric way to deploy Java applications on Amazon EC2 including a plugin for Eclipse (or does this require STS?).

VMware then took over explaining their technology blueprint that leverages Spring tc server running in virtualized environments. Looks like VMware which has till date been visibile mostly in the infrastructure and operations space will soon be surfacing virualization and the cloud to developers. Some of the technologies that were showcased were:

1. vMotion
2. Dynamic Resource Scheduling

Interesting stuff. I later on learnt that on of the organizations that was implementing an enterprise OSGi application was using vMotion at the infrastructure layer for fail over.

Spring Core BOF

Spring ESB? More like Environment Specific Beans may be coming in a future release of Spring 3.x.This should eliminate the need to use environment placeholder configurers for environment specific beans. Learnt that spring-oxm can be used outside of the spring-ws.

http://www.springbyexample.com was suggested as a useful resource for learning.

Wrap up

Manning was running a treasure hunt of sorts all through the conference with free book vouchers hidden around the conference areas. I had absolutely no luck!

One of the best parts of this SpringOne conference is rubbing shoulders with guys who’ve written the books, written the code, and give talks about the technologies that we use. These guys literally sit around with the attendees and are there to geek out with us regular joes. I got the chance to meet Craig Walls and talk about OSGi and Venkat and pick his brain on functional languages. And of course there is the always helpful SpringSource team easily recognized by their “uniforms”.

Looking forward to more. Also got my first re-tweet.