6 Replies Latest reply on May 17, 2005 4:23 AM by mikesg

    Application properties outside the ear package in 4.0

    mikesg

      Sorry if this is a frequently asked question, but my search withih the forums and google did not return results to help me completely answer the question myself.
      I am upgrading from JBoss 3.2 to 4.0 and I am facing some difficulties with property files. We used to deploy our applications using the following structure which worked fine in 3.2:
      ...\deploy
      ........|-app1 <-A directory
      ........|......|-app.ear
      ........|......|-config1.properties
      ........|......|-config2.properties
      ........|-app2 <-A directory

      The properties are accessed using ResourceBundle.getBundle("config1"),
      so they must be on the classpath main level.
      This gave us way to reconfigure some properties without repacking the ear file.

      Using the same structure in JBoss 4.0 results in the following upon startup:

      11:00:27,359 WARN [JARDeployer] Failed to add deployable jar: file:/F:/newServers/jboss-4.0.1sp1/server/default/tmp/deploy/tmp14870bubu.properties
      java.util.zip.ZipException: error in opening zip file
       at java.util.zip.ZipFile.open(Native Method)

      And the property file is not accessible by the application anymore.
      After putting the property files into a jar file that resides on the same level as the ear the application accessed them and I had no deployment warning.

      So my question is what structure of the deployment should be used in order to provide the same effect of property files outside the ear file.

      Or if this is no longer possible can you please point me to some documentation where the structure of the application and the file locations are described.

      Thanks for your attention and time

      Mike

        • 1. Re: Application properties outside the ear package in 4.0
          mikesg

          I still cannot get to a solution for this.
          Can someone please guide me what parts of the documentation could contain information on this issue, or what keywords to search, it seems I am searching in the wrong direction.

          Thanks
          Mike

          • 2. Re: Application properties outside the ear package in 4.0
            starksm64

            Such a deployment shown no such exception in 4.0.1sp1. A bug report with an example, version details of jboss, jdk would help.

            http://jira.jboss.com/jira/browse/JBAS

            • 3. Re: Application properties outside the ear package in 4.0
              mikesg
              • 4. Re: Application properties outside the ear package in 4.0
                dimitris

                Isn't this because the URLDeploymentScanner recurses into the 'hallo' subdir, then attempts to deploy 'hallo.properties' file using the JARDeployer?

                I guess the solution is to configure the Scanner to ignore the .properties extension (i.e. add .properites to the suffixes list below):

                 -->
                 <attribute name="FilterInstance"
                 attributeClass="org.jboss.deployment.scanner.DeploymentFilter"
                 serialDataType="javaBean">
                 <!-- Files starting with theses strings are ignored -->
                 <property name="prefixes">#,%,\,,.,_$</property>
                 <!-- Files ending with theses strings are ignored -->
                 <property name="suffixes">#,$,%,~,\,v,.BAK,.bak,.old,.orig,.tmp,.rej,.sh</property>
                 <!-- Files matching with theses strings are ignored -->
                 <property name="matches">.make.state,.nse_depinfo,CVS,CVS.admin,RCS,RCSLOG,SCCS,TAGS,core,tags</property>
                 </attribute>
                

                This is introduced in v4.0.2.

                • 5. Re: Application properties outside the ear package in 4.0
                  mikesg

                  Thanks for the quick reply, Dimitris,
                  I implemented a simple filter that uses DeploymentFilter as default filter and excludes .properties itself (code is after the message), and I got rid of the 'Failed to add deployable jar' message.
                  However the bundle still is not on the classpath because I get MissingResourceException:

                  13:00:02,109 ERROR [LogInterceptor] RuntimeException in method: public abstract java.lang.String com
                  .nbl.ejb.HalloEJB.sayHallo():
                  java.util.MissingResourceException: Can't find bundle for base name Hallo, locale en_US
                   at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:804)
                   at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:773)
                   at java.util.ResourceBundle.getBundle(ResourceBundle.java:511)
                   at com.nbl.ejb.HalloEJBBean.sayHallo(HalloEJBBean.java:17)
                   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                  

                  I put a log message that tells me the file is excluded and it shows it is ignored:

                  13:03:38,906 INFO [STDOUT] >>>>Ignore URL:file:/F:/newServers/jboss-4.0.1sp1/server/default/deploy/
                  hallo/(Hallo.properties)
                  


                  Anyway, thanks for the quick reply.
                  I have another question: is 4.0.2 available somewhere or it is scheduled for later times, since I didn't see it in the downloads section.

                  Mike
                  import java.io.*;
                  import org.jboss.deployment.scanner.DeploymentFilter;
                  
                  public class PropertyExcludeFilter implements FileFilter, org.jboss.net.protocol.URLLister.URLFilter{
                   private DeploymentFilter defaultFilter = new DeploymentFilter();
                  
                   public boolean accept(java.net.URL url, String s){
                   if(s.endsWith("properties")){
                   System.out.println(">>>>Ignore URL:" + url + "(" + s + ")");
                   return false;
                   }
                   return defaultFilter.accept(url, s);
                   }
                  
                   public boolean accept(File pathname){
                   if(pathname.getName().endsWith("properties")){
                   System.out.println(">>>>Ignore:" + pathname);
                   return false;
                   }
                   return defaultFilter.accept(pathname);
                   }
                  }
                  


                  • 6. Re: Application properties outside the ear package in 4.0
                    mikesg

                    I downloaded and installed 4.0.2 (CVSTag=JBoss_4_0_2 date=200505022023)

                    I configured the deployer filter so it will filter .properties files, however this did not solve the problem - I got MissingResourceException again.

                    However, there is another strange problem I had not observed before. I found the reason why the EJB was not bound when my example posted in the bug report was tested: for some reason the EJB was bound like this:

                    # jndiName=local/HalloEJB@1669611,service=EJB
                    (copy-pasted from http://localhost:8080/jmx-console/ section jboss.j2ee)

                    instead of the expected local/HalloEJB.

                    I modified my JSP to accept a parameter for that lookup(it varies for different startups and managed to reach the bean). So for the above startup I wrote in the browser:

                    http://localhost:8080/hallo/Hallo.jsp?lookup=@1669611

                    Sorry, I was not able to shrink it to a one-click test.
                    The same deployment works as expected under 3.2.1. Adding those lines in the ejb-jar.xml did not help either:

                     <jndi-name>HalloEJB</jndi-name>
                     <local-jndi-name>HalloEJB</local-jndi-name>
                    


                    The new deployment is attached to the issue(http://jira.jboss.com/jira/browse/JBAS-1697)

                    Thanks for your time and cooperation
                    Mike