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.
All I had to do in act() is call setup() (all needed parameters are
present), setConsumer() with an XMLByteStreamCompiler to capture the
output and then generate(). The XMLByteStream is then wrapped by an
XMLFragment implementation and put in a request attribute for later use.
Cache management of the generator is simply ignored (i.e. it is not
cached).
> 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.
That's what I first started to do. But I found that was a lot of
copy/paste from ServerPagesGenerator and didn't like it (code
duplication is never good).
I also thought of instanciating a ServerPagesGenerator in the act()
method but found this solution very ineficient.
So I decided to look at the sitemap internals to see if inheritance was
possible and came to the conclusion that it was (see above).
> > 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.
The factories inherit sitemap characteristics because of they generate
code inside the sitemap, but the object version (Matcher and Selector
interfaces) do not enforce ThreadSafe like Action does, and extend
Component. Why is Action different ?
> I would prefer to see actual components instead of code factories--but
> then again the code factories execute a little bit quicker.
I do also. It's easier to code and test.
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
