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.

This is my first trip through St. Louis and I kept thinking that I need to visit this place. It’s only 40 mins flying time from Des Moines. So it can’t be a very long drive. A quick tour of the airport and a quick survey of the eateries led me to the Wolfgang Puck Express restaurant. A big ‘ole breakfast sandwich and coffee later I was back on the schedule working my way through the second round of eliminations. The session descriptions on the conference schedule are usually indicative of the content. But sometimes you never know. Fortunately I’d been to NFJS couple months earlier. So that helped me eliminate some of the similar talks and sometimes the same talk from NFJS. I knew I still had at least three or four rounds before I could narrow my schedule down. A lot of the sessions sound very interesting and it’s going to be difficult to choose between them but it has to be done and I decided to go over it again on my way to New Orleans. For now I’m going to work on a OSGi blog posting.

St. Louis to New Orleans is a little under 2 hours flying time. Enough time to read the in-flight magazine cover to cover…ok I skipped the inflight entertainment section. I went down the conference schedule one more time to weed out the “not useful to me right now” sessions. I’ve found that while hands-on practical sessions are great, if you do not have immediate applications for them you don’t derive their full benefit. Instead I’m trying to assemble a mix of immediately applicable hands-on sessions, sessions that build upon my existing skills, overview type sessions and sessions which I think may have some potential near future applications. I still ended with some time-slots where as many as 5 of the 8 sessions made it to my 3 round. So yeah still plenty of work to do. I’m sure we’ll be getting the slides to all the sessions. I wonder if we will get the videos though.

So New Orleans is my new favorite airport to transit through. Guess why!? Free wireless internet baby! It’s not the world’s fastest but it’s free. In all the major US airports I’ve transited through not one has had free wireless..not O’Hare, not JFK, not LAX. Somebody should start a website tracking airports with free wireless. It may influence a lot of travel plans

Met up with Matt at the New Orleans airport and took a cab ride to our hotel in downtown. On the way I was reminded a couple times about big city driving. After check-in we headed out to the conference hotel which, the newly reopened Roosevelt which is right across the street from the hotel we are staying in. Thanks to Mandy for booking us into our very convenient hotel. I won’t have an excuse to miss the morning sessions . I was a little surprised to see a handful of vendor stalls. We got to talk to the VMware guys about Spring and VMware and from the sounds of it looks like they are trying to sell a cloud provider solution for those who want to get into business of providing cloud service solutions a la google, amazon etc. Apparently this will give the consumer the benefit of switching between different providers as opposed to currently being locked-in. Also got the chance to talk to the BIRT guys and catch up how BIRT has matured over the last couple years since I used it. I’d be interested to hear if anyone else has any experience using BIRT over JasperReports or other open-source reporting solutions. Dinner was pretty awesome — New Orleans cuisine for the most part including my first taste of bread pudding…yumm.

Rod Johnson’s keynote followed. He covered what Spring 3.0 was about and some of the new stuff, pointing out sessions that would follow during the next two days. There was a demo on Spring – Flex Blaze DS integration. It looked pretty cool though a lot went over my head. I think it was building on top of Spring JMS. The big announcement was the Spring tc Developer server which gives the developer a pretty powerful tool to look into the guts of an application. The demo showed where you can make a request on slow loading page and you then drill down through the Insight tool to the specific slow running query. Just scraping what was demoed. Apparently the first release is not due until later this year. I’ll probably pull down the Milestone and take a more closer look at this.

Time to go to bed and rest up. Day 2 will be another long day. But before that I need to pick out at least the first two sessions for the day. The conference slides were distributed on thumb drives. So I did a quick scan and was able to pick out a couple sessions before calling it a night.

This is the first in a series of blog posts that will attempt to demystify OSGi and demonstrate how it enables the creation of modular web applications. We will explore various aspects of the technology along with the challenges of using this technology. I encourage you to join in the discussion by posting any comments about your own experiences or challenges you have faced developing OSGi applications. We start with the assumption that we understand what OSGi is and the specific modularity problem it tries to solve. Here are some resources you can visit to read up on this.

1. http://neilbartlett.name/blog/2008/06/06/what-is-osgi-for/ – this one talks about the problem space
2. http://www.infoq.com/interviews/osgi-adrian-colyer – this one brings Spring and OSGi together

Turn on the ignition

Lets get started. This first post will show you how to launch an OSGi framework and how you can interact with it. You will first need to have a JDK installed. I recommend the Sun JDK. You then need an OSGi implementation. There are several implementations of the OSGi 4.2 specification. We will stick with equinox from the Eclipse Foundation. It is the same core technology that powers the Eclipse application framework. If you have Eclipse installed browse to the plugins folder and copy the org.eclipse.osgi_<version>.jar to a working folder (say c:\work\toes). You can also download the equinox jar from the eclipse download site.

Take it out for a spin

Open a command window to c:\work\toes where you have placed the equinox jar. Run the following command to start up the Equinox OSGi framework remembering to replace the equinox jar with the version you have.

c:\work\toes>java -jar org.eclipse.osgi_3.5.1.R35x_v20090827.jar -console

osgi>

You are greeted with the OSGi console prompt. Type ss – for ’short status’ at the console.

osgi> ss

Framework is launched.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.5.1.R35x_v20090827

osgi>

The list of bundles available in the framework along with their current status is displayed. This output shows that we have one bundle installed in the framework and it is the framework bundle itself. And you can see it is an the ACTIVE state. We will see more about the bundle lifecycle in the next post. The bundle id is the handle with which you interact with the bundle. Try the following command:

osgi> headers 0
Bundle headers:
Bundle-Activator = org.eclipse.osgi.framework.internal.core.SystemBundleActivat
or
Bundle-Copyright = Copyright (c) 2003, 2004 IBM Corporation and others. All rig
hts reserved. This program and the accompanying materials  are made available un
der the terms of the Eclipse Public License v1.0 which accompanies this distribu
tion, and is available at http://www.eclipse.org/legal/epl-v10.html
Bundle-Description = OSGi System Bundle
Bundle-DocUrl = http://www.eclipse.org
Bundle-Localization = systembundle
Bundle-ManifestVersion = 2
………………
……………

You will see a screen full of information. This is information from the bundle’s MANIFEST file. We will be covering most of this in later posts. For now just know that the bundle id is your handle to poke at the bundle and make it do interesting things.

Type help at the OSGi prompt to see what other commands are available. This list is mostly the same across the OSGi frameworks with some having extra commands and sometimes having different names for the same command.

Finally type exit to shutdown the framework.

Let’s go remote

Now that you know how to interact with an OSGi console, don’t you want to hack into that corporate OSGi application. No. But maybe you need to poke into a remote OSGi application. Let’s see how you can do that. Pass a port number parameter to your OSGi framework launch command like below:

c:\work\toes>java -jar org.eclipse.osgi_3.5.1.R35x_v20090827.jar -console 9999
Listening on port 9999 …

This lauches the OSGi framework as a process and waits for telnet connections on port 9999. Now you can connect to the console on via c:\> telnet localhost 9999.

Since eclipse is built on OSGi you can just as easily attach to the console. Just run eclipse.exe from the command prompt with -console <port no>. But be careful not to stop any bundles unless you know what you are doing. You may mess up your eclipse workspace and you don’t want to have to start from scratch.

In the next post we will go more than just toes in. We will build a simple OSGi bundle and look at bundle headers in more detail.