directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [Shared] [Model] What was the reason for removing the schema entity interfaces like AttributeType?
Date Tue, 08 Mar 2011 15:43:01 GMT
On Tue, Mar 8, 2011 at 10:09 AM, Pierre-Arnaud Marcelot <>wrote:

> Hi Alex,
> That's something I had also noticed a few weeks ago.
> See [1].
> I wanted to decouple the SchemaObjects from the SchemaManager, but I guess
> I ran into other work and couldn't complete it.
> AFAIR there are around 5 methods in the SchemaObject interface/abstract
> class that needed to be removed and added in the SchemaManager utilities.
> I'm not sure they are that much used outside of SchemaManager related
> classes.
> On the lack of interfaces for schema objects, it's probably a little more
> complex to move them back and requires more refactoring from depending
> parts.
> Tell me if I can be of any help about those two matters.
> Regards,
> Pierre-Arnaud
> [1] -
OK thanks Pierre for your assistance. I'm just trying to get my build back
to normal now after merging in from trunks and confronting this
maven-bundle-plugin issue discussed in the other thread.

I want to clean up my build and then start analyzing a bit more, we can post
ideas on the ML too but at the same time I want to experiment with some of
the refactorings to see how it will look. Will keep everyone informed of my
findings and thoughts.


> On 8 mars 2011, at 00:09, Alex Karasulu wrote:
> Hi all,
> I just looked through the schema packages and noticed that it has
> become another hives nest of inter-dependency. I'm not blaming anyone
> here so please don't get the wrong idea. I just want to avoid these
> trends because they cause more complexity and lead more unnecessary
> work. Let me show y'all some code to be clear.
> There once were clean simple schema entity interfaces like
> AttributeType that were used to shield the API from getting
> contaminated by irrelevant implementation methods and functionality.
> [0] shows an example of a clean interface which was there earlier that
> most of the code handled. This was removed and replaced by a class.
> Now look here [1] to see the big 1800 line file mixed with all sorts
> of functionality [1] like addToRegistries(). This method has no place
> in this object which is now used globally. As a result,
> interdependencies have increased through and through inside these
> packages as well as in the server which now depends on these out of
> place methods. It's going to be a PITA to clean this up and the work
> will be twice, maybe more, as hard as when the interfaces were
> removed. The rest of the code base now has come to depend on these
> non-essential methods specific to some function or use case associated
> with implementation details.
> I'm trying to get some traction with making schema loadable and this
> is yet another surprise to have to contend with. Please let's not
> remove interfaces just because they seem unappealing. When in doubt,
> leave the interface where it is, it can't hurt, but the opposite can
> hurt a lot. I'm sitting here starring at this nest and wondering what
> the heck I should do first.
> Best Regards,
> Alex
> [0] -
> [1] -

View raw message