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.
