directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <>
Subject [jira] Updated: (DIRSERVER-833) Attribute(s)Impl usage and API
Date Fri, 17 Aug 2007 22:24:31 GMT


Alex Karasulu updated DIRSERVER-833:

    Fix Version/s:     (was: 1.5.1)

This is not so easy to do at the present time.

Emmanuel you have some good points here.  Yes we have to do comparisons 
(contains), gets etc with matchingRules driving the standard Java constructs for 

However I think that we should do away with using Attributes objects all together in the core
and have a ServerEntry as we discussed at some point.  This entry can be made schema aware
especially if instances are acquired from a factory within the server which can enable these
objects to have a handle on the schema registry elements they require to appropriately perform
checks on contains(), get(), etc.  Now when returning entries to the outside we can create
a wrapper class 
that implements the Attributes interface.  Does this sound good.

I am seeing a class of issues emerging which require a large refactoring of several aspects
the server.  This one hinges on the schema subsystem and the design of various interfaces
in the 
server.  I have changed this issue's fix to 2.0 but it might even go into 3.0.  Don't know
for sure.  However right now we should limit the amount of needless work we do on this since
it will just add more clutter without serious refactoring.

> Attribute(s)Impl usage and API
> ------------------------------
>                 Key: DIRSERVER-833
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Task
>            Reporter: Emmanuel Lecharny
>            Priority: Critical
>             Fix For: 2.0.0
> We should modify the Attribute(s)Impl API and usage. Those classes should never be used
outside of the server, and we should use BasicAttribute(s) instance instead.
> When we receive a BasicAttribute(s) instance, we should convert them to an Attribute(s)Impl
before working on attributes. 
> A second point is that operations like contains(), get() or equals() must use the matchingRules
instead of doing straight comparizons of case sensitive strings.
> Last, not least, we should not use the attribute name to do operations on attributes,
but their OID. Operations like 
> "objectClass".equals( trim( attributeType.getName() ).toLowerCase )
> should not be used. It's much better to define a static final OBJECT_CLASS_OID somewhere
and do a 
> OBJECT_CLASS_OID.equals( attributeType.getOid() )

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message