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

[Matt R. <li...@ra...>]

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=