I don’t get it. My understanding of your last suggestion is that all the services you want to bind implement some interface, and that DS check type compatibility with this interface before accepting the service event (or discovery-by-query) before binding. How is this any different than putting that interface in the ObjectClass the service exposes, aside from duplicating functionality already managed by the service registry?
Why can’t you do what you want today by including Object in the ObjectClass of all the services you want to bind, and declaring Object as the interface in all the references? thanks david jencks > On Apr 8, 2016, at 6:23 AM, Simon Chemouil <schemo...@gmail.com> wrote: > > Hi, > > For the record I have had the same need as Jens in the past. As Neil > suggested, I ended up using a ServiceTracker but this is a pity. > > BJ recently talked about a DS spec update. I have a few ideas > (in-component control of service registration for one, to support > asynchronous activations better!). > > To improve the situation Jens is describing, I would suggest making the > "interface" attribute of the "reference" element optional, in which case > only the "target" attribute would be taken into account for the filter. > > Now there are 2 options: either it would be up to the component > developer to make sure the method parameter type is compatible with the > service type (e.g use Object to be safe or another interface that he > considers "implied" by a specific set of service properties), or that > specific object type would become a new parameter (assignationType ?) > and DS would test for "assignability" before actually binding the > service if "attr(assignationType) != attr(interface)". The second design > is nice, and backwards compatible (by default, assignationType = interface). > > The @Reference annotation might (or not) get that capability through a > new parameter, false by default, such as "ignoreInterface". > > My use case: getting rid of ugly marker interfaces for services which a > "dynamic interface" (discovered through reflection on runtime > annotations). If needed I could show some pseudo-code to illustrate the > pattern. > > I understand the KISS camp is urging for an opinionated 80/20 approach, > but this is a very small update that would allow a bunch of new cool > stuff. :) > > Cheers, > Simon > > Le 08/04/2016 11:32, Neil Bartlett a écrit : >> Hi Jens, >> >> Can you clarify please… are you saying that you want to inject services of >> *any* type, using some kind of filter that looks at the other properties of >> the service reference? >> >> This is an unusual requirement, and I don’t think you can do it with DS’s >> event strategy. You should use a ServiceTracker instead. >> >> Regards, >> Neil >> >> >>> On 8 Apr 2016, at 10:23, Jens Offenbach <wolle5...@gmx.de> wrote: >>> >>> Sorry, but I am confronted with a new problem. >>> >>> I am declaring a Reference annotation on a method, but I cannot declare a >>> service interface. If I declare nothing than Object gets used and nothing >>> is happening. When I remove the interface definition from my XML >>> descriptor, SCR validation fails with "An interface must be declared for >>> the reference". I have a filter expression that selects my services, but >>> they do not have an interface in common. >>> >>> I have to select some service based on a filter expression without >>> indicating a service interface. How is this achievable? >>> >>> Again... Thanks a lot for your help! >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> For additional commands, e-mail: users-h...@felix.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
