Hi I have been thinking a bit more: I think we should not use reflection any longer for finding the InventoryPrinter and AttachmentProvider methods any more.
We introduced this reflection use for the ConfigurationPrinter service because we thought it would be a good idea to not force a WebConsole wiring on a bundle, whose primary task is something completely different. The image we had was that the bundle had to be wired statically to the Web Console API before it could even start and we didn't want to prevent a bundle from starting to service just because the administrative hook was not supported in a certain deployment. In the meantime we have found an existing nice solution in the OSGi context itself: (a) the import is declared as a DynamicImport-Package (not required to resolve the bundle but requested and available on demand) and (b) ServiceFactory services. Together these mechanisms nicely solve the issue: Only when the ConfigurationPrinter service is actually required is the service instance created (ServiceFactory) and the API wired (DynamicImport-Package). And the service can only be acquired if there is some API to wire to (because the assumption is that the service requester has access to this API). So, here we are: * For the deprecated ConfigurationPrinter we still support reflection * For the InventoryPrinter we don't support reflection but suggest to use the delayed mechanism with dynamic wiring and ServiceFactory. WDYT ? Regards Felix Am 10.03.2013 um 19:52 schrieb Felix Meschberger: > Hi, > > The InventoryPrinter service is the successor of the Web Console > ConfigurationPrinter service. And like the ConfigurationPrinter service an > InventoryPrinter service does not need to be registered as an > InventoryPrinter service: As long as the service is registered with some > service registration properties and a method > > print(String, PrintWriter, boolean) > > is defined, the service will be accepted as an InventoryPrinter. > > The question is how to find this method ? > > * Search in the service's class only or in the class hierarchy ? > * Supporting public/protected only or also package private > and private methods ? > > My opinion would be: > > (a) search the implementation class only > (b) accept all method modifiers > (c) document to prefer private > > Alternatively we could search the class hierarchy as is defined in section > 112.9.4 (Locating Component Methods) of the Declarative Services > specification. > > WDYT ? > > Regards > Felix > > PS: Web Console 4 supported (for the ConfigurationPrinter) searching the > implementation class only and supporting any modifier. > > -- > Felix Meschberger | Principal Scientist | Adobe > > > > > > > -- Felix Meschberger | Principal Scientist | Adobe
