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