Enrique Rodriguez a écrit :
I have to split up this thread to respond to it, since you covered a
couple points. Comments below.
On 6/3/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
...
Those two values was simply not accepted because the related members
have been removed from the StartupConfiguration class. I can't imagine
that it has been unnoticed before committing the code, or I guess that
*no* integration tests has been done, or that the server has never been
launch, because launching the server with such a configuration leads to
a direct crash in one second.
The two parameters you felt were missing are, in fact, only ever used
by the SearchHandler.
Do I have to remind you that LDAP is all about searching ?
Therefore, in the split of core configuration
to LdapConfiguration I moved them to LdapConfiguration. These
parameters are in the new config doco at:
http://cwiki.apache.org/confluence/display/DIRxSBOX/LDAP+Protocol+Configuration
I apologize if you think this change wasn't warranted but it does
reflect how the server is designed.
I just tried to launch the server, and it immediatly failed. That's why
I wrote this mail. It's not a design question, it's all about user
expecting a stable behaviour. We have had this discussion back in march
about this configuration modification :
Emmanuel Lécharny a écrit :
>>Enrique Rodriguez wrote :
>>> On 3/15/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
>>> Yeah I agree with Emmanuel. Enrique let's leave the configuration
as it is
>>> for now.
>>>
>>> You are after all just trying to add the SASL stuff and getting
bogged down
>>> with configuration.
>> What just happened to LdapConfiguration? It seemed like an easy part
>> of the SASL initiative. Emmanuel brought up good points, and I'm fine
>> with putting the LdapConfiguration bean under
>> ServerStartupConfiguration.
>
> This is the perfect place right now. We will reconsider this later, I
think, because as you said, the actual config does not help > end users.
But anyway, the urgent things is SASL, not configuration refactoring.
I don't think we agreed on modifying the configuration, so far. It was
clearly the opposite, for a simple reason : let's go on step by step.
And the result is that I get trapped one month and a half after with a
problem we anticipated.
The fact that there is no unit
test is bad but there wasn't one before this move. I think these
parameters belong on LdapConfiguration and that your change should be
reverted. The parameters you added back to StartupConfiguration only
satisfy your attempt to configure server.xml and they are unused
during runtime.
I just reverted to a configuration which should have never been changed,
as we stated it was not urgent. You committed it anyway. I hope you
simply forgot about what we agreed on.
I know you are busy and that this change came at a bad time, but in
Eclipse a quick "right-click | References | Workspace" will show that
the LdapConfiguration#getMaxSizeLimit and
LdapConfiguration#getMaxTimeLimit are being used by the SearchHandler.
This is not the point. We are all busy, but we can deal with it, unless
we have unexpected modifications which were done without agreement. The
LdapConfiguration modification has been postponed, at least this is what
I remembered, so I kept the previous configuration as it was, except
your SASL specific configuration.
Ok, now, one very important thing : this new proposed configuration has
been evaluated, and we think it's a good thing. We agreed on that.
Changing it straight without notification, in within a bunch of SASL
code, was a bad move, because we focused on SASL (which is working well,
btw), and totally forgot about LdapConfiguration modification. That plus
the other problems I faced at the same time were a little bit to much
for me to handle, so my mail.
I really want you to be *cautious* when adding new code, just to be sure
that this does not happen again. We could perfectly have commit those
LdapConfiguration changes a week later, smoothly, without all those
problems. I would have been warned, and I would have changed my
server.xml without wondering where the problem is coming from.
Let's just work together, interact more, and doing baby steps, for the
good of community. The way it worked for SASL was just perfect. We have
had many interactions, we also have discussions about the chain pattern
which was quite interesting, I really appreciated it. And it was
*really* good to have SASL into the server, you did a good job on this,
Enrique. I wish we can work the same way for every part of the server,
that's all we need.
Thanks,
Emmanuel
