Yea, I look at the OSGi move as an overall good thing.
And I look at it from 2 points of view.
1) The GF wanted a more modular implementation because it gives them more flexibility. For example, it's now easier, though not necessarily trivial, to replace components of the implementation. But, also, importantly for JEE 6, it will be easier to REMOVE items. Since JEE 6 will have different profiles, yanking stuff out becomes important. So, then, if you're going to "modularize" your application, then, why not OSGi?
but also, 2), in a similar vein to 1, you can look at it as a mechanism of futureproofing the application server. The whole architecture will ideally be more nimble, and, in fact, OSGi will get new, different "refactoring" opportunities to the developers.
In truth, OSGi is a packaging model, right? And once in that model, new opportunities can appear, especially opportunities that we can't quite see right now. For example, in the beginning, they weren't using OSGi, they had a different model. But apparently it wasn't a terrible time synch to port over to OSGi (at one time they supported both, but I don't know the status of that now).
So, yea, it's hard to say "Wow! GFv3 is on OSGi! Umm..now what?"
From a JEE point of view, it's as meaningless as JBosses MicroKernal Architecture. Like you care, as an implementor of JEE applications. You just want the thing to work and perform.
The Spring Application Platform is OSGi for the sake of OSGi. It's for those who want to write straight on top of OSGi. But, frankly, as nice as OSGi is, I think it's a bit premature to be bailing on JEE, or even "raw" Spring, for something like OSGi for mainstream, back office applications. It's simply not mature enough yet, and really doesn't offer anything save nice sticker you can put in your car window. "Ooh, look I use OSGi!".
Somehow I don't see it being to onerous to convert a Stateless SessionBean to an OSGi module at some point in the future should you ever need to port. And if the GF team manages to come up with, say, some "automagic" way of exposing generic OSGi modules through, say, a dynamic JCA proxy "thing", then...huzzah...mix and match.
Let someone else bleed on the edge, I'd rather get work done. JEE is at the stage now where we can quit mucking with it and second guessing and fighting the platform, and instead we can just Use It flat out without a lot of teeth gnashing.
I had a colleague just yesterday change database tables, add some EJB code, and add new logic to the Web Tier using little more than a few prompts over AIM -- he can't even spell EJB, and is so new to Java he was fighting the "classname == filename" issue all first timers have.
When someone with that little familiarity, and little experience on the platform (AND the language) can actually enhance and improve the existing code base without a bunch of drama, considering all that is provided (ORM, Transactions, container security, etc. etc), that's a good testament to the usability of the platform, IMHO.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=294459