Re: [Springframework-developer] Retrieve all class path resources with the same name

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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