You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Peter Kriens <pe...@aqute.biz> on 2008/10/01 08:39:10 UTC
Re: AW: AW: Problem with bindex/generation of repository.xml
Well, they call it age :-) It gets even worse after you get children ...
Kind regards,
Peter Kriens
On 30 sep 2008, at 18:48, Richard S. Hall wrote:
> Well, I definitely don't remember talking about these, but I agree
> that the filter is currently insufficient to handle these issues.
>
> -> richard
>
>
> Peter Kriens wrote:
>> They are definitely in RFC 112 ... and it has your name on it :-)
>>
>> From RFC 112:
>>
>> 5.6 Filter Extensions
>> The OSGi filter language is based on LDAP. For this specification,
>> the filter is extended with new capabilities.
>> 5.6.1 Greater and Less Operators
>> The filter supports now all comparison operators: <, >, >=, <=. The
>> absence of the < and > operators should have
>> been fixed in R4.
>> 5.6.2 Set Arithmetic
>> The Filter must support SUBSET and SUPERSET capabilities. The set
>> operators are:
>> key *> 1,2 SUPERSET <key> must contain at least 1 and 2
>> but may contain more.
>> key <* 1,2 SUBSET All of <key> must be in {1,2}.
>> For a
>> single property, this is a member
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>> On 30 sep 2008, at 15:17, Richard S. Hall wrote:
>>
>>> Richard S. Hall wrote:
>>>> Peter Kriens wrote:
>>>>> Well, if Felix's OBR uses its framework filter it needs to
>>>>> create its own filter. You can not reuse the framework
>>>>> filter ... This is not a big deal.
>>>>
>>>> Well, we'd gladly take a contribution in this area. :-)
>>>
>>> Seriously, though, Peter, I don't remember having any discussion
>>> around these operators and adding them to OBR...
>>>
>>> -> richard
>>>
>>>>
>>>> -> richard
>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Peter Kriens
>>>>>
>>>>>
>>>>> On 30 sep 2008, at 10:58, Hampel, Michael wrote:
>>>>>
>>>>>> Ok - if I understand you right this would mean to change Felix
>>>>>> OBR's code
>>>>>> to strip the unrecognized operators before it calls
>>>>>> BundleContextImpl.createFilter()?
>>>>>> Or do you mean to change the Equinox implementation?
>>>>>>
>>>>>> Thanx again,
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: Peter Kriens [mailto:peter.kriens@aqute.biz]
>>>>>> Gesendet: Dienstag, 30. September 2008 09:50
>>>>>> An: users@felix.apache.org
>>>>>> Betreff: Re: AW: Problem with bindex/generation of repository.xml
>>>>>>
>>>>>> The problem is that the OSGi filter syntax is too restricted
>>>>>> for the
>>>>>> kind of things you need to do for OBR. Therefore, OBR
>>>>>> implementations
>>>>>> must add these operators as described in RFC 112. I am not sure
>>>>>> what
>>>>>> software you are running, but the software should adapt ... The
>>>>>> OBR
>>>>>> filter syntax is a superset of the OSGi filter syntax.
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Peter Kriens
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 30 sep 2008, at 08:03, Hampel, Michael wrote:
>>>>>>
>>>>>>>
>>>>>>> Hello Mr. Kriens,
>>>>>>>
>>>>>>> Thank you for your answer and clarifications - but I still
>>>>>>> have to
>>>>>>> avoid the InvalidSyntaxException.
>>>>>>> Would it be better to change bindex code to not add the
>>>>>>> mandatory
>>>>>>> header or
>>>>>>> To alter the Spring-core manifest file?
>>>>>>>
>>>>>>> Thanks again for any help,
>>>>>>>
>>>>>>> Michael
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>> Von: Peter Kriens [mailto:peter.kriens@aqute.biz]
>>>>>>> Gesendet: Montag, 29. September 2008 21:35
>>>>>>> An: users@felix.apache.org
>>>>>>> Betreff: Re: Problem with bindex/generation of repository.xml
>>>>>>>
>>>>>>> The <* is an operator that I added to the filter. It mean that
>>>>>>> the
>>>>>>> attribute can have multiple values and is therefor a set. This
>>>>>>> set
>>>>>>> must then be a subset of the right hand site. RFC 112
>>>>>>> elaborates this
>>>>>>> further. I tried to get these operators (subset/superset) part
>>>>>>> of the
>>>>>>> spec but it was rejected. However, OBR needed them to model
>>>>>>> mandatory
>>>>>>> directive. There you have a set of attribute names that all
>>>>>>> needed to
>>>>>>> be present.
>>>>>>>
>>>>>>> In this case, mandatory: is the set of attribute names in the
>>>>>>> expression, and we verify that they are all there with <*
>>>>>>> operator.
>>>>>>> Again, these operators did not make for the next OSGi release.
>>>>>>>
>>>>>>> Hope this helps, RFC 1112 can be found here: http://www.osgi.org/Download/File?url=/download/rfc-0112_BundleRepository.pdf
>>>>>>>
>>>>>>> Kind regards,
>>>>>>>
>>>>>>> Peter Kriens
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 29 sep 2008, at 13:00, Hampel, Michael wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> today I ran into a problem when generating my repository.xml
>>>>>>>> with
>>>>>>>> bindex:
>>>>>>>> Spring-core has a manifest entry:
>>>>>>>> org.eclipse.core.runtime;resolution:=optional;common=split
>>>>>>>>
>>>>>>>> Bindex will generate the following <require> entry:
>>>>>>>>
>>>>>>>> <require extend='false'
>>>>>>>> filter='(&(package=org.eclipse.core.runtime)
>>>>>>>> (version>=0.0.0)
>>>>>>>> (comm
>>>>>>>> on=split)(mandatory:<*common))'
>>>>>>>> multiple='false' name='package' optional='true'>
>>>>>>>> Import package org.eclipse.core.runtime
>>>>>>>> </require>
>>>>>>>>
>>>>>>>> The problem is the
>>>>>>>>
>>>>>>>> mandatory:<*common
>>>>>>>>
>>>>>>>> entry - this will cause an
>>>>>>>> org.osgi.framework.InvalidSyntaxException
>>>>>>>> in
>>>>>>>> the org.eclipse.osgi.framework.internal.core.FilterImpl class
>>>>>>>> for the
>>>>>>>> mandatory: input.
>>>>>>>>
>>>>>>>> Why does bindex add this attribute and what does it stand for?
>>>>>>>>
>>>>>>>> Thanx in advance for any help,
>>>>>>>>
>>>>>>>> Michael
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org