Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: softfail (athena.apache.org: transitioning domain of
 brian@pingtoo.com does not designate 217.154.193.216 as permitted sender)
Message-ID: <4F0F9C8F.9070304@pingtoo.com>
Date: Fri, 13 Jan 2012 12:53:03 +1000
From: Brian Burch <brian@pingtoo.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16
MIME-Version: 1.0
To: dev@tomcat.apache.org
Subject: Re: problem using default Realm in new unit tests
References: <4F064F88.8080709@pingtoo.com>
	<CABzHfVn-tAmM9ycOOc2FORPbhZ_wQ2PuUDSW5WNVCinNtOCc9g@mail.gmail.com>
	<4F0AF386.6080604@pingtoo.com>
 <CABzHfVm3xddXuhb5SZpeT+j1WwX+=DfKk6f=5MsPDP5fbTkyOA@mail.gmail.com>
 <4F0BAEB3.1090200@pingtoo.com>
In-Reply-To: <4F0BAEB3.1090200@pingtoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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?

Thanks,

Brian

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