tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ma...@apache.org
Subject Re: problem using default Realm in new unit tests
Date Fri, 13 Jan 2012 07:05:02 GMT
Brian Burch <brian@pingtoo.com> wrote:

>On 10/01/12 13:21, Brian Burch wrote:

>Tomcat.getEngine has not changed its overall behaviour: it creates the 
>Engine when it doesn't already exist. However, it now also creates and 
>assigns the default MemoryRealm to the new StandardEngine instance.

It isn't the MemoryRealm but a simplified version of it.

>I can see the StandardEngine constructor is also called in both the 
>MBeanFactory and Embedded classes. MBeanFactory, at first glance, seems
>
>to set the Realm on request, but not define a default for the Engine. 
>The Embedded constructors will either explicitly set a Realm, or leave 
>it uninitialised.
>
>If this observation is correct, then there are real cases where the 
>Engine can be created without a default realm, in which case 
>StandardEngine will create a default JAASRealm as soon as the getRealm 
>method is called. This JAASRealm MUST be properly configured in the jvm
>
>if an Exception is to be avoided.
>
>Is it still meaningful to let the StandardEngine establish a default 
>JAASRealm in getRealm under these circumstances, or would it be more 
>consistent to use a default MemoryRealm? Anyone who wants to use a 
>JAASRealm would surely have to configure it, so isn't it is a bit lazy 
>to rely on implicit assignment. Surely these users would (should) 
>explicitly define the JAASRealm in Embedded or MBeanFactory?
>
>Perhaps the logic in StandardEngine.getRealm to catch these special 
>cases and create a default JAASRealm is redundant?

My preference is to create a new NullRealm (with a better name) that always fails authentication
and is used in place of the JAAS realm as a default for the engine.

Mark
>
>Thanks,
>
>Brian
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: dev-help@tomcat.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message