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 <njbartl...@gmail.com
<mailto:njbartl...@gmail.com>> wrote:
On 24 May 2016, at 21:57, Christian Schneider
<ch...@die-schneider.net <mailto: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
