On Jan 3, 2008, at 8:30 AM, Thomas Watson wrote:

According to the javadoc there is no syntax check done on the pattern.

I'm not sure that I see this explicitly stated in the javadocs.
If the pattern includes characters which cannot legally be part of a jar entry name then the call will always return null because no matching entry will be found. Interestingly enough it appears ZipFile in Java does allow entries to contain the '\' char and probably lots of other characters which are not valid characters on many file systems. The content of the bundle entries are represented in a jar file, not directly on the file system so this should not be an issue in general.

Some frameworks do support "directory" style bundles where the content can be exploded into the file system. In these cases you will only find entries which have valid chars for the file system you are running on. But we probably cannot accurately specify a complete character set of invalid file characters across all file system flavors. Instead we just use the pattern as-is (except the wildcard '*' character) and see if we can find a match.

I'm not sure that the two paragraphs speak to my concern about a *syntax* error in the filter pattern.

As I think more on this I think that given the current state of affairs the only thing that this method can do is to silently return nothing. Ideally it would have thrown an InvalidSyntaxException to be consistent w/ createFilter() and to limit developer confusion when the method returns nothing. I guess it's too late for that given the fact that the exception is not a runtime exception.

Maybe it would be better to distance, or even remove, the association with the substring filter and, instead explicitly state the specialized "substring" syntax that's to be used for findEntries() in the documentation.


Regards,
Alan


Tom



<graycol.gif>Alan Cabrera ---01/02/2008 06:03:53 PM---"foo\"

<ecblank.gif>
From:   <ecblank.gif>
Alan Cabrera <[EMAIL PROTECTED]>
<ecblank.gif>
To:     <ecblank.gif>
OSGi Developer Mail List <[email protected]>
<ecblank.gif>
Date:   <ecblank.gif>
01/02/2008 06:03 PM
<ecblank.gif>
Subject:        <ecblank.gif>
Re: [osgi-dev] findEntries' filePattern




"foo\"


Regards,
Alan

On Jan 2, 2008, at 2:53 PM, BJ Hargrave wrote:

> findEntries is really just using the rvalue of the substring
> production of
> section 3.2.6. Thus, the only interesting character is the '*'
> which isn't
> a legal file name char anyway (certainly in most commonly used file
> systems.)
>
> Can you construct a pattern that you believe is a syntax error?
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance
> [EMAIL PROTECTED]
>
> office: +1 386 848 1781
> mobile: +1 386 848 3788
>
>
>
>
> From:
> Alan Cabrera <[EMAIL PROTECTED]>
> To:
> OSGi Developer Mail List <[email protected]>
> Date:
> 2008-01-02 17:03
> Subject:
> Re: [osgi-dev] findEntries' filePattern
>
>
>
> I'm probably being dense but IIRC, the pattern can be escaped and, so,
> be escaped incorrectly.
>
>
> Regards,
> Alan
>
> On Jan 2, 2008, at 10:57 AM, BJ Hargrave wrote:
>
>> Well it uses the wildcard method of the filter string. So I am not
>> sure
>> there can be a syntax error. But, if nothing matches the pattern,
>> null is
>> the return.
>> --
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM
>> OSGi Fellow and CTO of the OSGi Alliance
>> [EMAIL PROTECTED]
>>
>> office: +1 386 848 1781
>> mobile: +1 386 848 3788
>>
>>
>>
>>
>> From:
>> Alan Cabrera <[EMAIL PROTECTED]>
>> To:
>> OSGi List Developer Mail <[email protected]>
>> Date:
>> 2007-12-18 02:07
>> Subject:
>> [osgi-dev] findEntries' filePattern
>>
>>
>>
>> It seems to me that filePattern can have a syntax error.  It's not
>> clear to me what a call to findEntries() should do in this situation.
>> I'm guessing that it should probably return null.  Maybe I missed
>> something.
>>
>>
>> Regards,
>> Alan
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> http://www2.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> http://www2.osgi.org/mailman/listinfo/osgi-dev
>>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> http://www2.osgi.org/mailman/listinfo/osgi-dev
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> http://www2.osgi.org/mailman/listinfo/osgi-dev
>

_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev

Reply via email to