Hi, I see that a question form with some simple question motivated people to write 35 emails on this thread. I am euphoric to see that as these discussions can be very useful for others, too. For me, they were useful.
I started to write an e-mail with the summary of responses, but it got too long. I wanted to attach pictures, but I think they would not be shown in mailing list archives. I do not know how others are with it, but I like short texts with pictures :). Therefore, I split the content into 2-3 parts and release it as a series of blog posts. The first one is here: https://everitorg.wordpress.com/2016/05/26/how-do-you-use-osgi-part-1/ Kind regards, *Balázs* On Wed, May 25, 2016 at 9:20 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi, > > It's a good approach. We use the same approach in camel-blueprint-test to > "fake" OSGi services (as describe here: > http://blog.nanthrax.net/2014/08/testing-utest-and-itest-apache-camel-blueprint-route/) > However, it's a bit "limited" compared to a full OSGi framework. > > I like what you did to show that we can "embed" OSGi applications in > spring-boot. > Another interesting approach would be to show how to embed the OSGi > framework or container (Karaf Minimal/Static/Main) in spring-boot too. Or > even better showing how to use karaf-boot to do it for us. > > Regards > JB > > > On 05/25/2016 09:12 AM, Christian Schneider wrote: > >> Yes .. pojosr (connect) works quite nicely. I even managed to bridge to >> the world of spring-boot now. >> >> https://github.com/cschneider/decanter-docker/tree/master/spring-boot-starter-decanter >> >> In this module I define a spring boot extension for Karaf Decanter. It >> starts a minimal decanter inside a spring boot application. >> >> Basically the idea is to forward all log informations (later also JMX >> beans) into an embedded decanter that can then be configured to forward >> the logs >> using any protocol decanter supports. In my case it forwards to a kafka >> broker. There a full scale decanter picks up the logs, processes them >> and forwards to ES. >> >> In the spring boot app you can then define a logger that forwards the >> logs into decanter using EventAdmin. >> >> https://github.com/cschneider/decanter-docker/blob/master/taskservice/src/main/resources/logback.xml >> >> I was quite surprised that I was able to reuse the normal decanter >> bundles including config handling and DS without any changes. >> This is very helpful as it allows to reuse OSGi code that has to run >> inside a non OSGi application for some reason. >> >> Christian >> >> >> On 25.05.2016 08:42, Peter Kriens wrote: >> >>> In PojoSR and thus I assume you can install, start, and stop bundles. >>> You cannot update, resolve, or uninstall for obvious reasons. It is >>> uncannily close to a real framework :-) >>> >>> Kind regards, >>> >>> Peter Kriens >>> >>> >>> On 24 mei 2016, at 23:43, Neil Bartlett >>>> <<mailto:njbartl...@gmail.com>njbartl...@gmail.com> wrote: >>>> >>>> >>>>> On 24 May 2016, at 21:57, Christian Schneider >>>>> <<mailto:ch...@die-schneider.net>ch...@die-schneider.net> wrote: >>>>> >>>>> On 24.05.2016 21:02, Scott Lewis wrote: >>>>> >>>>>> >>>>>> Yeah you can do this, but my observation is that very few are. >>>>>> >>>>>> I would also suggest that the classes/API in the launch package >>>>>> (e.g. BundleFinder) are/would be essential [1], as launch >>>>>> configuration is extremely important to address more than a few use >>>>>> cases. Actually, I also think that some standard config >>>>>> properties (e.g. BundleFinder impls, or specific bundles to be >>>>>> added/started on startup) would be useful, but I haven't thought >>>>>> that through yet. >>>>>> >>>>>> I agree. A big part is finding and selecting the bundles to start. >>>>> This is not covered by FrameworkFactory. >>>>> >>>> >>>> I’m confused, are you still talking about Connect? In Connect, you >>>> cannot install, update or uninstall bundles, because that would >>>> require the full OSGi lifecycle and classloaders. Instead, Connect >>>> automatically gives you ersatz bundles representing JARs on the >>>> classpath. You can, however, start and stop these bundles because >>>> that only requires setting a flag and calling a callback (they are >>>> all started by default when the framework starts). >>>> >>>> >>>>> >>>>> Another interesting part would be a kind of health check. >>>>> When I start a feature or bundles in karaf I can use the shell to >>>>> introspect if the bundles are all resolved and start correctly and >>>>> which DS components are started and which are not. >>>>> For embedded OSGi where you typically do not have a shell it would >>>>> be great to have some configureable health checks that tell you if >>>>> something might be wrong in your setup. >>>>> One example would be that I expect that all bundles are started and >>>>> all DS components come up. I am not sure if this requires an API >>>>> though. It could simply be a bundle. >>>>> Of course this would be interesting for other OSGi deployments too. >>>>> >>>> >>>> This area is always tricky because there are common scenarios in >>>> which some bundles/components do not start but the overall >>>> application is still considered to have successfully started. So the >>>> health-check would need application-specific knowledge. You’re right >>>> that this can be implemented in a bundle. >>>> >>>> >>>> >>>>> Christian >>>>> >>>>> -- >>>>> Christian Schneider >>>>> http://www.liquid-reality.de >>>>> >>>>> Open Source Architect >>>>> http://www.talend.com >>>>> _______________________________________________ >>>>> OSGi Developer Mail List >>>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>> >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> osgi-dev@mail.osgi.org >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >> >> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> http://www.talend.com >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
