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

[Colin S. <col...@ex...>]

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