[
https://issues.apache.org/jira/browse/DIRSERVER-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Karasulu updated DIRSERVER-833:
------------------------------------
Fix Version/s: (was: 1.5.1)
2.0.0
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
matching.
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 within
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: https://issues.apache.org/jira/browse/DIRSERVER-833
> 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.
