Become a fan of Slashdot on Facebook


Forgot your password?

Spring Dynamic Modules In Action 63

RickJWagner writes "Every once in a while a technical book comes out that so exhaustively covers a topic that it becomes the definitive word on the topic. These books are the end-all reference, the final authority, the singular go-to reference that every practitioner falls back to in their hour of need. This book review covers one such book, the newly released Spring Dynamic Modules in Action from Manning." Read below for the rest of Rick's review.
Spring Dynamic Modules In Action
author Arnaud Cogoluegnes, Thierry Templier, Andy Piper
pages 548
publisher Manning Publications
rating 9/10
reviewer Rick J Wagner
ISBN 1935182307
summary Presents the fundamental concepts of OSGi-based apps and maps them to the familiar ideas of the Spring framework.
First, a quick word about OSGi. OSGi is a specification meant to make Java more "modular." In practice, this means it is an attempt to solve the age-old problem of "jar hell", including all the class loading issues that go with it. (Users of JEE application servers know what I'm talking about here.) OSGi lets you specify every external library your component needs, to the version. So if you need FooLib v1.2.3, and the application beside yours needs FooLib v10.9.8, that's not a problem at all-- both applications can happily run in the same OSGi container, at the same time.

Should you care about OSGi? The answer is maybe. It's without question a big deal to the makers of Java application containers-- everybody from JBoss to Mule has an opinion on OSGi, and many vendors are busy baking it into their infrastructure. What will differ to you, the user of the container, is how the container developers decided to make OSGi available to their users. This book is about how Spring went about it, and what you need to do to use Spring and OSGi together.

Spring DM (short for "Dynamic Modules") is a framework that enables you to use the popular Spring framework with OSGi. Spring, of course, comes with a multitude of components for solving all kinds of enterprise application needs. So this book is all about using Spring with OSGi.

It's a big book, over 500 pages, written by 3 authors. In those 500 pages you get lots of valuable content:
- An introduction to OSGi and an explanation of its purpose
- Explanation of how Spring can be used within an OSGi container, review of the currently available containers
- Details about how Spring DM works, and the parts you need to understand
- Details about OSGi services, and how they relate to Spring DM
- In depth best practices for data access, enterprise Java projects, and web applications (includes specific advice for popular web application frameworks)
- Testing practices
- Extended uses of OSGi, including likely future direction

A big part of what makes this book valuable are the many pieces of advice from the authors as they explain best practices for using various tools. So you want to use Eclipse, Ant or Maven? No problem, these are all covered. About to use MyFaces, Wicket, or DWR? All covered. Are you a Tomcat user or Jetty? Check and check. I'm sure you get the picture-- if you use these tools, the path ahead of you is already blazed and you can avoid some headaches by leveraging the author's experience.

Make no mistake about it, there will be some headaches ahead of you. Seldom is an application written today that doesn't use an external framework or library of some sort. Using these pre-packaged bits of functionality (and we need to be thankful for them!) might mean 're-packaging', if the library isn't offered as an OSGi bundle. This re-packaging means pealing apart some .jar files and editing the manifest files inside-- yuck! Luckily, this book offers you two things to help you with this task: tooling and advice. Tooling comes in handy because it can automate a lot of the manual, error-prone drudgery that goes along with such a task. Advice is even more valuable-- these authors have already worked done the hard work and have written down what you need to do to make your efforts successful.

So who is this book appropriate for? I'd say anyone who is going to use Spring DM. If you're convinced this is the right framework for your needs, you need a copy of this book. If you're not sure, or if you're just a casual reader wanting to know more about OSGi-- then I'd say you should look through the book first before you buy it. You might like it, or you might not because a lot of the book is all about hands-on use of Spring DM and the little tricks you need to make it work right the first time. But if you're just interested in an overview of the technology, this book might be too detail-oriented and not enough high-level for your tastes.

If you use Spring DM, you need to buy a copy of this book. It's going to be the definitive resource on the topic for a long time.

You can purchase Spring Dynamic Modules In Action from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.


This discussion has been archived. No new comments can be posted.

Spring Dynamic Modules In Action

Comments Filter:
  • Re:Why even bother? (Score:3, Interesting)

    by Nadaka ( 224565 ) on Wednesday November 24, 2010 @04:57PM (#34336586)

    I do java development and I am starting to feel grognardly rage at things like annotations, framework changes between struts 1 / struts 2 and the proposed features for 1.7 and 1.8.

  • Re:Why even bother? (Score:1, Interesting)

    by Anonymous Coward on Wednesday November 24, 2010 @05:22PM (#34336852)

    I'm still here. I develop in Java and still hate it enough to not want to correct negative remarks about it.

  • Re:OSGi is great (Score:3, Interesting)

    by durdur ( 252098 ) on Wednesday November 24, 2010 @07:51PM (#34338160)

    Quite the contrary, IMO. After having had considerable recent experience with it, and before that, having had extensive knowledge of older enterprise Java technologies (EJB, Servlets), I think the benefits of OSGi are mostly illusory, while the costs are real and substantial. There are theoretical benefits in terms of flexibility and modularity, which are good things, but these benefits can be realized in other and simpler ways. The costs come in the form of complexity - especially dependency management and class loading headaches - as well as bugs and immaturity in the frameworks and tools, and the fact that a good chunk of existing Java code wasn't planned to be used in OSGi environment and so doesn't support it well.

  • Re:OSGi is great (Score:3, Interesting)

    by A.K.A_Magnet ( 860822 ) on Wednesday November 24, 2010 @08:16PM (#34338356) Homepage
    I do agree there's a problem with legacy Java code that makes use of features that are hardly reconcilable with OSGi. I think most of those libs that don't get along well with OSGi are doing something wrong, but sometimes they're trying to be too smart ;). Incompatible legacy code is pretty much the only reason one should run classloader issues, because frankly I find OSGi makes things easier here (especially if you generate your manifest with bnd, which avoids most of the mistakes). One way or another, I agree we most often have no choice but to use those libraries (legacy or not). We can't know "before" if the third party Jars we're using will get along well. At work, I was lucky for one huge software stack (which included C++ parts) and had basically no trouble (beside the initial pain to help my co-workers going) porting the whole thing to OSGi. Another stack is still not ported because of dependencies on those bad JARs (packages split across Jars, having API that's not theirs, etc).

    A lot of Java projects are now OSGi-ready though. It's really taking off. I also agree that the tooling is not perfect yet, but it's improving. If you are using Eclipse, I recommend using BndTools rather than PDE. It's a lot less stressful.

    In general, I believe the constraints clean programming in OSGi put on the developer lead to better design/architecture, cleaner separation of concerns, even if you're going to dump OSGi after that. But usually when you reach that point you usually get to like it: like coffee, it tastes bad at first. Unlike coffee though, there are too many ways to do OSGi wrong, because there's a lot of contradicting approaches around there. The common wisdom is to avoid the OSGi API when we can (it can be avoided if we don't have to register services dynamically or do framework-level stuff), but after that all hell breaks lose when it comes to testing, building, what editor to use etc. Too many dissenting voices make it long to find a non-intrusive way, but it exists! :)

    Damn, I sound like a commercial, but really OSGi and DI are the only thing that made me enjoy Java. I disliked it before. Also, OSGi is a nice way to do mix polyglot JVM components and that's the "next big thing" (which is not novel at all, but all this has happened before, and will happen again...)

"Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." -- Howard Aiken