Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3B6EB1F1.113F82E5@apache.org>
Date: Mon, 06 Aug 2001 11:04:17 -0400
From: Berin Loritsch <bloritsch@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Why does Action extend ThreadSafe ?
References: <3B6EA71F.9E4DFB89@anyware-tech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sylvain Wallez wrote:
> 
> Hi team,
> 
> As a vacation exercise (rainy days here in the french Alps), I
> implemented the XSP-action that is so much wanted by some of you. The
> easiest way to implement it is to make it a subclass of
> ServerPagesGenerator that implements Action.
> 
> But I faced the following problem : Action extends ThreadSafe while
> ServerPagesGenerator implements Recyclable, and thus cannot be
> ThreadSafe (the component manager doesn't allow this). I moved
> ThreadSafe implementation from Action to AbstractAction (which my action
> does not inherit from), and all went well !
> 
> So the question is : why does Action extend ThreadSafe ? Isn't the
> implied contract too strong for a general interface like Action ?

No.  The contract for an Action is that it is ThreadaSafe.  That is why
it implements it.  It reduces the number of instances of the Action in
the system to only one.

You should have approached Action the way the Sitemap is compiled.
Actions don't have anything in common with Generators in reality, so you
shouldn't extend any time of Generator.

You could have copied some of the logic--or even abstracted the base
stuff away (returning a CompiledComponent) and cast it into the exact
return type needed.

> I'd like to remove ThreadSafe from Action and leave that decision to
> each Action implementation (note also that neither Matcher nor Selector
> extend it).

Matcher and Selector (as implemented in the sitemap) are merely code
inserted into the sitemap--which is ThreadSafe.  They are still subject
to that limitation.

I would prefer to see actual components instead of code factories--but
then again the code factories execute a little bit quicker.

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