directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: [naming] statuses and use to replace tomcat read-only jndi
Date Sat, 19 Nov 2005 19:40:00 GMT
Stephane Bailliez wrote:
> Resending for the 3rd time, I keep getting confused with subscriptions 
> and emails.
> 
> jerome lacoste wrote:
> 
>> [...]
>> I am not 100% happy with any of the alternatives (why is Tomcat's JNDI
>> read-only?)?
>>  
>>
> Because it is part of the J2EE specifications. The environment must be 
> read-only for applications.
> 
> "Each application component defines its own set of environment entries. 
> All instances of an application component within the same container 
> share the same environment entries. Application component instances are 
> not allowed to modify the environment at runtime."
> 
> It makes sense otherwise if you store state information in the jndi tree 
> and that it is shared by all instances of the same webapp, you're just 
> potentially breaking everything and security is a problem. The 
> environment is supposed to be configurable by the deployer only.
> 
> See Chapter 5 (Naming) for more details.
> 
>> Statuses: latest code change on the Naming project was in April. Does
>> that mean that the project is stable or abandonned? (I would lean on
>> #1, just want some confirmation)
>>  
>>
> AFAIK it is a copy of Tomcat code. Nothing else for now. And it does not 
> work for remote invocation, so what would be needed is to make it 
> remotable...and why not writable as it is very useful for testing purposes.

There are three main features not available in the tc code base:
1) generic XML configuration
2) support for federated namespaces (added since 0.8)
3) support for synchronized contexts

Phil





Mime
View raw message