Announcement Announcement Module
Collapse
No announcement yet.
Runtime Configuration Changes Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Runtime Configuration Changes

    Hi,

    I'm having real trouble finding good use of spring. I wish to use the Hibernate assistance classes to cut down uneccessary code but my problem is that I don't have information about datasource settings until runtime. In my app the database settings are provided at runtime though a swing gui and hence I can't simply construct my DAO's from a configuration.

    The hibernate templates dont seem to allow changing the datasource and I can't see how to modify an application context programmatically, so I can add settings, *then* construct my beans.

    What is best practice here? Should I even be using spring?

  • #2
    Once you know the settings, can't you just programmatically load in the bean config files? Like using xml class path loaders. There is a way to push and pull config values to these, PropertyOverrideConfigurer. See http://forum.springframework.org/showthread.php?t=9991

    In this post, I use a Swing gui to select beans in a context: http://forum.springframework.org/vie...hp?p=2100#2100 But, not really the same problem.

    btw, this sounds similar to another discussion regarding config when data required was coming from a database. In Jira there is some code that extends a factory to do this.

    Perhaps the Spring RC project has examples of your situation.
    Last edited by robyn; May 14th, 2006, 04:45 PM.

    Comment


    • #3
      Those methods for loading configs you mention are what you might call 'one pass' methods I guess. That is, once the configuration is loaded then you can't modify it. It doesn't look to me as if a PropertyOverrideConfigurer would let me change and save at runtime - it looks like it allows you to throw new values in on the first (and only) pass.

      For example. After my applicationcontext has loaded, I need to be able to do stuff like

      context.updateProperty("beanName", "user", user);
      context.updateProperty("beanName", "pass", pass);

      ISomeInterface object = (ISomeInterface) context.get("beanName");


      Because I can't do that, I have to put *all* the configuration within my business logic.

      ..........

      public void onApplicationShutdown() {
      context.saveModifications();
      }


      It just sort of makes sense to me - that lots of people would need to change config settings at runtime, especially for things like database access and since I was a newbie I therefore assumed it must be built already or most likely that I was attempting to use the framework incorrectly.

      Comment


      • #4
        I'm not sure of your environment but we use JMX to manipulate the hibernate session factory at run time. Hibernate provides an MBean implementation that creates a session factory and registers it with JNDI. The MBean exposes methods to allow you to change properties of the session factory (eg the datasource) and restart (which basically recreates the session factory for the new datasource).

        Using Spring is simply a process of specifying the session factoy as a JndiObjectFactoryBean.

        This is, of course, all within a J2EE container to provide both a JNDI implementation and a JMX server.

        But, JMX has been introduced into J2SE in v1.5 and I believe Spring is (or has?) introducing JMX support, so maybe this is worth looking into.

        Comment


        • #5
          Regarding the change of props during runtime.

          Maybe I'm being dense today. I don't get what the problem is. Since what is stored in the factories are POJOs and they adhere to the javabean 'pattern', you can change their properties anytime. Ultimately, even the JMX approach will just call a property setter, directly or via reflection.

          What I see is a problem with non-singletons. If you use the init-method attribute, how do you pass run-time params? Perhaps, by use of call-backs? But, this seems related to http://opensource.atlassian.com/proj...browse/SPR-334

          Comment


          • #6
            Originally posted by hidethebaby
            Those methods for loading configs you mention are what you might call 'one pass' methods I guess. That is, once the configuration is loaded then you can't modify it. It doesn't look to me as if a PropertyOverrideConfigurer would let me change and save at runtime - it looks like it allows you to throw new values in on the first (and only) pass.

            For example. After my applicationcontext has loaded, I need to be able to do stuff like

            context.updateProperty("beanName", "user", user);
            context.updateProperty("beanName", "pass", pass);

            ISomeInterface object = (ISomeInterface) context.get("beanName");


            Because I can't do that, I have to put *all* the configuration within my business logic.

            ..........

            public void onApplicationShutdown() {
            context.saveModifications();
            }


            It just sort of makes sense to me - that lots of people would need to change config settings at runtime, especially for things like database access and since I was a newbie I therefore assumed it must be built already or most likely that I was attempting to use the framework incorrectly.

            hi! i am having the same problem, have u foud a solution... i need to set up dataSourse to my hibernateTamplate in my dao objects... i am lost...

            Comment


            • #7
              Originally posted by jwray
              I'm not sure of your environment but we use JMX to manipulate the hibernate session factory at run time. Hibernate provides an MBean implementation that creates a session factory and registers it with JNDI. The MBean exposes methods to allow you to change properties of the session factory (eg the datasource) and restart (which basically recreates the session factory for the new datasource).

              Using Spring is simply a process of specifying the session factoy as a JndiObjectFactoryBean.

              This is, of course, all within a J2EE container to provide both a JNDI implementation and a JMX server.

              But, JMX has been introduced into J2SE in v1.5 and I believe Spring is (or has?) introducing JMX support, so maybe this is worth looking into.

              hi! can u tell us please how to y use JMX with some code lines please? what is this MBean. Thank you

              Comment

              Working...
              X