cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: Bug in Cocoon Spring Configurator 2.0 (!?)
Date Thu, 12 Feb 2009 18:40:26 GMT
Benjamin Boksa wrote:
> Not sure if I understand you on that one… Let's assume there are two 
> "foo.properties" files both containing a property "bar" - when using the 
> settings above how does the spring-configurator decide which is the 
> right property to use? I think this might result in a problem (the wrong 
> "bar"-property is used)…

you are of course right :) I was talking about the opposite:

file1.jar: application.properties with 'foo' property
file2.jar: application.properties with 'bar' property

classpath:/META-INF/properties/application.properties will pick one file 
(which one is either not deterministic or depends on jar file naming).

classpath*:/META-INF/properties/application.properties will pick both 
files and load all properties. This way you do not have to keep 
different names across modules.

> 
> However the big problem/misunderstanding/bug is that with my the 
> original settings
> 
>    <configurator:settings>
>      <configurator:include-beans dir="/META-INF/foo-service/spring"/>
>      <configurator:include-properties 
> dir="META-INF/foo-service/properties"/>
>    </configurator:settings>
> 
> the bean definitions seem to be read correctly while the properties are 
> not - which I absolutely can't understand. I feel a bit like going in 
> circles and can't find any good resources (despite of Leszek ;-) ) which 
> might help me solve this problem.

I am afraid this is simply a false positive. In other words: a pure 
coincidence.

> So if you have further information please let me know :-)

Your path definition: META-INF/foo-service/properties gets converted into:

classpath:META-INF/foo-service/properties/*.properties

which is an 'ant style path'. [1] states:

<quote>
Ant-style patterns with "classpath:" resources are not guaranteed to 
find matching resources if the root package to search is available in 
multiple class path locations. This is because a resource such as

     com/mycompany/package1/service-context.xml

may be in only one location, but when a path such as

     classpath:com/mycompany/**/service-context.xml

is used to try to resolve it, the resolver will work off the (first) URL 
returned by getResource("com/mycompany");. If this base package node 
exists in multiple classloader locations, the actual end resource may 
not be underneath. Therefore, preferably, use "classpath*:" with the 
same Ant-style pattern in such a case, which will search all class path 
locations that contain the root package.
</quote>

Have fun

[1] 
http://static.springframework.org/spring/docs/2.5.x/reference/resources.html#resources-wildcards-in-path-other-stuff
[2] 
http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/core/io/support/PathMatchingResourcePatternResolver.html



-- 
Leszek Gawron                         http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.

Mime
View raw message