[Design of OSGi Integration] - OSGi?MC ClassLoading todos
by adrian＠jboss.org
METADATA/DEPLOYERS
As I mentioned on the deployers todos, not all the classloading metadata is currently
being mapped.
ATTRIBUTES
The OSGi classloading rules allow you to specify dependencies using attributes
rather than name/version. This is really just a form of aliasing, but there are some
subleties such as the "mandatory" attribute.
This is probably the main part that is "missing" in the sense that it is not just a case
of mapping OSGi features to existing MC features.
PACAKGE ADMIN
This should be implemented as a facade on top of the current "ClassLoading" api.
Some of this does already exist (it was added for AOP) but it obviously has a
different api. It would also require some kind of reverse mapping so you can do
Module->Deployment somewhere.
RESOLVED NOTIFICATION
Currently the bundles are getting notified when there classloaders are
resolved/unresolved. i.e. when the classloaders are created/destroyed.
This needs some kind of notification from the classloading layer.
FRAGMENTS
OSGi has a feature where you can create a "fragment bundle".
This is a deployment that adds to another deployment/classloader rather than
creating its own. We don't have this notion currently within JBoss.
VERSION RANGE
I mentioned in the METADATA todos that it would be good if we could just use
the ClassLoading VersionRange class.
SPLIT PACKAGES
Although not really a requirement (split packages are optional) it would be good
to fix the classloading validation to allow it.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249979#4249979
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249979
16 years, 7 months
[Design of OSGi Integration] - OSGi/MC Deployer todos
by adrian＠jboss.org
The current deployers are just the ones for bundle lifecycle.
The ones that are missing are the;
OSGiStructure
OSGi bundles are not allowed to have subdeployments. Instead you have
to specifically list nested jars to be a part of the classpath using the manifest.
This is similar to how an ear works.
CLASSLOADING
As I mentioned on the METADATA todos. Some of the metadata is wrong,
e.g. the VersionRange for exporting packages. So I haven't mapped all these
into JBoss ClassLoadingMetaData yet. See also the ClassLoading todos.
DECLARATIVE SERVICES
This deployer should add dependencies to a deployment for the required services
before it is activated, i.e. reaches the "REAL" stage.
Since the service layer is not yet integrated with the MC (see the services todos)
this can't be implemented yet.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249974#4249974
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249974
16 years, 7 months
[Design of OSGi Integration] - OSGi/MC Bundle todos
by adrian＠jboss.org
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. :-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249973#4249973
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249973
16 years, 7 months
[Design of OSGi Integration] - OSGi/MC MetaData todos
by adrian＠jboss.org
I haven't really touched the MetaData that Ales (and I think from the comments Scott)
worked on. This is what I would describe as what needs doing.
MANIFEST vs PROPER OBJECT MODEL
I don't really like the idea that this is basically stored in a Manifest with a wrapper.
That might be nice for real OSGi deployments but it makes it difficult if you want to:
* add osgi metadata by hand
* modify osgi metadata - e.g. in the profile service/console
* expose other metadata as though it was osgi metadata, e.g. so non-osgi classloading
rules can be exposed using the OSGi management queries.
BUILDER
The previous comment might be mitigated if there was some kind of
OSGiMetaDataBuilder class to make it easier?
OBJECT CONSTRUCTION
The metadata seems to have a whole copy of what is done by TypeInfo.convertValue()
it should just use that.
LOCALISATION
I'm not entirely sure how this is supposed to work? But I've put a TODO
where I think it should done. :-)
VERSION RANGE
I've reworked this so that it uses the ClassLoading VersionRange.
The only thing I can see that is different is that the the OSGi class
has a static method to parse the range from a string?
COMPLETION/TESTING
I've not looked too deeply at all the metadata. But there are obviously some things
missing as well as some things being wrong, e.g. exporting packages gives
you a version range instead of a version?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249962#4249962
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249962
16 years, 7 months
[Design of OSGi Integration] - Re: Updated OSGi/MC prototype
by adrian＠jboss.org
I'll explain the architecture of the rewrite so you can understand how it works.
The old prototype had lots of different elements scattered around which made
it not very easy to implement things.
I've replaced them with essentially two main items, OSGiBundleState and
OSGiServiceState which then have "proxies/facades" for the standard OSGi api.
BUNDLES
The OSGiBundleState is little more than a facade over a top level DeploymentUnit.
Every deployment goes through the OSGiBundleStateDeployer which creates an
OSGiBundleState wrapper for that deployment.
They are all registered in an OSGiBundleManager such that the bundle query stuff
can work - and other system level data/services can be configured/reached on that item.
The OSGiBundleState is added as an attachment to the deployment.
This doesn't mean it is an OSGi deployment (that is controlled by whether the
deployment has an OSGiMetaData attachment). What it means is that
you can write other deployers like the OSGiBundleActivatorDeployer
that can see what the Bundle is for a deployment.
When we come to do the service layer properly, we should also add
the OSGiBundleState to the DEPLOYMENT MDR scope so any MC context
can know which "bundle" it belongs to.
The OSGiBundleState has two "facades" the standard Bundle and the BundleContext
interfaces. Of course, there's a special implementation of the OSGiBundleState
for the "system bundle" which works slightly differently.
SERVICES
The service layer is not so well integrated with the MC. It does just enough to
be "OSGi compliant" (of course that's not yet tested). So this is at the
moment very simple.
The OSGiServiceState which should eventually turn into an MC context implementation
has two "facades", the standard ServiceRegistration and ServiceReference interfaces.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249955#4249955
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249955
16 years, 7 months