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. Once this is
done, ThreadSafe will be removed from Action, and moved on relevant
Action implementations.
+1 from me :)
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
