4 ms·

Reinventing OSGi configurations.

by _pmf_ 10y ago

mindcrime 10y ago
We're using ServiceMix as a container for services (micro or otherwise) and while OSGI isn't without its own annoyances, it really is nice once you get everything working. The biggest problem I've found so far is simply 3rd party dependencies that aren't packaged with OSGI manifest information. Recently I specifically had an issue with Spring in this regard (yeah, yeah, don't use Spring, I know... but there was a specific reason in that case, at least initially) that would have been easy to resolve if the Spring guys still distributed OSGI'ified versions of their jars. Still, all in all, I'm pretty happy with this approach.
- _pmf_ 10y ago
  > The biggest problem I've found so far is simply 3rd party dependencies that aren't packaged with OSGI manifest information. It's a mess, and I fear Java 9/10's modularization approach will even make it worse (so that instead of P2 (Eclipse's Equinox' OSGi bundles) and Maven, we'll have another set ... sigh. I'm still looking for a solution that transparently translates Maven metainformation to OSGi bundle information at some higher level (for example by hooking into the OSGi container's dependency resolution logic). Edit: apparently, such a mechanism exists (ResolverHook)
  - sytringy05 10y ago
    isn't that exactly what wrap is for?
    - mindcrime 10y ago
      That has mostly worked well for me when dealing with non-OSGI jars. Once I figured out how to set things up using the features.xml file and specify wrap: for the generic jars, things worked nicely. All of this said, I'm fairly new to OSGI, so I may still run into some dark corners that will turn me off. But right now, it seems to be serving the purpose well.
- sytringy05 10y ago
  I've been working with Fuse for ages and I'm still not convinced OSGi is worth the trouble. ServiceMix, Felix, Karaf etc can be a total lottery some times as to whether or not it will do what you asked. Dropwizard or SpringBoot ftw!

Reinventing OSGi configurations.

by _pmf_ 10y ago

Reinventing OSGi configurations.

We're using ServiceMix as a container for services (micro or otherwise) and while OSGI isn't without its own annoyances, it really is nice once you get everything working. The biggest problem I've found so far is simply 3rd party dependencies that aren't packaged with OSGI manifest information. Recently I specifically had an issue with Spring in this regard (yeah, yeah, don't use Spring, I know... but there was a specific reason in that case, at least initially) that would have been easy to resolve if the Spring guys still distributed OSGI'ified versions of their jars. Still, all in all, I'm pretty happy with this approach.

_pmf_ 10y ago
> The biggest problem I've found so far is simply 3rd party dependencies that aren't packaged with OSGI manifest information. It's a mess, and I fear Java 9/10's modularization approach will even make it worse (so that instead of P2 (Eclipse's Equinox' OSGi bundles) and Maven, we'll have another set ... sigh. I'm still looking for a solution that transparently translates Maven metainformation to OSGi bundle information at some higher level (for example by hooking into the OSGi container's dependency resolution logic). Edit: apparently, such a mechanism exists (ResolverHook)
- sytringy05 10y ago
  isn't that exactly what wrap is for?
  - mindcrime 10y ago
    That has mostly worked well for me when dealing with non-OSGI jars. Once I figured out how to set things up using the features.xml file and specify wrap: for the generic jars, things worked nicely. All of this said, I'm fairly new to OSGI, so I may still run into some dark corners that will turn me off. But right now, it seems to be serving the purpose well.
sytringy05 10y ago
I've been working with Fuse for ages and I'm still not convinced OSGi is worth the trouble. ServiceMix, Felix, Karaf etc can be a total lottery some times as to whether or not it will do what you asked. Dropwizard or SpringBoot ftw!