OSGi/MC Bundle todos

[adrian.brock]

The bundle stuff is perhaps the most complete and best integrated at the moment.

The TODOs basically revolve around the lifecycle stuff.

UPDATE/INSTALL

The install(URL) works and I don't think it would be hard to do the install(InputStream)
you just need to copy the input stream somewhere, but this has relations to the
persistence see below.

The update has some very funny semantics (which is my least favourite part
of the OSGi spec). This basically allows you to update the bundle contents
but the classloading changes not effected until somebody does
PackageAdmin.refreshPackages()
This seems like a recipe for all sorts of classloading leaks, since I doubt
any user bundle will understand the full scope of how this should be done properly.

START/STOP

The basic start/stop is working, but there are other options like lazy activation
that are not implementated. This also appears to have relations to the peristence
and the run level service so these can be implemented when those are.

LOCKING

There is a requirement in the spec that when somebody is controlling the lifecycle
the bundle should be locked. Other requests on the bundle, whether lifecycle or
service operations should wait.
I haven't implemented this since this is also an outstanding item on the
jboss deployment layer and will need to play nicely with that to avoid deadlocks.

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?

getDataFile()

I haven't implemented this optional method. I don't think it would be hard, it's just
not a priority. :-)

[bosschaert]

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

[warjort]

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.

[bosschaert]

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