-
1. Re: ServiceMix resurected
While it's entirely true that the OSGi specs sometimes use bundle.id and service.id to decide which one to take in case of a tie I think in practise this shouldn't be relied on by developers and deployers.
Take bundle.id. This one is used, for instance, when two exporters export the same package and an importer needs that package. In that case the lowest bundle.id is used. Well... which one it is shouldn't matter at all. If there is a difference between the two bundles while they export the same package then one of the bundles is wrong (they clearly don't export the same version of the same package). If they don't export the same package and the importer wants a particular one it should refine its import range...
For service.id. If you rely in the lowest service.id as a service consumer you should really define the service lookup filter to include additional criteria. Services can come and go dynamically so depending on a particular service that might be there first is highly unreliable...
-
2. Re: ServiceMix resurected
All true. Still, we need to define how non-osgi deployments and their associated services map to bundle.id and service.id. Currently both are assigned lazily when there is a lookup of a non-osgi service.
I'm ok with formalizing this approach for now until we see a usecase that requires to change that rule.
WRT bundle.id it would also be possible to do this eagerly because the eployemnts pass through the osgi deployer anyway. With service.id and objectClass I'd like to hear Ales' input because it is not so clear to me how these map to MC provided services.
-
3. Re: ServiceMix resurected
#1 Currently, when the providing bundle for a non-osgi ControllerContext is requested, the bundle gets dynamically generated on the fly and is registered with the BundleManager. This would assign a bundle.id to a deployment which might have been deployed earlier than the id suggests. The bundle.id is relevant in resolver preferences and possibly other use cases. Perhaps, we should register every deployment with the BM. this may also be what Adrian originally envisioned. Comment?
"we should register every deployment with the BM" -- this is how it used to be done, until you changed some behavior. ;-)
And like you say, this is how we had it planned from the beginning.
It's only dynamic so it could work with your changes at that time.
#2 In OSGi every service has two mandatory properties
- A property named Constants.SERVICE_ID identifying the registration number of the service
- A property named Constants.OBJECTCLASS containing all the specified classes.
How is the SERVICE_ID and the OBJECTCLASS for a non-osgi service defined?
See getProperty() in
on how this is currently done. Similar to bundle.id above, service.id is relevant for ServiceReference ordering. So it seems wrong that this gets assigned lazily on demand.
In any case we need proper definitions for the value of these properties for non-osgi services. Please comment.
I actually don't see a lot of value in service_id, and David's comments confirm that.
If you don't want them lazily, this can easily be fixed with some deployer that would atomically populate that value at deployment time.
I think it's only a matter of making this behavior clear and deterministic.
For objectclass, I had/have two distinctions in mind.
The one is from <osgi> / OSGiMetaData, where you explicitly define exported classes,
and the other one is plain/default/dummy pojo behavior where you export it all.
For <osgi> / OSGiMetaData we use the concept of related classes -- see usage RelatedClassMetaData in BeanMetaData.
Plain/default/dummy pojo behavior might not be the best, specially if POJO gets picked up by some service lookup query,
who's demanding bundle doesn't see impl details, in this case pojo's actual class or its super classes.
But I would leave this to the user to be careful enough to do this right.
Or perhaps some quick config flags could be written; e.g. expose just interfaces, or interfaces/classes from certain packages, etc ...
#3 The GenericServiceReferenceWrapper is currently limited to handle AbstractKernelControllerContext only. Is this correct? What use cases would require other types of ControllerContext and if so how do we define service.id and objectClass in these contexts?
Reading this again, it's not the best choice of class name.
Perhaps I also had in mind how we serve Weld, Guice, Spring beans with the same ControllerContext impl, hence generic.
Or perhaps this is a super class of the ServiceReferenceWrapper that also knows how to handle MBeans; aka ServiceControllerContext from MC-JMX-int?
We can discusss this mocking futher when we have some new ControllerContext impls.
-
4. Re: ServiceMix resurected
Or perhaps this is a super class of the ServiceReferenceWrapper that also knows how to handle MBeans; aka ServiceControllerContext from MC-JMX-int?
Just noticed that this test was not ported:
vs.
This is where I test MBeans pretending to be OSGi services; another model that needs this service-mix functionality.
Currently I only expose given/direct MBean interface as potential OSGi interface. No work on the service.id yet.