On 28.10.2016 15:37, Thomas Watson wrote:
For really low-level things consider using system.bundle fragments.
In OSGi R6 system.bundle fragments are now allowed to have activators
by specifying a ExtensionBundle-Activator header. See the R6
specification for the details, but in short the system.bundle
fragments are activated at framework init() time before start-level 1
is even reached. This is really useful for system level code that
hooks directly into the framework and must be present from the init of
the framework to provide consistent behavior for the lifetime of the
framework. Things like bundle/service/resolver/weaving hooks. It
sounds like that would be needed for things like aspects if they are
being applied at runtime with a weaving hook.
That sounds good. It can work fine for Aepcio. It would not work for the
whole decanter though as it is too high level .. but perhaps we can
split off a basic part.
For Karaf decanter, I think I am missing the issue. If you are using
service-oriented design patterns wouldn't the necessary services
become available before the rest of the system can come on-line?
Unfortunately we can not rely on that. Let me explain the design of
decanter.
There are two main parts collectors and appenders. A collector taps into
a source and creates EventAdmin events on a topic. Examples are a file
collector to tail a log file or the pax logging collector that is called
when log events are sent. Other examples are collectors for bundle and
service events. Other bundles do not depend on the collectors so they
can be started later than user bundles. So for example the pax logging
collector can miss the logs that are created before it is started.
Appenders listen on an EventAdmin topic and write the contents to an
external sink like a file, jms or kafka. So the second problem is that
an appender might be started after some collectors. So it will miss some
events.
Collectors as well as Appenders most of the time need config so they
depends at least on config admin. So it is not possible to start them as
a system bundle fragment.
For the simple collectors I could imagine to have a system bundle
fragment but then they would need to queue events until the appenders
are present. I would like to avoid to do queueing there though as it is
a generic functionality that should only be implemented once. On the
other hand EventAdmin might not be such a good fit as it does not queue
at all.
Btw. I am also currently discussing with Dmytro about better options for
OSGi tests and assertions. One idea that came up is to have a logging
facility that queues all interesting events (Bundle, Service, Log) and
makes them available for assertions in tests. Somehow I think this is
very similar to what we need in decanter.
Christian
--
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
