Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Spring Dynamic Modules In Action

samzenpus posted more than 3 years ago | from the read-all-about-it dept.

Book Reviews 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.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.

cancel ×

63 comments

first post (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#34335634)

the TSA touched my junk liberally.

Thanks For Another (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#34335642)

"Non-commercial" ** plug.

** ( See NPR: National Public Radio - Commercial Radio with donors' "support" ).

Yours In Electrogorsk,
Kilgore Trout.

P.S. : Happy Opt-Out Day [youtube.com] !

I used Java for a server side mini app in 2001. (0)

Anonymous Coward | more than 3 years ago | (#34335644)

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.

Drat! (4, Insightful)

SharpFang (651121) | more than 3 years ago | (#34335718)

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...

Re:Drat! (0)

Anonymous Coward | more than 3 years ago | (#34335862)

Dying but not totally dead. Consider Watchmaking books.
Mechanical watches will remain popular for the foreseeable future as exquisite items (Rolex, Omega, Patek Philippe, Vacheron Constantin *) until the proles take over.

* If you are offended that I included the former two with the latter two, take note in advance that I recognize and appreciate your snobbery.

Re:Drat! (1)

Captain Splendid (673276) | more than 3 years ago | (#34336982)

Doesn't matter. You've already pissed off the Breitling reps, and they're a vicious bunch.

/ex-Breitling rep

Re:Drat! (0)

Anonymous Coward | more than 3 years ago | (#34339236)

... until the proles take over.

Until?!

And if you didn't know, designer watches are very popular with chavs this season, beware of prole drift [wikipedia.org] .

Re:Drat! (0)

Anonymous Coward | more than 3 years ago | (#34336266)

Building complex mechanisms that don't use electricity seems to be a dying art

The way Oracle has been going lately, that may soon apply to Java too.

Re:Drat! (1)

ellenbee (978615) | more than 3 years ago | (#34337412)

thats what i was hoping too :(

So this is about Java? (0)

Anonymous Coward | more than 3 years ago | (#34335746)

The thing that Oracle is trying to kill without realizing it?

Re:So this is about Java? (0)

Anonymous Coward | more than 3 years ago | (#34335948)

Unfortunately they aren't doing it fast enough. The sooner Java is finally thrown out onto the garbage heap of history the better it will be for the rest of us.

And before anyone respond I know, I know. This means that programmers will *gasp* have to actually learn how a computer works when writing code instead of being spoon-fed by bloated abstractions over every single detail. Oh the horrors!

25 glorious full colour seconds (0)

Anonymous Coward | more than 3 years ago | (#34335754)

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 :(

Re:25 glorious full colour seconds (1)

Yvan256 (722131) | more than 3 years ago | (#34335790)

Flicking at 24 pages per second is not enough. Double that to 48 pages per second.

Damn Hollywood for holding on old standards.

Re:25 glorious full colour seconds (1)

Sulphur (1548251) | more than 3 years ago | (#34336682)

Flicking at 24 pages per second is not enough. Double that to 48 pages per second.

Damn Hollywood for holding on old standards.

/quote

Old standards on hold, what a Slinky idea.

The Ultimate Reference?? (0)

Anonymous Coward | more than 3 years ago | (#34335768)

So this is the Ultimate Reference to something so obscure that even Googling it doesn't help to get any info on it?

Re:The Ultimate Reference?? (1)

Cougar Town (1669754) | more than 3 years ago | (#34335832)

http://www.google.ca/search?q=%22spring+dynamic+modules%22 [google.ca]

Very first result (of 646,000) is: http://www.springsource.org/osgi [springsource.org]

Re:The Ultimate Reference?? (1)

us7892 (655683) | more than 3 years ago | (#34336094)

Ok. And I guess this is meaningful...for all you OSGi folks out there...

The Spring Dynamic Modules for OSGi(tm) Service Platforms project makes it easy to build Spring applications that run in an OSGi framework. A Spring application written in this way provides better separation of modules, the ability to dynamically add, remove, and update modules in a running system, the ability to deploy multiple versions of a module simultaneously (and have clients automatically bind to the appropriate one), and a dynamic service model. OSGi is a registered trademark of the OSGi Alliance. Project name is used pending approval from the OSGi Alliance.

Graphic design peeve (2, Funny)

girlintraining (1395911) | more than 3 years ago | (#34335794)

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."

Re:Graphic design peeve (2, Informative)

iluvcapra (782887) | more than 3 years ago | (#34336002)

The Manning technical books always have someone in an elaborate local costume on the cover. Their Ruby on Rails book has a Turkish bey with an elaborate fan hat, for example.

Re:Graphic design peeve (0)

Anonymous Coward | more than 3 years ago | (#34337154)

And it's fucking stupid.

Re:Graphic design peeve (1)

girlintraining (1395911) | more than 3 years ago | (#34337268)

The Manning technical books always have someone in an elaborate local costume on the cover. Their Ruby on Rails book has a Turkish bey with an elaborate fan hat, for example.

That would be almost forgivable if their typography wasn't so atrocious, furthering my belief that the cover designer was a lobotomized flatworm. Look at the typography treatment -- The casual reader might interpret it as "Spring Dynam Module". The designer of this took gestalt theory out back, pissed on it, rolled it through the mud, and then dropped it in the rubbish pile. About the only thing this guy got right was not using Comic Sans Serif as the typeface.

Re:Graphic design peeve (1)

Zancarius (414244) | more than 3 years ago | (#34340060)

About the only thing this guy got right was not using Comic Sans Serif as the typeface.

I hear they're saving that for the second edition.

Re:Graphic design peeve (1)

gandhi_2 (1108023) | more than 3 years ago | (#34336022)

I was expecting a treatise on Prussian cavalry tactics and their use in battles up-to-but-not-including Waterloo. Written in part by Gebhard Leberecht von Blücher (with foreword by Tom Clancy).

Re:Graphic design peeve (1)

tonyfugere (930903) | more than 3 years ago | (#34336626)

In Soviet Russia, Java compiles you!

Is this one of those Paid reviews? (2, Informative)

commodore64_love (1445365) | more than 3 years ago | (#34335818)

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.

Re:Is this one of those Paid reviews? (1, Troll)

Desler (1608317) | more than 3 years ago | (#34336056)

RickJWagner? Yep, it's a shill review.

Re:Is this one of those Paid reviews? (0, Troll)

noidentity (188756) | more than 3 years ago | (#34336760)

No way it could be a paid review, where the summary says absolutely nothing about what the hell Spring Dynamic Modules are. No way.

ignorant paid review (-1, Troll)

MichaelKristopeit211 (1946194) | more than 3 years ago | (#34335902)

yeah, so in the distant future when everyone has built all systems on top of a framework THAT SIT ATOP ANOTHER FRAMEWORK, when developers need to fall back to the universal book; they'll all fall back to the book about the..... second framework? because books on the first framework.... oh right, this is a lie.

slashdot = stagnated

Bah (0)

Anonymous Coward | more than 3 years ago | (#34335906)


I was interested in whatever this was, some kind of new development stuff, then saw it was about Java and lost all interest.

Oblig. (5, Funny)

gandhi_2 (1108023) | more than 3 years ago | (#34336042)

Yo dawg, I haerd you like frameworks.

So I made a framework for your frameworks so you can code while you...learn another framework.

Spring is an overengineered mess!!! (1, Offtopic)

syousef (465911) | more than 3 years ago | (#34339482)

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.

Re:Spring is an overengineered mess!!! (0)

Anonymous Coward | more than 3 years ago | (#34340840)

Agree. I thought it just me that felt that way as all I see is people jumping on frameworks (even when roll your own is simpler/smaller).

Re:Spring is an overengineered mess!!! (0)

Anonymous Coward | more than 3 years ago | (#34341940)

Insightful my ass. Used correctly spring has cut down a ton of code and made things much more flexible for us. How much? 4 years worth of work was thrown away and rebuilt in 5 months!

Re:Spring is an overengineered mess!!! (1)

syousef (465911) | more than 3 years ago | (#34344656)

Insightful my ass. Used correctly spring has cut down a ton of code and made things much more flexible for us. How much? 4 years worth of work was thrown away and rebuilt in 5 months!

Then your old code was crap, and your current requirements are childishly simple.

The frameworks are junk. My latest example was with Spring Security. Try doing something as simple as forcing the user to a change password page when their password expires. Never mind that you have to build your own user model from scratch, forcing change password requires setting up a custom filter to do it properly.

The standard way of doing it - overriding authentication control classes - leaves a user with an expired password able to go to any page by typing in the full URL. Or you can mess with the authentication object and assign a custom role for change password (and no other roles) but then you have to reload the authenticated user with proper roles once they have changed password.

Yet I've seen comments from Ben Alex that though it's a common requirement the current mechanisms are good enough. FUCK THAT. Changing an expired password is a basic requirement.

Re:Spring is an overengineered mess!!! (0)

Anonymous Coward | more than 3 years ago | (#34345194)

Wow, way to use a tiny example of a single project to invalidate an entire constellation of useful projects. They very fact that you are willing to make such hyperbolous statements based on cursory usage calls you out as a shitty engineer.

The hallmark of all Spring framework projects is extensibility. Didn't like their out-of-the-box implementation? Extend a more abstract one. Don't like they way their security framework is implemented? Just use the AOP stuff to do your own.

There is a middle ground between taking an off-the-shelf solution and writing your own shit from scratch every time. You are clearly a huge money pit of a developer for not recognizing this. Enjoy your over budget project.

Why even bother? (-1, Troll)

Anonymous Coward | more than 3 years ago | (#34336412)

Mention Java on Slashdot and all you'll get are the same old retarded tropes that have been the currency here for over a decade. Anyone interested in Java development has long ago left slashdot for a community that doesn't keep their heads firmly implanted up their asses.

Re:Why even bother? (2, Interesting)

Nadaka (224565) | more than 3 years ago | (#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? (3, Insightful)

Desler (1608317) | more than 3 years ago | (#34336622)

Java is the new COBOL. Get over it.

Re:Why even bother? (2, Insightful)

Kyont (145761) | more than 3 years ago | (#34337160)

I still program in COBOL, you insensitive clod!

Re:Why even bother? (1, Interesting)

Anonymous Coward | more than 3 years ago | (#34336852)

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

OSGi is great (3, Informative)

A.K.A_Magnet (860822) | more than 3 years ago | (#34336422)

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.

Re:OSGi is great (2, Interesting)

durdur (252098) | more than 3 years ago | (#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 (2, Interesting)

A.K.A_Magnet (860822) | more than 3 years ago | (#34338356)

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...)

Re:OSGi is great (1)

durdur (252098) | more than 3 years ago | (#34338946)

Just ask if your benefits exceed the cost. If you are spending time fixing your manifests, tracking down why dynamic class loading is broken, integrating legacy code, or the like, then you're not adding features or value to your end software product. You are just burning cycles that your framework and app server are making you burn.

Re:OSGi is great (1)

A.K.A_Magnet (860822) | more than 3 years ago | (#34341356)

We have had different experiences. When I started using it, I definitely struggled many times with OSGi (or more like setting up some containers for my specific needs), but not any more than I did with any other 'advanced' framework (including JEE). But on the (full-OSGi) project I'm working on, OSGi is not costing us anything. We're doing agile development (Scrum) and we're very much feature driven. If we were wasting too much time fighting against OSGi, I'd totally agree with you. But we're not. And our team has members that are just "Java developers" that don't know the specifics of OSGi that much, but we integrated OSGi best practices into our coding guide and it's working well.

In fact, I think OSGi is costing us *less*, because for an application like the one we're developing that requires modularity, we would have ended up writing our own inferior, more expensive and most of all not standardized "plugin system". In fact, in my company there are many different kinds of modules systems that were previously developed and we can't easily exchange modules between those systems (developed for different projects, clients, etc). With OSGi, we can start to share more than just classes or jars. Good bundles do half the integration work.

Anyway I'm not trying to convince you. OSGi is no silver bullet, and it can be difficult in practice when you're plugging into legacy. But when it's working, then it's really nice. My non-OSGi inclined co-workers even grew to like it.

Re:OSGi is great (1)

butlerm (3112) | more than 3 years ago | (#34344796)

Of course 95% of Slashdot is stuck using Perl

Make up things a lot? The number of new web applications of any significance written using Perl has probably been minimal to non-existent for about a decade now.

Re:OSGi is great (1)

A.K.A_Magnet (860822) | more than 3 years ago | (#34344848)

For the record. [wikipedia.org]

What am I missing? (3, Insightful)

eison (56778) | more than 3 years ago | (#34336632)

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?

Re:What am I missing? (2, Insightful)

RichMan (8097) | more than 3 years ago | (#34336718)

And if the app framework and packaging system really need 500 pages to describe how to use do you really want to use them?

Re:What am I missing? (2, Insightful)

PJ6 (1151747) | more than 3 years ago | (#34336962)

It has been my experience that frameworks such as these frequently make trivial exercises nontrivial, for the sake of implementing an idea or serving a need in a way that most would call ill-conceived, bloated, far out of the realm of sanity. How much information in this book would anyone call timeless truth? How much is instead incidental complexity, gotchas, meaningless detail, and syntax of usage? In software, beware the pursuit of an academic objective for its own sake without any regard to practicality or usability.

A simple design that can achieve great complexity, that's beauty; a greatly complex design that can achieve only simple behavior, that's humor.

Re:What am I missing? (3, Funny)

abigor (540274) | more than 3 years ago | (#34337916)

No offense, but you sound like a pompous idiot.

Re:What am I missing? (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34338676)

No offense, but you sound like somebody with no real-world experience.

Re:What am I missing? (0)

Anonymous Coward | more than 3 years ago | (#34340592)

Not really.
The post referred was all true, on topic and concise. But it still managed to express that in an unnecessarily pompous form. Opinions expressed like this tend to be disregarded simply because the form makes them sound untrustworthy, "merit be damned that guy talks like a prick, I don't want to side with him".

Re:What am I missing? (1)

PJ6 (1151747) | more than 3 years ago | (#34371100)

You're right, wrong form. Better said with limericks.

Re:What am I missing? (0)

Anonymous Coward | more than 3 years ago | (#34338748)

Really? I'd say he nailed it.

That's just the sound (0)

Anonymous Coward | more than 3 years ago | (#34340112)

He may sound like a pompous idiot; he is right.

Re:What am I missing? (1)

geekoid (135745) | more than 3 years ago | (#34337280)

Presumable it goes into theory and value of the concept, not just a how to get it running.
I haven' reed it, so for all I know it has 60 blank pages to write down what to wish for.

Better solution (0)

Anonymous Coward | more than 3 years ago | (#34337030)

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.

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.

Re:Better solution (3, Insightful)

abigor (540274) | more than 3 years ago | (#34337926)

Meanwhile, back in the real world, Spring, Hibernate, etc. are awesome and heavily used to prevent the kind of wheel reinvention you no doubt excel at.

Re:Better solution (2, Insightful)

Lunix Nutcase (1092239) | more than 3 years ago | (#34339506)

Yes, so awesome that you need another framework on top of them just to manage all the dependencies. Brilliant!!

Windup Girl (0)

Anonymous Coward | more than 3 years ago | (#34339500)

Will my module come with a genetically engineered super elephant to wind it?

Spring DM is dead and OSGi is overkill (2, Insightful)

secondsun (195377) | more than 3 years ago | (#34344436)

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.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...