cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: [end?]Re: Why does Action extend ThreadSafe ?
Date Wed, 15 Aug 2001 15:42:19 GMT
Quoting Sylvain Wallez <sylvain.wallez@anyware-tech.com>:

> 
> 
> 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 :)

Don't be sorry :) Discussions like these are common anyway.

> > 
> > PLEASE COMMITERS vote on this:
> > 
> > Is it best to remove the TheradSafe interface from the Action
> interface?
> 
> Well, +1 ;)

Berin expressed being consisten to the following pattern: 

    No "lifestyle" nor "lifecycle" interfaces on working interfaces.

So +0 from me.

Giacomo

> > 
> > >
> > > 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