That is great, thank you for the work ,) Imust admit I was not quite clear what questions you wanted to answer for your own projects, but seeing the answers it is certainly usefull on its own. Will you please notify us on the other parts via mailing list as well?
I wonder if that would be a nice project for the OSGi consortium to prepare and conduct a community survey. It has become quiet about OSGi, a widely distributed survey and result could get some traction back. Bernd -- http://bernd.eckenfels.net -----Original Message----- From: "Balázs Zsoldos" <[email protected]> To: OSGi Developer Mail List <[email protected]> Sent: Do., 26 Mai 2016 18:17 Subject: Re: [osgi-dev] How do you use OSGi? 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é <[email protected]> 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:[email protected]>[email protected]> wrote: >>>> >>>> >>>>> On 24 May 2016, at 21:57, Christian Schneider >>>>> <<mailto:[email protected]>[email protected]> 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 >>>>> [email protected] <mailto:[email protected]> >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>> >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> [email protected] <mailto:[email protected]> >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> 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 >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
