Quoting Sylvain Wallez <[EMAIL PROTECTED]>:
>
>
> Sylvain Wallez wrote:
> >
> > Berin Loritsch wrote:
> > >
> > > 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.
> >
> > But why is it so, why does an Action have to be ThreadSafe ?
> >
> > This removes for Action all the benefits of the Avalon component
> > architecture (you know it better that me :) ) that transparently
> handles
> > ThreadSafe, Recyclable, etc, and allows concrete implementations to
> > define how they should be managed depending on how they are
> implemented.
> >
> > > 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.
> >
> > But I *did* look at generated sitemap code before building this action
> !
> > What I've seen is that all sitemap elements (including actions), are
> > handled the same way through a component selector. That's why I came
> to
> > the conclusion that I could make a Generator implement Action.
> >
> <snip/>
>
> Looking deeper at the sitemap code, I think to have found why Action
> currently must be ThreadSafe : actions are fetched by the sitemap in a
> ComponentSelector just like all other sitemap components, but are never
> released ! This doesn't cause a memory leak only in the special case
> where a component is ThreadSafe and thus a single instance is always
> used.
>
> Matchers and selectors are also never released, and they're not
> constrained to be ThreadSafe, meaning memory leak. Factories are mainly
> used for these, so the problem didn't reveal up to now, but it's there,
> hidden in the dark, waiting for someone to fall on it ;)
>
> So the way the sitemap was implemented has caused the ThreadSafe
> contract to be put on the high-level Action interface, while IMO, this
> contract should be the decision of each particular Action implementor.
>
> So I propose to modify the sitemap so that Action, Matcher and Selector
> are handled as regular components and properly released.
I agree with the issue mentioned above.
> Once this is
> done, ThreadSafe will be removed from Action, and moved on relevant
> Action implementations.
But here I have to agree with Berin. The Action interface is kept as small as
possible (one single method) to strengthen the contract to ThreadSafe'tines. It
should in ever case be stateless. Else we had used the already available
interfaces like SitemapModelComponents. And as Berin mentioned it has nothing to
do with Generators. If you like to have compiled Actions via the XSP machinery
you should use an similar approach like the ServerPagesGenerator or the sitemap
(thus a separate MarkupLanguage). I think it is very dangerous to use the
current XSP spec to be used to generate Actions because of the need of a
ContentHandler to capture SAX events because silly thing will happen when users
use expressions like <xsp:text>Booh</xsp:text> in an Action (which doesn't make
much sense normally).
Giacomo
>
> +1 from me :)
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
