Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
To: cocoon-dev@xml.apache.org
Subject: Re: [C2] Checking vars before assignment
Message-ID: <986997001.3ad4610924173@mail.otego.com>
Date: Wed, 11 Apr 2001 15:50:01 +0200 (CEST)
From: Giacomo Pati <giacomo@apache.org>
References: <3.0.6.32.20010411233349.0091f100@mail.alphalink.com.au>
In-Reply-To: <3.0.6.32.20010411233349.0091f100@mail.alphalink.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.4

Quoting Peter Donald <donaldp@apache.org>:

> Hi,
> 
> I noticed a few things when playing a bit. In quite a few places there
> is
> the pattern
> 
> public void blahize( Blah blah ) {
> 
>   if( this.blah != null ) {
>     this.blah = blah;
>   }
> }
> 
> Where blah is context/configuration/componentmanager/other. I am curious
> -
> is this needed. It seems to me that if the method is called twice (which
> this method protects against) it is a fault of container and the
> component
> should not be defending against that. Where did this pattern arise and
> is
> it still needed ?

What do you think about this:
Suppose I have a component written as a Composer
   
  SecurityManager secman =       
      (SecurityManager)manager.lookup("role.for.security.manager");

  Configuration myconf = createMyOwnEvilConfig();
  ((Configurable)secman).configure(myconf);  

Well, the real pattern to use should be:

  DON'T EVER LET YOUR WORKING INTERFACE EXTEND *ANY* LIFECYCLE INTERFACES
  THAT IS NOT IN THE CONCERN OF THE COMPONENT CLIENTS

Maybe I've missed a discussion about how to specify working interfaces but 
component writers may not be aware of that fact. And because you cannot prevent 
this the easiest way to get more security is to prevent your component being 
configured/initialized/... more that once.

Giacomo

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