@Jason
I'd be happy to even leave the class loading out of it. Maybe just conceptual isolation with service lookup that could bridge to OSGi?
--
Founder & CEO of ZeroTurnaround
@ekabanov | Skype: ekabanov | http://www.linkedin.com/in/ekabanov
On Thursday, 26 July 2012 at 17:58, Jason T. Greene wrote:
> 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
>
>