is responsible for computing the modules classloader wirings

It provides the APIs for wiring modules together - it has no notion of resolver. The AS7 system modules are hard-wired together with what you see in the various modules.xml files

In the OSGi layer we parse the manifest to get at the set of caps/reqs for a bundle deployment. We give that to the standalone Resolver implementation, which comes back with the wiring result. With that result we go to the modules API. There is only one resolver. AS7 modules are hard wired either in modules.xml or in code.

Dependencies: some.named.dependency

This should be for AS7 internal use only. I recommend not to use that propriatary technique in user deployments - it couples tightly and violates the fundametal principals of modularity. A named dependency is however still better than flat classpath.

The recommended approach is to use standard OSGi metadata in all your deployment types if you have a modularity concern. Often the JavaEE standard is "good enough" and you don't need OSGi at all.

Personally, I am not happy with that.

...

I have no real JEE-Component and no real OSGi-Bundle. That's not in the inventor's sense, isn't it?

What would you be happy with? Perhaps you could outline a comprehensive description of how you think this should work.

Very interesting discussion...

Let me try to explain my point-of-view here since we are dealing with the exact same question and issue right now.

IMHO, OSGi is a very powerful concept and technology, but it is too complex for the "average" software engineer (no offense to those millions of excellent "average" Java developers meant here) - it is even hard to grasp and get right for many seasoned Java engineers and architects, to be honest.

So, my point is that OSGi and its complexities should be "hidden" from the average application developer similar how it is done within the Eclipse IDE.

And this is the power of JBoss, once the integration between JEE and OSGi has been completed. This allows a small team of advanced "infrastructure" engineers to develop some core infrastructure services and other capabilities / modules using OSGi while the majority of application developers stay in the standard JEE-world building standard JEE applications (WARs, EARs).

So, the ultimate question would be now: how do we bridge the two worlds OSGi and JEE?

In my personal opinion, CDI (Weld) should come to the rescue. Any service and module based on OSGi should be "injectable" into a standard JEE application via CDI.

This is currently possible in JBoss AS 7 by injecting the OSGi BundleContext into any JEE application using a @Resource annotation.

However, my issue with this approach is that once you do that, your JEE application becomes "OSGi-aware" and your application developers will have to be OSGi-aware exposing them to the complexity of OSGi.

So, the new Weld-OSGi extension may be our rescue here but unfortunately it is not clear to me at what stage this is and when the integration will be completed (and with what version of JBoss AS). From what I see in GitHub it is part of the Weld 1.2.0 branch but JBoss AS 7.2.0-Alpha1-SNAPSHOT is still referencing Weld 1.1.10.

Thomas: maybe you can shed some light on this integration as this may solve a lot of integration problems between OSGi and JEE.

The Enterprise OSGi Expert Group is currently working on OSGi/CDI integration (RFC 193). This is jointly led by Red Hat, SERLI and Luminis.

The RFC aims to define a standard for OSGi-CDI implementations. A number of different implementations currently exist.

The implementation from SERLI had a dependency on a few changes at the Weld core level. AFAIK, these changes have now made it upstream and are available in jboss-as/master. So there should be no blocking issue any more for progress in that area. We track the OSGi/CDI integration by this roadmap item.

As always, I'm happy to help anybody anlong who likes to make the next progress step in any of the areas that we identified as being important.

Thomas,

thank you very much for your timely reply - as always .

One comment though regarding your reply and the mentioned RFC 193.

I quote from David Bosschaert's Blog (http://osgithoughts.blogspot.com/2012/11/current-themes-in-osgi-enterprise.html):

{quote}The aim is to bring the CDI programming model to OSGi with portability across compliant implementations.{quote}

This is not exactly what I proposed above. While I certainly would welcom to add the CDI programming model to OSGi, I am more interested the other way around: expose services from OSGi to non-OSGi applications via CDI. From what I have found on the internet, this is currently not covered by RFC 193. In addition, RFC 193 seems to be targeted for R6 which is coming way too late for my specific use case.

P.S. I could not find the mentioned RFC 193 anywhere in the public. Is there a chance to get access to it to see what exactly is being proposed?

The way we could go about this is that we first resolve JBOSGI-445 then gather requiremtents based on what we see and finally feed them back to RFC-193.

We could also gather requirements without having an implementation and try to feed them back to the RFC.

I think the direction of the RFC is fine given that in JBossAS any deployment can have an OSGi view and hence be a target for OSGi service injection through CDI.