Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-06-24 07:59:42
|
Colin,
=20
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*:".
=20
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.
=20
Juergen
=20
________________________________
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
>=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: <jue...@we...> - 2004-06-25 07:25:30
|
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
|
|
From: Tom T. <tom...@pr...> - 2004-06-25 10:17:03
|
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=20
> Juergen
>=20=20
>=20
> ________________________________
>=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
>=20
>=20
>=20
> Colin,
>=20
> 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*:".
>=20
> 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.
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> 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
>=20
>=20
>=20
> 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.
>=20
> Before, in ClassPathXmlApplicationContext, the locations
> beans.xml
> and
> classpath:beans.xml
> would return one resource, regardless of how many there were.
>=20
> Now the former still returns one, while the latter returns 1-x.
>=20
> 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.
>=20
> 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.
>=20
> 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?
>=20
> Colin
>=20
> 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=3D25=
0340
> >
> >So "classpath:/beans.xml" will load all beans.xml files in classes direc=
tories or JAR files, if passed into PathMatchingResourcePatternResolver. Of=
course, Ant-style file path patterns like "/WEB-INF/*-context.xml" still w=
ork.
> >
> >As this is automatically used by "contextConfigLocation" parameters, thi=
s 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 file=
s 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
>=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
>=20
>=20
>=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
>=20
>=20
>=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: Dmitriy K. <dko...@ru...> - 2004-06-25 11:50:47
|
How about "classpath-all:" to be more explicit?
Dmitriy.
jürgen höller [werk3AT] wrote:
>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
>>
>>
>>
>>
>
>
>
>
>-------------------------------------------------------
>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: Matt R. <li...@ra...> - 2004-06-25 14:28:32
|
classpath:* seems more intuitive to me - where its still using the =20
classpath: prefix
On Jun 25, 2004, at 5:50 AM, Dmitriy Kopylenko wrote:
> How about "classpath-all:" to be more explicit?
>
> Dmitriy.
>
> j=FCrgen h=F6ller [werk3AT] wrote:
> Any thoughts about the prefix naming? Is "classpath*:" for explictly =20=
> wanting all matching classpath resources fine?
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
=20
> von j=FCrgen h=F6ller [werk3AT]
> Gesendet: Do 24.06.2004 09:56
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Retrieve all class path =20
> resources with the same name
>
>
>
> Colin,
>
> You do have a point there. We coul use a prefix like "classpath*:" for =
=20
> loading all matching resources from the classpath. ("resources:" is =20=
> too general, IMO: It's about multiple _classpath_ resources.) That =20
> would keep the behavior of "classpath:" in any case, and allow to =20
> explicitly specify "I want all matching resources" via "classpath*:".
>
> Interestingly, a classpath resource string is the only resource =20
> location accepted by Spring's ResourceLoader that is not unique but =20=
> can result in multiple matching files.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
=20
> von Colin Sampaleanu
> Gesendet: Do 24.06.2004 06:06
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Retrieve all class path =20
> 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 =20
> 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 =20=
> keep
> this for just a single resource, and use something like 'resources:' =20=
> (or
> whatever) to mean multiple resources?
>
> Colin
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
>
> FYI, I've just refined PathMatchingResourcePatternResolver to be able =20=
> to retrieve all class path resources with the same name. It actually =20=
> inherits this from the new base class =20
> ClassPathResourcePatternResolver.
>
> =20
> http://sourceforge.net/forum/forum.php?=20
> thread_id=3D1096825&forum_id=3D250340
>
> So "classpath:/beans.xml" will load all beans.xml files in classes =20
> directories or JAR files, if passed into =20
> PathMatchingResourcePatternResolver. Of course, Ant-style file path =20=
> patterns like "/WEB-INF/*-context.xml" still work.
>
> As this is automatically used by "contextConfigLocation" parameters, =20=
> this means that we can specify such a URL for a root web application =20=
> context, for example to auto-load all beans.xml files contained in =20
> 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
>
>
> =20=
|
|
From: Colin S. <col...@ex...> - 2004-06-25 12:37:49
|
Juergen, I am ok with this. As an aside, I think there is the
potential for confusion on some people's part in that classpath*: can
find multiple resources, while the equivalent path with classpath:
won't, while classpath:xxxxx* can also find multiple paths in _some_
environments (of course the actual files will have different names
here). I'm not sure people should ever really rely on the latter. It
assumes that the classpath is actually available on the filesystem, and
is not really a safe assumption, as it varies so much from app server to
app server. People are also in general not used to dealing with
classpath resources with wildcards...
Colin
jürgen höller [werk3AT] wrote:
>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
>>
>>
|
|
From: Colin S. <col...@ex...> - 2004-06-25 14:39:38
|
No, that wouldn't actually make sense, since * in the resource name
(what comes after the 'classpath:' prefix), means an actual, 'glob'
style wildcard. (which as I meantioned in another email, is not
guaranteed to work, depending on whether the classes are actually on the
filesystem or not).
Matt Raible wrote:
> classpath:* seems more intuitive to me - where its still using the
> classpath: prefix
>
> On Jun 25, 2004, at 5:50 AM, Dmitriy Kopylenko wrote:
>
>> How about "classpath-all:" to be more explicit?
>>
>> Dmitriy.
>>
>> jürgen höller [werk3AT] wrote:
>> 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
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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: Tom T. <tom...@pr...> - 2004-06-25 15:39:32
|
Another suggestion...
If we'd like to keep the prefix "classpath:" the same, maybe "all" could
be the default anyway, so "classpath:beans.xml" would load them all, and
"classpath:|beans.xml|" would load only one?
This would not be backwards compatible, but maybe that's acceptable, and
when using ClassPathXmlApplicationContext there would still be a
difference between "beans.xml" (loads one) and "classpath:beans.xml"
(loads all).
But if you're not using a prefix, you know you're relying on the
getResourceByPath provided by the specific ApplicationContext
implementation (and you presumably don't know which one that is), so you
wouldn't expect more than one result...
If you are using a "classpath:" prefix, you know you'll get all results,
except when using the "||" notation, which is probably pretty clear.
Regards,
Tom.
On Fri, 25 Jun 2004 10:43:43 -0400, "Colin Sampaleanu"
<col...@ex...> said:
> No, that wouldn't actually make sense, since * in the resource name=20
> (what comes after the 'classpath:' prefix), means an actual, 'glob'=20
> style wildcard. (which as I meantioned in another email, is not=20
> guaranteed to work, depending on whether the classes are actually on the=
=20
> filesystem or not).
>=20
>=20
> Matt Raible wrote:
>=20
> > classpath:* seems more intuitive to me - where its still using the=20=
=20
> > classpath: prefix
> >
> > On Jun 25, 2004, at 5:50 AM, Dmitriy Kopylenko wrote:
> >
> >> How about "classpath-all:" to be more explicit?
> >>
> >> Dmitriy.
> >>
> >> j=FCrgen h=F6ller [werk3AT] wrote:
> >> Any thoughts about the prefix naming? Is "classpath*:" for explictly=
=20=20
> >> wanting all matching classpath resources fine?
> >>
> >> Juergen
> >>
> >>
> >> ________________________________
> >>
> >> Von: spr...@li... im=20
> >> 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=20=20
> >> resources with the same name
> >>
> >>
> >>
> >> Colin,
> >>
> >> You do have a point there. We coul use a prefix like "classpath*:"=20
> >> for loading all matching resources from the classpath. ("resources:"=
=20
> >> is too general, IMO: It's about multiple _classpath_ resources.)=20
> >> That would keep the behavior of "classpath:" in any case, and allow=
=20
> >> to explicitly specify "I want all matching resources" via=20
> >> "classpath*:".
> >>
> >> Interestingly, a classpath resource string is the only resource=20=20
> >> location accepted by Spring's ResourceLoader that is not unique but=20=
=20
> >> can result in multiple matching files.
> >>
> >> Juergen
> >>
> >>
> >> ________________________________
> >>
> >> Von: spr...@li... im=20
> >> Auftrag von Colin Sampaleanu
> >> Gesendet: Do 24.06.2004 06:06
> >> An: spr...@li...
> >> Betreff: Re: [Springframework-developer] Retrieve all class path=20=20
> >> 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=20=20
> >> 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=20=
=20
> >> keep
> >> this for just a single resource, and use something like 'resources:'=
=20=20
> >> (or
> >> whatever) to mean multiple resources?
> >>
> >> Colin
> >>
> >> j=FCrgen h=F6ller [werk3AT] wrote:
> >>
> >>
> >> FYI, I've just refined PathMatchingResourcePatternResolver to be=20
> >> able to retrieve all class path resources with the same name. It=20
> >> actually inherits this from the new base class=20=20
> >> ClassPathResourcePatternResolver.
> >>
> >> http://sourceforge.net/forum/forum.php?=20
> >> thread_id=3D1096825&forum_id=3D250340
> >>
> >> So "classpath:/beans.xml" will load all beans.xml files in classes=20=
=20
> >> directories or JAR files, if passed into=20=20
> >> PathMatchingResourcePatternResolver. Of course, Ant-style file path=20=
=20
> >> patterns like "/WEB-INF/*-context.xml" still work.
> >>
> >> As this is automatically used by "contextConfigLocation" parameters,=
=20=20
> >> this means that we can specify such a URL for a root web application=
=20=20
> >> context, for example to auto-load all beans.xml files contained in=20=
=20
> >> 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
> >
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
> digital self defense, top technical experts, no vendor pitches,=20
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
