Hi, here is the fourth and last part of the series: https://everitorg.wordpress.com/2016/06/08/how-do-you-use-osgi-part-4/
I hope it will be as instructive to you as it was me to see the answers. Thanks for all of you who took the time to answer! Regards, *Balázs* On Fri, Jun 3, 2016 at 2:06 PM, Balázs Zsoldos <balazs.zsol...@everit.biz> wrote: > Hi, > > here is the third part of the answers (a bit longer than the previous > ones): > https://everitorg.wordpress.com/2016/06/03/how-do-you-use-osgi-part-3/ > > The next one will be the last one. > > Regards, > *Balázs* > > > On Mon, May 30, 2016 at 10:56 AM, Balázs Zsoldos < > balazs.zsol...@everit.biz> wrote: > >> 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, <e...@zusammenkunft.net> 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" <balazs.zsol...@everit.biz> >>> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> >>> 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é <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 >>> >> >> >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
