Tuesday April 06, 2010 Spring Training at Improving Enterprises (blatant advertisement)
Unless you've been hiding under a rock for the past few years or are completely detached from the Java community, you have no doubt heard of Spring. Nothing has changed the face of Java development as much as Spring. What started out as a challenge to complex and burdensome enterprise Java standards has now deposed those standard and has heavily influenced newer specifications. Spring is, in fact, considered by many to be a de facto standard for enterprise Java development.
But Spring didn't stop with simplifying enterprise Java development. As Spring has evolved, there have been simplifications to Spring itself. With each new version, Spring not only offers greater development power, but has also found ways to simplify its own programming model. What used to take pages and pages of XML-based configuration has now been replaced with more succinct XML, common conventions, and even annotation-based options.
If you're new to Spring and want to see how to use it in your applications or if you're a Spring veteran who is looking to leverage the new features and ease of the latest versions of Spring, then let me encourage you to attend Java Development with Spring, a course that I'll be teaching in Dallas next week. In this 3-day course, we'll go through all of the essentials of working with Spring and you'll get a chance to try it out in hands-on lab activities.
This course will be held at the Improving Enterprises office in Dallas, TX (map) on April 13-15. I really hope to see you there.
For those of you who can't make it, you can catch me at several stops of the No-Fluff/Just-Stuff tour this year. I'm currently slated to speak in:
- Bloomington, IL : April 10
- Reston, VA: May 1-2
- St. Louis, MO: May 22
- Dallas, TX: June 4-6
- Columbus, OH: June 26-27
- Salt Lake City, UT: July 9
And I'll also be at Dallas TechFest on July 30.
See ya soon!
(2010-04-06 13:00:00.0) Permalink Comments [1]
Thursday April 01, 2010 Action Framework to become Apache project
The response to my earlier announcement regarding the Action Framework has been overwhelming. In a surprise move, the Apache Software Foundation has railroaded Action through what will go on record as being the fastest incubation period in ASF history--Action is now a top-level Apache project.
Shortly thereafter, Apache agreed to sell out to Oracle for $1.5B. As the newest member of the Apache family, my cut of the proceeds is just under $5 million ($1 million of it to be paid in rolled pennies, $2 million in the cash equivalent of 1985 Topps Bo Jackson rookie football cards, and the remainder to be paid out by a Saudi prince through an elaborate balance transfer directly into my savings account.)
In celebration of this momentous occasion, I've worked with Manning to offer a 50% discount on all Spring-related Manning books. Use the code "april1" on Manning's site (today only) to get 50% off on the following titles:
- Spring in Action, 2nd Edition
- Spring Integration in Action
- Spring Dynamic Modules in Action
- SpringSource DM Server in Action
- OSGi in Action
- OSGi Application Frameworks
- AspectJ in Action
In case you haven't figured it out by now, the first two paragraphs of this blog post, as well as the blog post from earlier today, are just part of the April Fool's Day fun. The part about the Manning discount, however, is not a joke...go take advantage of the 50% discount at Manning.com now.
(2010-04-01 13:16:01.0) Permalink Comments [1]Announcement: Action Framework!
Today I'm delighted to announce that I've started development on Action, a new open-source web framework. As its name implies, Action builds upon the action-based model espoused by several web frameworks, most notably Struts and WebWork.
What? Another web framework? Why do we need another one, much less one that is based on Struts? Action differentiates itself from those other frameworks is that it is designed from the ground up to exploit modern web development practices, including Ajax, HTML 5, and semantic web technologies.
Development of Action has been underway for several months and I am nearing the point of a 4.1-Milestone release. (The decision to version the first release as 4.1 will become apparent later.)
Much as with all new frameworks, there will be a slight learning curve to become proficient in Action. To help smooth out that curve, I've already been working with Manning to publish a definitive guide to Action entitled Action in Action. The first MEAP chapters of that book will become available in concert with the 4.1 GA release of the framework.
As it turns out, the design of Action makes it quite portable to .NET. Consequently, I have also been working in parallel on the .NET version of Action, known as NAction. A corresponding edition of NAction in Action will also be available from Manning upon the release of the NAction framework.
On a technical note, the Ajax portion of the Action framework will leverage a RESTful API driven by JSON resources. I'm particularly proud of a custom extension of the Jackson JSON Processor that will power the REST/JSON features of Action. More details of this component and how to develop with it will be featured in the upcoming Action Jackson in Action, also to be published by Manning.
It should also be noted that due to some clever optimizations in memory and processor utilization, Action can run with ease on constrained devices such as the iPad, Blackberry Storm, or Commodore 64.
(2010-04-01 10:00:00.0) Permalink Comments [10]
Monday February 08, 2010 Spring Web Flow RefCard
In case you've not heard or don't follow me on Twitter, I'm pleased to announce that my fourth DZone Refcard, one covering Spring Web Flow, was released today. You can also read a short interview that I did with James Sugrue.
In case you're wondering...yep, I'm still working on Spring in Action 3. In fact, I'm now writing the Spring Web Flow chapter...so I get a chance to expand on what's in the Refcard. It's a lot of fun writing Refcards, but it's incredibly difficult to cram so much good material into less than 6 pages. In fact, despite my best efforts to keep it brief, over 2 pages of material landed on the cutting floor before the final product made it online. I assure you that there all of that good stuff, and more, will make it into the SiA3 Web Flow chapter.
I hope you like the Spring Web Flow Refcard. I hope to get a chance to do some more later this year once I've finished working on SiA3.
(2010-02-08 22:34:49.0) Permalink Comments [1]
Thursday January 21, 2010 Mark your calendars! My upcoming speaking engagements
Now that we're a few weeks into 2010, my speaking calendar is starting to take shape. Already in just the first quarter I think I have more dates set than I did in all of 2009.
If you follow this blog, you know me and you know that I like to yammer on about Spring and OSGi. So it should be no surprise that it is those topics that I'll be talking most about again this year. But I'll be throwing in some other stuff as well.
In case you're interested in attending one of the places I'll be speaking, here's a list of the places I've got on my calendar right now:
- Feb 10th: JavaMUG - Dallas, TX
- I'll be talking about Spring MVC and the new REST features in Spring 3.
- Feb 23rd: SOA User Group - Dallas, TX
- Here I'll be talking about OSGi and how it provides an "SOA in a JVM".
- Feb 27-28: Greater Wisconsin Software Symposium (NFJS) - Milwaukee, WI
- Jay Zimmerman has me scheduled to talk about what's new in Spring 3, OSGi, Spring Roo, and testing beyond JUnit.
- Mar 14th: Twin Cities Software Symposium (NFJS) - Minneapolis, MN
- As in Wisconsin, I'll be talking about Spring 3, OSGi, Spring Roo, and the Spring Expression Language (SpEL).
- Mar 17th: Spring Dallas User Group - Dallas, TX
- We haven't ironed out a specific topic for this event, but I'm sure it will be something about Spring. Any requests?
One way you can keep up with where I'll be speaking is to subscribe to my speaking engagements feed (served via FeedBurner). I will do my best to keep that feed updated.
In addition to all of these fun events, I'm also scheduled to teach a Spring course for my company, Improving Enterprises. The dates are April 6-8 and it will be at the Improving Enterprises offices in Dallas, TX. Do me a favor and tell your friends and tweet about this...it's the first time I've taught a class through Improving and I'd like to see a good turn out.
Put these events on your calendar. I hope to see you at one of them.
(2010-01-21 10:00:00.0) Permalink
Friday October 23, 2009 SpringOne/2GX: A Retrospective
SpringOne/2GX is now over and most everyone has made their way back to the real world. Rather than write a long-winded review of the conference, I decided to summarize my thoughts in the form of a retrospective. That is, what went well, what didn't go so well, and what I'd improve upon next time around.
Feel free to contribute to this retrospective with your own comments.
What went well
- The Day 1 Keynote
- The keynote on Monday night was quite interesting with SpringSource tcServer Developer Edition stealing the show. But also hearing about all of the different facets of the Spring ecosystem and seeing how they are evolving was great.
- Adrian Colyer's comedic bit to start the Day 2 Keynote
- Funny stuff. Adrian's quite the story teller. Wish I could find this on YouTube.
- My talk on SpEL went well
- I had given this talk twice before with less-than-desirable results. This time it worked out. It may have been the best talk I've ever given.
- The people
- It was great meeting and chatting with so many people who are also interested in Spring and Groovy/Grails. Also fun to catch up with my friends in SpringSource who I only get to see once per year.
- Rod Johnson's duet
- Rod played piano while another attendee played clarinet. Very entertaining.
- Roo and tcServer Dev Edition
- The darlings of the show. Almost everyone was talking about them. Both are awesome and you should check them out.
- The Roosevelt New Orleans
- This was hands-down one of the nicest hotels that I've ever stayed in. Very comfortable and luxurious. Highly recommended.
- The food
- The food served at lunch and dinner during the conference was outstanding.
When didn't go so well
- The Day 2 Keynote
- Don't get me wrong...I think the VMWare stuff is cool and interesting. But this is a developer conference and the parade of VMWare products would have better suited an IT crowd. It was interesting, but not valuable to me. I did find Chris Richardson's demo of CloudFoundry very interesting, though.
- The constant pinging sound in Salon 5
- What the heck was that?
- My failure to schedule appropriately
- I think that my strategy for choosing which sessions to attend was flawed. All of the sessions were great, but I think I could've learned more by attending a different mix of sessions. I'm especially regretful that I didn't attend more Groovy-oriented sessions.
- The size of the desserts
- Last year's desserts were much bigger...slices of cake the size of your head. This year they were more petite. But, if you smash several of them together...
Things to improve upon next year
- Personal session selection
- I should try to attend more sessions on topics that I don't know as well.
- More audience interaction
- The best part of my talk was where the audience chimed in with things to try in SpEL. I should purposefully set aside time to "take requests" from the crowd in my talks.
- Get more sleep
- I missed out on a few things because I was exhausted. Should plan my sleep better so that I can attend and see more stuff.
- Bigger desserts
- 'Nuff said.
Thursday October 22, 2009 Curing ADD with Roo, Blueprints, and Karaf
Yesterday was a big day for me at SpringOne/2GX. It was the day that I gave my talk on the Spring Expression Language (SpEL). I've been excited about giving that talk, but also excited about attending so many of the great sessions by other speakers. So, I started the day by attending a session presented by Stefan Schmidt on web productivity with Roo.
Unfortunately, due to lack of sleep and anxiety for my own presentation, I was unable to focus well on Stefan's talk. He was doing a great job presenting Roo, but my brain just couldn't focus. So to entertain my brain with something that at least was close to the topic at hand, I decided to tinker a bit with Roo's support for SpringSource's Bundlor to generate OSGi manifests for Roo artifacts.
The first thing I did was to start up the Roo shell and issue the project command:
roobundle% roo
____ ____ ____
/ __ \/ __ \/ __ \
/ /_/ / / / / / / /
/ _, _/ /_/ / /_/ /
/_/ |_|\____/\____/ 1.0.0.RC2 [rev 321]
Welcome to Spring Roo. For assistance press TAB or type "hint" then hit ENTER.
roo> project --topLevelPackage com.habuma.numbers
Created /Users/wallsc/Projects/roofun/roobundle/pom.xml
Created SRC_MAIN_JAVA
Created SRC_MAIN_RESOURCES
Created SRC_TEST_JAVA
Created SRC_TEST_RESOURCES
Created SRC_MAIN_WEBAPP
Created SRC_MAIN_RESOURCES/META-INF/spring
Created SRC_MAIN_RESOURCES/META-INF/spring/applicationContext.xml
roo>
From here it looks like Roo has created the basic project structure. Nothing special so far. But what I want to do with Roo is build a simple OSGi bundle that publishes a service to the OSGi service registry. So, let's start by creating the service's interface. There's lots of ways I could do this, but as long as I'm in Roo...
roo> interface --name NumberToEnglishService Created SRC_MAIN_JAVA/com/habuma/numbers Created SRC_MAIN_JAVA/com/habuma/numbers/NumberToEnglishService.java roo>
Notice that Roo's interface command creates the interface in the base directory without me having to explicitly specify that package. If we dig around in the project directory, you'll see that Roo has created NumberToEnglishService.java in src/main/com/habuma/numbers. But it's empty, so let's give it something to do. I could find no way to do this directly in Roo (and I can't imagine how that'd work anyway), so I hopped out of Roo and opened up NumberToEnglishService.java in my text editor and made it look like this:
package com.habuma.numbers;
public interface NumberToEnglishService {
String translate(int number);
}
The idea behind NumberToEnglishService is to take a number as an int and to return a String that spells it out in English. For example, given 6, the translate() method should return "six". Simple enough. Now we need an implementation. So, trying to do as much work in Roo as possible, I issue the class command in the Roo shell:
roo> class --name ~.internal.NumberToEnglishServiceImpl Created SRC_MAIN_JAVA/com/habuma/numbers/internal Created SRC_MAIN_JAVA/com/habuma/numbers/internal/NumberToEnglishServiceImpl.java roo>
Since I'm ultimately going to export com.habuma.numbers in the OSGi manifest, I want to put the implementation of NumberToEnglishService in a different package. This keeps it private to this bundle so that no other bundle will try to use it directly. In Roo, the tilde (~) is a shortcut for the project's base directory, so "~.internal" will be expanded into "com.habuma.numbers.internal"...and that's where NumberToEnglishServiceImpl.java was created.
We're almost ready to create our bundle, but we need to flesh out the contents of NumberToEnglishServiceImpl.java. Again I turn to my text editor to have it implement the NumberToEnglishService interface as follows:
package com.habuma.numbers.internal;
import com.habuma.numbers.NumberToEnglishService;
public class NumberToEnglishServiceImpl implements NumberToEnglishService {
public String translate(int number) {
if(number == 6) {
return "six";
}
return "unknown";
}
}
So this implementation of NumberToEnglishService is a bit short-sighted, but it does satisfy the aforementioned requirement of translating 6 to "six", so it's a good start.
Now we have all of the code in place for our service, so let's build it. Roo produces a Maven project, so all we need to do is run Maven with the package goal:
roobundle% mvn package [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Building numbers [INFO] task-segment: [package] [INFO] ------------------------------------------------------------------------ ... [INFO] Building jar: /Users/wallsc/Projects/roofun/roobundle/target/numbers-0.1.0-SNAPSHOT-sources.jar [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 16 seconds [INFO] Finished at: Wed Oct 21 22:09:43 CDT 2009 [INFO] Final Memory: 19M/34M [INFO] ------------------------------------------------------------------------ roobundle%
So far, so good. Let's crack open the JAR artifact to see what its manifest looks like. Unfortunately, it looks like this:
Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: wallsc Build-Jdk: 1.5.0_20
There's no Bundle-SymbolicName, Bundle-Version, Export-Package or any other header that would indicate that this is an OSGi bundle. This is just a plain old JAR file. We need it to be an OSGi bundle.
We could edit our own manifest file, but that's no fun. Fortunately, Roo has support for the Bundlor tool to automatically generate a proper OSGi manifest. All we need to do is tell Roo that we want it to use Bundlor. To do that, issue bundlor setup in the Roo shell:
roo> bundlor setup Managed ROOT/pom.xml Created ROOT/template.mf roo>
Now our Roo project is setup with Bundlor, so let's build it again and the review the manifest to see if it looks any better. This time the manifest looks like this:
Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Built-By: wallsc Created-By: Apache Maven Import-Package: javax.sql;version="0.0.0",org.springframework.stereoty pe;version="[3.0.0,3.1.0)" Export-Package: com.habuma.numbers;version="0.1.0.BUILD-SNAPSHOT" Bundle-Version: 0.1.0.BUILD-SNAPSHOT Bundle-Name: numbers Bundle-Classpath: . Build-Jdk: 1.5.0_20 Bundle-ManifestVersion: 2 Bundle-SymbolicName: com.habuma.numbers Tool: Bundlor 1.0.0.M5
Now that looks like an OSGi manifest. We have a Bundle-SymbolicName and a Bundle-Version, among other things. And notice that the Export-Package header exports our base package. It all looks good...except...
The Import-Package header imports javax.sql and org.springframework.stereotype. We're not really going to use those in our bundle, so I'm not sure that we need them. So we need to tell Bundlor to not import them. If you paid close attention when doing the Bundlor setup, you saw that Roo added a file called template.mf to the project. This file contains instructions to guide Bundlor in producing a manifest. We'll need to edit this file to remove the Import-Package instructions for javax.sql and org.springframework.stereotype. If you open up template.mf, you'll see a line that looks like this:
Import-Package: org.springframework.stereotype;version="[3.0.0,3.1.0)", javax.sql;version="0.0.0"
Just remove it and then run the build again. Then have another look at the produced bundle's manifest. It should look a little like this:
Manifest-Version: 1.0 Bundle-Name: numbers Bundle-Classpath: . Archiver-Version: Plexus Archiver Build-Jdk: 1.5.0_20 Built-By: wallsc Created-By: Apache Maven Bundle-ManifestVersion: 2 Bundle-SymbolicName: com.habuma.numbers Tool: Bundlor 1.0.0.M5 Export-Package: com.habuma.numbers;version="0.1.0.BUILD-SNAPSHOT" Bundle-Version: 0.1.0.BUILD-SNAPSHOT
Much better. Now the manifest doesn't import anything we don't need. But we're not quite ready to deploy our bundle yet. Even though we have a service interface and implementation and our bundle's manifest is in shape, there's nothing that actually publishes the service to the OSGi service registry.
There are a lot of ways to publish services to the OSGi service registry. In Modular Java I wrote about using both the core OSGi API and Spring-DM to publish and consume OSGi services. But recently, the OSGi R4.2 specification was released including the OSGi Blueprint Services specification and I've been wanting to try it out. OSGi Blueprint Services is a formalization of the service model from Spring-DM. It's slightly different than Spring-DM, but if you've already used Spring-DM, then it should be quite easy to figure out. Even if you've not used Spring-DM before, I think that the Blueprint model is quite intuitive.
All we need to do to publish our service in the OSGi service registry using OSGi Blueprint Services is to add an XML file containing the blueprint specifications to the bundles OSGI-INF/blueprint folder. Since our Roo-created project is a Maven project, that means creating the blueprint XML file in src/main/resources/OSGI-INF/blueprint. This one ought to do fine:
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:ext="geronimo.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
default-activation="lazy">
<bean id="numberService"
/>
<service ref="numberService"
interface="com.habuma.numbers.NumberToEnglishService" />
</blueprint>
I named the file numbers.xml, but the name really isn't important. Any filename with a ".xml" extension will work.
The root of the blueprint specification XML is <blueprint>. Within that the <bean> element declares the NumberToEnglishServiceImpl class as a bean in the blueprint context (just like Spring). Finally, the <service> element refers to that bean and publishes it in the OSGi service registry under the com.habuma.numbers.NumberToEnglishService package (just like Spring-DM).
There's only one more bit of bookkeeping to be done before we're ready to build and deploy our bundle. When Roo first created the project, it assumed that we'd be doing some Spring stuff, so it created a Spring configuration XML file at src/main/resources/META-INF/spring/applicationContext.xml. Since we're using OSGi Blueprint Services and no plain-old Spring, we'll not need that file anymore. And, if our bundle is deployed in an OSGi framework with the Spring-DM extender installed, this file will actually keep our bundle from starting successfully because it refers to stuff in org.springframework.stereotype, which we no longer import in our manifest. The simple solution to this problem is to simply remove applicationContext.xml.
Now after we build the project one last time, we'll have an OSGi bundle with a service that is published to the OSGi service registry using OSGi Blueprint Services. All we need now is an OSGi runtime that supports Blueprint Services.
Even though OSGi R4.2 is rather new, there are already a few options available for using Blueprint Services. Spring-DM 2.0.0.M1, for instance, includes support for Blueprint Services and is, in fact, the reference implementation. But I've been tinkering with Karaf lately, which includes Blueprint out of the box. And just to prove that this will work even without Spring, let's deploy it to Karaf.
Assuming that Karaf is running, all I need to do is to copy numbers-0.1.0-SNAPSHOT.jar from our Roo project's target directory into Karaf's deploy directory. Upon arrival in Karaf's deploy directory, Karaf will install and start the bundle. Then Karaf's Blueprint deployer will pick it up and publish the se