7 Replies Latest reply on Dec 1, 2008 10:17 AM by Rajagopal Yendluri

    Seam.properties and components.properties?

    Matt Davis Newbie

      Would someone mind quickly explaining how these work?  I know that seam.properties goes into the folder with your entities...  but what if you want to package them into subfolders? Do I need to put a seam.properties file into each and every subfolder that has an entity bean in it?


      I'm not sure what components.properties does at all... I think it is an alternative to components.xml or something?


      Anyhow, a quick explanation of these 2 files would be awesome.

        • 1. Re: Seam.properties and components.properties?
          Matt Davis Newbie

          And is there anything that can go inside these files? Or are they  just marker files or something?

          • 2. Re: Seam.properties and components.properties?
            Pete Muir Master

            seam.properties is both a marker file, and, if placed on WAR classloader e.g. in WEB-INF/classes can be used to set properties on Seam components e.g.


            application.name=Seam Wiki



            components.properties can be used to do ant style replacement in components.xml on the fly:


            <component name="application">
               <property name="name">@name@</property>
            </component>



            name=Seam Wiki

            • 3. Re: Seam.properties and components.properties?
              Tom Nichols Newbie

              Hi Pete --


              Can you go into a little more detail about how seam.properties files are resolved and used? 


              The reference documentation (Section 5.1) suggests you should only have a single seam.properties file at the root of the classpath.  But then how does this work if you have Seam-managed resources in multiple JARs?  Since the same documentation says it uses a seam.properties file for Seam's own configuration, it would indicate it is possible to have more than one seam.properties file.  So how exactly does Seam handle these files?


              I'm asking because I'm attempting to use that mechanism to inject a file path into a @Name-d SLSB.  However I can't seem to get the value to be injected into my bean. 


              My SLSB looks like this:


              @Name("configBean") @Stateless
              public class ConfigBeanImpl implements ConfigBean {
              
                private File configBaseDir;
              
                // code....
                
                public void setConfigBaseDir( String dir ) {
                  configBaseDir = new File( dir );
                }
              



              seam.properties


              configBean.configBaseDir /var/tmp/MyApp/config/




              Since the setter wasn't being called I thought an empty (marker) seam.properties file might be preceeding it in the classpath from another JAR (which it was).  So I copied this seam.properties file to the root of my EAR and verified that it was indeed being pulled from the classpath by calling


              getClass().getResourceAsStream("/seam.properties")



              and reading the result.  But the value still is not getting to my SLSB.  So what should I do? 


              Thanks.

              • 4. Re: Seam.properties and components.properties?
                Pete Muir Master

                Tom Nichols wrote on May 27, 2008 17:53:


                The reference documentation (Section 5.1) suggests you should only have a single seam.properties file at the root of the classpath.  But then how does this work if you have Seam-managed resources in multiple JARs?  Since the same documentation says it uses a seam.properties file for Seam's own configuration, it would indicate it is possible to have more than one seam.properties file.  So how exactly does Seam handle these files?



                You can have a single seam.properties at the root of each archive (look at how getClass().getClassLoader().getResources() returns an enumeration of URLs).



                Since the setter wasn't being called I thought an empty (marker) seam.properties file might be preceeding it in the classpath from another JAR (which it was).  So I copied this seam.properties file to the root of my EAR and verified that it was indeed being pulled from the classpath by calling

                Make sure the seam.properties which you are setting properties from is in the WAR classloader.

                • 5. Re: Seam.properties and components.properties?
                  Tom Nichols Newbie

                  Make sure the seam.properties which you are setting properties from is in the WAR classloader.

                  Can you elaborate?  The seam.properties file has to be in the root of the WAR file?  Now the actual component I'm trying to configure is an SLSB in another JAR.  But the configuration value has to be in the root of the WAR rather than in the JAR with the associated class?


                  Thanks again Pete for the explaination.

                  • 7. Re: Seam.properties and components.properties?
                    Rajagopal Yendluri Newbie

                    We need to include a seam.properties file in the root of the archive(ear/war/jar) file.
                    We have to do this for all the archive's whereever we are using the @Name Annotation.
                    Seam will check every Java class packaged in that archive for component annotations, and bind them to names according to their @Name annotations. If there is no seam.properties file, no checking will be done, and your components won’t be bound to JSF names.


                    Why does Seam force you to flag your archives this way ?


                    Well, if an archive contains a significant number of classes, parsing all of them for Seam annotations can be an expensive operation. Even if it’s only a one-time scan performed when an application is deployed, you might like to avoid this when possible.


                    How exactly does Seam trigger the scan for component names?


                    configuring an application to use Seam included the addition of a listener to the web.xml deployment file:


                    -listener-
                         -listener-class-org.jboss.seam.servlet.SeamListener-/listener-class-
                    -/listener-


                    This listener is the key to the component-naming magic (as well as several other Seam capabilities). When the web container starts up the web context for the application, it initializes any listeners configured in the web.xml file. The SeamListener, in its initialization routine, checks each archive that has been loaded with the application for a seam.properties file (it does this through some class loader games that I won’t go
                    into here). If an archive contains this file, it’s a simple matter (through other class loader games) to iterate through all the classes loaded in that archive for @Name annotations. Each one that’s found is inserted into a list of name bindings with the appropriate details needed to manage the component at runtime.


                    s. Then edit this text and check the preview.