Q: How to point to a file resource from an appContext located in a JAR?

[ZipwiZ]

I want to configure some bean properties using org.springframework.beans.factory.config.PropertyP laceholderConfigurer, but the configuration (currently loaded as applicationContext) is itself located in a JAR on EAR level, and the .properties file to load by the org.springframework.beans.factory.config.PropertyP laceholderConfigurer *MUST* be located in some "expanded" place in the EAR to grant easy access to operations / deployers. (It is because they must setup some values for production in this file which I am not allowed to know in detail as a developer.)

The EAR contains 3 WARs, 7 EJB-JARS and some "normal" JARs, is deployed on WAS60 and as such the WARs are guaranteed to be expanded to the file system on deployment. The applicationContext is actually located in one of the "normal" JARs on EAR level, and it is used only by logic residing in the WARs (not in any EJB).

Is there some way to point to an "expanded" location inside the EAR from inside my applicationContext?

Or is it required for any applicationContext which wants to load some resource from the file system (relative to the EAR, not knowing about its absolute location) also to reside in an "expanded" location like an expanded WAR?

[calebphillips]

You can load your property files from the classpath:

<bean  class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
     <property name="location" value="classpath:com/company/env.properties" />
</bean>

[jonnio]

The the jar on the classpath by setting up the manifest of your ejb modules with class-path entries for your 'resource' jar. Of course, some application servers have a different or configurable ear class loader so you may have to read up on the documentation.

[ZipwiZ]

Putting the location of the properties file on the JAR class path (in MANIFEST.MF) seems a good idea. Is it possible to add an "expanded pyhsical" location for class and property files which are *not* stored inside another JAR? (This is no Spring question but merely a general J2EE one of course.)

[ZipwiZ]

However, we decided to put the properties file in the "classes" directory of the application server which is the usual place for classes and resources which should be visible for the app server VM as a whole. This way it is *not* part of the EAR, always visible via classpath access, "expanded" and thus freely editable by the operations team. Operations is satisfied with that :-)

Theoretically the configured values are still visible inside the application since they are injected into the LDAP ContextSource, but the application code does not implement any direct access to this bean anyhow. A solution for this would require to externalize the configuration via a JNDI-served "LDAP connector factory" or the like. This topic already has its own discussion thread in the Spring LDAP subforum.