On 12/17/2013 2:35 AM, Stuart Douglas wrote:
>
> On 12/14/2013 5:33 AM, Stuart Douglas wrote:
>>
>>> What does ordering have to do with AuthMechFactory? Are you planning an
>>> additional META-INF/services mechanism for AuthMechFactorys? If not,
>>> how does one plug in one? Via a ServletExtension? If so, *AGAIN*, what
>>> is the point of the AuthMechFactory when all the construction can be
>>> done within the ServletExtension?
>>
>> Because you can have multiple servlet extensions. This way undertow
>> controls the order. If both extensions just add themselves you have no
>> defined order.
>>
>
> Again, what does ordering have to do with requiring an AuthMechFactory
> interface?
>
> MyServletExtension {
> di.registerAuthMech("AUTH_PROTOCOL", new AuthMech(...));
> }
>
> Why do i need a AuthMechFactory if the servlet extension is able to
> construct the AuthMech? I just would never use AuthMechFactory as all
> config information is already available within the ServletExtension for
> me to construct the AuthMechanism. In fact, there's much more metadata
> available within the ServletExtension than is passed to the AuthMechFactory.
Note that with my latest changes you can do exactly what you mention above
(di.registerAuthMech("AUTH_PROTOCOL", new AuthMech(...));).
I guess the only real thing it buys you is having the ability to configure the same
mechanism with different properties, although I am not sure
if that is really something that anyone would ever want to do.
It also makes reading the config properties easier, as they are passed directly to the
factory, although I guess it is pretty easy to just retrieve them directly, especially if
I just add a convenience method.
So maybe it is not really worth having the factory concept, although given that you
don't have to use it if you don't want to I am not sure if we should keep it or
not.
BTW, all in all, the AuthMech SPI is holding up pretty well. Good stuff.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com