First – I have to install Roo and get the Roo shell up and running.  I’m really excited at this point because Roo does look really cool – really RAD!

So I download Roo and explode it out to where I explode all of my 3rd party tools and then open cygwin (I’m on Windows and am trying hard to move away from Dos…) and navigate to the new directory.  I find a bin directory with two scripts in it: roo.bat and roo.sh.  Sweet!  They have a linux version ( cygwin == linux in many ways ).  So I run roo.sh and get:

./roo.sh

Exception in thread "main" java.lang.NoClassDefFoundError: org/springframework/roo/bootstrap/Bootstrap
Caused by: java.lang.ClassNotFoundException: org.springframework.roo.bootstrap.Bootstrap
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
Could not find the main class: org.springframework.roo.bootstrap.Bootstrap.  Program will exit.

OK – take a step back.  What have I done wrong here.

I back up a directory and also try ./bin/roo.sh.  I look in the readme.txt and create the symlink for install on linux that they recommend:

ln -s /path/to/roo/bin/roo.sh /usr/bin/roo

I type in ‘roo’ and get the same BootStrap Exception.

So then I invoke the wisdom of Google and learn that most everyone who encounters this error gets it because they are in Dos and are working in a different drive than where Roo is installed.  I’m on the same drive – but it’s not working in cygwin!  No hits on this somehow?!?  I find some other results which want me to additionally set an environment variable ROO_HOME.  I do this by running from the Roo install directory ( above bin, that is…):

export ROO_HOME=`pwd`

env | grep ROO

I still get the same problem (ClassNotFoundException: org.springframework.roo.bootstrap.Bootstrap), so I cave and go into a Dos prompt. Well, first I add %ROO_HOME%\bin to my path, and *then* go into a Dos prompt. I run ‘roo’ and get the same Bootstrap Exception again. But now, I am on the wrong drive, and cd to the same drive I installed Roo on – now things are working.

Time to even start using Roo in this example : 15 minutes

So, Roo is working now – I have a shell up and running. I’m stoked because it really is cool. It has ‘hint’ as a keyword and tab-based auto-completion which is contextual – it auto-completes the correct things at the correct times.
Creating a project with Roo is a very nice experience : 3 minutes

I already have maven2 installed so I’m able to exit out of Roo and run ‘mvn eclipse:eclipse’ and import the project into Eclipse : 2 minutes

Wow, now we’re flying.  Except, wait, there a bunch of “.aj” files in my project.  Cool, Roo is leveraging AspectJ.  Suck, I don’t have AJDT plugin configured for Eclipse and I’m missing a bunch of the stuff Roo has added to my project ( 9 .aj files in all ).  Thinking this might not matter, I run the JUnitTest that Roo created for my project and see only 1 test being run – the demo has a bunch of tests being run ( added via AspectJ ).  Also, when I auto-complete on my entity class I created, I don’t get any of the framework added static methods.  Translation: I need to install the AJDT plugin for Eclipse: 10 minutes ( http://download.eclipse.org/tools/ajdt/34/update ).

Now things are good to go – I now see the out-of-the box static methods added to my domain class ( Choice.java ).   And now when I run the JUnitTest I see that 8 new tests have been added and run.  But there’s something else stinky in the state of Denmark!

IllegalStateException: Entity manager has not been injected (is the Spring Aspects JAR configured as an AJC/AJDT aspects library?

No, the SpringAspects JAR is *NOT* configured as an AJC/AJDT aspects library!  I don’t know what the SpringAspects JAR is nor what it means to configure it as an AJC/AJDT aspects library.  Basically, this means you need to select the spring-aspects.jar to be in the Aspect Path of the AspectJ Build configuration of the project.  A picture is worth a 1,000 words here

Adding spring-aspects.jar to AspectJ Build path

10 minutes

So, we’re up to 40 minutes of time spent when the whole thing up until now should only be 5 minutes.

But wait, there’s more.  Now I find that I don’t have setters being woven into my Choice.java class by the Choice_Roo_Javabean.aj aspect.  I see the correct code in the aspect, but Eclipse’s autocomplete and the actual compilation fail when I attempt to access new Choice().setNamingChoice().    I can deal with this later because I’ve got to get on with the demo.

Next up – Roo will automatically update the companion aspect files it creates as new properties are added to the domain entity.  That is, if I simply add a new property called ‘description’ to my entity, and I have roo running in the background, then the Choice_Roo_Javabean.aj is automatically updated with the new getter/setter methods, and the Choice_Roo_ToString.aj is updated to include description.  SUPER COOL.

On a tangent, it is not mandatory that these woven aspects dictate the toString and javabean parts of the entity class.  The class has annotations in it to specify that the framework will handle these concerns: @RooJavaBean, @RooToString.  There is also a @RooEntity which adds all of the dao-ish methods to the class.  This is a pattern taken from Grails.

At this point we have an autogenerated JavaBean and a companion TestCase that works.

What about the webapp?  Inside of Roo shell, we can now run:

new controller automatic

With a few arguments to generate the framework jsps, the wiring, the formBackingObject functionality and even the crud forms for the domain entity.  The ordering of the fields on the crud forms matches the order in which they appear in the java file.  Changing the order of properties in the java file will change their order in the ToString.aj and crud JSPs as well. 2 minutes

Here are my notes from the presentation:

Does My Bus Look Big in This?
———————————————-
Talk given by Jim Webber and Martin Fowler

Most integration tools are bloated lard asses because they’ve been on a rich
diet of BPM, Transformations, Security, Adapters, Rules Engine and GUI tools.

Integration software is a bridge built between two existing applications (silos)

SOA to the rescue!  ( not! )  It’s the same old stuff.  Same old atrocity -
if a single service ever needs to change then you’re screwed.

SOA != Service Oriented Architecture
SOA == Same Old Atrocity

ESB – this should fix things.  Just plumb your databases and services in
and you are suddenly Scalable and Governable.

ESB != Enterprise Service Bus
ESB == Erroneous Spaghetti Box

ESB is an Architectural Fantasy – at least as a magic bullet.

Mainstream SOA Today : it doesn’t run and it’s full of fat.

We need to think carefully, plan ahead, design interfaces wisely.

Agile Architecture:
1) Accept change as an inevitable part of the Software Process
2) The most important part of the Software Process is people – we need
to make allow the people to be effective.

Continuous Integration
Automated Testing
Refactoring – disciplined way to design and evolve the software
Behaviour Driven Development

Grow the system, incrementally.  With a solid core that functions to begin
with and then add more layers of functionality deliberately over time.

Frameworks have gotten agile, too.  Spring, Hibernate, Rails, etc…

Http and the web – broke some of the rules.  All the links *DON’T HAVE TO WORK* – 404 errors are a good compromise

The web is great because the underlying network is so simple and dumb, but it
facilitates almost any higher level usage layered on top of.

The web allows us to do things that we never considered in advance.

Great design isn’t considering all the cases and designing for them.  Great design is
when you can handle situations with your architecture that you’ve never thought of
or considered.

Guerilla SOA – just do it in the trenches but don’t bet the entire project on it.  Then
with each small victory, re-prioritise and keep delivering.

Web-based Services: The Web *is* middleware.  HTTP is a big, coordination framework.

The web is slim, trim middleware – not fat bloated like SOA and ESB.  The web is ubiquitous!

The web is incremental and, therefore, low risk.

So, we don’t need what middleware vendors are selling us.

SQUID?!?  What is it?

Squid is your ESB – a Big, Big Proxy Server.

Proprietary Middleware  vs  Web-centric techniques
——————————————————
Big, up-front design  vs  Evolutionary
Lengthy death-marches  vs  Constant delivery
Expensive  vs  Inexpensive
Risky  vs  Incremental
Enterprise Scale  vs  Internet Scale
Specialised  vs  Commoditised
Integration separate activity  vs  Integration by-product of delivering business value
Not very sensible  vs  Quite sensible

Take the same ideas we’ve come up with in application developement when attacking the larger
Enterprise issues.

This is a very informative talk given by Adrian Colyer – CTO of Interface 21 – on the new OSGi support within Spring 2.5

——————————————————————
OSGi == The Dynamic Module System for Java
In OSGi jars/modules are called “Bundles”
Modules can declare what it provides and what it requires.
Modules can be installed, started, stopped, uninstalled, and updated *at runtime*
Bundles can publish services dynamically.
Publish/Find/Bind – Service Registry allows this

A Brief History of OSGi
- started in 1999, focus on embedded Java and networked devices
- 2003: extended support to mobile devices
- 2004: significant open source community adoption ( Eclipse plugins )
- 2006: OSGi moving into server-side Java

Current implementations:
- Eclipse Equinox
- Apache Felix
- Makewave Knopflerfish
- Prosyst mBedded Server Professional Edition

Paremus?!? Enterprise company using OSGi – who are they?

How does OSGi help me?
- Strong modularity
By default a bundle is a black box and classes are isolated from other bundles.
A bundle can export one or more packages.
Only exported packages are visible outside of the exporting bundle.
Modularity gives : Independent development, easier to maintain, faster development cycles.

- Versioning support
Versioning allows two dependent Libraries A and B to each use a different version of
Library C v1 and v2 with v1 and v2 being incompatible. This is fine so long
as no classes from C are leaked back to your application through A and B.

** What about Singletons in Library C?

- Operational control (life cycle)
With OSGi console and/or JMX you can see all modules and their status
Get information on wiriing
Install/Update/Stop/Uninstall new bundles
Activate bundles ( publishing services in the process )
Deactivate bundles ( unregistering services in the process )
All of the above happen without stopping or restarting the server.

Type-space contributions
Object-space contributions

OSGi WebApps can be written and deployed either as:
1) OSGi bundles in an OSGi-compliant container – but not many of these are open to this, yet.
2) As a more standard WebApp, but using the Embedded OSGi container ( and the ServletBridge )

Spring 2.5 is OSGi ready.

Class.forName becomes troublesome because the Class may not be exported out of its bundle.
Class.forName does it’s own caching of Classes, so the correct version of a class may not be found

OSGi doesn’t have a ContextClassLoader because:
1) it has no notion of “context”
2) is has no notion of “application”
** Solutions
1) Eclipse Equinox’s ContextFinder – this looks up the call stack for the most recent bundle
owned class and uses that bundle’s ClassLoader “which works in many, many situations”.
2) Spring Dynamic Modules: CCL Management

Web Applications
- OSGi HttpService: allows for programmatic configuration. ability to register Servlets/resources
under aliases.
- Equinox Http Registry Bundle: declarative configuration.

What does Spring Dynamic Modules for OSGiprovide? www.springframework.org/osgi
- Bundle needs: instantiating, configuring, assembling, decorating
- Bundle blueprints
- expose bundle objects as services
- wire service references between bundles
- consistent/easy way to manage dynamics
– services may come and go
– broadcast operations
- test environment
- ContextClassLoader management
- Configuration Admin service integration
- Bundle lifecycle management

OsgiBundleXmlApplicationContext
- uses bundle context and classloader to load resources
- implements Spring’s resource abstraction for OSGi
– relative resource paths resolved to bundle entries
– “bundle:” prefix for explicit specification

Instead of a ContextLoaderListener there is org.sfw.osgi.extender bundle
- acts like “ContextLoaderListener”
- automatically creates Spring application context inside a bundle
when a bundle is started. No code or dependence on Spring APIs required!

Creating a bundle – from jar file to Spring bundle…
- start with a normal old jar: mymodule.jar
- add needed headers to META-INF/MANIFEST.MF
- Bundle-SymbolicName: org.xyz.myapp.mymodule
- Bundle-Version: 1.0
- Bundle-ManifestVersion: 2
- place configuration files in META-INF/spring

Exporting a Service:

<osgi:service id=”myServiceOsgi” ref=”myService”
interface=”org.sfw.osgi.samples.ss.MyService”/>

Importing a Service

<osgi:reference id=”aService”
interface=”org.sfw.osgi.samples.ss.MyService”/>

What happens if…?
- there isn’t a matching service? Dampening…
- there are several matching services? osgi:set vs osgi:reference, perhaps.
- a matched service goes away at runtime? Dampening…
- new matching services become available at runtime? osgi:set vs osgi:reference, perhaps.

Relevant JSR’s
———————————————————-
JSR-291 Take OSGi and endorse it on Java Platform
JSR-277 Java Module System ( poor man’s osgi )
JSR-294 Language changes that support Java Module System

I just read infoQ’s Architecting Twitter article.

Concepts

Single-Instance Storage

Data Sharding

Flickr Architecture

Google Architecture

LiveJournal Architecture