-
1. Re: What's the difference between class-loading via jboss-modules and jbosgi-resolver-felix?
thomas.diesler Nov 12, 2012 7:26 AM (in response to cberger)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.
-
2. Re: What's the difference between class-loading via jboss-modules and jbosgi-resolver-felix?
cberger Nov 12, 2012 12:25 PM (in response to thomas.diesler)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
Ok, so jboss-modules has no resolving functionality at all. It just performs the wirings between the different modules based on the dependencies in module.xml or Dependencies-Header, right?
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.
Yes, I think that's the same problem with Require-Bundle in OSGi. You have a explicit dependency to a bundle and that's against the principals of modularity
The recommended approach is to use standard OSGi metadata in all your deployment types if you have a modularity concern.
Personally, I am not happy with that. When I add some OSGi metadata to any JEE-Component like a WAR-File or EAR-File, what's the result? Is it a bundle or not? So why should I mix up these two worlds? I think it's cool to invoke OSGi-Services from an EJB or Servlet but when I resolve the dependency to the required OSGi-Service API via OSGi metadata, then everything is mixed up. I have no real JEE-Component and no real OSGi-Bundle. That's not in the inventor's sense, isn't it?
-
3. Re: What's the difference between class-loading via jboss-modules and jbosgi-resolver-felix?
thomas.diesler Nov 13, 2012 3:05 AM (in response to cberger)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.
-
4. Re: What's the difference between class-loading via jboss-modules and jbosgi-resolver-felix?
cberger Nov 13, 2012 6:58 AM (in response to thomas.diesler)What would you be happy with? Perhaps you could outline a comprehensive description of how you think this should work.
Hey Thomas,
I do not have a perfect solution. It was just my intention to provide thought-provoking impulses for how to handle this issue. As a matter of fact each OSGi bundle becomes a JBoss module. So if these modules have OSGi metadata, that's absolutely fine with me because they are OSGi compliant bundles at the same time. But I think it isn't a good idea to add spec compliant osgi metadata to non osgi-components, isn't it? You have also defined a proprietary Dependency-Header in your module context which covers the functionality of Require-Bundle in OSGi. What can be said against a second proprietary header which has the same effect as Import-Package, or at least a header with a X- as prefix to indicate that something JBoss specific is happening? Because as far as I understand, you parse the manifest data of import-package and give that to your modified felix resolver which computes the wiring based on modules and not on bundles. So for me that's something different.
Furthermore, I am not happy with adding some parts of the defined osgi metadata to a WAR-File. Either it is a JEE compliant component or it is an OSGi compliant bundle with all the required osgi metadata and the jar extension as defined in the spec (WAB). In your case you have a mix of both. So at the end, a war file has an import-package header but no Bundle-SymbolicName / Bundle-Version. Therefore it isn't a bundle, it's a JEE-Component with OSGi metadata which will be used to compute wirings on the basis of modules.
However, that's just my opinion and it would be nice if somebody else could give an opinion on this.
Btw, thanks for your time ...
Cheers Christian
-
5. Re: What's the difference between class-loading via jboss-modules and jbosgi-resolver-felix?
ulrichromahn Nov 19, 2012 2:28 PM (in response to cberger)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.
-
6. Re: What's the difference between class-loading via jboss-modules and jbosgi-resolver-felix?
thomas.diesler Nov 20, 2012 3:15 AM (in response to ulrichromahn)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.
-
7. Re: What's the difference between class-loading via jboss-modules and jbosgi-resolver-felix?
ulrichromahn Nov 20, 2012 2:45 PM (in response to thomas.diesler)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?
-
8. Re: What's the difference between class-loading via jboss-modules and jbosgi-resolver-felix?
thomas.diesler Nov 21, 2012 9:44 AM (in response to ulrichromahn)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.