[jira] Created: (DIRSERVER-1608) A couple of question os Apacheds 1.5.5 server.xml file
A couple of question os Apacheds 1.5.5 server.xml file -- Key: DIRSERVER-1608 URL: https://issues.apache.org/jira/browse/DIRSERVER-1608 Project: Directory ApacheDS Issue Type: Task Environment: All Reporter: Anusha Fix For: 1.5.5 In the server.xml can I know components of the DS do these attributes affect? maxSizeLimit=1500 ldapServer id=ldapServer maxTimeLimit=1500 maxSizeLimit=1500 If I change it to the following values what impact do you think it is going to have on the server? maxSizeLimit=3000 ldapServer id=ldapServer maxTimeLimit=15 maxSizeLimit=15 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DIRSERVER-1608) A couple of question os Apacheds 1.5.5 server.xml file
[ https://issues.apache.org/jira/browse/DIRSERVER-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny resolved DIRSERVER-1608. -- Resolution: Not A Problem The timeLimit and sizeLimit parameters are used to limit the number of enrries returned by a searchRequest and to limit the time it takes to return them. The default value is to return 1000 entries, and a searchRequest should not take more than 1000 seconds (which is insanely long, btw). Modifying those values makes sense if you want to protect the server against bad requests. A couple of question os Apacheds 1.5.5 server.xml file -- Key: DIRSERVER-1608 URL: https://issues.apache.org/jira/browse/DIRSERVER-1608 Project: Directory ApacheDS Issue Type: Task Environment: All Reporter: Anusha Fix For: 1.5.5 In the server.xml can I know components of the DS do these attributes affect? maxSizeLimit=1500 ldapServer id=ldapServer maxTimeLimit=1500 maxSizeLimit=1500 If I change it to the following values what impact do you think it is going to have on the server? maxSizeLimit=3000 ldapServer id=ldapServer maxTimeLimit=15 maxSizeLimit=15 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSHARED-91) Solve the issue with an embedded Felix running in codec while being embedded in eclipse RCP
[ https://issues.apache.org/jira/browse/DIRSHARED-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12995265#comment-12995265 ] Pierre-Arnaud Marcelot commented on DIRSHARED-91: - Confirmed! It's now fixed. After a few tweak here and there, Studio is now working perfectly in both RCP and 'in Eclipse' modes. Great job, Alex. Thanks! Solve the issue with an embedded Felix running in codec while being embedded in eclipse RCP --- Key: DIRSHARED-91 URL: https://issues.apache.org/jira/browse/DIRSHARED-91 Project: Directory Shared Issue Type: Sub-task Affects Versions: 1.0-M1 Environment: All Reporter: Alex Karasulu Fix For: 1.0-M2 Original Estimate: 48h Remaining Estimate: 48h Pierre is having issues and they may not go away. We might have to find an alternative. Some alternatives were posted here: http://goo.gl/OP6de -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DIRSHARED-91] Status
Confirmed! It's now fixed. After a few tweak here and there, Studio is now working perfectly in both RCP and 'in Eclipse' modes. Great job, Alex. Thanks! Regards, Pierre-Arnaud On mercredi 16 février 2011 at 06:06, Alex Karasulu wrote: I merged the trunks back to all m1 branches. You may need to do a superclean rebuild to get all working right again. I've got the build working here on my side after cleaning out a few things. Regards, Alex On Wed, Feb 16, 2011 at 5:47 AM, Alex Karasulu akaras...@apache.org wrote: After a discussion with Pierre last night we took an approach similar to how SLF4J works with a codec factory that generates the codec. This is documented in the svn commits that are tracked by the issue here: http://goo.gl/c6bi9 There's one problem though it seems there was a merge from trunk into just studio and other things were not updated. Plus the merge used the M1-SNAPSHOT instead of using the M2-SNAPSHOT that are currently available. I guess we can now merge from trunk but it's getting a little late for me. There's breakage due to mismatching identifiers but easy to fix. Basically we're all set with DIRSHARED-91. If we can just get this confirmed by getting studio back online we can close this remaining issue. Regards, Alex
[jira] Created: (DIRAPI-41) SASL connection information is not refreshed after a first SASL bind
SASL connection information is not refreshed after a first SASL bind Key: DIRAPI-41 URL: https://issues.apache.org/jira/browse/DIRAPI-41 Project: Directory Client API Issue Type: Bug Affects Versions: 1.0-M1 Reporter: Pierre-Arnaud Marcelot Assignee: Pierre-Arnaud Marcelot Fix For: 1.0-M2 SASL connection information is not refreshed after a first SASL bind. Successive SASL binds reuse SASL information (user, credentials, realm, etc) from the first bind method call, even if it is different in other bind method call. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DIRAPI-41) SASL connection information is not refreshed after a first SASL bind
[ https://issues.apache.org/jira/browse/DIRAPI-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Arnaud Marcelot resolved DIRAPI-41. -- Resolution: Fixed Fixed on both trunk and m1 branch. http://svn.apache.org/viewvc?rev=1071263view=rev http://svn.apache.org/viewvc?rev=1071264view=rev SASL connection information is not refreshed after a first SASL bind Key: DIRAPI-41 URL: https://issues.apache.org/jira/browse/DIRAPI-41 Project: Directory Client API Issue Type: Bug Affects Versions: 1.0-M1 Reporter: Pierre-Arnaud Marcelot Assignee: Pierre-Arnaud Marcelot Fix For: 1.0-M2 SASL connection information is not refreshed after a first SASL bind. Successive SASL binds reuse SASL information (user, credentials, realm, etc) from the first bind method call, even if it is different in other bind method call. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DIRAPI-42) Add additional classes and clean method arguments for SASL binds (CRAM-MD5, DIGEST-MD5, GSS-API)
Add additional classes and clean method arguments for SASL binds (CRAM-MD5, DIGEST-MD5, GSS-API) Key: DIRAPI-42 URL: https://issues.apache.org/jira/browse/DIRAPI-42 Project: Directory Client API Issue Type: Improvement Reporter: Pierre-Arnaud Marcelot Assignee: Pierre-Arnaud Marcelot Fix For: 1.0-M2 Add additional classes and clean method arguments for SASL binds (CRAM-MD5, DIGEST-MD5, GSS-API) There's a discussion for this on the dev mailing list: http://directory.markmail.org/thread/yjmnnvqfayg72kas -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Some more thoughts about the Dn class
Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Merge shared trunk to m1 branch
Excellent, it's already done. Thanks Alex. On Wed, Feb 16, 2011 at 2:12 AM, Alex Karasulu akaras...@apache.org wrote: +1 On Wed, Feb 16, 2011 at 1:51 AM, Pierre-Arnaud Marcelot p...@marcelot.net wrote: +1 Regards, Pierre-Arnaud On mercredi 16 février 2011 at 00:13, Stefan Seelmann wrote: Hi devs, is it ok to merge the changes in shared trunk to m1 branch? I already merged locally, fixed some version numbers and dependencies. I just run a full build to verify all works. The new version number will be 1.0.0-M2-SNAPSHOT. Kind Regards, Stefan
Re: Some more thoughts about the Dn class
On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharny elecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” dn.getAncestorDn( 6 ); = “5, 4, 3, 2, 1, 0” dn.getDnToAncestor( “1, 0” ); = “9, 8, 7, 6, 5, 4, 3, 2” dn.getDnToAncestor( 2 ); = “9, 8, 7, 6, 5, 4, 3, 2” Dn namingContext = “1, 0”; // all same below Dn dnAfterNamingContext = dn.getDnToAncestor( 1, 0 ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext.size() ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext.toString() ); dnAfterNamingContext === “9, 8, 7, 6, 5, 4, 3, 2” Overloads should be provided for Dn, String and int.
Re: Some more thoughts about the Dn class
On Wed, Feb 16, 2011 at 10:02 PM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharny elecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” dn.getAncestorDn( 6 ); = “5, 4, 3, 2, 1, 0” dn.getDnToAncestor( “1, 0” ); = “9, 8, 7, 6, 5, 4, 3, 2” dn.getDnToAncestor( 2 ); = “9, 8, 7, 6, 5, 4, 3, 2” Dn namingContext = “1, 0”; // all same below Dn dnAfterNamingContext = dn.getDnToAncestor( 1, 0 ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext.size() ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext.toString() ); dnAfterNamingContext === “9, 8, 7, 6, 5, 4, 3, 2” Overloads should be provided for Dn, String and int. Maybe some convenience methods like: dn.isAncestor( namingContext ); namingContext.isDescendant( dn ); dn.isRelated( namingContext ); = i.e. two DNs in different namingContexts will not be related namingContext.isParent( dn ); dn.isChild( namingContext ); dn.isSibling( namingContext ); Regards, Alex
Re: Some more thoughts about the Dn class
On 2/16/11 9:02 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” That's ok, but why not getParent() ? getAncestorDn() is lng. I'd rather use getAncestor(), but I find it more user friendly to use getParent() dn.getAncestorDn( 6 ); = “5, 4, 3, 2, 1, 0” Does not work. What if the initial dn is 9, 8, 7, 6, 5, 4, 6, 3, 2, 2, 0 ? dn.getDnToAncestor( “1, 0” ); Again, the name is frankly difficult to understand, and also confusing (getDnToAncestor ? getAncestorDn ? Which one does what ?). dn.getDescendant() is easier to understand, even if not perfect. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On 2/16/11 9:29 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 10:02 PM, Alex Karasuluakaras...@apache.org wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” dn.getAncestorDn( 6 ); = “5, 4, 3, 2, 1, 0” dn.getDnToAncestor( “1, 0” ); = “9, 8, 7, 6, 5, 4, 3, 2” dn.getDnToAncestor( 2 ); = “9, 8, 7, 6, 5, 4, 3, 2” Dn namingContext = “1, 0”; // all same below Dn dnAfterNamingContext = dn.getDnToAncestor( 1, 0 ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext.size() ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext.toString() ); dnAfterNamingContext === “9, 8, 7, 6, 5, 4, 3, 2” Overloads should be provided for Dn, String and int. Maybe some convenience methods like: dn.isAncestor( namingContext ); namingContext.isDescendant( dn ); We may add such methods, sure. Again, I'd rather use isParent( Dn ). IsDescendant( Dn ) fits me. dn.isRelated( namingContext ); = i.e. two DNs in different namingContexts will not be related dn.hasParent( Dn ) sounds again simpler. Every time you peek a different name for the same element (ancestor, related, ...), you confuse the user. namingContext.isParent( dn ); dn.isChild( namingContext ); isChild is not good, as the child is supposed to be the RDN only. isDescendant() and hasDescendant() is ok IMO, unless we decide that child fits better (dn.getChild( Dn ), dn.isChild( dn ), dn.hasChild( dn )) I'd like to get the API as simple as possible, avoiding using different terminology to describe the same cocept, plus to keep it simple to remember (and here, xxxdescendant() is problematic, because it's not easy to type without doing a mistake. I'd rather use 'child', if we don't mind about the Rdn relation) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On Thu, Feb 17, 2011 at 12:55 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/16/11 9:02 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” That's ok, but why not getParent() ? Because the result is not necessarily the parent of 'dn'. It may be if it's immediately superior. You're mixing together the meanings I think. getAncestorDn() is lng. I'd rather use getAncestor(), but I find it more user friendly to use getParent() dn.getAncestorDn( 6 ); = “5, 4, 3, 2, 1, 0” Does not work. What if the initial dn is 9, 8, 7, 6, 5, 4, 6, 3, 2, 2, 0 ? dn.getDnToAncestor( “1, 0” ); Again, the name is frankly difficult to understand, and also confusing (getDnToAncestor ? getAncestorDn ? Which one does what ?). dn.getDescendant() is easier to understand, even if not perfect. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On 2/17/11 12:03 AM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 12:55 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/16/11 9:02 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); =“5, 4, 3, 2, 1, 0” That's ok, but why not getParent() ? Because the result is not necessarily the parent of 'dn'. It may be if it's immediately superior. You're mixing together the meanings I think. Sorry, I don't get it. You have a DN, and you want the parent of it's left part, how possible the result couldn't be the parent ? If the parameter is not the left part, then you get an exception, but that's in the contract. Did I missed something ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On Thu, Feb 17, 2011 at 1:20 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/17/11 12:03 AM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 12:55 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/16/11 9:02 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” That's ok, but why not getParent() ? Because the result is not necessarily the parent of 'dn'. It may be if it's immediately superior. You're mixing together the meanings I think. Sorry, I don't get it. You have a DN, and you want the parent of it's left part, how possible the result couldn't be the parent ? If the parameter is not the left part, then you get an exception, but that's in the contract. Did I missed something ? The dn is “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” you're getting one of it's ancestors not it's parent. The parent would be “8, 7, 6, 5, 4, 3, 2, 1, 0”, the ancestor in the example is “5, 4, 3, 2, 1, 0”. You see what I mean? Alex
