1

spring dm has its own OSGi specific application context Osgi-BundleXmlApplicationContext.The OsgiBundleXmlApplicationContext class implements all OSGi-specific behaviors required for proper Spring application context startup. Spring DM uses it for standard OSGi bundles and turns to its little sister, OsgiBundleXmlWebApplicationContext, for web OSGi bundles

what i have seen/tried in other examples and spring dm documentation is that bean configurations for spring powered osgi bundle is done in xml, i already have a spring boot app which is annotation based.

can i convert this spring boot to spring powered osgi bundle?

Jayant Mishra
  • 31
  • 4
  • Correct me if I am wrong, but Spring DM is not maintained for many years. Spring is a monolith technology, while OSGi is a modular one, therefore the two cannot be used together, only with the endless implementation of workarounds. I suggest that you should not think in a mixed Spring-OSGi architecture. – Balazs Zsoldos May 16 '18 at 11:40
  • @BalazsZsoldos Spring DM is now Eclipse Gemini. It is still supported and works pretty well (though development isn't soaring or anything). Both Eclipse Gemini and Apache Aries implement the OSGi blueprint specification. OSGi Blueprint is comparable to OSGi Declarative Services in how it fits in to the ecosystem. – Jasper Siepkes Jan 27 '19 at 08:21
  • @JasperSiepkes My experience: The problem is that even the specification of Blueprint has many harmful conceptual mistakes that make the system unstable. The second problem, that even if one has some workaround for these issues, Aries Blueprint code quality is way below acceptable. Even standard use-cases do not work well. I am not sure about Gemini code quality, but I cannot imagine that something that pulls Spring libs in can work stable within OSGi. These libs are just not designed to work in OSGi. Most people hate OSGi because they wanted to use monolith stuff in it like Spring, JPA, ... – Balazs Zsoldos Jan 28 '19 at 09:46
  • @BalazsZsoldos I definitely wouldn't advise anyone to use Blueprint who starts with a new project. Your definitely better of with Declarative Services. Still I don't understand what your saying about the mismatch between Spring and Osgi; Each OSGi bundle has it's own Spring context (with beans, config and such) and you can easily obtain references to other OSGi services and inject them in beans by using `osgi:reference` and expose Spring beans with `osgi:service`. But yeah if you try to have a single Spring context for all bundles that will not work. But thats not what Gemini does. – Jasper Siepkes Jan 28 '19 at 09:58
  • @JasperSiepkens Spring breaks the contracts of modules by enhancing its classes at runtime. By doing that, it generates chaos that is very harmful in a modularized world where bundles can be reinstalled any time. It generates an endless loop of bugfix. In my experience, any technology that uses ASM, CGLIB, Javassist, etc. are causing at least 100% overhead in OSGi development and in the end one gets a "nobody should touch the source ever again otherwise it will collapse" application. – Balazs Zsoldos Jan 29 '19 at 10:11

0 Answers0