[logoff]

I read this post today and I'm surprised. I reported some issues to JBoss AS in different versions (7.1.x, 7.2 and even 8.x). I was waiting during months (or more) to get OSGi really integrated and more concisely, Apache Karaf integrated in JBoss AS. And now I read this post... I know the community will continue developing JBoss OSGi project, but it would be not the same being developed outside of new JBoss AS/Wildfly release cycle.

The problem, as other users expose, is that Red Hat was promising during yers the real OSGi integration in JBoss AS, and now many users realize that it is not true, it is a lie.

I'm very disappointed with these decisions. We are waiting for the new release 8 during months to integrate our ServiceMix/Fuse application, OpenNaaS, into JBoss AS/Wildfly. Now we can forget this kind of integration .

Bad news from Red Hat.

[thomas.diesler]

Julio,

could you perhaps share with us your motivation to integrate with WildFly? Is this because of the JavaEE/OSGi integration, domain management, configuration, anything else? JBoss continues to offer an OSGi based product stack with JBoss Fuse, which comes with Fuse Fabric + Karaf.

You have probabaly evalutate a number of platform choices for OpenNaaS, why did you choose WildFly?

[logoff]

Hi Thomas,

thank you for your interest and the answer. He developed OpenNaaS as a set of OSGi features/bundles. We package it as a complete solution using a Fuse/ServiceMix platform. It works well. we want to be able to distribute it in a platform-independent way. Our first approach is being able to install OpenNaaS core as an OSGi feature in any Fuse/ServiceMix platform using Karaf. It is possible now more or less. Moreover we had considered offering the possibility of installing OpenNaaS as OSGi features in any Karaf instance. This option is the most flexible one, and allows using any platform, including JBoss AS/Wildfly with Karaf.

All these considerations provide the ability to install OpenNaaS in almost any environment and integrate any tool as an extension of OpenNaaS.

In March, I tried installing OpenNaaS in JBoss AS (7.1, 7.2 not final, 7.2.Final, and beta GitHub 8.x versions), but the modular build was not working well and I experienced many problems. Now I'm reading that the OSGi integration is suspended. I have not tested yet the same as in March with current versions, but one day I will try.

Moreover, we have decided to use pure Apache ServiceMix platform, because we can not understand the way Red Hat is managing Fuse. Where can I access the old download links? and the Maven artifacts? Red Hat is offering a free 30-day trial of an open source project? What?!?

By now, we discarded using JBoss AS/Wildlfy as a platform alternative for OpenNaaS. We were waiting for OSGi news, now we have them.

[thomas.diesler]

If I read this correctly, you don't have a reason to run OpenNaaS on WildFly. If we deploy Karaf on WildFly we'd create a large functional overlap and an equally large set of disconnects in terms of management and configuration. What you see through Karaf (CLI) you don't see through the domain management (CLI) and vise versa.

we have decided to use pure Apache ServiceMix platform, because we can not understand the way Red Hat is managing Fuse

Ok, let me find out about this.

[logoff]

First of all, thank you for your interest. Your thoughts are helping us.

I agree with you, Karaf is overlapping some JBoss AS functionalities. The problem is the way OSGi bundles are deployed, and the ability of having Karaf features (logical aggregations of bundles). OpenNaaS is composed by a big set of OSGi bundles with a dependency tree of more bundles and it is not easy to deploy them. Features and the way Karaf resolve dependencies are a big help to achieve OpenNaaS deployment without problems. Maybe there are more ways to achieve this deployment, but we have not found it.

The ability of OpenNaaS to be deployable in JBoss AS/Wildfly give us the possibility to get deployed in any context or existing scenario in an easy way. When we discovered that Karaf could be available in any JBoss AS instance, we became very happy. But now we are upset, because it will be not as easy as we expected.

Anyway, we will continue trying to find ways to adapt OpenNaaS to any scenario.

[dastraub]

Hi Julio

JBoss Fuse goes here one step further, additionally to karaf features you can deploy so called FAB's (Fuse Application Bundle).

You could deploy only one jar/bundle with a (valid) pom and Fuse resolves and loads all required bundles from a maven repo.

Maybe this is a option.

Btw. we're now a little bit off topic in this discussion   - but it's interesting.

[ampie]

Thomas, excellent job thus far! Ditto to Ales and the Weld-OSGI team. It is a shame the vision we all shared with you had to be placed on the back-burner like this.

David, there is a problem if yours is indeed the perception of the technical influencers inside Redhat. RedHat does play a prominent role in the standards processes even around OSGI, especially CDI and OSGI. And the Redhat supporters are looking at Redhat to follow through. I have just completed a relatively successful POC integrating Weld-OSGI and JBoss-OSGI where we solved a very pertinent real world problem for a huge consumer of Redhat technologies in the banking industry. Imagine my shock when upgrading to WildFly 8 Alpha 3 to find JBoss-OSGI missing/optional, and the reasons for it. Ironically, the choices for the POC were: expand the existing use of SpringFramework or port it to Weld-OSGI and JBoss-OSGI. Apparently I made the wrong decision.

There is no way I can, with a clear conscience continue with the Redhat-centric solution. Pragmatic decision or not, the perception ulitimately is that Redhat is not committed to/does not buy into its own OSGI implementation. Due to my personal investment in Redhat technologies in my career, I've always tried to support Redhat's ideas and directions when facing customers. But this unfortunate situation  leaves me no choice now but exploring the alternatives, and none of them involve Redhat technologies. For my customer, this could very well start a trend of reducing their  reliance on Redhat technologies, especially after the recent  JBoss 7.2.Final naming debacle.

The risk now is that Redhat's participation in the OSGI standardization proceses could be perceived as being a bit obstructionist. You have no customer interest, you have no internal vision for OSGI. What are you doing there?

Just my 2 cents.

[eagleigor]

Wow! Excellent point Ampie! Nicely put!

Red Hat failed to deliver on the promise to bring full OSGi support to JBoss (WildFly).

I think a lot of people will have to make a difficult choice now - do I stick to JBoss or find another alternative after spent my R&D money on JBoss + OSGi POCs.

[uliromahn]

Thomas et. al. @ JBoss/Redhat!

Thomas wrote: "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."

IMHO, something just doesn't add up here!

My company has been very interested in the promised unification of JEE and OSGi, but when we inquired the official channels of Redhat, the response was: "Only technology preview and not for production use - please wait until EAP 6.1". And then there came EAP 6.1 and ... nothing but the same message. Well, OSGi was not even declared as "technology preview" anymore and was removed completely from the standard profile.

However, there appears to be a HUGE disconnect: If there is no demand, then we should not invest (actually a very wise commercial decision). However if the "official channels" within Redhat actively and strongly discourage the use of a potential future feature, then you shouldn't be surprised if that also "kills" all demand for the feature.

Great job, Thomas et. al. from a technology perspective. Really lousy job from a marketing and product management perspective!

RIP JBoss/Wildfly + OSGi!

[gunterze]

Thomas,

It's a pitty!

I start using JBoss AS  for my open source implementation (dcm4che) of a standard compliant medical imaging archive application 11 years ago.

When the small PACS company I was working for was bought by one of the big players in the global PACS market 8 years ago, they decided to build their future PACS products on dcm4che and canceled their investigations in using WebSphere.

I always had the feeling, that J2EE (now JavaEE) does not fit too well with the requirements building a PACS archive application, which has to handle inbound and outbound non-http connections and streaming of large objects between sockets and filesystems, which particularly conflicts with the restrictions for EJBs according I/O and thread management. So I used EJBs just for DB access, and used JBoss AS 4.x proprietary SARs and JMX XMBeans for modularisation of the implementation.

Recently we started evaluating OSGi Enterprise, and so far my feeling is, that it provides was I am looking for: JTA/JPA integration, JMS integration by JNDI,  Http Servlet/Web Application integration (beside a Web GUI, the archive also provides SOAP and Restful Http Services) and with Blueprint a standardized IoC container - without any I/O or thread management restrictions, and still having the possibiliy to use EJBs, if there is a good reason for.

We played arround with jboss-osgi-2.1.0 and got the impression, that there is still (may be only little) work to do, to get it ready for production use. E.g. WAB's only get registered in undertow, if they are deployed after server start, but not on restart or if pre-installed under wildfly/bundles and specified as capability. Simular for JPA bundles, which only get exported as OSGi Service if deployed after server start. But more about the (small) bugs we found, we are worried about the silence in this forum and in the JBoss OSGi issue tracker, and in the decreasing amount of commits to the josgi source at github during last months. Did with the decision of Red Hat, to do not include OSGi support in EAP really "nothing much changes" ? Or is jboss-osgi rather dead and we should spent our time better in evaluating other free OSGi Enterprise implementations?

As long the licensing of JBoss Fuse is not clarified by Red Hat, it's not a viable option for use by dcm4che. Probably we will rather go using Apache components directly. It's to early to estimate, if and when my company will migrate their products to next generation of dcm4che's archive implementation and stop paying EAP subscription fees to Red Hat.

My respect to your work on the OSGI integration in JBoss AS. I guess Red Hat's decision hurts you more than any of us.

gunter