Wesley Hall wrote:
This would actually be my preference too. I dont think the stack trace will be affected unless a new exception is created, but I would have liked to set the Authentication object in an overloaded constructor. The problem is that it seemed that in some cases the Authenication instance wasnt available. The advantage of intercepting it in the ProviderManager is that it seems to be a central location where there is access to the Authenication instance, so no matter how the user decides to implement their custom AuthenicationProvider or Dao the Authenication object will always be available when it counts.
I guess there are pros and cons of both approches, but I didnt want to dive
in and start making very invasive changes and given that the ProviderManager
interception represented the least invasive change, I eventually opted for
this route.
Hi Wesley
If you'd like to submit patches which take advantage of the enhanced AuthenticationException.getAuthentication() method, I'd be pleased to apply them to CVS.
Best regards Ben
------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
