|
On 29/11/12 04:22, Gunnar Wagenknecht wrote:
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.
Humm, I think that I understood now. I will create one application
for a JBPM server to test it.
Btw, if you don't use app pattern for business applications, how do
you deal with multi-tenant business applications that needs
different behavior per tenant? using only Roles plus bundles?
do you have any paper about multi-tenant setup?
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
ok, thanks..
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.
I'm asking because in future I would deal with roles using
Configuration Manager service instead
Equinox Extension Registry
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.
very interesting !! I would like to try asap :D
could you point me to any paper explaining how to setup this?
-Gunnar
|
