Hello Martin, Nice needle in the ashtray you found over there btw. Since we are in Java, the default behaviour of the == operator is memory address comparison. Seems that it's possible to overload operators for any object, but in the String class the '==' is not overloaded. It's strange how the committer let this go through, but he was right on the performance statement: it's faster to compare 2 string addresses than the actual content of the strings : ) I would say it's safe to revert.
Best Regards, Miguel Figueiredo -----Original Message----- From: Martin Kalén [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 27 de Junho de 2007 20:25 To: slide-dev@jakarta.apache.org Subject: Problem with PropertyName equals() when using JNDIPrincipalStore Greetings developers, after some hours of debugging a weird phenomena in my application I have a question about String .intern() usage in the equals() method of org.apache.slide.common.PropertyName. Quick summary: * problem with retrieving properties from a NodeRevisionDescriptor, when updating org.apache.slide.common.PropertyName to trunk (SVN r429274) * problem goes away if reverting change to PropertyName#equals, changing line 179 from: return this.name == that.name && this.namespace == that.namespace; to: return this.name.equals(that.name) && this.namespace.equals(that.namespace); (ie backing out r429274) Background information: I am using org.apache.slide.store.txjndi.JNDIPrincipalStore for retrieving user and group information from an LDAP server. When updating Slide from SVN trunk my groups started loosing all it's members [1] after some initial time - everything works fine at first NodeRevisionDescriptor property access, but not on subsequent property reads. Metacode for my usecase (based on the repository block from Cocoon v2.1.6): [code] public static final PropertyName GROUP_MEMBER_SET = PropertyName.getPropertyName("group-member-set"); ... SlideToken slideToken = new SlideTokenImpl(new CredentialsToken(caller)); Structure structure = nat.getStructureHelper(); Content content = nat.getContentHelper(); ObjectNode object = structure.retrieve(slideToken,path); String uri = object.getUri(); NodeRevisionDescriptors revisions = content.retrieve(slideToken, uri); NodeRevisionDescriptor revision = content.retrieve(slideToken, revisions); NodeProperty property = revision.getProperty(GROUP_MEMBER_SET); [/code] The last line tries to get the DAV:group-member-set property from the NodeRevisionDescriptor. This works fine on first access, but after a subsequent update of the revision descriptor due to JNDIPrincipalStore executing it's background RefreshThread to refresh the descriptor from LDAP, the PropertyName for DAV:group-member-set used for access is no longer considered equal to the PropertyName for DAV:group-member-set in "properties" hashtable of the NodeRevisionDescriptor (ie null is returned for the "property" reference above, although memory inspection shows that the NodeRevisionDescriptor indeed has the DAV:group-member-set property in it's property table). If i back out SVN commit r429274 [2] everything works fine. Reading up a bit on String.intern() does not make me any wiser, since I think it ought to work with "==" comparision in PropertyName, but I have a go vs no-go reproducable system showing that "==" and String equals() does not behave the same. Anyone else that had similar problems? Thoughts about this? Would it be OK to back out r429274? The SVN comment states performance improvements as reason for changing "String.equals()" to "==", but I suspect that in recent Java runtimes this difference might be almost neglectable. Best regards, Martin [1] group->member mapping is implemented by <href/>-values of the "DAV:group-member-set" property in JNDIPrincipalStore [2] See http://mail-archives.apache.org/mod_mbox/jakarta-slide-dev/200608.mbox/%3c20 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
