Spring in Practice

December 3, 2008

New stuff in Spring 3.0, part 2

Filed under: SpringOne — Willie Wheeler @ 3:34 pm
Tags: , , , ,

[Here's part 1 if you missed it.]

As promised, here’s the rest of my notes dump on what’s new in Spring 3.0, or really Spring 3.x since a lot of what comes in Spring 3.x is waiting on JEE 6, which probably won’t be finalized until after Spring 3.0 is already released.

More about Spring 3 and its support for JEE 6

Before I continue describing Juergen’s first talk, I did attend another of his talks just a while ago and it seems like Spring 3/JEE 6 integration is going to be “interesting,” especially as concerns Spring integration with the forthcoming Java Web Beans effort (and to a lesser extent, EJB 3.1). He didn’t work too hard to hide his displeasure at the unattributed fashion in which many of the core ideas from Spring are making their way into the JEE specs. He described Web Beans as being a standardized DI framework with a focus on supporting scoped beans (request, conversation, session, application, etc.), and noted that many of the annotations from Web Beans and EJB 3.1 have direct counterparts in Spring. Taken together it sounds like Web Beans + EJB 3.1 will compete with Spring, with Web Beans handling the user component model and EJB 3.1 providing platform services (transaction management, container-managed security and so forth).

Anyway regarding Spring 3 and JEE 6, it will be fun to watch as it unfolds. :-)

Here’s some more information related to how Spring 3 will support JEE 6:

  • JSF 2.0: full compatibility as managed bean facility
  • JPA 2.0: support for lock modes and query timeouts (Hibernate supports these, but this is new for JPA)
  • JAX-RS and Jersey reference implementation (part of Glassfish): Spring will support these though they see JAX-RS as an alternative to Spring Web MVC’s REST support. Juergen said that he sees JAX-RS for more “hardcore” RESTful web service applications, and it’s a completely separate component model for building programmatic resource endpoints.
  • JSR 236 WorkManager and TimerManager: Rich, standardized access to thread pools. This spec is behind schedule so it won’t be in Spring 3. Maybe Spring 3.1. Juergen is excited about this though it sounded like it’s more from the framework perspective than from the app developer perspective.
  • Servlet 3.0: This won’t be supported til Spring 3.1 or Spring 3.2, but two major items here are (1) auto-deployment of framework integration classes (I didn’t fully catch what this meant–I couldn’t tell if it’s about hot-deploying JARs or what), and (2) support for Comet requests. The Comet support would include new HTTP request and response types.
  • EJB 3.1 and Web Beans as described above. Just depends where the specs go.

The Spring team is tracking GlassFish 3 and Tomcat 7 as well.

JSR 303: Bean Validation

This one looks like it will be for Spring 3.1 rather than Spring 3.0 since the Bean Validation spec isn’t done yet. The idea though is that JSR 303 provides a declarative, annotation-based model for defining validation constraints, and so instead of forcing developers to invoke validation manually, the framework would automatically invoke it at appropriate places. I haven’t played much with Hibernate Validator yet but I think you can make Hibernate automatically validate persistent objects before saving them. So the same sort of thing would occur elsewhere. For example Spring Web MVC will I believe automatically invoke validation after doing form binding.

I did ask about the Bean Validation Framework (from the Spring Modules project), and whether that was dead. I think for a brief moment he didn’t know what I was talking about when I said “Bean Validation Framework” (not a good sign for the BVF), and when I mentioned Spring Modules he said [paraphrasing here]: yeah, BVF is pretty much dead, use Hibernate Validator instead. My brother asked Uri Boness (BVF lead) about it several months back and he said roughly the same thing, that the best bet is for people to use Hibernate Validator and plan on JSR 303 being the future of validation.

Spring 3.0 will support Hibernate Validator annotations but the real goal is to support JSR 303 annotations.

Portlet 2.0 support

Some major Portlet 2.0 capabilities include:

  • An explicit action name concept for dispatching
  • Two new request types: resource requests for servlet-style serving, and events for inter-portlet communication
  • Portlet filters, which are analogous to servlet filters

Spring 3 will have Portlet 2.0 support. In particular, Portlet MVC 3.0 will support the following mapping annotations: @ActionMapping, @RenderMapping, @ResourceMapping, and @EventMapping. Conceptually these are specializations of Spring Web MVC’s @RequestMapping annotation even though there’s no explicit subtype relationship here.

Some other odds and ends:

  • In the Spring EL there will be some scope-sensitive Portlet-related implicit objects such as the current PortletRequest and PortletSession.
  • The @RequestHeader and @CookieValue annotations I mentioned yesterday will work for both Servlet MVC and Portlet MVC.

Juergen also described some areas of research. These aren’t necessarily going into Spring 3 anytime soon but they’re just taking a look right now.

Research area #1: Conversation management

A key problem in conversation management is isolating concurrent windows in the same browser. Historically this has been the domain of Spring Web Flow, but there’s some thought of moving some level of conversation management to Spring Core. The idea is to introduce a new scope that’s larger than a single request but smaller than an entire session–a conversation–and be able to handle that, along the lines of the MyFaces Orchestra project.

This is just me editorializing now, but I’m myself a little dubious of the usefulness of a conversation scope if the goal is really just managing different browser windows. To me it seems like running a single app in multiple browser windows is a corner case. I suspect that what’s going on is that Spring is responding to the fact that JEE 6 Web Beans will have a conversation scope.

If the goal is to handle Spring Web Flow-type scenarios (single window) then yeah, that I can see. Anyway.

Research area #2: Scoped bean serializability

Sometimes you want to be able to serialize beans, but you can’t, because they contain references (either directly or indirectly) to unserializable objects, like e.g. DataSources. They’re looking at ways to address this.

I’m not sure what sorts of serialization scenarios they have in mind. Originally I was thinking Juergen was talking about saving out sessions during server shutdowns (like Tomcat does) and stuff like that, but as I write this, that doesn’t seem right, because your domain objects wouldn’t have DataSource references. So apparently some people want to save managed objects, which seems odd since those managed objects (controllers, service beans, DAOs, etc.) are usually stateless. Oh well. I don’t doubt that somebody has some reasonable use case here; I just don’t myself know exactly what people have in mind on this one.

Hm… but scoped beans would typically be domain objects… heh, I’m totally confused on this one. :-)

Anyway, the Spring team is thinking about how best to handle this. Juergen offered that one “solution” is just to design your apps so that they don’t involve serializing scoped beans. Another idea might be to have serializable proxies that are able to reconstitute the scoped bean when the proxy is initialized.

Spring 3 will also address a handful of housekeeping items.

Housekeeping and portfolio rearrangements

Some portfolio rearrangements include:

  • There will be a revised OXM modules as part of the core, rather than just being part of Spring Web Services, as there are broader areas of applicability, including XML payloads in REST and XML datatypes in the database.
  • The binding and type conversion infrastructure will be revised. It will include capabilities from Spring Web Flow’s binding, and there will be EL integration here.
  • Spring 3.0 will include the core functionality of Spring JavaConfig, which basically allows you to configure application contexts from Java instead of using XML.

Deprecation and pruning

The following will be deprecated:

  • The traditional MVC controller class hierarchy (deprecated in Spring 3.0, removed entirely in Spring 3.1).
  • Traditional JUnit 3.8 test class hierarchy (this will be replaced with the test context framework)
  • Various outdated helper classes

The following will be removed in Spring 3.0:

  • Commons Attributes support
  • TopLink API support (replace with JPA/EclipseLink)
  • Support for Struts 1.x subclass-style actions

Some related links:

[Update: Here's a related InfoQ article.]

December 2, 2008

New stuff in Spring 3.0

Filed under: SpringOne — Willie Wheeler @ 7:59 pm
Tags: , , , , , ,

This morning I attended a talk by Juergen Hoeller on what’s coming in Spring 3.0. First, he said that we can expect the first milestone release sometime this week, and said that he expected there to be about three milestone releases I think. RC1 is supposed to be out around March 2009 and final around April 2009.

Echoing something I’ve heard Keith Donald say, Juergen said that Spring 3.0 is intended to complete the work that was started in Spring 2.5. Keith described the release as being “evolutionary, not revolutionary.” That may be, but there’s still quite a bit to be excited about. Here’s what I got from the talk today. (Hold onto your hats because I took good notes.)

Java and JEE compatibility

Spring 3.0 will be the first release that requires Java 5+. From SpringSource’s perspective this is nice because they can avail themselves to generics, varargs, etc. But from the app developer’s perspective, the idea is that the platform is really pushing use of annotations as the preferred way of doing configuration. So that means Java 5+.

Spring 3.0 will continue to be compatible with J2EE 1.4 and JEE 5. Also, as JEE 6 matures, Spring 3.0 will try to provide early support, but progress on JEE 6 has been somewhat slow and Spring 3.0 should be out before JEE 6. So Spring 3.1 and 3.2 will probably continue work in this direction. Anyway, SpringSource plans to support JSF 2.0, JPA 2.0, Servlet 3.0 when it’s ready, etc.)

Spring EL (Unified EL++)

Juergen described support for expression languages as probably the most important and powerful feature in Spring 3.0. It will be a proprietary EL parser implementation–one of the few new modules that Spring 3.0 will introduce–and it sounded like it would like Unified EL but on steroids. They’re trying to keep the EL pretty similar to how it works in JSF, and Spring’s EL is designed to be stylistically and syntactically compatible with Unified EL. Also, even though right now Spring Web Flow 2 uses external EL implementations (JBoss EL implementation of Unified EL, I think, or else OGNL), SWF 3 will use Spring EL instead of an external implementation.

Here’s a code example he gave. This one is for EL in bean definitions:

<bean class="mycompany.RewardsTestDatabase">
    <property name="databaseName" value="#{systemProperties.databaseName}"/>
    <property name="keyGenerator" value="#{strategyBean.databaseKeyGenerator}"/>
</bean>

The idea is this. Just like in other ELs, you will have some implicit objects–objects that you can reference in your EL either because the objects are global in scope or else because the object lives in your current scope (e.g., request scope, session scope, etc.). So in the example above, systemProperties is a global implicit object, and strategyBean is a bean name. Bean names will be available as EL objects then.

I’m assuming that the databaseName and keyGenerator properties will be evaluated each time they are accessed. Otherwise it wouldn’t be much of an expression language. I’m kind of curious to see how they do this. My guess is that the approach will be to proxy beans with EL-based properties, with the proxies evaluating the reference upon demand.

Juergen gave another example, this time of EL in component annotations. Here it is:

@Repository
public class RewardsTestDatabase {

    @Value("#{systemProperties.databaseName}")
    public void setDatabaseName(String dbName) { ... }

    @Value("#{strategyBean.databaseKeyGenerator}")
    public void setKeyGenerator(KeyGenerator kg) { ... }
}

I believe these two configuration examples are different in a subtle way. The value of the @Value attribute is a default value for the property if a value isn’t explicitly defined in the app context. One practical benefit we get has to do with how component scanning currently works. When we component scan, we depend on autowiring to establish injected references. The problem is that if our dependencies are primitive types, autowiring is no longer an option and so we have to go explicit with our bean definitions. With EL-based defaults, we can keep the component scanning, and just set the primitive types using a bean, or maybe using system properties, etc.

REST support

Another big topic in Spring 3.0 is REST support. Spring Web MVC will provide first-class support for RESTful web services, and not necessarily just XML-based. Keith was saying that there will be a JSON view as well. So the web services would be useful not only in integration efforts but also for example when you have JavaScript widgets that want to make AJAX calls back to the server and get JSON. Anyway, Spring Web MVC’s current design is such that it’s really easy to tweak it a bit to support REST, and that’s what they’re doing. So one aspect of this would be to continue to use @RequestMapping to specify an HTTP method, such as RequestMethod.PUT. Another piece would be to introduce a new @PathVariable annotation that works pretty much like @RequestParam currently works, but handles URL path segments instead of HTTP parameters. Here’s a code example that shows how it will work:

@RequestMapping(value = "/show/{id}", method = GET)
public Reward show(@PathVariable("id") long id) {
    return this.rewardsAdminService.findReward(id);
}

I like it!

Another feature of the REST support is support for different representations, i.e. content negotiation. They want to use the HTTP Accept header as a new way to do view resolution. So presumably there will be a new ViewResolver implementation that looks at the Accept header and returns, say, an XML view (accepts application/xml), a JSON view (accepts application/json) or an ATOM view (accepts application/atom+xml) according to that header. This would be the preferred way of doing view resolution for the hardcore REST purists. But Spring Web MVC would also support extension-based resolution; e.g. .json maps to a JsonView, etc.

Some @MVC refinements

They’re planning to add a couple of new @MVC annotations besides @RequestParam (which already exists) and the new @PathVariable annotation. These are:

  • @RequestHeader: Grab HTTP request header data.
  • @CookieValue: Grab cookie value. (Surprise!)

These will allow us to get at the data without having to declare the raw HttpServletRequest as we currently have to do. Here’s a code sample:

@RequestMapping("/show")
public Reward show(@RequestHeader("region") long regionId,
    @CookieValue("language") String langId) {

    ...
}

There’s quite a bit more, but this post is pretty long as it is and I need to hit the sack. I’ll try to post a little more tomorrow.

[Update: Here's part 2.]

[Update: Here's a related InfoQ article.]

December 1, 2008

Rod Johnson’s keynote address at SpringOne Americas 2008

Filed under: SpringOne — Willie Wheeler @ 10:44 pm
Tags: , , , , , ,

I’m at SpringOne right now, and very much enjoying the Westin Diplomat. My room is on the 21st floor and it overlooks the Atlantic. My balcony door is open and I can hear the waves crashing on the shore as I write. This is how life should always be. :-)

I attended Rod Johnson’s keynote a couple of hours back. The keynote itself was informative, offering a pretty good glimpse into where SpringSource sees itself going over the coming year, and I had a chance to chat it up with Thomas Risberg and Colin Sampaleanu just a little bit since we were all sitting at the same table. Recognizing an opportunity when I see one, I asked them when they thought Spring 3 would be coming out and they laughed in a way that suggested that this wasn’t the first time somebody had asked. Right now they’re shooting for late March or thereabouts, though that was just their impression as opposed to a definite statement.

Anyway, here are some highlights from the keynote.

SpringSource in 2008

Rod started the keynote with some SpringSource efforts and accomplishments over 2008. I won’t go into those in detail, but he mentioned several items, including

They’ve clearly been a busy company over the past year, but it may not be entirely clear what they’re up to. (Well, part of it is clear enough–they’re moving into the app server space.) The next part of the keynote explained where SpringSource is going as a company.

SpringSource in 2009

Rod noted that 2008 has been a tough year for the world economy in general, and thus one reasonable prediction is that that’s going to translate into pressure on IT budgets. One development he expects to see is license costs coming under increased scrutiny. Another is that he thinks IT will begin paying more attention to the costs associated with complexity, and will invest more in reducing that complexity.

I know from my own workplace that his ideas here are correct. Even before news broke that everything’s melting down, we were reevaluating our license situation and indeed even in some cases making changes. And one of the themes that our CIO has sounded time and time again is that we need to work to reduce complexity when we can. I suspect that these are common themes anyway, but with the tough economic times it’s pretty easy to believe that one can build a business strategy around this, and that’s what SpringSource is doing.

The SpringSource strategy: help customers control costs by managing and reducing complexity

This was really the theme of the keynote and Rod noted that they’d even changed their tagline to reflect it: “Weapons for the War on Java Complexity.” He explained how the various efforts over 2008 are generally aligned with managing complexity on different fronts. For example:

Continue targeting complexity in development by expanding the Spring Framework in a way that simplifies application development. Rod showed how with each new release of Spring, the SLOC for the pet store application dropped. He highlighted Spring Web MVC, Spring Web Flow and the acquisition of G2One in particular as representing a continued commitment to simplifying application development. Another notable item here includes Spring 2.5-style configuration via annotations.

Spring 3.0 moves the platform further along in this simplifying direction. Some highlights:

  • Spring 3.0 will support EL in XML configuration and in annotations. He didn’t say exactly where this would appear.
  • Spring Web MVC will provide first-class support for RESTful web services. The match is strong (Spring Web MVC already has a @RequestMapping attribute that serves well here), and RESTful remoting is simpler than say SOAP-based web services.
  • With Spring Web MVC, developers should adopt the annotated POJO model as Spring 3.0 will deprecate the Controller hierarchy and 3.1 will probably eliminate it altogether. Again the argument is that this is simpler than XML configuration.
  • Spring Web Flow should be seen not as a niche technology but as a core part of their web framework that potentially applies any time there’s a directed navigation requirement. Examples include wizards, back button, refresh, multiple UIs, and UI reuse.
  • Speaking of their web framework, they’re treating the following four projects as constituting a coherent, layered set: Spring Web MVC (the core), Spring JavaScript and Spring Web Flow (sitting on top of Spring Web MVC), and Spring Faces (sitting on top of the other three). He said that historically Spring hadn’t simplified web development as much as it could have, and their converging the four aforementioned web technologies into a single group is an effort to address this.

Finally (we’re still on the topic of managing complexity in development), Rod suggested that we take a look at @Configurable (which was available in Spring 2.0) and consider it a “secret weapon” against complexity.

The other major way in which SpringSource aims to manage/reduce complexity:

Target complexity not only in development but also in operations: Though it’s by no means unanimous, lots of people feel that Spring has done a pretty nice job of simplifying JEE development. Their idea is now to take that to the data center. Their commercial offerings align with this; for example, the Application Management Suite provides deep diagnostics for Spring-based applications, and the dm Server aims to make release management simpler and more flexible. Besides their commercial offerings, their investment in Covalent Technologies (better access to Apache and Tomcat expertise) represents a desire to strengthen their offering in hosting and operations.

They see Tomcat as being the platform of choice where WAR-based deployments are concerned, but they see server-side OSGi as the wave of the future. Because Tomcat is currently widely deployed (I think Rod said something like 70% of enterprises have deployed Tomcat?), SpringSource wants to be involved there, and that’s why they bought Covalent. But at the same time they are trying to encourage their customers and indeed the industry at large to make the transition to OSGi-based deployment.

And this leads to a couple of announcements he made.

A couple of product announcements

tc Server: The first announcement was that SpringSource will be releasing another server product to complement their current dm Server offering. This one is called tc Server for (you guessed it) Tomcat Server, and the idea is that it’s an enhanced version of Tomcat, one that includes management functionality to make it “ready for the data center.” The AMS product comes with it, and it will provide features such as visibility into Tomcat and app performance stats, deadlock detection, heap and thread dumps, and stuff like that. It will also be possible to manage tc Server WAR deployments through AMS. They’re expecting (if I understood correctly) a GA release in January 2009.

Rod emphasized that the Spring Framework itself would remain server-agnostic, despite the fact that SpringSource is a server vendor.

SpringSource Application Platform Configurator: The second announcement is that SpringSource will be making available a web application called the SpringSource Application Platform Configurator. Again, managing complexity is the driver here. This time they are addressing the complexity associated with managing dependencies between JAR files, eliminating version conflicts, and that sort of thing. The idea is that you go to this app (which they host), and you specify a bunch of parameters such as the app type (web app, Grails, batch, etc.), whether you’re OK with including pre-release software (such as milestone releases) or whether you allow only GAs, what sorts of capabilities you want and where your religious allegiances lie (is it OK to include JSF? is it OK to include Flex?), what hosting provider you’re using (WebSphere, WebLogic, dm Server, etc.), what OS, etc. (By the way, they don’t explicitly ask “where are your religious allegiances,” but Rod noted that they recognize this reality of how software is sometimes chosen and the configurator is designed accordingly.) Then at the end you register (free), get a text dump of the JARs you just chose, and get a dynamically-generated ZIP containing those JARs (and they’re of course mutually consistent so as to avoid versioning conflicts). That’s a cool idea. They don’t know though when this will be available for use; it’s not even in beta yet.

Well, there you have it. If you weren’t at the keynote, now it’s as if you were. :-)

I’ll post more as the conference progresses. Here’s another post on the same keynote.

[Update: Here's a related InfoQ article.]

November 27, 2008

SpringOne Americas 2008

Filed under: SpringOne — Willie Wheeler @ 11:37 pm
Tags:

I’ll be at SpringOne Americas 2008 this week. Check this space for information about the conference as it unfolds.

October 11, 2008

Article on Spring Security 2: Hashing and salting passwords

Filed under: Tutorials — Willie Wheeler @ 11:33 pm
Tags: , , , ,

One of the things that I’ve discovered during the writing of this book is 600 pages sounds a lot bigger than it actually is. In writing about Spring Security 2, John and I have been forced to be pretty selective about the recipes that we include. There just isn’t enough room to cover it all.

One of the casualties was a recipe I wrote about using Spring Security 2 to hash and salt passwords. I’d already written a general article on hashing and salting passwords on my website, but I also wrote one on using Spring Security 2 specifically. But it just didn’t fit into our chapters.

It wasn’t for naught, though. It’s a perfectly good recipe, so I just put it on my website so people can see what kind of information they might expect to find in the book.

Here it is. Hope you enjoy it!

http://wheelersoftware.com/articles/spring-security-hash-salt-passwords.html

October 1, 2008

Some thoughts on the new SpringSource maintenance policy

Filed under: Meta — Willie Wheeler @ 10:38 pm
Tags: , ,

At the risk of getting myself involved in a highly charged political issue, I have some thoughts about the new SpringSource maintenance policy that I wanted to share. Not sure that I know what I’m talking about, but I have no doubt that others will let me know if I’m totally off-base.

Initially I was a little disappointed when I heard the news about the change. I don’t have anything against capitalism, and I think that the Spring developers absolutely ought to benefit financially from all the good work that they’ve been doing over the years. The disappointment was really just a function of my being a bit of a cheapskate: I’m happy to contribute on the forums, contribute JIRA issues, even the occasional code patch, but I suppose I’ve grown too used to being able to download the latest and greatest for free.

But I found out that I misinterpreted the part about “major” releases in an important way, and now I feel a lot better about things.

I thought that SpringSource was saying that the community would be able to download binaries for 3.0, 4.0, 5.0 etc. for free, as well as 3.x (x > 0) releases as long as the 3.x releases were released within the first three months of the 3.0 release.

I’m happy to report that that’s totally wrong.

It turns out that the community will have access to binaries for 3.0, 3.1, 3.2, 3.3, etc., as they appear. The for-pay releases will be the 3.1.x (x > 0) releases that come out three months after the initial 3.1 release. Don’t take my word for it though. It’s right here and here too.

I can definitely live with that. Sure, I’d prefer to download 3.1.5 for free, but it’s not going to kill me to wait for 3.2. I think that there are probably a lot of developers who would feel the same way.

I have to wonder, though, whether SpringSource might do a better job explaining the change. It’s pretty easy to read

After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues.  Subsequent maintenance releases will be available to SpringSource Enterprise customers.  Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software.

and think that you’re going to have to wait a year for an update. I interpret “major version” as meaning Spring 2, Spring 3, etc. Maybe that’s not the way SpringSource thinks of major versions (though that’s news to me), but it doesn’t really matter what SpringSource thinks – what matters is what the Spring community thinks, and I can’t be the only one who read the above passage thinking that we’d have to pay for version 3.3.

My understanding is that this change is about getting enterprises to start paying for Spring while letting smaller shops and individual developers still have access to pretty recent stuff. Enterprises are slower about upgrading versions. So say you’re an enterprise and you built an app against version Spring 3.0.2. It’s more painful for you to upgrade to version 3.1 than it is to just buy the enterprise license and get your 3.0.x upgrades, so you buy the license. On the other hand, smaller organizations are in many cases fine with going from 3.0.2 to 3.1, as are many individual developers (indeed, I think a lot of individual developers eagerly await new releases), so they can still use it for free without too much inconvenience. No doubt some smaller organizations and developers will be inconvenienced though.

If my understanding is correct, I think SpringSource ought to consider explaining it in roughly that way instead of this:

“The maintenance policy provides IT teams responsible for building and running mission-critical production systems with the quality, assurance and peace of mind that comes from reliable, predictable and guaranteed support direct from the source,” said Mark Brewer, vice president of enterprise delivery for SpringSource. “And, the policy will always give the developer community access to the same cutting-edge innovations they have come to expect with Spring.”

When developers read the above, they hear “blah blah blah.” Developers hate that kind of explanation. I assume that since Brewer is VP of enterprise delivery he’s addressing enterprise customers more than he is the community, but (1) it’s important to address the community since you don’t want people defecting from the platform, and (2) there’s a way to present the explanation so that it’s palatable to enterprises. I am myself in corporate IT leadership, and if somebody told me that the enterprise license allows you to get bugfixes without having to upgrade from 3.0.x to 3.1, I would be able to see value in that.

Anyway, I’m glad to discover that the situation is not what I had originally thought, and to my mind SpringSource is striking a reasonable balance between their desire (and right) to build a profitable business around Spring vs. their desire to maintain a supportive developer community. They just need to work on the communication. :-)

September 30, 2008

We’ve been MEAPed – chapters 4 & 5 available

Filed under: Book news — Willie Wheeler @ 9:27 pm
Tags: , , , ,

We’re very excited to announce that we’ve been MEAPed. :-)

MEAP is the Manning Early Access Program. MEAP allows you to buy the book before it’s actually done so you can start getting at the content as it becomes available.

We just released the first pair of chapters: Chapter 4 (User registrations) and Chapter 5 (Authentication). Also the table of contents is online for those who are interested.

MEAP page: http://www.manning.com/wheeler/

Author forum: http://www.manning-sandbox.com/forum.jspa?forumID=503

September 6, 2008

September 5, 2008

Just got the book cover

Filed under: Book news — Willie Wheeler @ 10:49 am
Tags: , ,
Spring in Practice book cover

Fun stuff: Spring in Practice book cover

Manning just sent us the book cover – we love it!  I’m pretty sure we will have a lot more than fifty problems solved (we’re targeting about 600 pages) but I think the text is just sample text for now.

August 31, 2008

About our book

Filed under: Book news — Willie Wheeler @ 5:20 am
Tags: , , ,

In a nutshell: Spring in Practice is an applied book on the Spring Framework. It’s not theoretical, and it’s not a reference manual.

Let’s look at that statement in more detail, since we’d like you to know what you’re buying before you buy it. And maybe we can even pique your interest in what we’re doing.

We assume you already have your reasons for using Spring

While it’s true that we like Spring, we assume that you already have your reasons for using it – maybe you heard it was a good framework and you want to try a few things out, or maybe you’ve just joined a development team where it’s already been decided by the powers that be that you’re going to be using Spring.

Given that assumption, we don’t make much of an effort to “sell” the framework.  We don’t rehash the history, and we don’t explain in much detail what recommends Spring over this this-or-that alternative.  Instead we give you some bare minimum technical background (mostly around practices that we adopt in the book, such as using the “p” namespace or using annotations to accomplish various things) and then launch immediately into the “how-to” materials.

We try to show you not only areas in which Spring excels, but also areas in which Spring doesn’t help you out very much or even areas in which Spring seems to make things more difficult than they ought to be.  With respect to the latter, we believe that such information is extremely practical but not necessarily easy to find.

It’s not a reference manual

In saying that Spring in Practice is an applied book, we mean to distinguish it from reference manuals, which generally take a technology-centric perspective in that they organize around the technologies that make up their topic.  For example, reference manuals on the Spring Framework typically start with a history of the framework, and then go on to explain why Spring represents an improvement over traditional approaches. They then continue with chapters on the IoC container, data access, transactions, web services, Spring Web MVC, Spring Web Flow, Spring Security, testing and so forth.

Those are certainly appropriate reference manual topics, but the problem is that it’s hard for a novice to become productive without first absorbing a lot of background information.  To build a single vertical in a web application, such as a user registration form (including all aspects of the form – web presentation, form validation, form processing and storage, security, web flow if necessary, etc.), you potentially have to read several chapters’ worth of material.  It isn’t necessarily obvious what you can skip (for example, can you skip the chapter on Spring Web Flow? can you skip the section on programmatic validation?), and it isn’t necessarily clear how all the pieces fit together.  The novice must analyze each chapter to understand what is and isn’t relevant, and then must further synthesize the relevant pieces into a coherent solution.

In a certain respect, the novice’s difficulties are exacerbated by the fact that reference manuals of necessity tend to present toy examples.  On the one hand, the simplification is useful because it allows the reader to grasp the technology without getting bogged down in messy problem domain details.  On the other hand, most readers – novices included – are tasked with solving realistic problems, and so there’s a gap between the reader’s task and what the book directly explains.

Reference manuals are optimized for people who already have a reasonable understanding of the technology and who just need to learn or remember how a certain piece works.  As such they serve an important function; certainly all readers, novices again included, will benefit from having a reference manual handy.  But novices relying solely on a reference manual will usually read a lot of material that isn’t directly relevant to what they’re trying to do, and spend lots of time figuring how to integrate the pieces.

We organize around problems rather than around Spring technologies

Spring in Practice takes a completely different approach.  We wanted to contribute something optimized for people who are newer to Spring and who, despite their novice status, are required to solve realistic problems, and quickly.

Except for the first few introductory chapters, the book is organized not around Spring Framework technologies, but instead around problems that you might want or need to solve using Spring. For instance, you won’t find anything in the table of contents that says “Integrating Hibernate and Spring” or “Using Spring Web MVC to do such-and-such;” rather we treat problems that can be stated in the language of application domains.  Some of the problems are highly general in that they show up in multiple application categories; examples include the following:

  • Display a user registration form
  • Store user passwords securely
  • Allow users to select a site theme
  • Use CAPTCHAs to prevent comment spam
  • Create a business process monitor (BPM)

Other problems are more category-specific (but not tied to any particular industry). Again, here are some examples:

  • Marketing: Create HTML e-mail templates for e-mail marketing campaigns
  • Lead generation: Submit leads to a web service
  • E-commerce: Implement a simple shopping cart
  • CRM: Implement contact history

Because we focus on domain problems instead of technologies, we can do a few things that are harder for reference manuals to do:

  • We can treat problems more realistically. Instead of including only those pieces of the problem that scaffold the technical discussion, we can include other concerns that are often neglected in reference-type treatments, including issues around usability, security, search engine friendliness, and so on.  Often the concerns in these non-functional areas give rise to requirements that further drive the technical discussion.  Our hope is that readers – novices and veterans alike – will find this aspect of our book to be of great value.
  • We can focus the solution on those pieces that are directly relevant to the problem. If user registration forms deal with hashes and salts but not ACLs, then you’ll read about hashes and salts and you won’t read about ACLs.
  • We can integrate all aspects of the solution in a single place. You won’t have to “put it all together;” we’ve already done that for you.

Hopefully that gives you a good understanding of the book we’re writing.  If you have thoughts or suggestions please do let us know.

Next Page »

Blog at WordPress.com.