[
https://issues.apache.org/jira/browse/FELIX-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741755#action_12741755
]
Marcel Offermans commented on FELIX-1464:
-----------------------------------------
You are right that even though the filter used in the underlying ServiceTracker
does not filter on the name of the service, the addingService() method does.
Therefore it makes sense to include the service name in the filter condition. I
do find the serviceFilter.indexOf("objectClass") a bit too tricky to commit. I
understand what you're trying to achieve, but I don't think this is the right
way to do it. In fact, I believe we should not add that condition at all. Three
scenarios here:
1) The user did not manually add an objectClass condition to the filter. This
will work, we just add our condition.
2) The user already added an objectClass condition to the filter, on the same
class we're about to add. This will work, but the condition is part of the
expression twice. One could argue that the filter expression parser could
optimize that away if it's smart.
3) The user already added an objectClass condition for a *different* class.
This will not work, with our without the check you added, since in the end, the
filter condition will conflict with the filtering done in addingService() so
you won't ever find a match.
Therefore I propose to include the patch without this extra check.
> issue when using a negation in ldap service dependency filter
> -------------------------------------------------------------
>
> Key: FELIX-1464
> URL: https://issues.apache.org/jira/browse/FELIX-1464
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
> Affects Versions: dependencymanager-2.0.1
> Reporter: Arjun Panday
> Assignee: Marcel Offermans
> Priority: Minor
>
> I found an issue when using a negation in the service dependency ldap filter
> (or more generally when the filter alone is not sufficient to narrow the
> search down to the required service).
> Let's consider the following bundle activator:
> public class Activator extends DependencyActivatorBase {
>
> interface Toto { }
> private Toto _toto; //injected
>
> public void init(BundleContext ctx, DependencyManager mgr) throws Exception
> {
> mgr.add(createService()
> .setInterface(Toto.class.getName(), new Hashtable() {{
> put("key", "toto");
> }})
> .setImplementation(new Toto() {
> public String toString() { return "toto"; }
> }));
> mgr.add(createService()
> .setImplementation(this)
> .add(createServiceDependency()
> .setService(Toto.class, "(!(key=tutu))")
> .setAutoConfig("_toto").setRequired(true)));
> }
> public void start() {
> System.out.println("got _toto="+_toto);
> }
> public void destroy(BundleContext ctx, DependencyManager mgr) throws
> Exception {
> }
> }
> When deployed in a framework with a WebConsole, we can see under the
> "Configuration Status" tab that ALL the services in the registry (like all
> the org.apache.felix.shell.Command for instance) are shown as being used by
> our test bundle (list of "Using bundles").
> From our test bundle point of view, only the correct service is bound because
> DM's ServiceTrackerCustomizer will filter out all services whose name don't
> match the expected one.
> But from the service registry point of view it looks quite messy.
> Besides being very confusing on the WebConsole page, it becomes a real
> problem when, for example, lazy activated services managed by
> DeclarativeService are activated when they should not.
> Merely as a suggestion, I found the following patch which corrects the issue:
> Index: src/main/java/org/apache/felix/dependencymanager/ServiceDependency.java
> ===================================================================
> --- src/main/java/org/apache/felix/dependencymanager/ServiceDependency.java
> (revision 802768)
> +++ src/main/java/org/apache/felix/dependencymanager/ServiceDependency.java
> (working copy)
> @@ -530,7 +530,9 @@
> throw new IllegalArgumentException("Service name cannot be
> null.");
> }
> m_trackedServiceName = serviceName;
> - m_trackedServiceFilter = serviceFilter;
> + if(m_trackedServiceName != null && serviceFilter != null &&
> serviceFilter.indexOf("objectClass") < 0) {
> + m_trackedServiceFilter =
> "(&(objectClass="+m_trackedServiceName.getName()+")"+serviceFilter+")";
> + } else m_trackedServiceFilter = serviceFilter;
> m_trackedServiceReference = null;
> return this;
> }
> Best regards,
> Arjun
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
