directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: [jira] Closed: (DIRSERVER-948) Possibly a Bug - See Descrption
Date Thu, 31 May 2007 04:50:50 GMT
Good Point.

That one could have been a "Little" cleaner :-)

I'm going to try Quaaludeing.

Thanks,
- Ole




Alex Karasulu wrote:
> Ole, my buddy,
> 
> Why put "Possibly a Bug - See Description" into the subject when in JIRA 
> you can label issues as a
> bugs?  Furthermore how do you expect someone looking at a looooong list 
> of issues in JIRA to know
> what you're talking about with such a title?   You cannot expect 
> everyone to go into that description
> just for your issue.
> 
> Good god man you have more sense than this: stop, take a breath, pop a 
> Quaalude if you have to,
> and think before you touch your keyboard :).
> 
> Alex
> 
> On 5/30/07, *Ole Ersoy (JIRA)* <jira@apache.org 
> <mailto:jira@apache.org>> wrote:
> 
> 
>          [
>     https://issues.apache.org/jira/browse/DIRSERVER-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>     ]
> 
>     Ole Ersoy closed DIRSERVER-948.
>     -------------------------------
> 
>         Resolution: Fixed
> 
>     Whooopseee - Got it.
> 
>     The members on  AbstractTypeCreator
>     were static.
> 
>     When the MetaTopSDOObjectClassCreator
>     runs, it also creates the AttributeType
>     entries that it needs, and these
>     creators also use the AbstractTypeCreator.
> 
>     So the AbstractTypeCreator members
>     were getting shared...
> 
>      > Possibly a Bug - See Descrption
>      > -------------------------------
>      >
>      >                 Key: DIRSERVER-948
>      >                 URL:
>     https://issues.apache.org/jira/browse/DIRSERVER-948
>      >             Project: Directory ApacheDS
>      >          Issue Type: Bug
>      >         Environment: FC6
>      >            Reporter: Ole Ersoy
>      >            Priority: Minor
>      >
>      > I'll check the test in that shows this when I
>      > check in the DAS.
>      > I have a parent class that does this:
>      > public abstract class AbstractTypeCreator
>      > implements
>      > EnumeratedSchemaAttributeTypeValues,
>      > SchemaAttributeTypeConstants,
>      > AttributeTypeConstants,
>      > SchemaObjectClassConstants,
>      > ObjectClassConstants,
>      > DASConstants
>      > {
>      >     protected static Attribute objectClassAttribute;
>      >     protected static Attributes basicAttributes;
>      >
>      >     protected static void create()
>      >     {
>      >         objectClassAttribute    =
>      >             new BasicAttribute(
>      >                 OBJECT_CLASS, TOP );
>      >
>      >         objectClassAttribute.add(
>      >             META_TOP );
>      >
>      >         basicAttributes = new BasicAttributes();
>      >         basicAttributes.put(objectClassAttribute);
>      >         basicAttributes.put( M_OBSOLETE, LDAP_FALSE );
>      >     }
>      > }
>      > What I want to do is leverage the work in
>      > this parent class here.  Notice I have
>      > commented out the
>      > work that the parent class does.
>      > package org.apache.tuscany.das.ldap.schema.create;
>      > import javax.naming.NamingException;
>      > import javax.naming.directory.Attribute;
>      > import javax.naming.directory.BasicAttribute;
>      > import javax.naming.directory.BasicAttributes;
>      > import javax.naming.directory.DirContext;
>      > public class MetaTopSDOObjectClassCreator
>      > extends AbstractTypeCreator
>      > {
>      >     public static void create(
>      >         DirContext attributeTypesContext,
>      >         DirContext objectClassesContext,
>      >         String oidPrefix)
>      >     throws NamingException, Exception
>      >     {
>      >         //Here's where we initialize the parent
>      >         AbstractTypeCreator.create();
>      >
>      >         MComplexMayAttributeTypeCreator.create(
>      >             attributeTypesContext,
>      >             oidPrefix );
>      >
>      >         MComplexMustAttributeTypeCreator.create(
>      >             attributeTypesContext,
>      >             oidPrefix );
>      >
>      >         /* Commenting out the work that the parent does
>      >         Attribute objectClassAttribute    =
>      >             new BasicAttribute(
>      >                 OBJECT_CLASS,
>      >                 TOP );
>      >
>      >         objectClassAttribute.add(
>      >             META_TOP );
>      >             */
>      >
>      >         objectClassAttribute.add( META_OBJECT_CLASS );
>      >
>      >         //basicAttributes = new BasicAttributes(); parent does
>     this work
>      >         basicAttributes.put(objectClassAttribute);
>      > //        basicAttributes.put( M_OBSOLETE, LDAP_FALSE ); parent
>     does this work
>      >         basicAttributes.put( M_MAY,               M_COMPLEX_MAY);
>      >         basicAttributes.put( M_MAY,               M_COMPLEX_MUST);
>      >         basicAttributes.put( M_OBSOLETE,          LDAP_FALSE );
>      >         basicAttributes.put(
>     M_SUP_OBJECT_CLASS,  META_OBJECT_CLASS );
>      >         basicAttributes.put( M_TYPE_OBJECT_CLASS, STRUCTURAL);
>      >         basicAttributes.put(
>     M_NAME,              M_META_TOP_SDO_OBJECT_CLASS);
>      >         basicAttributes.put( M_DESCRIPTION,
>      >             "Meta ObjectClass for all SDO DataObjects" );
>      >
>      >         String rdn =
>      >             ComplexTypeRDNCreator.create(
>      >                 oidPrefix,
>      >                 DAS_XSD_NAMESPACE,
>      >                 M_META_TOP_SDO_OBJECT_CLASS);
>      >         objectClassesContext.createSubcontext(
>      >             rdn, basicAttributes );
>      >     }
>      > }
>      > Now when I run the test
>      > MetaTopSDOObjectClassCreatorTest (I'll check it
>      > in when I check in the DAS)
>      > I get this:
>      > javax.naming.InvalidNameException:
>     m-oid=1.3.6.1.4.1.18060.4.99985052.4991015.9998535.5410097.9495056.0251549.9857505.52551005.48:
>     [LDAP: error code 64 - failed to add entry
>     m-oid=1.3.6.1.4.1.18060.4.99985052.4991015.9998535.5410097.9495056.0251549.9857505.52551005.48
>     ,ou=objectClasses,cn=das,ou=schema: The parent entry of a
>     attributeType should have a relative name of ou=attributeTypes.];
>     remaining name
>     'm-oid=1.3.6.1.4.1.18060.4.99985052.4991015.9998535.5410097.9495056.0251549.9857505.52551005.48
>     '
>      >       at
>     com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2943)
>      >       at
>     com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2758)
>      > However if I comment
>      > the line
>      > ===================================
>      > AbstractTypeCreator.create();
>      > ===================================
>      > And uncomment these:
>      > ===================================
>      >       Attribute objectClassAttribute    =
>      >             new BasicAttribute(
>      >                 OBJECT_CLASS,
>      >                 TOP );
>      >
>      >         objectClassAttribute.add(
>      >             META_TOP );
>      >
>      >         objectClassAttribute.add( META_OBJECT_CLASS );
>      >
>      >         basicAttributes = new BasicAttributes();
>      >         basicAttributes.put(objectClassAttribute);
>      >         basicAttributes.put( M_OBSOLETE, LDAP_FALSE );
>      > The same exact test runs fine.
>      > It seems to me that test should run fine in either case...
>      > For some reason it now thinks that I'm trying to create
>      > an AttributeType entry...
> 
>     --
>     This message is automatically generated by JIRA.
>     -
>     You can reply to this email to add a comment to the issue online.
> 
> 

Mime
View raw message