Announcement Announcement Module
Collapse
No announcement yet.
database driven application properties Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • database driven application properties

    I have my beans defined in the config files with default values, liek this one:
    <bean id="mailSender" class="org.springframework.mail.javamail.JavaMailS enderImpl">
    <property name="host">
    <value>mail.mycompany.com</value>
    </property>
    </bean>
    I would like to save those options in the database instead of in the config files.
    I could create an application bean, which would contain a reference to DAO for looking up the properties and pass reference to that bean for all other beans needing reference to properties.

    I am thinking that might not be very helpful when I need to enhance the app tp allow customization of those properties per user (kind of 2 different problems I know but still).

    Is there a nice regular/accepted way of doing that kind of thing?

    Thanks

  • #2
    Why make it available in the context then?
    Just make it available like a service from your service layer.

    Like
    Code:
    class MyService {
        private MyDao dao;
    
        public JavaMailSender getMailSender() {
            JavaMailSender sender = new JavaMailSenderImpl();
           
           // collect data from dao layer
    
           sender.setHost(host);
           ...
           return sender; 
        }
    
    }
    In your MailService you populate the sender bean with info from the database layer.

    /montana
    Last edited by montana; Nov 18th, 2005, 04:53 PM.

    Comment


    • #3
      I could, don't think I want the service to be directly dao dependent but it would work fine. It is basically the same principle as I proposed.

      That would not give me quite what I want though. I keep thinking the ability to have application properties, potentially dependent on the current user, is a basic requirement for an dynamic web site.
      I was wondering if anybody came up with an elegant solution to the problem.

      It is almost a cross cutting concern, starting thinking where that would be one of the things I could use AOP for. Not entirely sure how to optionaly make it user logged dependent though.

      Thanks for replying, I appreciate

      Comment


      • #4
        That sounds an interesting idea. Eventually, an interceptor could change the value of the current fields, but, hmm, that couldn't make the singleton thread safe, which defeats the original purpose. Hence, that must be prototypes which are used, in which case I guess the user defined values can be set at construction time.
        Or, keeping in mind the AOP approach, it could only be used to alter the method parameters, which is thread safe.
        Why not, indeed ...
        what do you think of this ? I'd be interested in trying to tweak spring code to add this eventually ...

        Comment


        • #5
          This is where I am at:
          - MailSender as a host property that is currently set using the bean mapping.
          - I can use AOP to intercept calls to getter and change the ouput with round advice to be the readProperty from the application property object.
          - It does not solve the issue of user specific values. I have started implementing acegi security and they manage to implement it using AOP so there must be a way to access the Authentication object. I will look into that.

          I am thinking of creating a special property name to make sure I don't call it for all getters like getHostProperty() instead of getHost().

          Not sure I like adding the host as a parameter toSendMail() method but it works too.

          How does that sound?

          Comment


          • #6
            There is a problem with this approach. The getters need to be declared in the interface for the AOP to be able to intercept those calls.
            My issue with that one of my class implementing the interface needs to have as parameter that does not really make sense in the context of the parent interface.
            I might need to go back to the obvious approach of passing an object containing the properties to the implementing classes. Or a combination of both.

            Does anybody have a better idea?

            Thanks

            Comment

            Working...
            X