On 10/7/11 9:21 AM, Anil Saldhana wrote:
On 10/07/2011 04:32 AM, Darran Lofthouse wrote:
> No CallbackHandlers don't need to be stateful, they do tend to require
> some form of access to a backing store but there is no need for the
> actual state to be held within the CallbackHandler - the CallbackHandler
> is just a proxy to this store.
Can Bill define what the constitution of state is so we know whether
cbh is stateful or not?
Doesn't matter if the CBH itself caches state or not. It could delegate
to a service reference, or not. IMO though, they need the option to be
stateful.
What the CBH's do, is give a *typed* interface that is *storage-type
agnostic* to query for authentication information. THis way auth
algorithms can be decoupled from the storage mechanism. Much of this is
already built into the JSAPI from what I understand.
> Saying that picking up changes to a properties file would require
a
> server reboot is like saying picking up a users changed password or
> roles from the DB after they have connected also requires a reboot.
> There are various options to pick up a modified properties file without
> restarting the server.
For properties files, unless you reload them, there is no way you can
pick up changes. You can try to retain the last modified timestamp
someplace,
to check whether you want to load them. Now that is added complexity IMO for
a mechanism that we should not recommend users use (unless for testing
or simple usage).
This is just *one* problem of the current API. Its broken. Needs to be
fixed. I don't know how many times I have to say it.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com