cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: AW: Why does Action extend ThreadSafe ?
Date Mon, 06 Aug 2001 20:13:41 GMT

Carsten Ziegeler wrote:
> 
> The 2.1 cvs version of Cocoon 2 has the ScriptAction. Perhaps it's better
> to extend this action for xsp (if it can't do it right now anyway,
> I don't know).
> 
Unfortunately, ScriptAction can't be used : it relies on BSF whereas
ServerPagesAction relies on the XSP engine. It also serves other
purposes : it allows to easily pre-generate XML fragments as a result of
business logic, these fragments being inserted later in the content (for
example by a regular XSP).

But ScriptAction is also an example where ThreadSafe is harmful : if we
could make ScriptAction Recyclable, it could reuse the BSF engine and
cache the loaded scripts instead of reinstantiating and reinterpreting
the whole stuff at each request.

IMO, actions like these ones prove that activity constraints should be
defined in concrete implementations and not in high-level interfaces.

What do you think ? Should I commit my changes on 2.1 so that we can
play with them (including move of ThreadSafe implementation to
AbstractAction, which leaves other actions untouched) ?

> Carsten
> 
> > -----Ursprungliche Nachricht-----
> > Von: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> > Gesendet: Montag, 6. August 2001 16:18
> > An: cocoon-dev@xml.apache.org
> > Betreff: Why does Action extend ThreadSafe ?
> >
> >
> > 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 ?
> >
> > 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).
> >
> > Thanks for your comments.
> >
> > --
> > Sylvain Wallez
> > Anyware Technologies - http://www.anyware-tech.com

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com


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


Mime
View raw message