> > Will you please notify us on the other parts via mailing list as well?
I have just finished the second part: https://everitorg.wordpress.com/2016/05/30/how-do-you-use-osgi-part-2/ Thanks again for the answers! Balazs On Thu, May 26, 2016 at 6:39 PM, <[email protected]> wrote: > 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 >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
