There is a whole lot of assumptions going on here and before conjecture wins the day I want to make some corrections:
- OSGi CDI Integration is *completely reactive to both Services and Configuration*. See the spec [1] - *Aries CDI is the RI and is very active*. See the commit history [2] - Supports a *dynamic ecosystem of CDI Portable Extensions*. There are no class space compromises in the design and use of CDI Portable Extensions. (No funky classloaders were harmed in the making of this CDI container) Furthermore, I will admit that the spec is ambitious but I think we have it right (really trying to put bias aside). Also, neither the Spec or RI are officially released yet (probably will be around January or February before it gets through the whole OSGi process) and so there may be some bugs in the RI but it does pass a gamut of tests which prove it's reactiveness and ease of use. Also, there's already preliminary tooling in place in bnd (4.1.0+) for it so writing OSGi CDI bundles is already simple and doesn't require a whole slew of mental fortitude to get the metadata correct. Just code away (see the i-tests in Aries [3]). I would really encourage people to take a look. We put a huge effort into not compromising either CDI or OSGi, applying the best of each. I really encourage comments particularly on real usage attempts. Sincerely, [1] https://osgi.org/specification/osgi.enterprise/7.0.0/service.cdi.html#d0e91186 [2] https://github.com/apache/aries/tree/trunk/cdi [3] https://github.com/apache/aries/tree/trunk/cdi/cdi-itests/src/main/java/org/apache/aries/cdi/test -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
