[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [gyrex-dev] dealing with modularization...
|
Hi,
Am 29.11.2012 06:36, schrieb Cristiano Gavião:
I have no sure yet, but seems that an application (the one defined in
OSGi Application Admin specification) has no lifecycle relation with the
bundles that it depends on, right? I mean, if I start/stop one app it
not necessarily will do the same with it child bundles, right?
That's implicit through the extension registry. When the application
class is loaded, it's bundle is started. Same is true for any other code
the application depends on. That's the beauty of lazy loading (IMHO).
You no longer care what bundles to start.
I recommend providing any OSGi service implementations using DS. This
allows to continue using lazy loading for OSGi service implementations
as well. Thus if your application requires a service, the bundle will be
started as well.
BTW, there is also the question of when to provide an OSGi application.
In Gyrex we use applications as a way to enable technical capabilities
on a node. We don't use this patterns in our business applications that
we build on top of Gyrex. For example, the Jetty app starts the Jetty
bundles and launches a Jetty server that listens on configured ports
(SSL, SPDY, HTTP). Web applications are then developed on top of that
using OSGi DS. It's similar for batch jobs. The worker engine is
developed and started as an OSGi app. The jobs are provided using OSGi
DS. The scheduler is configured via console commands. When a job is
queued the worker engine will pick it up and lookup a job provider from
the OSGi service registry.
I could see that the application defined in Subsystem Service
Specification do that... but only Apache Aries have implementation for
that(http://aries.apache.org/modules/applications.html)...
I've read about sub systems. But we do not support that. We also do not
have any plans to implement it. The current model (flat bundles, lazy
loading, OSGi apps) serves our needs very well.
It would be interesting to explain the existent trigger types. they are
fixed ?
http://wiki.eclipse.org/Gyrex/Developer_Guide/Roles#Activation_Triggers
is there an api for the roles maintenance ?
No. Roles are managed using
org.eclipse.gyrex.server.internal.roles.LocalRolesManager. It's possible
to extract an API out of this if this is something of interest for your.
It's possible today to manage roles dynamically today using tags. For
example, when a node tag is added, role conditions will be re-processed
and roles may get started because of this. Same is true when a tag is
removed.
what is the expected behavior actually defined for provisioning ?
installing a feature in the master node will trigger the same in the
other nodes?
So we create and store repository information as well as "packages" in
ZooKeeper. A "package" is like a list of IUs that must be installed (or
removed) from a node. Again, packages (as well as repositories) can have
node filters to only install packages on specific nodes or to have nodes
in a different data centre (or of a different type, eg., staging/testing
nodes) use a different repository.
On each node a background job is running (provided by an OSGi app) that
checks regularly for new packages to install or to remove. It then
acquires a lock in ZooKeeper and performs any p2 operation. If
necessary, a node is restarted. Upon successful completion, the lock is
released back and other nodes may continue.
-Gunnar
--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx
http://wagenknecht.org/