You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Felix Meschberger <fm...@adobe.com> on 2013/03/10 19:52:59 UTC
[InventoryPrinter] Finding methods by reflection
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
Re: [InventoryPrinter] Finding methods by reflection
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
I have created FELIX-3963 [1] and attached two patches implementing the options.
Regards
Felix
[1] https://issues.apache.org/jira/browse/FELIX-3963
Am 11.03.2013 um 09:47 schrieb Clement Escoffier:
> Hi,
>
> What about walking in two steps:
> - first with getMethod
> - then with getDeclaredMethod and check the owner class.
>
> If the first lookup is not successful, then try with the private methods of the implementation class.
>
> Regards,
>
> Clement
>
> On 11 mars 2013, at 08:35, Felix Meschberger <fm...@adobe.com> wrote:
>
>> Hi,
>>
>> Am 10.03.2013 um 19:59 schrieb Carsten Ziegeler:
>>
>>> Hi,
>>>
>>>> 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.
>>>
>>> I think the current implementation searches the hierarchy
>>
>> Yes and no ;-) The current implementation walks the hierarchy but it uses the Class.getMethod method to find the method, which actually only returns public methods. So walking the hierarchy is essentially useless.
>>
>> Just using getDeclaredMethod is not fully correct, because you probably don't want to use a private method from a super class or a package private method from a super class in a different package. Which is why I also refer to the DS specification, which explains how to actually find and select methods from superclasses.
>>
>>
>>> - I don't
>>> have a strong preference, but I think searching the hierarchy is
>>> better.
>>
>> I somehow have the impression that subclassing is not a concern for InventoryPrinter services and in fact may not even make sense. Which is probably also why Web Console 4 does not walk the class hierarchy for finding ConfigurationPrinter methods.
>>
>> Regards
>> Felix
>>
>>>>
>>>> --
>>>> Felix Meschberger | Principal Scientist | Adobe
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org
>>
>>
>> --
>> Felix Meschberger | Principal Scientist | Adobe
>>
>>
>>
>>
>>
>>
>>
>
--
Felix Meschberger | Principal Scientist | Adobe
Re: [InventoryPrinter] Finding methods by reflection
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
What about walking in two steps:
- first with getMethod
- then with getDeclaredMethod and check the owner class.
If the first lookup is not successful, then try with the private methods of the implementation class.
Regards,
Clement
On 11 mars 2013, at 08:35, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> Am 10.03.2013 um 19:59 schrieb Carsten Ziegeler:
>
>> Hi,
>>
>>> 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.
>>
>> I think the current implementation searches the hierarchy
>
> Yes and no ;-) The current implementation walks the hierarchy but it uses the Class.getMethod method to find the method, which actually only returns public methods. So walking the hierarchy is essentially useless.
>
> Just using getDeclaredMethod is not fully correct, because you probably don't want to use a private method from a super class or a package private method from a super class in a different package. Which is why I also refer to the DS specification, which explains how to actually find and select methods from superclasses.
>
>
>> - I don't
>> have a strong preference, but I think searching the hierarchy is
>> better.
>
> I somehow have the impression that subclassing is not a concern for InventoryPrinter services and in fact may not even make sense. Which is probably also why Web Console 4 does not walk the class hierarchy for finding ConfigurationPrinter methods.
>
> Regards
> Felix
>
>>>
>>> --
>>> Felix Meschberger | Principal Scientist | Adobe
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>
Re: [InventoryPrinter] Finding methods by reflection
Posted by Carsten Ziegeler <cz...@apache.org>.
:) Just to be consistent....I'm not favoring one or the other, using
public seemed natural for me because of the interface, but allowing
non-public is fine as well.
Carsten
2013/3/11 Felix Meschberger <fm...@adobe.com>:
> Hi
>
> Why does the method need to be public ?
>
> Ok, if you implement the interface, it is by definition public. But if you don't use the interface ?
>
> Regards
> Felix
>
> Am 11.03.2013 um 14:26 schrieb Carsten Ziegeler:
>
>> 2013/3/11 Felix Meschberger <fm...@adobe.com>:
>>> Hi,
>>>
>>> Am 10.03.2013 um 19:59 schrieb Carsten Ziegeler:
>>>
>>>> Hi,
>>>>
>>>>> 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.
>>>>
>>>> I think the current implementation searches the hierarchy
>>>
>>> Yes and no ;-) The current implementation walks the hierarchy but it uses the Class.getMethod method to find the method, which actually only returns public methods. So walking the hierarchy is essentially useless.
>>>
>> Ah, right - yes the idea was that the method has to be public,
>> otherwise the service is not used, now I remember :)
>>
>> Carsten
>>
>>> Just using getDeclaredMethod is not fully correct, because you probably don't want to use a private method from a super class or a package private method from a super class in a different package. Which is why I also refer to the DS specification, which explains how to actually find and select methods from superclasses.
>>>
>>>
>>>> - I don't
>>>> have a strong preference, but I think searching the hierarchy is
>>>> better.
>>>
>>> I somehow have the impression that subclassing is not a concern for InventoryPrinter services and in fact may not even make sense. Which is probably also why Web Console 4 does not walk the class hierarchy for finding ConfigurationPrinter methods.
>>>
>>> Regards
>>> Felix
>>>
>>>>>
>>>>> --
>>>>> Felix Meschberger | Principal Scientist | Adobe
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Carsten Ziegeler
>>>> cziegeler@apache.org
>>>
>>>
>>> --
>>> Felix Meschberger | Principal Scientist | Adobe
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [InventoryPrinter] Finding methods by reflection
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Why does the method need to be public ?
Ok, if you implement the interface, it is by definition public. But if you don't use the interface ?
Regards
Felix
Am 11.03.2013 um 14:26 schrieb Carsten Ziegeler:
> 2013/3/11 Felix Meschberger <fm...@adobe.com>:
>> Hi,
>>
>> Am 10.03.2013 um 19:59 schrieb Carsten Ziegeler:
>>
>>> Hi,
>>>
>>>> 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.
>>>
>>> I think the current implementation searches the hierarchy
>>
>> Yes and no ;-) The current implementation walks the hierarchy but it uses the Class.getMethod method to find the method, which actually only returns public methods. So walking the hierarchy is essentially useless.
>>
> Ah, right - yes the idea was that the method has to be public,
> otherwise the service is not used, now I remember :)
>
> Carsten
>
>> Just using getDeclaredMethod is not fully correct, because you probably don't want to use a private method from a super class or a package private method from a super class in a different package. Which is why I also refer to the DS specification, which explains how to actually find and select methods from superclasses.
>>
>>
>>> - I don't
>>> have a strong preference, but I think searching the hierarchy is
>>> better.
>>
>> I somehow have the impression that subclassing is not a concern for InventoryPrinter services and in fact may not even make sense. Which is probably also why Web Console 4 does not walk the class hierarchy for finding ConfigurationPrinter methods.
>>
>> Regards
>> Felix
>>
>>>>
>>>> --
>>>> Felix Meschberger | Principal Scientist | Adobe
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org
>>
>>
>> --
>> Felix Meschberger | Principal Scientist | Adobe
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
--
Felix Meschberger | Principal Scientist | Adobe
Re: [InventoryPrinter] Finding methods by reflection
Posted by Carsten Ziegeler <cz...@apache.org>.
2013/3/11 Felix Meschberger <fm...@adobe.com>:
> Hi,
>
> Am 10.03.2013 um 19:59 schrieb Carsten Ziegeler:
>
>> Hi,
>>
>>> 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.
>>
>> I think the current implementation searches the hierarchy
>
> Yes and no ;-) The current implementation walks the hierarchy but it uses the Class.getMethod method to find the method, which actually only returns public methods. So walking the hierarchy is essentially useless.
>
Ah, right - yes the idea was that the method has to be public,
otherwise the service is not used, now I remember :)
Carsten
> Just using getDeclaredMethod is not fully correct, because you probably don't want to use a private method from a super class or a package private method from a super class in a different package. Which is why I also refer to the DS specification, which explains how to actually find and select methods from superclasses.
>
>
>> - I don't
>> have a strong preference, but I think searching the hierarchy is
>> better.
>
> I somehow have the impression that subclassing is not a concern for InventoryPrinter services and in fact may not even make sense. Which is probably also why Web Console 4 does not walk the class hierarchy for finding ConfigurationPrinter methods.
>
> Regards
> Felix
>
>>>
>>> --
>>> Felix Meschberger | Principal Scientist | Adobe
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [InventoryPrinter] Finding methods by reflection
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 10.03.2013 um 19:59 schrieb Carsten Ziegeler:
> Hi,
>
>> 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.
>
> I think the current implementation searches the hierarchy
Yes and no ;-) The current implementation walks the hierarchy but it uses the Class.getMethod method to find the method, which actually only returns public methods. So walking the hierarchy is essentially useless.
Just using getDeclaredMethod is not fully correct, because you probably don't want to use a private method from a super class or a package private method from a super class in a different package. Which is why I also refer to the DS specification, which explains how to actually find and select methods from superclasses.
> - I don't
> have a strong preference, but I think searching the hierarchy is
> better.
I somehow have the impression that subclassing is not a concern for InventoryPrinter services and in fact may not even make sense. Which is probably also why Web Console 4 does not walk the class hierarchy for finding ConfigurationPrinter methods.
Regards
Felix
>>
>> --
>> Felix Meschberger | Principal Scientist | Adobe
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
--
Felix Meschberger | Principal Scientist | Adobe
Re: [InventoryPrinter] Finding methods by reflection
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
> 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.
I think the current implementation searches the hierarchy - I don't
have a strong preference, but I think searching the hierarchy is
better.
Carsten
>
> 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
>
>
>
>
>
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [InventoryPrinter] Finding methods by reflection
Posted by Felix Meschberger <fm...@adobe.com>.
Ok, So I'll refactor along these lines.
Regards
Felix
Am 12.03.2013 um 04:22 schrieb Carsten Ziegeler:
> 2013/3/12 Felix Meschberger <fm...@adobe.com>:
>>
>> 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.
>
> +1
>
> Carsten
>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
--
Felix Meschberger | Principal Scientist | Adobe
Re: [InventoryPrinter] Finding methods by reflection
Posted by Carsten Ziegeler <cz...@apache.org>.
2013/3/12 Felix Meschberger <fm...@adobe.com>:
>
> 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.
+1
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [InventoryPrinter] Finding methods by reflection
Posted by Felix Meschberger <fm...@adobe.com>.
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