[Design of OSGi Integration] - Re: OSGI/MC General
by thomas.diesler＠jboss.com
Adrian, thanks for this work.
I updated the osgi version to r4v42 and will now try to add an implementation of the Framework launch API
https://www.osgi.org/members/build/r4v42-core-spec-final/osgi.companion/g...
This will then allow me to plugin this OSGi framework implementation with our hudson QA environment and run the existing tests not only against felix & equinox, but also this framework impl.
When this is done I can setup the osgi TCK.
Please note, that Filters now behave differently. When running the test, you should see
| Running org.jboss.test.osgi.filter.test.FrameworkUtilFilterUnitTestCase
| FIXME: verify: Invalid (*=b)
| FIXME: verify: NoMatch (a=)
| FIXME: verify: NoMatch (a<= 2)
| FIXME: verify: NoMatch (a<=2 )
| FIXME: verify: NumberFormatException (a<= )
| FIXME: verify: NoMatch (a>= 0)
| FIXME: verify: NoMatch (a>=0 )
| FIXME: verify: NumberFormatException (a>= )
| Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.325 sec
| Running org.jboss.test.osgi.filter.test.BundleContextFilterUnitTestCase
| FIXME: verify: Invalid (*=b)
| FIXME: verify: NoMatch (a=)
| FIXME: verify: NoMatch (a<= 2)
| FIXME: verify: NoMatch (a<=2 )
| FIXME: verify: NumberFormatException (a<= )
| FIXME: verify: NoMatch (a>= 0)
| FIXME: verify: NoMatch (a>=0 )
| FIXME: verify: NumberFormatException (a>= )
| Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.808 sec
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250847#4250847
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250847
14 years, 8 months
[Design of OSGi Integration] - OSGi/MC Service todos
by adrian＠jboss.org
Services are also largely complete. What's missing is that we want to expose
MC pojos and JMX MBeans etc. as OSGi services.
The proper way to do this would be to push the OSGi Filter into kernel project
and use the MDR INSTANCE scope as the attributes.
There would be a gotcha in that OSGi expect attributes to have case insensitive names,
but we would only have to enforce that for OSGi created services.
The big problem with doing this now is that it would make it difficult to drop the OSGi
layer into existing jboss releases since we can't change their MC implementations to
do this.
There's probably some compromise we can reach between the two extremes
and leave the proper solution to a future major release of JBoss.
We definitely need to do some service/mc integration to get the declarative service
stuff working.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249981#4249981
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249981
14 years, 8 months
[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
14 years, 8 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
14 years, 8 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
14 years, 8 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
14 years, 8 months