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

[<jue...@we...>]

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