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 <[email protected]> wrote:
>
>>
>> On 24 May 2016, at 21:57, Christian Schneider <[email protected]
>> <mailto:[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 <http://www.liquid-reality.de/>
>>
>> Open Source Architect
>> http://www.talend.com <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
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
