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 <[email protected]> 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, <[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
