You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2010/06/29 17:09:16 UTC
New module for the ACI parser needed
Hi guys,
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
elements).
I will try to create this new module, and will give you some feedback.
Please feel free to comment.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: New module for the ACI parser needed
Posted by Emmanuel Lécharny <el...@apache.org>.
On 6/30/10 1:23 PM, Alex Karasulu wrote:
> On Wed, Jun 30, 2010 at 2:02 PM, Emmanuel Lécharny<el...@apache.org>wrote:
>
>> On 6/30/10 11:36 AM, Alex Karasulu wrote:
>>
>>> On Tue, Jun 29, 2010 at 6:09 PM, Emmanuel Lecharny<elecharny@gmail.com
>>>> wrote:
>>> Hi guys,
>>>> 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
>>>> elements).
>>>>
>>>> I will try to create this new module, and will give you some feedback.
>>>>
>>>> Please feel free to comment.
>>>>
>>>> Perhaps there's some functionality in the SchemaManager that can be
>>> 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
>>>
>> 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).
>>
>>
> 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.
uh? Not sure to get what a resolver can do here. The issue is pretty
simple :
- the ACIItem has to be SchemaAware, which means we must pass a
reference on the SM when initializing the ACIItemParser.
- in order to do that, we must move the ACI elements in a separate
module because it will depend on the ldap-schema-manager module *or*
inject the ldap-schema-manager into shared (plus all the associated
modules, like the ldap-schema-loader, etc). This is what I did and it
was pretty straightforward.
I think you still have i mind the previous Schema handler which used
resolver. It's not anymore the case.
>
>> o being schema aware (read-only) can be achieved either with
>>> non-SchemaManager components or a new SchemaManager implementation
>>>
>> 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.
>>
>>
> 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.
A kind of proxy then. That could work, but the problem is that you need
to add some glue later on when you init the ACIItem parser. Sadly, it
breaks the tests, as you have to move them to another location where the
SM is available. A bt too complex IMO.
>
>> 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.
>>>
>> 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.
>>
>>
> 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.
We don't pull any server dependencies. I'm just talking about shared
dependencies here.
> I presumed the SM implementation had deps on server components
No, none. All the SchemaManager is standalone atm.
This was an absolute need in order to get the client API to be able to
use the Schema.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: New module for the ACI parser needed
Posted by Alex Karasulu <ak...@apache.org>.
On Wed, Jun 30, 2010 at 2:02 PM, Emmanuel Lécharny <el...@apache.org>wrote:
> On 6/30/10 11:36 AM, Alex Karasulu wrote:
>
>> On Tue, Jun 29, 2010 at 6:09 PM, Emmanuel Lecharny<elecharny@gmail.com
>> >wrote:
>>
>> Hi guys,
>>>
>>> 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
>>> elements).
>>>
>>> I will try to create this new module, and will give you some feedback.
>>>
>>> Please feel free to comment.
>>>
>>> Perhaps there's some functionality in the SchemaManager that can be
>> 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
>>
> 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).
>
>
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.
>
> o being schema aware (read-only) can be achieved either with
>> non-SchemaManager components or a new SchemaManager implementation
>>
> 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.
>
>
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.
> 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.
>>
> Not sure I see where you are going to.
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.
>
> 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.
>>
> 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.
>
>
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.
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: New module for the ACI parser needed
Posted by Emmanuel Lécharny <el...@apache.org>.
On 6/30/10 11:36 AM, Alex Karasulu wrote:
> On Tue, Jun 29, 2010 at 6:09 PM, Emmanuel Lecharny<el...@gmail.com>wrote:
>
>> Hi guys,
>>
>> 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
>> elements).
>>
>> I will try to create this new module, and will give you some feedback.
>>
>> Please feel free to comment.
>>
> Perhaps there's some functionality in the SchemaManager that can be
> 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
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).
> o being schema aware (read-only) can be achieved either with
> non-SchemaManager components or a new SchemaManager implementation
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.
> 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.
Not sure I see where you are going to.
> 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.
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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: New module for the ACI parser needed : some more problems...
Posted by Kiran Ayyagari <ka...@apache.org>.
On Wed, Jun 30, 2010 at 6:59 PM, Emmanuel Lécharny <el...@apache.org> wrote:
> So I created this new module. So far, so good. Trunk is building.
>
> Now, I'm facing some more problems :
> - in order to make the ACIItem schema aware, I have to inject the
> schemaManager into many data structures (the ACI parser and ACI checker,
> some protectedItems, etc)
> - the tests need to access a schemaManager
> - that leads to create some dependency between ldap-aci and
> ldap-schema-manager and ldap-schema-loader
> - the problem is that now, the ldap-schema-loader tests are failing because
> this module does not depend on ldap-aci, thus can't load the
> ACIItemSyntaxChecker...--
damn, another cycle..
>
> maybe we should have all the schema related tests moved to a specific module
> instead of having all the tests in each module ? Or at least, having global
> tests put into a global module : we already have a shared-all module, we may
> need a shared-test-all module too...
+1
IMHO shared-test-all is a bit vague, how about shared-schema-test or
shared-integ-test
Kiran Ayyagari
Re: New module for the ACI parser needed : some more problems...
Posted by Emmanuel Lécharny <el...@apache.org>.
So I created this new module. So far, so good. Trunk is building.
Now, I'm facing some more problems :
- in order to make the ACIItem schema aware, I have to inject the
schemaManager into many data structures (the ACI parser and ACI checker,
some protectedItems, etc)
- the tests need to access a schemaManager
- that leads to create some dependency between ldap-aci and
ldap-schema-manager and ldap-schema-loader
- the problem is that now, the ldap-schema-loader tests are failing
because this module does not depend on ldap-aci, thus can't load the
ACIItemSyntaxChecker...--
maybe we should have all the schema related tests moved to a specific
module instead of having all the tests in each module ? Or at least,
having global tests put into a global module : we already have a
shared-all module, we may need a shared-test-all module too...
Thoughts ?
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: New module for the ACI parser needed
Posted by Alex Karasulu <ak...@apache.org>.
On Tue, Jun 29, 2010 at 6:09 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> Hi guys,
>
> 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
> elements).
>
> I will try to create this new module, and will give you some feedback.
>
> Please feel free to comment.
>
Perhaps there's some functionality in the SchemaManager that can be
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
o being schema aware (read-only) can be achieved either with
non-SchemaManager components or a new SchemaManager implementation
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.
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.
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu