tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Burch <>
Subject Re: problem using default Realm in new unit tests
Date Fri, 13 Jan 2012 02:53:03 GMT
On 10/01/12 13:21, Brian Burch wrote:
> Konstantin,
> Thank you for your prompt and helpful response... at least I know I
> haven't overlooked something simple. With your encouragement, I'm happy
> to keep "fighting the alligators until I can get back to draining the
> swamp"!

I am working on this issue in my spare time while on holiday in 
Australia. I was testing a local fix yesterday which inserted the 
default MemoryRealm into the StandardEngine. I decided to go to bed and 
email my proposed change in the morning.

While I was sleeping, Mark committed r1230777 (and r1230767), which is 
very similar to mine, but was more bold. I was nervous (through 
ignorance) about the consequences for the standalone and embedded cases.

I have now reworked my new unit tests to work with Mark's change (they 
no longer need to explicitly trigger assignment of the default 
MemoryRealm), and they all run successfully. I will submit them soon.

Sorry to keep this topic open, but I have some outstanding questions 
following Mark's change, so perhaps someone could spare the time to 
answer them for me?

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.

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?



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message