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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
