Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-06-25 16:19:27
|
I quite like "classpath*:" too: It's a resource pattern prefix, just =
like "classpath:" is a resource location prefix. Everything after the =
":" should be the actual resource pattern, so I don't really like a "*" =
there.
=20
"classpath*:*-beans.xml" will _not_ work, as the implementation =
considers the path after "classpath*:" a standard classpath resource =
location. This means that the location after "classpath*:" is not =
supposed to contain an Ant-style pattern in any case; it will not be =
parsed but rather passed straight through to the ClassLoader.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Tom Turelinckx
Gesendet: Fr 25.06.2004 12:16
An: spr...@li...
Betreff: Re: [Springframework-developer] Retrieve all class path =
resources with the same name
I've been thinking about this, and though I had some doubts at first, I
definitely like "classpath*:" now, because of the * character.
The point is that ResourceLoader takes a location, while
ResourcePatternResolver takes a location _pattern_, and depending on the
place where you use a resource string, a location pattern may or may not
be allowed. In this regard it is important to think of
"classpath:beans.xml" as a location, and "classpath*:beans.xml" as a
location pattern.
Thus, a resource location always results in at most one matching file,
which is consistent with the way Resource and ResourceLoader are
defined.
I think we should clearly document that "classpath*:" is not considered
a prefix, but part of a location pattern, so its use is only allowed
where location patterns are allowed.
The implementation is tricky though. I suppose "classpath:*-beans.xml"
would work if the individual locations are resolvable to File, but what
about "classpath*:*-beans.xml"? Not that I would try to use a pattern
like that myself though ;-)
Kind regards,
Tom.
On Fri, 25 Jun 2004 09:25:00 +0200, "j=FCrgen h=F6ller [werk3AT]"
<jue...@we...> said:
> Any thoughts about the prefix naming? Is "classpath*:" for explictly
> wanting all matching classpath resources fine?
>=20
> Juergen
>=20
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
von
> j=FCrgen h=F6ller [werk3AT]
> Gesendet: Do 24.06.2004 09:56
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Retrieve all class path
> resources with the same name
>
>
>
> Colin,
>
> You do have a point there. We coul use a prefix like "classpath*:" for
> loading all matching resources from the classpath. ("resources:" is =
too
> general, IMO: It's about multiple _classpath_ resources.) That would =
keep
> the behavior of "classpath:" in any case, and allow to explicitly =
specify
> "I want all matching resources" via "classpath*:".
>
> Interestingly, a classpath resource string is the only resource =
location
> accepted by Spring's ResourceLoader that is not unique but can result =
in
> multiple matching files.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
von
> Colin Sampaleanu
> Gesendet: Do 24.06.2004 06:06
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Retrieve all class path
> resources with the same name
>
>
>
> I've been thinking about this, and was wondering if it's appropriate
> that _all_ matching resources are found, all the time, and also if we
> should be worried about a backwards incompatible change.
>
> Before, in ClassPathXmlApplicationContext, the locations
> beans.xml
> and
> classpath:beans.xml
> would return one resource, regardless of how many there were.
>
> Now the former still returns one, while the latter returns 1-x.
>
> Is it a problem that we've made a backwards incompatible change for =
the
> latter form?
> Is it a problem that somebody, if they want just one resource, has to
> know that they need to use the first form? Additionally to this, this
> distinction is possible when something like
> ClassPathXmlApplicationContext, but for others that override the =
default
> getResourceByPath to default to something else than a classpath
> resource, it's not a possibility.
>
> I guess somebody could say, if there are multiple resources available
> under that name, is it ever appropriate to return just one? I think =
so,
> since after all, even in that case, the classloader resource loading
> strategy is well defined and deterministic.
>
> Since the 'classpath:' prefix is something we made up, why don't we =
keep
> this for just a single resource, and use something like 'resources:' =
(or
> whatever) to mean multiple resources?
>
> Colin
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
> >FYI, I've just refined PathMatchingResourcePatternResolver to be able =
to retrieve all class path resources with the same name. It actually =
inherits this from the new base class ClassPathResourcePatternResolver.
> >
> =
>http://sourceforge.net/forum/forum.php?thread_id=3D1096825&forum_id=3D25=
0340
> >
> >So "classpath:/beans.xml" will load all beans.xml files in classes =
directories or JAR files, if passed into =
PathMatchingResourcePatternResolver. Of course, Ant-style file path =
patterns like "/WEB-INF/*-context.xml" still work.
> >
> >As this is automatically used by "contextConfigLocation" parameters, =
this means that we can specify such a URL for a root web application =
context, for example to auto-load all beans.xml files contained in =
deployed JAR files in WEB-INF\lib (HiveMind-style)!
> >
> >Juergen
> >
> >
> >DI J=FCrgen H=F6ller
> >Senior System Architect
> >______________________________________
> >
> >werk3ATS - division systementwicklung
> >werk3AT informations- und mediensysteme
> >
> >europaplatz 4
> >A - 4020 linz
> >
> >t. +43 (0) 732 71 65 29 502
> >f. +43 (0) 732 71 65 29 3
> >mailto:jue...@we...
> >http://www.werk3at.com
> >______________________________________
> >werk3ATS - WIR ENTWICKELN ERFOLG
> >
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2004-06-25 18:00:47
|
Good point. I've just scratched the ClassPathResourcePatternResolver =
base class and moved the logic into PathMatchingResourcePatternResolver =
itself (which is the only class that is actually used anyway). The =
latter checks for "classpath*:" first now, then for =
PathMatcher.isPattern, then for a single resource.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Fr 25.06.2004 19:49
An: spr...@li...
Betreff: Re: [Springframework-developer] Retrieve all class path =
resources with the same name
W/regards to your 2nd paragraph, at a minimum you'd have to modify the
present implementation of
PathMatcher.isPattern
since it would trigger on the * in classpath*:, as used in
PathMatchingResourcePatternResolver before the prefix is ever matched by
code in ClassPathResourcePatternResolver...
j=FCrgen h=F6ller [werk3AT] wrote:
>I quite like "classpath*:" too: It's a resource pattern prefix, just =
like "classpath:" is a resource location prefix. Everything after the =
":" should be the actual resource pattern, so I don't really like a "*" =
there.
>
>"classpath*:*-beans.xml" will _not_ work, as the implementation =
considers the path after "classpath*:" a standard classpath resource =
location. This means that the location after "classpath*:" is not =
supposed to contain an Ant-style pattern in any case; it will not be =
parsed but rather passed straight through to the ClassLoader.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von Tom Turelinckx
>Gesendet: Fr 25.06.2004 12:16
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Retrieve all class path =
resources with the same name
>
>
>
>I've been thinking about this, and though I had some doubts at first, I
>definitely like "classpath*:" now, because of the * character.
>
>The point is that ResourceLoader takes a location, while
>ResourcePatternResolver takes a location _pattern_, and depending on =
the
>place where you use a resource string, a location pattern may or may =
not
>be allowed. In this regard it is important to think of
>"classpath:beans.xml" as a location, and "classpath*:beans.xml" as a
>location pattern.
>
>Thus, a resource location always results in at most one matching file,
>which is consistent with the way Resource and ResourceLoader are
>defined.
>
>I think we should clearly document that "classpath*:" is not considered
>a prefix, but part of a location pattern, so its use is only allowed
>where location patterns are allowed.
>
>The implementation is tricky though. I suppose "classpath:*-beans.xml"
>would work if the individual locations are resolvable to File, but what
>about "classpath*:*-beans.xml"? Not that I would try to use a pattern
>like that myself though ;-)
>
>Kind regards,
>Tom.
>
>On Fri, 25 Jun 2004 09:25:00 +0200, "j=FCrgen h=F6ller [werk3AT]"
><jue...@we...> said:
>=20
>
>>Any thoughts about the prefix naming? Is "classpath*:" for explictly
>>wanting all matching classpath resources fine?
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag =
von
>>j=FCrgen h=F6ller [werk3AT]
>>Gesendet: Do 24.06.2004 09:56
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] Retrieve all class path
>>resources with the same name
>>
>>
>>
>>Colin,
>>
>>You do have a point there. We coul use a prefix like "classpath*:" for
>>loading all matching resources from the classpath. ("resources:" is =
too
>>general, IMO: It's about multiple _classpath_ resources.) That would =
keep
>>the behavior of "classpath:" in any case, and allow to explicitly =
specify
>>"I want all matching resources" via "classpath*:".
>>
>>Interestingly, a classpath resource string is the only resource =
location
>>accepted by Spring's ResourceLoader that is not unique but can result =
in
>>multiple matching files.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag =
von
>>Colin Sampaleanu
>>Gesendet: Do 24.06.2004 06:06
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] Retrieve all class path
>>resources with the same name
>>
>>
>>
>>I've been thinking about this, and was wondering if it's appropriate
>>that _all_ matching resources are found, all the time, and also if we
>>should be worried about a backwards incompatible change.
>>
>>Before, in ClassPathXmlApplicationContext, the locations
>> beans.xml
>>and
>> classpath:beans.xml
>>would return one resource, regardless of how many there were.
>>
>>Now the former still returns one, while the latter returns 1-x.
>>
>>Is it a problem that we've made a backwards incompatible change for =
the
>>latter form?
>>Is it a problem that somebody, if they want just one resource, has to
>>know that they need to use the first form? Additionally to this, this
>>distinction is possible when something like
>>ClassPathXmlApplicationContext, but for others that override the =
default
>>getResourceByPath to default to something else than a classpath
>>resource, it's not a possibility.
>>
>>I guess somebody could say, if there are multiple resources available
>>under that name, is it ever appropriate to return just one? I think =
so,
>>since after all, even in that case, the classloader resource loading
>>strategy is well defined and deterministic.
>>
>>Since the 'classpath:' prefix is something we made up, why don't we =
keep
>>this for just a single resource, and use something like 'resources:' =
(or
>>whatever) to mean multiple resources?
>>
>>Colin
>>
>>j=FCrgen h=F6ller [werk3AT] wrote:
>>
>> =20
>>
>>>FYI, I've just refined PathMatchingResourcePatternResolver to be able =
to retrieve all class path resources with the same name. It actually =
inherits this from the new base class ClassPathResourcePatternResolver.
>>>
>>>http://sourceforge.net/forum/forum.php?thread_id=3D1096825&forum_id=3D=
250340
>>>
>>>So "classpath:/beans.xml" will load all beans.xml files in classes =
directories or JAR files, if passed into =
PathMatchingResourcePatternResolver. Of course, Ant-style file path =
patterns like "/WEB-INF/*-context.xml" still work.
>>>
>>>As this is automatically used by "contextConfigLocation" parameters, =
this means that we can specify such a URL for a root web application =
context, for example to auto-load all beans.xml files contained in =
deployed JAR files in WEB-INF\lib (HiveMind-style)!
>>>
>>>Juergen
>>>
>>>
>>>DI J=FCrgen H=F6ller
>>>Senior System Architect
>>>______________________________________
>>>
>>>werk3ATS - division systementwicklung
>>>werk3AT informations- und mediensysteme
>>>
>>>europaplatz 4
>>>A - 4020 linz
>>>
>>>t. +43 (0) 732 71 65 29 502
>>>f. +43 (0) 732 71 65 29 3
>>>mailto:jue...@we...
>>>http://www.werk3at.com
>>>______________________________________
>>>werk3ATS - WIR ENTWICKELN ERFOLG
>>>
>>>
>>> =20
>>>
>> =20
>>
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Colin S. <col...@ex...> - 2004-06-25 17:45:18
|
W/regards to your 2nd paragraph, at a minimum you'd have to modify the
present implementation of
PathMatcher.isPattern
since it would trigger on the * in classpath*:, as used in
PathMatchingResourcePatternResolver before the prefix is ever matched by
code in ClassPathResourcePatternResolver...
jürgen höller [werk3AT] wrote:
>I quite like "classpath*:" too: It's a resource pattern prefix, just like "classpath:" is a resource location prefix. Everything after the ":" should be the actual resource pattern, so I don't really like a "*" there.
>
>"classpath*:*-beans.xml" will _not_ work, as the implementation considers the path after "classpath*:" a standard classpath resource location. This means that the location after "classpath*:" is not supposed to contain an Ant-style pattern in any case; it will not be parsed but rather passed straight through to the ClassLoader.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von Tom Turelinckx
>Gesendet: Fr 25.06.2004 12:16
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Retrieve all class path resources with the same name
>
>
>
>I've been thinking about this, and though I had some doubts at first, I
>definitely like "classpath*:" now, because of the * character.
>
>The point is that ResourceLoader takes a location, while
>ResourcePatternResolver takes a location _pattern_, and depending on the
>place where you use a resource string, a location pattern may or may not
>be allowed. In this regard it is important to think of
>"classpath:beans.xml" as a location, and "classpath*:beans.xml" as a
>location pattern.
>
>Thus, a resource location always results in at most one matching file,
>which is consistent with the way Resource and ResourceLoader are
>defined.
>
>I think we should clearly document that "classpath*:" is not considered
>a prefix, but part of a location pattern, so its use is only allowed
>where location patterns are allowed.
>
>The implementation is tricky though. I suppose "classpath:*-beans.xml"
>would work if the individual locations are resolvable to File, but what
>about "classpath*:*-beans.xml"? Not that I would try to use a pattern
>like that myself though ;-)
>
>Kind regards,
>Tom.
>
>On Fri, 25 Jun 2004 09:25:00 +0200, "jürgen höller [werk3AT]"
><jue...@we...> said:
>
>
>>Any thoughts about the prefix naming? Is "classpath*:" for explictly
>>wanting all matching classpath resources fine?
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von
>>jürgen höller [werk3AT]
>>Gesendet: Do 24.06.2004 09:56
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] Retrieve all class path
>>resources with the same name
>>
>>
>>
>>Colin,
>>
>>You do have a point there. We coul use a prefix like "classpath*:" for
>>loading all matching resources from the classpath. ("resources:" is too
>>general, IMO: It's about multiple _classpath_ resources.) That would keep
>>the behavior of "classpath:" in any case, and allow to explicitly specify
>>"I want all matching resources" via "classpath*:".
>>
>>Interestingly, a classpath resource string is the only resource location
>>accepted by Spring's ResourceLoader that is not unique but can result in
>>multiple matching files.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von
>>Colin Sampaleanu
>>Gesendet: Do 24.06.2004 06:06
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] Retrieve all class path
>>resources with the same name
>>
>>
>>
>>I've been thinking about this, and was wondering if it's appropriate
>>that _all_ matching resources are found, all the time, and also if we
>>should be worried about a backwards incompatible change.
>>
>>Before, in ClassPathXmlApplicationContext, the locations
>> beans.xml
>>and
>> classpath:beans.xml
>>would return one resource, regardless of how many there were.
>>
>>Now the former still returns one, while the latter returns 1-x.
>>
>>Is it a problem that we've made a backwards incompatible change for the
>>latter form?
>>Is it a problem that somebody, if they want just one resource, has to
>>know that they need to use the first form? Additionally to this, this
>>distinction is possible when something like
>>ClassPathXmlApplicationContext, but for others that override the default
>>getResourceByPath to default to something else than a classpath
>>resource, it's not a possibility.
>>
>>I guess somebody could say, if there are multiple resources available
>>under that name, is it ever appropriate to return just one? I think so,
>>since after all, even in that case, the classloader resource loading
>>strategy is well defined and deterministic.
>>
>>Since the 'classpath:' prefix is something we made up, why don't we keep
>>this for just a single resource, and use something like 'resources:' (or
>>whatever) to mean multiple resources?
>>
>>Colin
>>
>>jürgen höller [werk3AT] wrote:
>>
>>
>>
>>>FYI, I've just refined PathMatchingResourcePatternResolver to be able to retrieve all class path resources with the same name. It actually inherits this from the new base class ClassPathResourcePatternResolver.
>>>
>>>http://sourceforge.net/forum/forum.php?thread_id=1096825&forum_id=250340
>>>
>>>So "classpath:/beans.xml" will load all beans.xml files in classes directories or JAR files, if passed into PathMatchingResourcePatternResolver. Of course, Ant-style file path patterns like "/WEB-INF/*-context.xml" still work.
>>>
>>>As this is automatically used by "contextConfigLocation" parameters, this means that we can specify such a URL for a root web application context, for example to auto-load all beans.xml files contained in deployed JAR files in WEB-INF\lib (HiveMind-style)!
>>>
>>>Juergen
>>>
>>>
>>>DI Jürgen Höller
>>>Senior System Architect
>>>______________________________________
>>>
>>>werk3ATS - division systementwicklung
>>>werk3AT informations- und mediensysteme
>>>
>>>europaplatz 4
>>>A - 4020 linz
>>>
>>>t. +43 (0) 732 71 65 29 502
>>>f. +43 (0) 732 71 65 29 3
>>>mailto:jue...@we...
>>>http://www.werk3at.com
>>>______________________________________
>>>werk3ATS - WIR ENTWICKELN ERFOLG
>>>
>>>
>>>
>>>
>>
>>
|
