Support-Brian wrote:

Robert, I should have noticed that error myself, thanks. Spring IDE does support importing using "classpath:", but not when the resource is in a JAR

Yes, that is what I meant, I was not specific enough.

Support-Brian wrote:

if you try that for a resource in your source folder, it should work fine; so one possible solution would be to modify your projectA build script to move the applicationContext.xml file into the source folder directly, but not sure if that is acceptable for your use.

Not really. These classpath entries refer to the included jar file built from Project A.

Support-Brian wrote:

I also noticed that if you use "classpath*:applicationContext.xml" instead of "classpath:applicationContext.xml", the error marker goes away and the JAR is not locked; unfortunately, you still need to use config sets for any config files you import from JARs and the existence of the resource is not validated. Is this an acceptable workaround for now? This is a core fix that may not be possible at this time.

It would possibly be acceptable, however I have to check what is the semantical difference between classpath and classpath*.

If I remember well, it means that multiple occurences of the same resource file name included in differerent jars in the classpath are all loaded. That would be acceptable as my naming convention is that the bean config file name is unique in the system, so in effect classpath and classpath* is semantically the same for me.

Support-Brian wrote:

As for the buildCommand section, I cannot think of anything in MyEclipse which would leave your project in such a state - but I will give related code a once over, just to be sure.

The project was originally created with an older version of MyEclipse (in early 2005) and it was used with several upgrades.

Best regards,

Robert

robvarga wrote:

Support-Brian wrote: I also noticed that if you use "classpath*:applicationContext.xml" instead of "classpath:applicationContext.xml", the error marker goes away and the JAR is not locked; unfortunately, you still need to use config sets for any config files you import from JARs and the existence of the resource is not validated. Is this an acceptable workaround for now? This is a core fix that may not be possible at this time. It would possibly be acceptable, however I have to check what is the semantical difference between classpath and classpath*. If I remember well, it means that multiple occurences of the same resource file name included in differerent jars in the classpath are all loaded. That would be acceptable as my naming convention is that the bean config file name is unique in the system, so in effect classpath and classpath* is semantically the same for me.

Ehh... seems I should try to upgrade Spring in this project... Spring 1.1 does not support classpath*:. :-(

Best regards,

Robert

Robert,

We have fixed this issue internally and it should be available in 6.5GA due any time now. You need to keep the import support on and continue using "classpath:applicationContext.xml", the tooling will find the resource in the JAR file, you will be informed if it does not exist. You also do not need to add this file to your config set.

An additional note, if you move applicationContext.xml from the root of the JAR to within the "lockbug" source folder, classpath:lockbug/applicationContext.xml will correctly locate the bean file even in 6.5M1.

Thanks again for taking the time to work with us on this one.

Cool,

thanks for fixing this :-)

Will it also find the bean config file in a jar included from the classpath if the jar is not explicitly mentioned in the .classpath but provided by a classpath container?

BR,

Robert

robvarga wrote:

robvarga wrote: Support-Brian wrote: I also noticed that if you use "classpath*:applicationContext.xml" instead of "classpath:applicationContext.xml", the error marker goes away and the JAR is not locked; unfortunately, you still need to use config sets for any config files you import from JARs and the existence of the resource is not validated. Is this an acceptable workaround for now? This is a core fix that may not be possible at this time. It would possibly be acceptable, however I have to check what is the semantical difference between classpath and classpath*. If I remember well, it means that multiple occurences of the same resource file name included in differerent jars in the classpath are all loaded. That would be acceptable as my naming convention is that the bean config file name is unique in the system, so in effect classpath and classpath* is semantically the same for me. Ehh... seems I should try to upgrade Spring in this project... Spring 1.1 does not support classpath*:. :-( Best regards, Robert

Btw, I created subclasses to the Spring XmlWebApplicationContext, DefaultResourceLoader and DefaultBeanDefinitionParser classes to allow classpath*: prefix and fall back to classpath: behaviour in case they encounter it.

This allows turning on classpath*: with Spring 1.1...

BR,

Robert