Tim,
I didn't do this here since has you might have noticed this is a factory
and the evaluation (your getRendereFor) is to determine which renderer type
to get a new instance of. We are using the pattern that you describe where
the services are just selected. But maybe it's just a piece that I'm
missing and it's a simple change.
Alain
On Fri, Aug 24, 2018 at 5:52 AM Tim Ward <tim.w...@paremus.com> wrote:
> Right, so in this case it looks like you’re running a whiteboard, is it
> possible you would be better off not using the service properties for this
> filtering? For example:
>
> @Reference(policy=DYNAMIC, cardinality=MULTIPLE)
> private final List<ZKRenderer> renderers = new CopyOnWriteArrayList<>();
>
> public ZKRenderer getRendererFor(Object o) {
> return renderers.stream()
> .filter(r -> r.supports(o))
> .collect(Collectors.maxBy((a,b) ->
> a.getPriority(o).compareTo(b.getPriority(o))))
> .orElseThrow(() -> new IllegalArgumentException("No renderer for
> object " + o));
> }
>
> Tim
>
> On 24 Aug 2018, at 10:34, Alain Picard <pic...@castortech.com> wrote:
>
> They represent classes, which is why I would have like to have a Class
> annotation so I could do "tester=MyTester.class". instead of
> "tester="com.acme.mypkg.MyTester".
>
> For example I have a number of components implementing a service and as
> part of their property they define their "filter conditions" which are then
> passed on to the 3rd party library, and there are 2 types of testers, etc:
> Component(service=ZKRenderer.class, factory=ZKRenderer.CONFIG_FACTORY,
> property= { ZKRenderer.CONFIG_STATIC_TEST +
> "=c.c.i.tester.ReferenceTree",
> ZKRenderer.CONFIG_STATIC_TEST_PRIORITY + ":Integer=9" })
>
> If I move my ReferenceTree tester in the above case, no compiler would
> catch it and I'm just looking for pain in the future.
>
> I am not sure I grasp your approach. Here clients just ask for a renderer
> (an instance of the service) for some "object" that is passed in and an
> appropriate and "highest ranking" one is returned. So the client is never
> specifying the class string at all. Here we are providing the full class
> name so it can be loaded, hence it would be much more natural to provide a
> Class object.
>
> When we have cases where the component and reference must have to match we
> do as such:
> public static final String CONFIG_QUALIFIER =
> OsgiConstants.SERVICE_QUALIFIER + "=ReferenceList"; //$NON-NLS-1$
> public static final String CONFIG_TARGET = "(" + CONFIG_QUALIFIER +
> ")"; //$NON-NLS-1$ //$NON-NLS-2$
>
> and here the component use the 1st line in its property and the reference
> target uses the 2nd constant and that is not an issue.
>
> Alain
>
>
>
> Alain Picard
> Chief Strategy Officer
> Castor Technologies Inc
> o:514-360-7208
> m:813-787-3424
>
> pic...@castortech.com
> www.castortech.com
>
>
> On Fri, Aug 24, 2018 at 5:16 AM Tim Ward <tim.w...@paremus.com> wrote:
>
>> Do these properties “represent” classes or are they actually classes? If
>> they are just representations (which would be a good thing) then you can
>> define a static string constant representing the class which is mapped
>> internally to the correct class name (which can then change over time).
>> Clients then filter based on the string representation which will not
>> change.
>>
>> Tim
>>
>>
>> On 24 Aug 2018, at 10:07, Alain Picard <pic...@castortech.com> wrote:
>>
>> Tim & all,
>>
>> My immediate use case is that my components have some properties and some
>> of those represent classes (this interfaces with 3rd party libraries, I
>> would probably design it differently if I could, but it has to be
>> configuration as it is used to determine if the component is a match, much
>> like for target filters). Properties in the component annotation are
>> String[] and that forces the specification of classes as String which is
>> very bad since if the class is moved, renamed, deleted, etc, it will cause
>> no error or warning and blow up later on. And since annotations only
>> support compile time constants, you can't do a MyClass.class.getName() to
>> even get a String. My idea was since the implementation class is part of
>> the component description, if I could get a hold of it, to have a static
>> method in the class to provide this "constant".
>>
>> How can I work around the limitations of Properties as String and Java
>> compile time constants. Am I stuck to introduce a new separate annotation
>> to track this configuration?
>>
>> Alain
>>
>> Alain
>>
>>
>> On Thu, Aug 23, 2018 at 5:24 AM Tim Ward <tim.w...@paremus.com> wrote:
>>
>>> The properties visible in the Map (or ServiceReference) are the service
>>> properties. There is some overlap with configuration (services that are
>>> configurable are encouraged to publish configuration properties as service
>>> properties) but they are separate, and can be different.
>>>
>>> The only way that something becomes a service property is if it is
>>> deliberately registered as such or, for a few specific properties such as
>>> service.id and service.scope, added automatically by the framework.
>>>
>>> The class name of the implementation would only be added as a service
>>> property if done so deliberately, and this is typically discouraged (it
>>> leaks internal implementation detail and forces your internal naming to
>>> become API). If you *really* care about the details of a service (and in
>>> general you shouldn’t) then you should mark it with a service property that
>>> you can recognise. Ideally one that is separate from the other
>>> implementation details of the service.
>>>
>>> Best Regards,
>>>
>>> Tim
>>>
>>> > On 22 Aug 2018, at 16:53, Alain Picard via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>> >
>>> > In a reference method, i can get the property configuration of the
>>> service along with the ComponentFactory and some other optional arguments.
>>> Can any of those give me a way to retrieve the implementation from the
>>> configuration (i.e. the class name of the implementation) ?
>>> >
>>> > Thanks
>>> > Alain
>>> >
>>> > _______________________________________________
>>> > OSGi Developer Mail List
>>> > osgi-dev@mail.osgi.org
>>> > https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>>
>>
>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
