On Wed, Jun 30, 2010 at 2:02 PM, Emmanuel Lécharny <email@example.com>
That's done now. We had some discussion about AT that does not belongs to the SchemaManager when parsing an ACI (like some AT found in an entry which has an ExtensibleObject OC, but that does not make any sense to protect such external ATs).
On 6/30/10 11:36 AM, Alex Karasulu wrote:
On Tue, Jun 29, 2010 at 6:09 PM, Emmanuel Lecharny<firstname.lastname@example.org>wrote:
Perhaps there's some functionality in the SchemaManager that can be
while working on the ACI parser, I hit a wall : if we want the parsed ACI
to be used directly in the server without having to convert EntryAttributes
to JNDI Attribute, we have to make the ACI parser schema aware. As it's a
good idea to do so, I checked if it was possible.
Sadly, the ACI parser is part of the shared-ldap module, when the
SchemaManager is in a separate module, depending on shared-ldap.
In order to solve this issue, I see no better way than creating a new
module (shared-aci), any other solution would be a real PITA (like
post-processing the ACI once parsed to inject the schemaManager into the
I will try to create this new module, and will give you some feedback.
Please feel free to comment.
separated out into another class to be put into the shared area. Or as
another option the SchemaManager functionality for dealing with schema
lookups can be separated and put into shared.
Basically my thinking is as follows:
o the parser just needs to be schema aware
Right we used some kind of resolver interface with an implementation that wrapped the AT registry if I remember correctly. This was done to facilitate decoupling.
Well, I think the current SchemaManager is already good enough for that purpose. I don't really see the added value to create a new one.
o being schema aware (read-only) can be achieved either with
non-SchemaManager components or a new SchemaManager implementation
I was saying a new implementation to avoid having to pull in the current implementation's dependencies. For example you could implement a schema manager that just implemented the needed lookup methods while making the other methods stubs that threw exceptions when used. This way you can have a SM but not pull in the server's dependencies into shared.
Not sure I see where you are going to.
If the SchemaManager interface has write based methods the interface can be
broken down into two separate interfaces to compose the SchemaManager
interface. Then the read only component of this contract can be placed and
implemented within shared.
Basically trying to say that some methods of the SM may be needed in scenarios outside of the server without pulling in server dependencies. This might hint that there are more atomic components than this course grained SM. If that's the case a breakdown of the interface into parts might help with decoupling.
I'm not sure we want to separate the read/write interfaces for the Schema. There is no need to do so atm, I don't see the added value. Also it won't solve the problem I have.
The read only component need not interact with the DS since nothing needs to
be changed in the registries. It's there for lookups. The code there can
then be reused elsewhere like in the server.
This just shows us that the SchemaManager interface needs to be further
decomposed. Whether this warrants another shared module (shared-aci) perhaps
is up for debate.
Sounds like you're not understanding me. There are SM interface methods that might need to go into a simpler interface that is extended by the SM is all I was suggesting. Nothing definitive. You said we needed to make ACI schema aware (capable of looking up schema elements and using them) but you do not want to pull in some of the server dependencies.
I presumed the SM implementation had deps on server components because some methods are used to change the schema while others used to lookup or access other components. I was suggesting that we might want to break it up into parts to avoid server dependencies.
No worries though if you already solved the problem.