On 7/26/12 6:57 AM, Jevgeni Kabanov wrote:
>
> Wouldn't it make more sense to accommodate OSGi as an optional extension
> of the spec and just define better interoperation? I'm afraid that
> baking modularity into the Java EE spec will introduce more complexity
> than it's worth for most of the Java EE ecosystem.
The problem with that approach is that OSGi and EE are essentially
competing models. OSGi isn't just modular classloading, it's a a service
and component environment with very extensive restrictions on
interaction and definition. You can't model legacy EE behavior and
packaging on it (e.g. EARs). So you end up with essentially two forms of
every deployment. WAB vs WAR, some kind of EJB bundle, and two types of
classloading models. The reverse is also difficult. The service registry
is not mappable to JNDI, or EE resource injection. In a nutshell, if you
include OSGi "support", unless you redesign EE around OSGi, it's going
to be an island.
IMO a better approach is defining something thinner that is purely
around classloading, and bridges well to the legacy EE approach. We
should make it easy as possible for users to transition to the modular
world.
> This all is very anecdotal. In our survey most folks did not indicate
> that they use OSGi or anything like it
I have similar anecdotal experiences. There is lots of interest around
OSGi (although it seems less than a year ago), but 9/10 times the
developers I hear from are interested just because they want more
isolation and better packaging. They aren't really after everything else
it brings in. I also found a lot of misconceptions. Like that having
OSGi means you can do side-by-side/versioned/rolling deployment in Java
EE. The 1/10 is usually someone that is self-building a container
anyway. Although I fully admit that as an EE vender, I tend to interact
more with those that have at least used or built something on Java EE.
This perception doesn't cover the complete Java market.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat