> From: "Humeniuk, David P" <[email protected]>
> >>> It can provide both. We recently clarified the Metatype spec for R6 to > >>> more clearly state that a bundle can provide both metatype resources > >>>and > >>> MetaTypeProvider services. The spec is clarified to say that if the > >>>bundle > >>> provides metatype resources, then a MetaTypeService implementation must > >>> not look for ManagedService/ManagedServiceFactory services that are > >>> instances of MetaTypeProvider (and, of course, not registered as > >>> MetaTypeProvider services.) > > > I¹m confused, you say a bundle can provide both, then go on to say if a > bundle provides resources the service should not look for instances of > MetaTypeProvider services. I specifically referred to ManagedService and ManagedFactoryService services which are also instances of MetaTypeProvider (but not registered as MetaTypeProvider services). If your bundle does NOT have metatype resources, then a MetaTypeService implementation must examine the ManagedService and ManagedFactoryService services of the bundle to see if they are also instances of MetaTypeProvider. If your bundle does have metatype resources, then a MetaTypeService implementation must NOT examine the ManagedService and ManagedFactoryService services of the bundle to see if they are also instances of MetaTypeProvider. MetaTypeProvider services (registered under the MetaTypeProvider name) are always used. > Are you saying that previously it was possible, > but is no longer allowed in R6? We are just clarifying the spec because the wording is not clear enough in R5. > Either way the current implementation from > Apache Felix doesn¹t allow this. You should file a JIRA issue against the Felix MetaTypeService implementation. > I have a workaround to register my > MetaTypeProvider with a dummy bundle, but that is definitely a hack. Hopefully, your dummy bundle is using the bundle context of the "real" bundle so that the MetaTypeProvider service appears to be registered by the real bundle. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
