On 5/21/07, Enrique Rodriguez <email@example.com> wrote:
On 5/21/07, Alex Karasulu <firstname.lastname@example.org> wrote:
> I've been reviewing the sasl branch and it looks good but I have not
> completed the whole thing
> since the changes are extensive. What ever I did not cover can be
> discusses over time instead
> of holding back a merge.
Cool. You mentioned noticing some re-org possibilities while in there
and I noticed some refactorings, too. However, they were outside the
scope of SASL so I held off. In particular, SessionRegistry is
redundant since MINA will handle this for you. However,
SessionRegistry is used by that test GUI extended operation handler or
else it would be trivial to refactor away.
Oh yeah this is also possible but I was thinking of other things. No matter
tho we can discuss these after we get the merge completed.
Also, protocol-shared is slowing being emaciated so we can probably
find homes for its code elsewhere and delete the module.
Ahh yes I saw this too. Also I think we need to do away with using generic JNDI
for the time being until we can re-write a better JNDI provider wrapper because
of some shortfalls with the JNDI class implementations. There are some horrendous
bugs in the JNDI code from SUN that has plagued Emmanuel for months now. But
we are seeing ways to fix these as we slowly clean somethings up.
Eventually I'd like to see us use a custom API since JNDI is not cutting it now. It
is seriously choking the architecture in the core and we need to do away with it
temporarily until we can implement a better JNDI wrapper around the core rather
than trying to integrate the core with JNDI. Incidentally these changes will better
isolate functionality and reduce the tight coupling we have in most packages making
it easier to goto OSGi. Again we can discuss these details later as we evolve the
server core with small refactorings after this merge.
Kerberos-aware LDIF loader should be removed since it conflicts with
the new and more capable KeyDerivationService.
Yes I figured this as well. No need for it with the new interceptor. Even later
the interceptor will be replaced by triggers I imagine but it's too early to discuss
that as well.
> If there are no objections please feel free to merge this SASL branch into
> the trunks. Even if
> we have some issues with things I'm sure we can rectify them later or
> perhaps you can clarify
> things more for us if we misunderstand your purpose.
Yeah, it's definitely not set in stone. Getting it into trunks will
get more people to try out the config live and to hit it with
SASL-capable clients. BTW, was anybody able to test SASL clients with
it? It works solid for me but I hadn't heard from others.
I'm ashamed to admit that have not tried yet with anything other than running
your test cases. I will give it a try though perhaps after the merge. I'm sure
after the structures are in place if we run into some snag a fix will be easily
applied if needed at all.
I will merge SASL after the 'kerberos-encryption- types' branch. I
want to test SASL GSSAPI with the KeyDerivationService and with AES
That's good news. Again keep me posted because I will wait on the merge before
adding the HTTP service as I mentioned before.