On Thu, 9 Aug 2001, Sylvain Wallez wrote:
>
>
> 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.
Well, I simply don't understand why you have to generate XML in a
Action. Maybe because we used to hide all the XML thing in our
application from the point where the request is accepted by a
AcceptorAction and held in "normal" java objects until it reaches the
generation stage where these objects get serialized as XML (preferred
are Marshallable objects).
>
> 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.
I hope I've missunderstud you here. Components will not be pooled
because they are heavywheigted but because they cannot be written in a
thread safe way but they can be reused in a serializedd fashion.
> 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 ?
Well, I'll give you a -0 ;)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
