Announcement Announcement Module
Collapse
No announcement yet.
problem getting full dn Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • problem getting full dn

    Hi, I am new using Spring-Ldap and my problem is that I need the full dn after a search operation to modify attributes of that entry. I have read the reference manual and some post about this, but I continue with this problem.


    Can anyone help me with some tips, please?

    Thank you

  • #2
    Simply use a ContextMapper, here is an example :
    Code:
        private class DnContextMapper implements ContextMapper {
    
    	/**
    	 * Mapping DN LDAP / UID
    	 * @param ctx
    	 * @return 
    	 */
    	public Object mapFromContext(Object ctx) 	{
    	    DirContextAdapter context = (DirContextAdapter)ctx;
    	    return context.getDn();
    	}
        }

    Comment


    • #3
      Actually, in the current version you'll not get the full DN of the entry if you have set a base path; the base path will be stripped from the value returned from getDn().

      In the upcoming version (any day now) we've included a method to get the full DN as well.

      Comment


      • #4
        context.getNameInNamespace()

        OK, the new release is out (talking about 1.1.1)..
        I've been waiting for the dirContextAdapter.getNameInNamespace() method...

        When I invoke it in my app, running on tomcat, i get the rdn relative to my base.As expected.

        When i invoke it in the sam app runing on WAS 5.1, i only get a CN=Name.

        The same thing happens with the dirContextAdapter.getDn() method.

        Ideas anyone?

        Comment


        • #5
          I'm not sure if I understand what you mean. Are you saying that the getNameInNamespace() method of DirContextAdapter works as it should under Tomcat, but not when running under WAS 5.1?

          If the configuration is exactly the same, I'd guess it's some jdk compatibility issue; WAS runs under IBM's JDK right? What JDK version are you running?

          Comment


          • #6
            Hey rasky, thanks for giving this some thought....

            The config is the same, it is the same app after all
            I've been running it on the following:
            - sun jdk 1.4.2 / tomcat 5.0.29 / 5.5
            - sun jdk 1.4.2 / was 5.1
            - ibm jdk 1.4.2 / was 5.1

            In tomcat, dirContextAdapter.getDn() and dirContextAdapter.getNameInNamespace() return the rdn of the object, without the base. In WAS 5.1, i only get the last leaf in the dn (ie cn=something).

            I also thought tha java version was the guilty party here, but running WAS on different versions, and upgrading it to the last cummulative patch didn't help a bit...

            Comment


            • #7
              Could you set a breakpoint near the call to getDn and check the environment on the context for both situations?

              We should rule out any funny stuff that the WAS may be doing regarding factories and such.

              Comment


              • #8
                Allready did that because i wanted to see if the base or server path changed somehow...but.....the environment remains the same in all cases.

                I'm working with IBM Ldap, my next test is to try to run my app on OpenLDAP, and see what happens...Will report back with findings.

                Comment


                • #9
                  I took a closer look at this now and unfortunately it seems it still doesn't work (in Spring LDAP 1.1.1). I got it the wrong way around when I implemented it; sorry for the inconvenience.

                  Comment


                  • #10
                    We actually decided to do an extra release where this is fixed. In Spring LDAP 1.1.2 (available for download here), the getNameInNamespace method of DirContextAdapter should be working properly, i.e. returning the full DN of the entry, including the base path.

                    Comment


                    • #11
                      Hey,

                      Many thanks on the unplanned release, I'll try it out and see if it solves my problems..

                      Thanx again!

                      Comment

                      Working...
                      X