felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Evanchik (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-3023) bundlerepository does not support RFC 112 Greater and Less operators
Date Thu, 07 Jul 2011 14:55:16 GMT

    [ https://issues.apache.org/jira/browse/FELIX-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061356#comment-13061356

Stephen Evanchik commented on FELIX-3023:

Yes, I found an email thread referenced from FELIX-973 that indicated using a Filter with
extensions in the Framework was not desirable but that the OBR implementation should not be
similarly constrained:


If I understand everything correctly there were two implementations of the LDAP Filter: one
in the Framework and one for OBR (see FELIX-973). In FELIX-2134 Guillaume updated the Filter
code to be faster/better but left out the RFC 112 extensions. It is at this point where I'm

I don't know what happened to the Filter code after FELIX-2134. There is no longer a FilterImpl
in the bundlerepository project it simply refers to the one in the utils project.

I created this issue because I'm attempting to use RFC 112 compliant code to generate the
OBR XML document so that Felix's bundlerepository project can consume it. What change would
you like to see to make bundlerepository adhere to RFC 112 in this regard? (Maybe it already
does but I'm doing something wrong?)

> bundlerepository does not support RFC 112 Greater and Less operators
> --------------------------------------------------------------------
>                 Key: FELIX-3023
>                 URL: https://issues.apache.org/jira/browse/FELIX-3023
>             Project: Felix
>          Issue Type: Bug
>          Components: Bundle Repository (OBR)
>    Affects Versions: bundlerepository-1.6.4
>         Environment: Apache Karaf 2.2.1 / bundlerepository 1.6.4
>            Reporter: Stephen Evanchik
>         Attachments: rfc112_5.6.1_exclusive_inequality_operators.patch
> I am using Ivy's "buildobr" Ant task to construct an OBR from my Eclipse installation.
It is generating filters in the following format:
>   (&(package=org.eclipse.core.runtime)(version<1.5.0))
> which cannot be parsed by the org.apache.felix.bundlerepository in Karaf 2.2.1
> I see the following exceptions in the Karaf logs:
> java.lang.Exception: Error while parsing resource null at line 10 and column 129
>      at org.apache.felix.bundlerepository.impl.PullParser.parseResource(PullParser.java:241)
>      at org.apache.felix.bundlerepository.impl.PullParser.parse(PullParser.java:138)
> .... skipping moderately relevant information ...
>  Caused by: org.osgi.framework.InvalidSyntaxException: Missing ')': (bundle=org.eclipse.wst.common.project.facet.core)))
>      at org.apache.felix.utils.filter.FilterImpl$Parser.parse_filter(FilterImpl.java:1203)
>      at org.apache.felix.utils.filter.FilterImpl$Parser.parse_and(FilterImpl.java:1248)
>      at org.apache.felix.utils.filter.FilterImpl$Parser.parse_filtercomp(FilterImpl.java:1222)
>      at org.apache.felix.utils.filter.FilterImpl$Parser.parse_filter(FilterImpl.java:1198)
>      at org.apache.felix.utils.filter.FilterImpl$Parser.parse(FilterImpl.java:1172)
>      at org.apache.felix.utils.filter.FilterImpl.newInstance(FilterImpl.java:87)
>      at org.apache.felix.bundlerepository.impl.RequirementImpl.setFilter(RequirementImpl.java:74)
> After looking through several examples of OBR XML files and reading the spec I understand
that the original OBR spec/implementation simply inherited the LDAP Filter constraints from
the core OSGi specification.
> This was fixed by FELIX-973 for bundlerepository-1.4.0 in 2009 but after FELIX-2134 was
committed it appears to have reverted to the standard OSGi LDAP Filter constraints.
> Making matters worse (for my at least) is HEAD has changed substantially from FELIX-2134
and I'm not sure where to put the OBR specific FilterImpl.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message