4 Replies Latest reply on Jul 22, 2008 1:07 PM by sil

    Annoyance with EARs and .properties file

    sil

      So I have a little annoyance here. Within my EAR I have a .properties file that multiple modules read from through an XML file by setting values to classpath:some.properties. It all works fine and dandy if I place the .properties file in the base of the EAR like so:

      myApp.ear
       |
       |--- some.properties
       |
       |--- META-INF
       | |
       | |--- (some files)
       |
       |--- APP-INF
       | |
       | |--- lib
       | | |
       | | |--- (various .jar files)
      

      However, I really want it to be read from APP-INF/classes instead, like so:
      myApp.ear
       |
       |--- META-INF
       | |
       | |--- (some files)
       |
       |--- APP-INF
       | |
       | |--- lib
       | | |
       | | |--- (various .jar files)
       | |
       | |--- classes
       | | |
       | | |--- some.properties

      I have tried adding a class path entry to the MANIFEST.MF file with no success. I have tried playing around in application.xml and jboss-app.xml as well. I always get the error:
      java.io.FileNotFoundException: class path resource [some.properties] cannot be opened because it does not exist

      I am looking for any tips or advice. Thanks!

        • 1. Re: Annoyance with EARs and .properties file
          jaikiran

          Can you post the code which reads this properties file?

          • 2. Re: Annoyance with EARs and .properties file
            sil

            Sure thing. This is from an XML file in our WAR. This is what we do to load it:

            <bean id="propertyConfigurer"
             class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
             <property name="location" value="classpath:some.properties" />
            </bean>

            This is how we read something from it (where some.datasource is an entry in there):
            <jndi:jndi-lookup id="dataSource" jndi-name="${some.datasource}"/>

            Additionally, in a seperate XML file associated with our core JAR, we use:
            <util:properties id="someProps" location="classpath:some.properties" />

            to which someProps is referenced a bunch throughout various .java files as it is tied to the bean entries for the Java classes. The information inside is referenced in other ways, but those are the only two places where we make mention of some.properties.

            I should note that I was not the one who initially wrote what is going on, so I am not too keen on the path things are taking. I am just the one who gets to port it from Weblogic to JBoss and try to get it to run on both with minimal config changes.


            • 3. Re: Annoyance with EARs and .properties file
              jaikiran

              How about trying this:

              <bean id="propertyConfigurer"
               class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
               <property name="location" value="/APP-INF/classes/some.properties" />
              </bean>


              Btw, why do you want the APP-INF folder in JBoss?

              P.S: I have zero knowledge about Spring.

              • 4. Re: Annoyance with EARs and .properties file
                sil

                I had thought about that last night. Just tried it out and it will work. Not exactly the solution I wanted, but it is at least another option, so thank you!

                There is an APP-INF folder because the EAR was initially designed for Weblogic, and APP-INF is their extension (well one of the project team seems to think it is a standard, but I don't believe him since I could not get any official confirmation on it so I am going with extension). So in jboss-app.xml I added:

                <jboss-app>
                 <library-directory>APP-INF/lib</library-directory>
                </jboss-app>

                And that works for the lib directory. This whole thing is not a big deal, I just wanted to see if there was something I could config so that I could easily go back and forth since we want to support it on both JBoss and Weblogic with minimal config/rearranging differences.

                p.s. about Spring, so do I.