2 Replies Latest reply on Jan 21, 2003 10:32 AM by Adrian Brock

    Jboss 3.0.5 and propertyfiles/classloaders?

    Erik Turesson Novice


      I would like to use 3.0.5 instead of 3.0.4, but I have run into on problem. I am using XDoclet do generate my interface classes. I have changed the implementation of the *Util.getHome methods to look up my EJBs. I store the JDNI names in resource bundles. Each propertyfile is located at the top of each .jar file within my .ear file. The propertifiles are all named JNDI.properties, but located in different .jar files. Bellow is the code that reads the propertyfile and gets the jndi name for each ejb.

      private static String getJNDI(String key){
      java.util.ResourceBundle bundle = java.util.ResourceBundle.getBundle("JNDI");
      return bundle.getString(key);
      }catch(Exception e){
      System.out.println("com.proventek.scj.user.internalinterfaces.UserManagerUtil.getJNDI Key " + key + " not found!");
      return null;

      I 3.0.4 this works fine but in 3.0.5 allways the same propertyfile are fetched.

      Have the classloading or something else changed?
      Is this a bug or it is supposed to work this way?


        • 1. Re: Jboss 3.0.5 and propertyfiles/classloaders?
          Erik Turesson Novice


          I have now solwed my problem.
          I have named my .properties files so that they are unique within the .ear file.

          But my question still remains. Is it not allowed to have files that are named exactly the same if they are placed in different .jar files within one .ear file?


          • 2. Re: Jboss 3.0.5 and propertyfiles/classloaders?
            Adrian Brock Master

            The classloading in 3.0.5 has been changed so
            that all sub-deployments (ejbs) of a top level
            deployment (ear) share the same classloader.

            Before, each jar got its own classloader.

            This fixes problems where classes in supporting
            libraries make package private access to each other.

            But it does mean you cannot uniquely load resources
            from a sub-deployments jar, as you have found.

            This "new" behaviour was also the behaviour in JBoss2.x

            If you are not happy, report it as a bug