Hear hear. What's happening?

+1

Hey,

this is definitely a big issue for some (us ;-) regarding mid-term strategies.

Especially, what does " withdraw from this technology on all levels" aim at? "Only" at the OSGi support in WIldfly? Will you drop development of JBoss OSGi in general and only use the implementation of others? How is this related to JBoss Fuse? Does one have to decide to choose OSGi OR JEE instead of taking the best of the two worlds?

And what are the reasons? Shifting ressources to other projects and stop OSGi support for the time being? Will JBoss/Red Hat get back to OSGi and integrating OSGi and JEE services?

Questions over questions... :-)

Any insight would be highly appreciated!

Best regards

Oliver

Can an official statment be made ?  A blog entry covering the decision ?  also covering how as a business information with the exact opposite rhetoric has been made public over the past months.

  It is usual to make this public statement first (explaining a 180degree reversal on previous rhetoric), then in the coming weeks the JIRA entries appear.  This helps reduce PR.

Is this decision permanent ?  Who has been involved in the process ?  Who had the final say ?

Does this affect Wildfly ?  EAP ?  JBoss AS ?  Existing releases that have OSGi ?

Is this due to technical complexity ?  What are the technical sticking points ?

Is this due to lack of man power ?

Is this due to JBoss not seeing OSGi as a viable technology in the EE space ?  What collection of technolgies should be looked at to replace it ?

Can the "OSGi Roadmap 2013" be updated to reflect this update.

From my point of view it seems a great shame as it did appear that healthy progress was being made in all areas to bat away each point necessary for Wildfly8 to claim usable support.

At this time, it has been decided to remove OSGi support from WildFly for various reasons.  OSGi support will continue within our SOA platform.  I personally do not view OSGi as a viable technology but on the other hand it is possible that the winds may shift and that we may revisit this decision some day.  Note that since we have a flexible low-level core in WildFly, the choice of specifications to support do not carry down into any kind of basic architectural lock-in so we're never really "too far" from supporting any given container specification or component model, so to me this isn't a terribly drastic choice, just a pragmatic one based on the current known factors.

Thanks a lot for your feedback, David. I appreciate it!

Can I ask you for your role in the JBoss/Red Hat eco system?

Isn't it, that OSGi will only be supported in the JBoss Fuse while Red Hat's JBoss AS backed SOA platform will not support OSGi but SCA? So, no OSGi and JEE components living side by side in one runtime environment. Especially with one Red Hat being co-chair of the OSGi Enterprise Group that

just feels kind of strange.

So if you would like to choose OSGi as your component model you would not get the big fat integration solution with business process orchestration, service governance and all that, 'cause Red Hat's SOA-P will "only" support JEE and SCA. Up until now the roadmap included OSGi in the EAP and therefore SOA-P.

For some of us that's quite some drastic choice. ;-)

Best regards

Oliver

We have monitored customer demand on OSGi in the context of our Enterprise Application Platform closely. The reality is, that the demand we are seeing does not justify to continue the OSGi integration effort at product level.

Instead, it has been decided to move the OSGi subsystem to the JBOSGi umbrella and keep it running as a community effort. We will have regular JBOSGi releases that follow the WildFly release cycle.

It seems that nothing much changes

• OSGi continues to run in WildFly with good JavaEE integration
• Everybody is invited & welcome to contribute

Thomas Diesler wrote:

 

it has been decided to move the OSGi subsystem to the JBOSGi umbrella and keep it running as a community effort. We will have regular JBOSGi releases that follow the WildFly release cycle.

[..]

It seems that nothing much changes

Forgive me, but...

I don't understand the claim that nothing much changes when the bugs that were open for Wildfly/JBoss OSGi were WONTFIXed (example, example, example...). If no bugs related to integration will be fixed that means it's basically not maintained or supported anymore. That's a big thing. That means it's not a viable choice anymore.

I don't see how we could use or recommend a product or a technology that doesn't get its issues fixed.

The issues have been moved to jbosgi. Like with any other open source project you are invited and welcome to contribute and work with me to improve on what we have already.

You can also vote on a particular issue to raise the level of user interest.

Perhaps you can understand that JBoss employes also schedule their resources according to customer demand. At the end of the day, the fine folks that pay for our products make it possible for us to work on the projects.

In case you have spare resources, please let me know on what particular issue you'd like to work on - I'd be happy to support you.

Hi Thomas,

thank you very much for your detailed information and for making the decision more transparent for us!

Please don't get us wrong in that we are just some greedy folks that only want as much as they can get, for free, but not wanting to get involved.

We just needed and will continue to need your / Red Hat's input on your mid-term strategy, so that we can decide wether it matches our own strategy or not.

Reading that there will  be continuing support for OSGi in Wildfly really is positive news.

I understand that there will be no commercial support for OSGi in the EAP product, i.e. if anybody wants to use OSGi and JEE side by side in "one container" they can install the JBoss OSGi modules in Wildfly/EAP but that won't be covered by some subscription/commercial support, correct?

At my company we were thinking about probably switching to the commercial JBoss platform. The decision to remove OSGi support from the EAP/SOA-P would eliminate these products as a viable choice for us.

So the commercial option for my company would be JBoss Fuse, right?

The JBoss OSGi site states that it will provide the OSGi R5 framework in Wildfly. Does that include the core and the enterprise part? I assume "yes", since Wildfly already (although for a different component model) provides the enterprise services needed. But any clarification on this would be splendid. 

That brings me to another question... ;-)

If JBoss Fuse will be Red Hats commercial enterprise OSGi product, will the OSGi R5 support in future JBoss Fuse releases be based on JBoss OSGi? If the integration in Wildfly would be as JBoss modules, what would the integration in Karaf look like? Or will JBoss Fuse not use JBoss OSGi but, I don't know, let's say plain Apache Aries? The relationship between JBoss Fuse and JBoss OSGi is just not clear to me. It would be great if you could eliminate some question marks in my head.

Our company has contributed and will continue to contribute to open source projects where we can. We are aware of the colaborative nature of the whole open source scene, that it should be at best giving and taking on an equal level, and we really appreciate the great work that all you folks have acomplished and are still acomplishing!

Best regards

Oliver

Oliver,

I share your fustrations, we have spend the best part of a year migrating a large enterprise application to JEE6 based on OSGi deployment model. Redhat has been promising OSGi for 2 years at all their conferences, and in their road map presentations. Now finally EAP 6 has it, but when raising a support call to try and resolve issues, we got the response "Oh, its only a tech preview, not for production!". So we watched all the new OSGi work in wildfly thinking that it was moving forward and would finally surface in EAP7 in maybe 6 months from now...But after seeing this, and from the feedback we got from several product and development leads at the 2013 Redhat Summit in Boston, it seems that we have a choice... JEE6 (with JBoss EAP) or OSGi (With JBoss Fuse)...Seems like RedHat have no plans to provide a supported JEE/OSGi platform for their customers to use...And this thread finally re-enforced this point.

After a being a JBoss customer/partner for over 9 years, I'm now having to look at alternate options that can address our future business stragegy...

If you look at the OSGi deployment strategy like Fuse Fabric has, and the power of the JEE6/7 platform, I can't believe they see there is no market for this...

Luckly Oracle/Sun, IBM, Apache and others are not this short sighted, so we still have choices...But not ones we want to make....

Regards,

PaulE

Here are some advantages of OSGi + JavaEE from IBM, I guess Red Hat look at OSGi differently.

The Liberty profile server and Liberty profile developer tools help you to develop

and deploy modular OSGi applications quickly. The advantages of OSGi are

included in the following list:

• Reduces complexity through modular design.
• Integrates with standard JavaEE technologies such as Servlets.
• Promotes service oriented design.
• Composes isolated enterprise applications using multiple versioned bundles with dynamic life cycles.
• Provides careful dependency and version management.
• Offers declarative assembly of components.
• Allows sharing modules through a bundle repository that can host common and versioned bundles.
• Allows access to external bundle repositories.
• Allows administrative updates to deployed applications at a bundle level.

This is an interesting report on "The Great Java Application Server Debate":

http://zeroturnaround.com/rebellabs/the-great-java-application-server-debate-with-tomcat-jboss-glassfish-jetty-and-liberty-profile/7/#!/

   JBoss

     JBoss AS7 is fully EE6 compatible out of the box, we mean Full Profile: EJB, CDI, JPA, JSF, Jax-RS, Bean validation etc. It supports OSGi 4.2, 4.3 is in the works.

     From an Open Source compatibility point of view, JBoss 7 is a fully Java EE compatible. Not much can be said here: JAXB, EJB, CDI, anything you throw on it will be handled gracefully.

     At the same time it is compliant with OSGi version 4.2 and allows you to take the best of both worlds.

I guess they won't be writing that for WildFly...

> if anybody wants to use OSGi and JEE side by side in "one container" they can install the JBoss OSGi modules in Wildfly/EAP but that won't be covered by some subscription/commercial support, correct?

Yes

The decision to remove OSGi support from the EAP/SOA-P would eliminate these products as a viable choice for us.

Desissions like this are driven by customer demand (i.e. if there is demand there will be support)

So the commercial option for my company would be JBoss Fuse, right?

From the OSGi perspective, yes.

The JBoss OSGi site states that it will provide the OSGi R5 framework in Wildfly. Does that include the core and the enterprise part? I assume "yes", since Wildfly already (although for a different component model) provides the enterprise services needed. But any clarification on this would be splendid.

Wildfly contains an R5 compliant core framework. There are also implementations of Enterprise OSGi specs at various levels of completeness. The way I'd like to handle progress here is through first messuring demand in jira (i.e. please vote on issues) and then work with the people who have the demand.

... will the OSGi R5 support in future JBoss Fuse releases be based on JBoss OSGi?

This will also be driven by (Fuse) customer demand. Currently they are happy to run on Felix, which is not R5 compliant AFAIK. Some of the R5 Enterprise functionality would not run (i.e. Enterprise Application Bundles)

The relationship between JBoss Fuse and JBoss OSGi is just not clear to me.

Currently there is none. This may change over time due to a general consolidation effort. Fuse also targets other container (i.e. Tomcat) this functionality will be preserved.

we really appreciate the great work that all you folks have acomplished

Merci