Hi Balazs,
Can anyone provide details on what metadata is meant by this statement:
/Availability of OSGi metadata from source (or correctness when
available), though it’s improving
/Thanksinadvance,
Scott
On 6/8/2016 7:04 AM, Balázs Zsoldos wrote:
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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[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]
<mailto:[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]
<mailto:[email protected]>>
To: OSGi Developer Mail List <[email protected]
<mailto:[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] <mailto:[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 <tel: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]
<mailto:[email protected]>>[email protected]
<mailto:[email protected]>> wrote:
>>>>
>>>>
>>>>> On 24 May 2016, at 21:57, Christian Schneider
>>>>> <<mailto:[email protected]
<mailto:[email protected]>>[email protected]
<mailto:[email protected]>> wrote:
>>>>>
>>>>> On 24.05.2016 <tel: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]>
<mailto:[email protected]
<mailto:[email protected]>>
>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> [email protected]
<mailto:[email protected]>
<mailto:[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
>>>
>>
>>
>> --
>> 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
>>
>>
> --
> Jean-Baptiste Onofré
> [email protected] <mailto:[email protected]>
> http://blog.nanthrax.net
> Talend - 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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
