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

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

No, that wouldn't actually make sense, since * in the resource name 
(what comes after the 'classpath:' prefix), means an actual, 'glob' 
style wildcard. (which as I meantioned in another email, is not 
guaranteed to work, depending on whether the classes are actually on the 
filesystem or not).


Matt Raible wrote:

> classpath:* seems more intuitive to me - where its still using the  
> classpath: prefix
>
> On Jun 25, 2004, at 5:50 AM, Dmitriy Kopylenko wrote:
>
>> 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
>