cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
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 
> "" 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: with 'foo' property
file2.jar: with 'bar' property

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

classpath*:/META-INF/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 

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

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


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

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


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


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.

Have fun


Leszek Gawron               
CTO at MobileBox Ltd.

View raw message