Re: [security-dev] [PicketBox 5] - Authentication API

Hi Pete, Thanks for the feedback and tips. The documentation was also updated. About the examples, I'm moving all of them to the PicketBox Quickstarts project. There you can find more details about the implementations. You're right about the callback/struct behaviour. I agree it seems more like a struct than a callback. Actually, I started to work as callback but during the implementation things changed. I'll change this concept to make it more clear. About the fluent configuration, the idea is to provide something like ISPN (which you know very well). The actual impl is just an attempt to have some things working. Regards. Pedro Igor ----- Original Message ----- From: "Pete Muir" <pmuir(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: security-dev(a)lists.jboss.org Sent: Tuesday, July 31, 2012 6:22:54 PM Subject: Re: [security-dev] [PicketBox 5] - Authentication API * In the first example, what is "authenticate" that you assert is not null? Without this, the example doesn't make much sense :-) * You should show some usage of the handler in this example as well. * In fact, looking at those examples I'm not sure how it is a callb, and not just a struct * You gone for a pattern half-way towards fluent configuration with the configuration, which I've found is normally a really bad place to be. I would go the whole way: ** Have a mutable builder class, ConfigurationBuilder, which has the fluent methods to configure all of PicketBox, which has a build() method ** Have a Configuration class, which is immutable, and emitted by the build method ** Have a constructor or static factory method on PicketBoxManager which takes a Configuration object This means that we can now easily create immutable (thread safe) configuration objects which can be passed around. This scheme will also work very well with CDI producers. * If mechanism, managers can be configured, then make sure you offer these as first class options on the Configuration e.g. configuration.authentication().userNamePasswordMechanism().allowBeavers() <-- works really nicely in IDEs * What you've called an observer, I think is actually a callback * You have an error in the SASL example, authenticate is not a local variable, and it's not complete (add javadoc to discuss missing methods?) On 31 Jul 2012, at 21:01, Pedro Igor Silva wrote: