-
1. Re: OSGi/MC Bundle todos
bosschaert May 24, 2010 5:31 PM (in response to adrian.brock)Adrian Brock wrote:
RUN LEVEL/PERSISTANCE
This stuff should be implementated on top of the profile service within jboss,
but we might want to provide vanilla implementations of this for standalone usage?How would one implement the Run Level stuff on top of the Profile Service? Seems like the Start Level Service can nicely be implemented on the OSGi layer (see OSGi Start Level Service), but maybe I'm missing something .
And Persistence, how does that relate to the Profile Service?
Thanks,
David
-
2. Re: OSGi/MC Bundle todos
warjort May 24, 2010 5:42 PM (in response to bosschaert)The profile service is the mechanism to persist deployment configurations for JBoss.
You can think of a "run level" as what JBoss calls a profile.
The idea is to be able to use the OSGi api as a facade to the profile service api.
You need to speak to Emanuel about how to do this.
-
3. Re: OSGi/MC Bundle todos
bosschaert May 27, 2010 2:38 AM (in response to warjort)Emanuel sent me the following information.
Emanuel Muckenhuber wrote:
Maybe a quick explanation. ProfileService is basically responsible for
two (quite contrary) things:
I) it's the AS configuration and management API [1], used by e.g. the
admin-console. Part of this is a attachment persistence Adrian was
talking about.
II) deployment control. Basically ProfileService controls/triggers the
deployment process (obviously the actual work is done by the deployers).
Additionally it determines which deployments are in a "profile" - this
is where the name originally comes from [2]
Having said this (I) is going to change in AS7 to a domain specific
configuration - where all configuration will be moved to a central
location, out of the actual deployments. Therefore the persistence part
will change - so it might not make much sense to use the PS persistence
for now.
The problem with (II) is that determining which deployments are going to
be deployed, is just based on what's in "deployers/" and "deploy/" -
which sucks.
In future we are going to move to a more requirement/capability driven
AS bootstrap - I'm currently working on a prototype for this [3]. Maybe
quite similar to what an OBR is doing - mainly focused on the local
part. Since remote repositories / updating "profiles" would be part of
provisioning.
For me the goal of the jboss OSGI integration would be to also make it
possible to resolve bundles against "normal" AS services and
deployments. So that we don't have duplicate already existing
services/libraries as separate and isolated OSGI bundle. At least those
are my thoughts about that, so far
There are a lot pieces missing and we have to put quite some effort into
modularizing AS, but that's where i would like to get at one point. I
need to admit that i haven't had much time to think much about the OSGI
integration and comments are always welcome.
So at the moment i rather suggest that you might just do the vanilla
implementation. I need to finish some work on ProfileService, maybe we
can take a deeper look on how we connect some parts of PS with OSGI then?
Thanks,
Emanuel
[1] http://community.jboss.org/wiki/ManagedObjects
[2] http://community.jboss.org/wiki/ProfileService
[3] http://community.jboss.org/wiki/AS6ProfileServiceDesign