Hi Alexander, Yes, at the moment the discovery implementation relies on the objectClass being set. The reasoning behind this relates to scalability. If you have a large distributed discovery system you probably don't want to select all the available remote services in the system, as that could bring in a huge amount of remote services. Since objectClass is typically known to the consumer we added this as a criterium.
However, I do see that this can be useful in smaller systems. So I agree that it would be worth enhancing the implementation to support your use case (feel free to file a JIRA :) Just a note, you may have seen this message: http://old.nabble.com/Migrating-CXF-DOSGi-to-be-complaint-with-the-new-OSGi-Remote-Service--Admin-spec-td26645023.html We're currently in the process of refactoring the CXF-DOSGi implementation to be compliant with the new Remote Service Admin spec. I think it would be good to look at your enhancement request after that refactoring is complete. Best regards, David 2009/12/11 Alexander Broekhuis <a.broekh...@gmail.com>: > Hi all, > > I am trying to use a service listener that handles all imported interfaces, > without knowing what the actual interface is. To do this, I created a > service listener with the following filter: (service.imported=true). > But this doesn't work. > > In the CxfFindListenerHook there is a check to see if objectClass is filled > in. If this is not the case, the discovery is not accessed to look for > remote services. > I know the imported property is only set on the imported proxy registration, > and not part of the actual remote service. So it isn't published in > discovery. This would mean that the service listener will be notified of all > remote services found in the discovery, which is exactly what I want. > > Is this something I can solve differently? > If not, is this a bug/feature request? > > > Thanx in advance, > > -- > Met vriendelijke groet, > > Alexander Broekhuis >
