12 Replies Latest reply on Mar 24, 2003 12:44 PM by katazan

    referencing application specific property files in ear from

    katazan

      I've been struggling with this issue for months, and have put-it-off and found temporary workarounds to facillitate development progress. It has come time to deploy my application into production, however, and I am faced with having to solve this issue before I can launch.

      I'm using ant to package several different application files, each of which uses some framework classes I've written myself (best-practices pattern implementations for handling persistence and property mangagement). The framework classes that I've written rely on a consistently named property file that is loaded from the classpath. Here's a scenario:

      reportingapp.ear
      -app.properties**
      -sql.properties**
      -reporting.war
      -reportingejb.jar
      -lib
      -ejbclient.jar
      -ejbutil.jar
      -META-INF
      -application.xml

      ** These property files have different contents for every application (data source, jndi lookup info for EJBs, factory settings, etc). They are not named differently, however. So, every other application ear file has the same names for the property files, but the files that are packaged with the respective ear files have application-specific content.

      My ejbs are having trouble finding their configuration files for getting at SQL prepared statement strings, and Datasource jndi information. I have a requirement to run all of the ears in the same JBoss instance. The classloader for a given ear should load the ear-specific properties files that are packaged with it FIRST, thus ignoring any other property files with the same name that are associated with other ear application files.

      I've tried referencing these property files via the ant manifest option as follows, with the following results:






      The manifest file ends-up with two linebreaks at the end of the file that I think might be hosing the references-up, but I can't say for sure. I have another jar file that requires several classpath entries in the manifest (theoretically), but the MANIFEST.MF file's entry for that classpath has had line-breaks inserted into it around 70 characters.

      Is there a trivial method for accomplishing what I'm attempting that I've overlooked, or havn't yet stumbled upon? Please, oh please share.

      Thanks,

      John C. Dale
      CEO
      Down in the Desert, Inc.

        • 1. Re: referencing application specific property files in ear f
          katazan

          Test to see if monitoring is working...

          • 2. Re: referencing application specific property files in ear f
            katazan

            After reading some of the comments from the 'core' guys of jBoss, I've come to the conclusion that the classloader issue is a huge thorn, especially the tomcat integration.

            If you ask me, this issue will prevent jBoss from appealing to the bigger technological players in industry. The ability to generacise an application and load resources from isolated classloaders (accessing the same named files with different content from different classpath contexts) is very important to those who understand OO and J2EE (the other joes I've seen working with the same jBoss issue seem to be pretty competent, and from bigger companies).

            Could one (or more) of your core engineers please look me up? Send me an email or something. This issue is about to kill my project.

            Thanks,

            JC
            jcd@downinthedesert.com

            • 3. Re: referencing application specific property files in ear f
              katazan

              After reading some of the comments from the 'core' guys of jBoss, I've come to the conclusion that the classloader issue is a huge thorn, especially the tomcat integration.

              If you ask me, this issue will prevent jBoss from appealing to the bigger technological players in industry. The ability to generacise an application and load resources from isolated classloaders (accessing the same named files with different content from different classpath contexts) is very important to those who understand OO and J2EE (the other joes I've seen working with the same jBoss issue seem to be pretty competent, and from bigger companies).

              Could one (or more) of your core engineers please look me up? Send me an email or something. This issue is about to kill my project.

              Thanks,

              JC
              jcd@downinthedesert.com

              • 4. Re: referencing application specific property files in ear f
                katazan

                My workaround was to put the property files in the WEB-INF directory of the war file. The EJB class loader has access to this on the classpath for some reason (might be spec, I haven't had time to research it - been cuttin' through code like a brit through the jungles of SA). Oh yeah, I had to reference the property files via a call to ...class.getResource("/WEB-INF/propfilename.props").openStream();

                I haven't tested that I'll get the correct degree of separation by ear file, but that's soon to come. I was just so happy that I was able to load a resource from the classpath that I thought I would come here and vent my global joy.

                Yay!

                Feel free to send an email if you have issues or comments.

                jcd@downinthedesert.com

                JC

                • 5. Re: referencing application specific property files in ear f
                  greghester

                  I'm using jboss-3.0.6-tomcat-4.x

                  We are successfully accessing our properties file using the classpath. Heres our setup:

                  eita-infinity.ear
                  -->eita-infinity.jar
                  -->infinity.properties <<********
                  -->infinity.war
                  ...

                  In order to access the infinity.properties file, we have a static initialization section in our Command session bean which does the following code:
                  ...
                  static {
                  EJBStartup startup = new EJBStartup();
                  java.io.InputStream stream = startup.getClass().getResourceAsStream("/infinity.properties");
                  startup.processProperties(stream);
                  }
                  ...

                  Hope that helps.

                  Greg

                  • 6. Re: referencing application specific property files in ear f
                    greghester

                    Opps.. My reply looks erroneous. The infinity.properties file is in the root directory of the eita-infinity.jar which is my ejb jar.

                    Hope that helps.

                    Greg

                    • 7. Re: referencing application specific property files in ear f
                      katazan

                      Hey Greg,

                      Thanks for the info, I'll try it.

                      An unrelated update on the home-front - Down in the Desert, Inc. is totally wondows-less and successfully deploying linux redhat 8.0 for all server and workstation class machines. FMS.

                      A related update..My previous workaround didn't work. I was able to load the property files from the classpath, but, unfortunately, the parent class loader of all ejb deployments (within the same war or otherwise) were picking up the property file. Yuck.

                      I'll give what you have a shot.

                      Were you implmenting the same solution as I, i.e., having different application deployments use the same property file name, but different property files delimited by classpath (thus, the contents of the property file, although named the same, would be application-specific)?

                      Thanks for the response.

                      Bear Down.

                      JC

                      • 8. Re: referencing application specific property files in ear f
                        katazan

                        sorry 'within the same war...' should read 'within the same ear'.

                        JC

                        • 9. Re: referencing application specific property files in ear f
                          greghester

                          John,

                          We are able to create a "portable" ear which has both an embedded war and ejb-jar. Both the war and the ejb-jar need access to the same properties file. During our ant build, we copy the properties file, infinity.properties, to war/WEB-INF/classes and to ejb-jar/ temp directories and then create the jar, war and finally ear. Our java code from both the web container and the ejb container uses someObject.getClass().getResourceAsStream() to obtain the properties file.

                          That ear can then be deployed to various machine for scalability and qa purposes.

                          I hope that clarifies. Let me know if I can tell you more about what we are doing.

                          Best Regards,
                          Greg

                          • 10. Re: referencing application specific property files in ear f
                            greghester

                            One more note... the property file, infinity.properties, does indeed have different values in it depending upon how we deploy. We have 3 models of deployment as well as supporting 3 different app servers, each with differences that are borne out in the infinity.properties file.

                            Best Regards,
                            Greg

                            • 11. Re: referencing application specific property files in ear f
                              katazan

                              Greg,

                              Unfortunately, I'm not experiencing the same results when trying to package a property file at the root (or nested directory) of the ejb.jar module. The classes aren't available as stream-able resources for whatever reason unless I put them in a system-level classpath destination (I'm using the latest stable jBoss release with Jetty). I don't know what the root cause of this might be.

                              I thought about this for some time, and think that my approach was completely wrong.

                              I did some research, and, lo and behold, there is a way to pass env references to both ejb and war components (essentially what I was doing by messing with class-loader context domains). I'm now passing references to respective property files via a context variable that is specified in the deployment metadata for both the war (web.xml) and the ejb.jar (ejb-jar.xml) in a platform-independent way. Then, I put the configuration details (in this case, groups of SQL statements logically belonging to a particular business component domain).

                              This has solved my issues completely, and I no longer rely on having only one name for my property files. In fact, I think it makes the system more maintainable by specifying the name of a property file as something logically relating to the name of the deployed application. I think this will afford me more deployment options down the road, and a huge configuration avenue has been opened up to me via the JNDI interface/implementation and how this information can be exclusively associated to deployed components in isolated contexts.

                              Thoughts?

                              Best,

                              John C. Dale
                              CEO
                              Down in the Desert, Inc.

                              • 12. Re: referencing application specific property files in ear f
                                katazan

                                Greg,

                                Are you using the manifest file in the EJB jar file to refer to itself in/from the ear file jar?

                                I'm simply not able to reference individual files (classes load fine) from the getResourceAsStream(...) method.

                                What version(s) of the product(s) are you using?

                                John C. Dale
                                CEO
                                Down in the Desert, Inc.