Announcement Announcement Module
Collapse
No announcement yet.
How to get a DirContext object Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to get a DirContext object

    What kind of bean config (applicationContext.xml) do I need to get an object that implements DirContext?

  • #2
    I'm not quite sure if I know what you mean, but the standard bean configuration is described in the reference documentation distributed with the library.

    If what you're trying to do is not covered by the reference documentation you'll need to be more specific as to what you need.

    Comment


    • #3
      I need an object that is a "javax.naming.directory.DirContext" object.
      Like now with spring + jboss (where ther is a ldap source configured in jndi) I can use:

      <bean id="dirContext" class="org.springframework.jndi.JndiObjectFactoryB ean">
      <property name="jndiName">
      <value>external/ldap/jboss</value>
      </property>
      </bean>

      this returns a javax.naming.directory.DirContext object (probably an javax.naming.ldap.InitialLdapContext object)

      But with this config I get an object that isn't a DirContext (I use this when I haven't got jboss around, eg. testing)

      <bean id="contextSource" class="org.springframework.ldap.support.LdapContex tSource">
      <property name="url" value="ldap://localhost:389" />
      <property name="base" value="dc=example,dc=com" />
      <property name="userName" value="cn=Manager" />
      <property name="password" value="secret" />
      </bean>

      There were some classes that sounded interesting like DirContextAdapter, but I don't know how they should be used...

      Thanks for the help.

      Comment


      • #4
        It you need the DirContext object I guess you need it for performing LDAP operations on, right? You get a DirContext instance by calling ContextSource.getReadOnlyContext/getReadWriteContext. However, you'd be better of calling LdapTemplate.executeReadOnly/executeReadWrite. That way you just don't need to worry about context creation and closing.

        If you want you can create your own ContextSource implementation that just retrieves the instance from jndi.

        But really, it doesn't seem to be such a good idea to have a DirContext instance stored in jndi and using that instance everywhere you do LDAP. That would be like placing a single DB connection in jndi and using it everywhere you do SQL.

        Comment


        • #5
          Rather than picking a DirContext from JNDI, I would have stored a ContextSource there. That's similar to storing the DataSource in order to be able to get database connections from it.

          My production configuration would then look something like this:

          Code:
          <bean id="contextSource" class="org.springframework.jndi.JndiObjectFactoryBean">
             <property name="jndiName" value="external/ldap/jboss" />
          </bean>
          
          <bean id="ldapTemplate" class="org.springframework.ldap.LdapTemplate">
             <constructor-arg ref="contextSource" />
          </bean>
          
          <bean id="personDao"
             class="org.springframework.ldap.samples.person.dao.PersonDaoImpl">
             <property name="ldapTemplate" ref="ldapTemplate" />
          </bean>
          
          ...
          My integration test configuration would not use a ContextSource from JNDI. Instead I would configure it directly:

          Code:
          <bean id="placeholderConfig"
             class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
             <property name="location" value="WEB-INF/ldap.properties" />
          </bean>
          
          <!-- Authenticate using a fixed user -->
          <bean id="contextSource"
             class="org.springframework.ldap.support.LdapContextSource" >
             <property name="urls" value="${urls}" />
             <property name="base" value="${base}" />
             <property name="userName" value="${userName}" />
             <property name="password" value="${password}" />
          </bean>
          
          ...
          The ldap.properties could look like this:

          Code:
          urls=ldap://integration.ldap.example.com
          base=dc=example,dc=com
          userName=cn=manager,ou=system
          password=somepwd
          If I wanted every user to authenticate their connection, rather than using a single hard-coded user, I would use Acegi Security together with our AcegiAuthenticationSource:

          Code:
          <bean id="placeholderConfig"
             class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
             <property name="location" value="WEB-INF/ldap.properties" />
          </bean>
          
          <!-- Authenticate using the currently logged in user, retrieved by Acegi Security -->
          <bean id="contextSource"
             class="org.springframework.ldap.support.LdapContextSource" >
             <property name="urls" value="${urls}" />
             <property name="base" value="${base}" />
             <property name="authenticationSource" ref="acegiAuthenticationSource" />
          </bean>
          	
          <bean id="acegiAuthenticationSource"
             class="org.springframework.ldap.support.authentication.AcegiAuthenticationSource" />
          
          ...
          In this case, the ldap.properties only needs this:

          Code:
          urls=ldap://integration.ldap.example.com
          base=dc=example,dc=com

          Comment


          • #6
            Thanks for your informative answers, I think I can build something out of them.

            I have a kind of "legacy" application, so I wouldn't want to change the code.
            The code gets injected with a DirContext object, with which it runs ldap-operations, eg. ctx.lookup(dn).
            I don't need to worry about closing/opening connections, that just works when using jboss's namingcontext.

            Just FYI, here how it's configured (in jboss, ie. a DirContext is ultimately stored in JNDI and from there it can be had with spring and injected).


            in jboss-service.xml

            <mbean code="org.jboss.naming.ExternalContext"
            name="jboss:service=ExternalContext,jndiName=exter nal/ldap/jboss">
            <attribute name="JndiName">external/ldap/jboss</attribute>
            <attribute name="PropertiesURL">ldap.properties</attribute>
            <attribute name="InitialContext">javax.naming.ldap.InitialLda pContext</attribute>
            <attribute name="RemoteAccess">true</attribute>
            <depends>jboss:service=Naming</depends>
            </mbean>

            And ldap.properties contains:

            java.naming.factory.initial=com.sun.jndi.ldap.Ldap CtxFactory
            java.naming.provider.url=ldap://localhost:636
            java.naming.security.principal=cn=admin
            java.naming.security.authentication=simple
            java.naming.security.credentials=aaaa
            java.naming.security.protocol=ssl

            Comment


            • #7
              Hi Ulsa, rasky,

              I am having the same problem right now. So searched out this very old discussion.
              I am using jboss 5.1. My jndi returns the DirContext. So far that works fine.
              However I agree with you that it's better to store the ContextSource in jndi.
              But how to configure the jndi so that it can create and return ContextSource?

              Another could be jboss question. How to make it as a pool in JBoss?
              Last edited by PeterSaw; Jun 19th, 2012, 08:52 PM.

              Comment

              Working...
              X