Announcement Announcement Module
Collapse
No announcement yet.
configuration outside ear Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • configuration outside ear

    I need to be able to configure my J2EE application after it was compiled and packed.

    Before we used spring, we were reading some property files (and other resources), that kept specific configuration data for the runtime environment, from a file path outside the ear (the configuration-root). The absolute path to this configuration root was read from JNDI or a system-property (in that order).

    Now with spring I was thinking of using a similar strategy. My idea is to introduce a new path-prefix similar to the classpath: prefix. (configuration-root. A special PropertyEditor (extended from ResourceEditor) would convert Strings starting with this prefix into a a FileResource by replacing the configuration-root: prefix with the real path read from JNDI or System-Property. I would register this PropertyEditor in an extended FileSystemXmlApplicationContext (for EJB contexts) and XmlWebApplicationContext (for Web-Application contexts)

    Using these ApplicationContexts I can then refer to resources outside the EAR for example to load property files for a PropertyPlaceholderConfigurer etc.

    The xml files for the context can also stay within the configuration-root from where I can include other xml configuration files.

    Does this sound like a good idea or are there better strategies?
    How did you solve the problem that an application needs to be configured after it was compiled (without having to unpack and repack the ear)?

    Any advice is very much appreciated.

  • #2
    You could add your own prefix in order to accomodate your need however, I would try to reuse some of the existing features. If you know the location upfront then try using file: or http: since they allow connection to remote or local filesystem no matter if you are using an application server or not.
    If you have to do some lookups then try using the jndiObjectFB to create a one liner definition for retrieving the lookup path.

    Comment


    • #3
      Can you put config entries into an MBean.

      That way, you can even change settings on the fly.

      Comment


      • #4
        Thank you very much for your reply

        Originally posted by Costin Leau View Post
        I would try to reuse some of the existing features. If you know the location upfront then try using file: or http: since they allow connection to remote or local filesystem no matter if you are using an application server or not.
        I was as well considering to use existing features as much as possible. However, the problem is that there is already existing applications that are using this approach to read files from outside of the ear, i.e. from the file system, and I could not yet successfully convince people to change this approach. (It is also used in the deployment procedures, so it does make some sense to stay with that). Therefore I need an way to (consistently) refer to resources that are kept within this configuration-root. This could be property files for the PropertyPlaceholderConfigurer, but for example as well Hibernate mapping files or other Spring Context xml files. That is why I came up with this Idea of a special prefix for resources.

        I was as well looking into the option of using the placeholder mechanism of the ResourceEditor (where you could replace ${xyz} placeholder with values from System-Properties). However, that would require using unique placeholder keys in each J2EE application in order to be able to deploy multiple such applications within one container JVM. Therefore I thought that the prefix strategy was a bit more elegant and also does not require special security settings (to be able to set system properties).

        The basic issue is that I don't know the actual path to this configuration root until runtime. Therefore, I think, I cannot really use the standard file: or http: prefix directly. (Of course, the special configuration-root: prefix in the end is converted into a file: resource and therefore it does use this infrastructure in the background. Only the actual value or the root directory is read from JNDI or System Property at runtime).

        Does this make sense or did I miss an important feature?



        Originally posted by Costin Leau View Post
        If you have to do some lookups then try using the jndiObjectFB to create a one liner definition for retrieving the lookup path.
        Yes, thank very much you for this hint.

        Comment


        • #5
          Originally posted by gmatthews View Post
          Can you put config entries into an MBean.

          That way, you can even change settings on the fly.
          Thank you very much for this idea, I was using MBeans in other projects before to configure parts of the application, but unfortunately this is not an option in this project, since it is required to read the configuration values from file resources outside the J2EE application.

          Comment


          • #6
            We actually used the following approach (for JBoss, but I expect it could work for other app servers):

            1. Define an MBean that returns a Properties object. The properties are actually loaded from a .properties file when the MBean is initialized.
            2. Define a PropertyPlaceHolderConfigurer that is configured from the Properties object returned from the MBean; it looks it up using a JndiObjectFactoryBean

            With JBoss, this involves creating a SAR archive with a couple of classes. JBoss allowed us to locate the .properties file in a directory relative to our appserver configuration; thus we didn't need to hardcode any server-specific paths.

            So the properties are still external to the application, yet the application only depends on the default InitialContext for looking them up from JNDI.

            Tim

            Comment


            • #7
              use WebApplicationContext

              If you want to put your properties file in a path relative to your web deployment, you can write your own data source class that looks like:
              Code:
              public class MyDataSource extends JndiObjectFactoryBean implements ApplicationContextAware {
              	public void setApplicationContext(ApplicationContext applicationContext) {
              		WebApplicationContext webApplicationContext = (WebApplicationContext) applicationContext;
              		String rootAbsolutePath = this.applicationContext.getServletContext().getRealPath("/");
              		Properties props = new Properties();
              		BufferedInputStream inStream = new BufferedInputStream(new FileInputStream(rootAbsolutePath + System.getProperty("file.separator") + FILE_NAME));
              		props.load(inStream);
              		super.setJndiName(props.getProperty(PROP_NAME));
              	}
              }
              and your config:
              Code:
              <bean id="myDataSource" class="MyDataSource" />
              
              <bean id="hibernateSessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
              	<property name="dataSource" ref="myDataSource"/>
              	<property name="hibernateProperties">
              		...
              	</property>
              </bean>
              Last edited by ashish_awst; Sep 13th, 2007, 12:57 PM. Reason: correction

              Comment

              Working...
              X