Announcement Announcement Module
No announcement yet.
Tricky Config Problem Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Tricky Config Problem


    I've written a class called LDAPAuthenticationService. It uses a LdapContextSource which is configured in a normal spring context config file, setting the "urls", "base", "userDn" and "password" properties.

    This works fine, but since we want to make the configuration as easy as possible for the person who has to install my app, I was wondering if I could...

    1) Create a parent class called something like AbstractLDAPAuthenticationService (no problem with this)

    2) Set virtually all of the standard properties such as port number, the 'ldap://' part of the url and baseDn in the parent class

    3) Set the hostname, userDn and password (for example) in the actual LDAPAuthenticationService class.

    I can't see a way to set e.g. the port number on its own, and also if it were possible, would I still get the failover behaviour that using the "urls" property gives me (by entering multiple URLs).

    Anyone know if this is possible/recommended/non-starter? Appreciate any feedback.


  • #2
    I think you're looking for a way of doing it to be portable to multiple environment. Try to implement a property handling so the application will read the property and pre-populate it when the application start. You can add the initialization on your context.xml and load the necessary property and passed it to your class file.


    • #3
      Thanks for the reply archetype. You are partly right about our environment, however it's a bit more complex that that; its the beans themselves that may or may not be deployed in certain environments, not just their properties. On app startup, Spring reads my additional context XML file and loads my bean(s) up using
      That mechanism works well for us. However we want to keep the configuration to a minimum, and make it as simple as possible for the people who are installing it by reducing the number of properties that need to be set.

      It's pretty lean as it is to be honest, but if it's possible to make it even more so I would like to do do it.

      Using property placeholders is something I might do (I usually do) but my question is more to do with what configuration options are possible for the LdapContextSource.

      Thanks again


      • #4
        I've got what I wanted eventually. I configure my bean with some really basic settings (just a map of arbitrary values) and then when my application context starts up (onApplicationEvent:ContextRefreshedEvent) I call an initialise method that my class implements. It then goes and programatically creates all the things my class depends on such as an LdapTemplate and ContextSource. I can build up the real properties that are required based on the very simple settings that I configured it with e.g. building up connection urls etc, and because its done this way, I have full control over how the settings are used.

        It was quite a bit of coding from my side (although not that much really) but the advantage is that when it gets implemented on a client site, the engineers have a REALLY simple configuration file to work with (it only contains the username (not the full DN), password, hostname and baseDN.

        Again, if this was the only configuration file required, this would be overkill, but we have lots and lots of others too!