cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: [end?]Re: Why does Action extend ThreadSafe ?
Date Thu, 16 Aug 2001 05:53:13 GMT
As the Action interface is only one method I am -1 on the change.

Carsten

> -----Ursprungliche Nachricht-----
> Von: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> Gesendet: Mittwoch, 15. August 2001 17:01
> An: cocoon-dev@xml.apache.org
> Betreff: Re: [end?]Re: Why does Action extend ThreadSafe ?
>
>
>
>
> giacomo wrote:
> >
> > On Mon, 13 Aug 2001, Sylvain Wallez wrote:
> >
> > >
> <big-snip/>
> > >
> > > Ok, your remarks led me to dig into Avalon component
> management (didn't
> > > do it up to know, and it was mainly a blackbox), and I admit
> my example
> > > was "dead wrong" for an Avalon-guru when I wanted it to be a
> little bit
> > > provocative. Thanks for this ;)
> >
> > You're welcome :-))
> >
> > > So, the obvious way to implement an action that relies on a statefull
> > > object is to wrap this object with a Poolable StateFullComponent which
> > > is added to the CM and do simple lookup/release in the action, right ?
> >
> > This might be a solution. I'd take this approach.
> >
> > > But I still have some questions (last ones for this thread, I promise)
> >
> > You don't need to. I think others will benefit from this as well :)
> >
> > > if StateFullComponent isn't used elsewhere in the system, even if this
> > > isn't the most frequent case.
> > >
> > > Isn't it potentially dangerous to expose StateFullComponent
> (fully setup
> > > with its configuration) to other Composable in the CM if they
> don't have
> > > to know about it ?
> >
> > First they have to know about it.
> >
> > > Is it acceptable, for the sole purpose of implementing an
> action, to add
> > > an additional entry in the .xconf file ? This file may
> rapidly grow and
> > > become hard to manage, when the action can simply be defined in the
> > > (sub)sitemap where it is used.
> >
> > I don't get this ('for the sole purpose of implementing an action'?). An
> > action doesn't have to have an entry in the xconf file. Yes the xconf
> > file might grow to a respectable size for some projects/applications. It
> > depends how much Avalon you use.
> >
> > > Or should we allow some components to be added to the local CM of each
> > > sitemap through a .xconf near each .xmap ? This would also enforce
> > > security by segmenting the visibility of components in a shared
> > > environment (some are security-sensitive, like datasources).
> > >
> > > To avoid adding StateFullComponent into the CM, a solution can be for
> > > the action to internally manage it using a ComponentHandler. But this
> > > isn't so satisfying : the ComponentHandler's lifecycle must be handled
> > > manually (need to be careful and Avalon-skilled), and we're stuck to
> > > ComponentHandler's handling strategy when the enclosing CM could have
> > > defined its own custom one (e.g. Avalon and Excalibur CMs
> strategies are
> > > very different). As an exercise, I updated ServerPagesAction to this
> > > solution.
> >
> > I'd go for a private CM for this. CMs can be arranged in a hierarchical
> > way.
> >
> > > Another solution, if Action doesn't implement ThreadSafe (yes, still
> > > believing in that), is for the action to adopt the "lifestyle" of the
> > > underlying component (SingleThreaded, ThreadSafe, Poolable) and simply
> > > act as an adapter to the Action interface. This way there are no
> > > additional declarations in the CM, no manual handling of a
> > > ComponentHandler, and the action is managed by the CM in a
> way suitable
> > > for StateFullComponent.
> >
> > Do you think it is good practice to make the Actions "lifestyle" based
> > on a StateFullComponents "lifestyle" used by that Action? I still
> > think this is wrong.
> >
> > Ok, It seems you'd like a simple vote like last time we'd discussed
> > map:parameter:
>
> Oh my ! Sorry if it reminds you of that ! I tried to expose arguments
> instead of voting. I still have to learn about the opensource process,
> and will try to remember it for the next time : be less verbose and vote
> earlier :)
> >
> > PLEASE COMMITERS vote on this:
> >
> > Is it best to remove the TheradSafe interface from the Action interface?
>
> Well, +1 ;)
> >
> > >
> > > What are your thoughts about all this ?
> > >
> > > And thanks a lot, Giacomo, for the time you spend answering my posts,
> > > even if some
> > > of them contain "dead wrong" statements :)
> >
> > If writing "dead wrong" means "you are stupid" I really appologies for
> > that. I absolutely never mean this that way.
> Thanks, but I do admit I wasn't really good on this point.
> >
> > Giacomo
> >
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message