Slashdot Mirror
Spring Dynamic Modules In Action
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 amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
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 amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I used Java for a server side mini app in 2001.
The requirement was "EJB!" we want it in an EJB! Even though it was a dumb stateless object, and I'm pretty sure the people on top did not know when EJBs were appropriate.
Fuck I wanted to kill myself. I probably read the whole internet back to front while procrastinating there.
Things aren't so bad now.
Java?
And I really hoped for an ultimate guide to building spring-loaded mechanical toys and devices in a modular way.
Building complex mechanisms that don't use electricity seems to be a dying art and we could really use some modern reference...
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
The thing that Oracle is trying to kill without realizing it?
As a non-engineer the only thing that would make me buy Spring Dynamic Modules In Action would be if I could flick through it at 24 pages per second. Don't tell me it's not true :(
So this is the Ultimate Reference to something so obscure that even Googling it doesn't help to get any info on it?
Looking at the cover of the book, I might think that this is some kind of book about Russian opera. I mean, really, we're talking modern technology here, and then there's this guy that looks like he belongs in 1892 staring at me with his big cutlass, as if to say "Buy this book, american swine, or your code will remain twisted and unoptimized forever, buwha ha ha ha haaaaaa."
#fuckbeta #iamslashdot #dicemustdie
You know the type:
The author hires someone to review his book, and of course the review will be extremely positive. Like that guy did for his "Second Principia" textbook which was really a pile of trash written by a nomad.
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
... was it written by Coily the Spring Sprite? http://www.youtube.com/watch?v=ngBNklagsHQ
Liberty - Security - Laziness - Pick any two.
I was interested in whatever this was, some kind of new development stuff, then saw it was about Java and lost all interest.
Yo dawg, I haerd you like frameworks.
So I made a framework for your frameworks so you can code while you...learn another framework.
THL phish sticks
OSGi and DI frameworks such as Google Guice are giving Java a new life. Of course 95% of Slashdot is stuck using Perl but thanks for your review (in fact I'm mostly replying here to compensate with the retarded posts). Sprint DM have been standardized in OSGi and renamed "OSGi Blueprint Services" and while I've not used them (because Declarative Services were enough for my needs and I never was a Spring user), I plan on checking them soon. A lot of people are using Spring and this is the way to get them interested in OSGi.
By the way, another great (but free/creative commons) book on OSGi is Neil Bartlett's "OSGi in Practice". I can't recommend it enough. Unfortunately, it's still in draft so some parts are not completed, but I learnt more about OSGi reading this book than any other resource I could find (printed or online), except maybe looking at the frameworks' code directly.
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.
Java is the new COBOL. Get over it.
From the article summary, this is a *500* page book on the topic of using an app framework with a packaging system.
How can that topic take 500 pages? It sounds like it should be a 2 page FAQ? What does a packaging system change so much that it needs 498 more pages?
is competition good, or is duplication of effort bad?
I'm still here. I develop in Java and still hate it enough to not want to correct negative remarks about it.
I've used java a lot in applications with high loads and I have never had this problem. Maybe it is because I avoid frameworks, run each significant application in its own JVM (preferably on its own hardware) and never use J2EE if I can help it? Try it. Spring, Hibernate, OSGi, etc are at best pointless and at worst highly harmful.
I still program in COBOL, you insensitive clod!
You shall see a cow on the roof of a cotton house.
As a Java developer i have to say friends don't let friends use Spring. Anything so branded will
- introduce a bucketload of complexity
- lack sufficient documentation for the latest version, leaving you trawling Internet boards or scrambling to have a Spring consultant or trainer come and visit so you can configure or customise your application
- require you to jump through hoops to implement basic features that are commonly requested but not catered for by default
- change significantly leaving you to rework everything with each major revision, and each major revisiion will fix some bugs and introduce a slew more
- use advanced language and framework features to implement basic things, leaving you in need of an advanced developer where you should be able to use a grad
- never pay off by reducing complexity the way it claims it will
Rolling your own may not be the way to do it in this day and age, but it's preferable to the nightmare that is Spring. You have been warned.
These posts express my own personal views, not those of my employer
Will my module come with a genetically engineered super elephant to wind it?
He may sound like a pompous idiot; he is right.
I happen to be someone who actually likes Spring. A few months ago, I was asked to do a proof of concept project; it was basically a event organizing system with a plug-in architecture.
A little google fu later and I found out Eclipse used OSGi for its plug in systems, Netbeans was going to support OSGi for their plugins, and Spring had an OSGi container solution called Spring DM AND Manning had this book in MEAP. I downloaded the earliest copy, ran through the "Hello World!"s and was on my way.
Then I actually had to implement OSGi. Packages wouldn't load, they would load in the wrong order, jars weren't OSGi aware, etc etc etc. After two weeks of long nights of frustration I gave up. The next morning I wrote a classloader and was up and running in about 2 hours.
To add insult to injury, SpringSource gave Spring DM to the Eclipse foundation and washed their hands of future development.
TL;DR; If you want to use OSGi + Spring DM: Don't, Spring gave DM to Eclipse and OSGi is a shitstorm waiting to rain itself out. Write your own classloader and in two hours and 200 lines of Java you will have 80% of OSGi and 99% of what you care about.
There is nothing wrong with being gay. It's getting caught where the trouble lies.