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

[Dmitriy K. <dko...@ru...>]

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
>  
>