Giacomo Pati wrote:
>
> Quoting Sylvain Wallez <[EMAIL PROTECTED]>:
>
<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
>
There are two distinct problems here that I'd like to discuss
separately: XSP as actions and the Action interface.
--o--
First, about the XSP-action : XSP is a great language to dynamically
generate XML. The purpose of the XSP-action is to be able to easily
generate XML fragments as part of actions processing (before generation
starts). We have in our C1 apps a set of form validation and database
update logicsheets that fit in this area and that I would like to adapt
to C2.
The real purpose of this action is XML fragment generation, which uses
XSP facilities, while most of the action logic will be written in
<xsp:logic> elements. Maybe this is a jumpstart for a new action markup
language ?
About the implementation (it's in the 2.1 CVS), I changed it from what I
described in the initial post : the action wraps a ServerPagesGenerator
instead of extending it (I recognize this was easy but hacky). The
output not captured internally using the "capture" logicsheet is
(optionnaly) captured in an XMLFragment put in a request attribute.
--o--
Now, about Action : the Action interface *allows* implementations to be
ThreadSafe, compared to interfaces like Generator or Transformer that
*forbid* it (for example because of setConsumer(), but there's no other
way with SAX).
I don't discuss the statelessness of Action. What I'd like to achieve by
removing ThreadSafe from Action is keep the ability of having ThreadSafe
actions (the vast majority of them) while still allowing heavyweight
implementations to be pooled.
Action is like DocumentRepository in Berin's excellent paper on Avalon :
the DocumentRepository interface is designed to *allow* ThreadSafe
implementations by having a single method but doesn't enforce it, and
the DatabaseDocumentRepository implementor *decides* to actually be
ThreadSafe.
So, do you still want to keep ThreadSafe on the Action interface, or
leave that decision to action implementors ?
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
