[
https://issues.apache.org/jira/browse/FELIX-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639306#action_12639306
]
Stuart McCulloch commented on FELIX-721:
----------------------------------------
Which version of Felix are you using - 1.2.1 or trunk?
That particular stack trace doesn't make sense if you're using trunk because
line 601 is appending a string constant to the passed in buffer, which must be
non-null according to the code path. I would have expected to see line 605 in
trunk, as this line makes the recursive call to toStringInfix shown in the
stack trace. But looking at the 1.2.1 sources, line 601 does make sense, so I
guess you're using 1.2.1 - which also correlates because 1.2.1 doesn't contain
the parser fix.
So in short, the problem is fixed in trunk but is not yet available in a
release.
> NPE in FilterImpl.toString()
> ----------------------------
>
> Key: FELIX-721
> URL: https://issues.apache.org/jira/browse/FELIX-721
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: felix-1.0.4
> Reporter: Don Brown
> Assignee: Karl Pauls
> Attachments: ldap.patch
>
>
> We see this NPE occasionally, probably 10% of the time on application startup:
> [java] java.lang.NullPointerException
> [java] at
> org.apache.felix.framework.util.ldap.Parser$AndOperator.toStringInfix(Parser.java:601)
> [java] at
> org.apache.felix.framework.util.ldap.Evaluator.toStringInfix(Evaluator.java:184)
> [java] at
> org.apache.felix.framework.FilterImpl.toString(FilterImpl.java:242)
> [java] at java.lang.String.valueOf(String.java:2615)
> [java] at java.lang.StringBuffer.append(StringBuffer.java:220)
> [java] at
> org.springframework.osgi.service.importer.DefaultOsgiServiceDependency.<init>(DefaultOsgiServiceDependency.java:52)
> [java] at
> org.springframework.osgi.extender.internal.dependencies.startup.MandatoryImporterDependencyFactory.getServiceDependencies(MandatoryImporterDependencyFactory.java:69)
> [java] at
> org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.findServiceDependencies(DependencyServiceManager.java:233)
> [java] at
> org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:248)
> [java] at
> org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:172)
> [java] at
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:136)
> [java] at
> org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:746)
> [java] at java.lang.Thread.run(Thread.java:613)
> My first guess would be we are constructing a filter improperly in our Spring
> config, but the fact that it only happens some of the time is strange. If
> nothing else, it would be nice if this bit of code was a bit more defensive.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
