You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2001/08/13 14:05:01 UTC
[end?]Re: Why does Action extend ThreadSafe ?
giacomo wrote:
>
> On Fri, 10 Aug 2001, Sylvain Wallez wrote:
>
> >
> > giacomo wrote:
> > >
> > > On Thu, 9 Aug 2001, Sylvain Wallez wrote:
> > >
> > <snip/>
> > > >
> > > > 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.
> > >
> > IMO, Poolable means non thread-safe *and* heavyweight. If instanciating
> > a non thread-safe component isn't costly then a new instance can be
> > created for each request.
> >
> > But in fact, I misexplained the problem I wanted to outline : what if an
> > action (stateless, thus potentially ThreadSafe) relies on a non
> > thread-safe heavyweight object ? Should the action create and destroy a
> > new instance of that object at each request ? That would be bad for
> > performance : preferably, the object should be fetched from a pool.
>
> Make it a Component.
>
> > An important hypothesis here : this object is not a component handled by
> > the ComponentManager holding the action, and thus the action cannot get
> > an instance using CM.lookup().
> >
> > If Action does not extend ThreadSafe, each instance of our action can
> > hold an instance of the object. The action consequently inherits the
> > object's non-threadsafety, and can implement Poolable to benefit of
> > automatic pool management by the CM. That's what I would like to be able
> > to do.
>
> C'on, that's nonsens. You can always make a nonComponent a Component. In
> a project we've made byte arrays into components to avoid garbage
> collection. I'm still not conviced.
>
> >
> > To illustrate this, here are two examples : first, as it must be now
> > whith Action extending ThreadSafe, second with Action not extending
> > ThreadSafe and the implementation beeing Poolable.
> >
> > //-------------------------------------------------
> > // Action extends ThreadSafe
> > //-------------------------------------------------
> >
> > public class MyAction extends AbstractConfigurableAction {
> >
> > Configuration heavyConf;
> >
> > public void configure(Configuration conf) {
> > this.heavyConf = conf.getChild("heavy");
> > // action configuration
> > ...
> > }
> >
> > public void act(...) {
> > // costly creation of the heavy object
> > HeavyStatefullObject heavyObj = new HeavyStatefullObject();
> > heavyObj.configure(this.heavyConf);
> >
> > // do the action stuff using heavyObj
> > ...
> > // costly destruction of heavyObj
> > }
> > }
> >
> > //-------------------------------------------------
> > // Action doesn't extend ThreadSafe
> > //-------------------------------------------------
> > public class MyAction extends AbstractConfigurableAction
> > implements Poolable {
> >
> > HeavyStatefullObject heavyObj = new HeavyStatefullObject();
> >
> > public void configure (Configuration conf) {
> > this.heavyObj.configure(conf.getChild("heavy"));
> > // action configuration
> > ...
> > }
> >
> > public void act(...) {
> > // do the action stuff using this.heavyObj
> > ...
> > }
> > }
> >
> > Now, one could say that the action could remain ThreadSafe and
> > instanciate its own pool and manage it manually. But such actions will
> > loose the benefits of automatic pool management by the ComponentManager
> > and have an increased complexity.
> >
> > I hope the problem is clear now, and you understand my point of view.
>
> Your problem is you don't understand how to benefit from Avalon. You try
> to convince me to a solution which is IMO dead wrong. And Action is not
> a object holder. Look at this:
>
> public interface HeavyStatefullObjectComponent {
> String ROLE = "HeavyStatefullObjectComponent";
> HeavyStatefullObject getHeavyStatefullObject();
> }
>
> public class HeavyStatefullObjectComponentImpl
> implements HeavyStatefullObjectComponent,
> Configurable,
> Poolable {
> private HeavyStatefullObject heavyObj = new HeavyStatefullObject();
>
> public void configure(Configuration conf) {
> heavyObj.configure(conf);
> }
>
> public HeavyStatefullObject getHeavyStatefullObject() {
> return heavyObject;
> }
> }
>
> You can make this even generic and pool every objet you like. As said
> above, I'm still -1 to remove ThreadSafe from Action!
>
> Giacomo
>
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 ;)
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 ?
But I still have some questions (last ones for this thread, I promise)
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 ?
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.
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.
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.
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 :)
Sylvain
--
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
Re: [end?]Re: Why does Action extend ThreadSafe ?
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Sylvain Wallez <sy...@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
RE: [end?]Re: Why does Action extend ThreadSafe ?
Posted by John Morrison <jo...@ntlworld.com>.
I've not really been following this thread (pardon the pun) as I've not yet
required Actions in my work. However, from a quick review of the discussion
I believe that it would be best for each Action to decide: +0.
> -----Original Message-----
> From: Giacomo Pati [mailto:giacomo@apache.org]
> Sent: Wednesday, 15 August 2001 4:46 pm
> To: cocoon-dev@xml.apache.org
> Subject: Re: [end?]Re: Why does Action extend ThreadSafe ?
>
>
> Quoting Berin Loritsch <bl...@apache.org>:
>
> > Giacomo Pati wrote:
> > >
> > > > PLEASE COMMITERS vote on this:
> > > >
> > > > Is it best to remove the TheradSafe interface from the Action
> > interface?
> >
> > I am +1 on this move. See my analysis thread for the reasons why.
> > (Same reason
> > I promoted not implementing LifeStyle interfaces in component work
> > interfaces).
>
> As the Action IS a component work interface and a move of all
> map:components
> into the xconf file might be realized some times I will follow as well.
>
> > While Actions will be implemented 99 times out of 100 in a ThreadSafe
> > manner,
> > it does not guarantee that there won't be a legitimate reason to not do
> > it.
>
> This is hypothetic because I haven't got any samples on that.
>
> Giacomo
>
> >
> > It costs very little to do this, so I give my +1 on it.
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [end?]Re: Why does Action extend ThreadSafe ?
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Berin Loritsch <bl...@apache.org>:
> Giacomo Pati wrote:
> >
> > > PLEASE COMMITERS vote on this:
> > >
> > > Is it best to remove the TheradSafe interface from the Action
> interface?
>
> I am +1 on this move. See my analysis thread for the reasons why.
> (Same reason
> I promoted not implementing LifeStyle interfaces in component work
> interfaces).
As the Action IS a component work interface and a move of all map:components
into the xconf file might be realized some times I will follow as well.
> While Actions will be implemented 99 times out of 100 in a ThreadSafe
> manner,
> it does not guarantee that there won't be a legitimate reason to not do
> it.
This is hypothetic because I haven't got any samples on that.
Giacomo
>
> It costs very little to do this, so I give my +1 on it.
>
> ---------------------------------------------------------------------
> 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
RE: [end?]Re: Why does Action extend ThreadSafe ?
Posted by Vadim Gritsenko <vg...@hns.com>.
>
> Giacomo Pati wrote:
> >
> > > PLEASE COMMITERS vote on this:
> > >
> > > Is it best to remove the TheradSafe interface from the Action interface?
>
> I am +1 on this move. See my analysis thread for the reasons why. (Same reason
> I promoted not implementing LifeStyle interfaces in component work interfaces).
> While Actions will be implemented 99 times out of 100 in a ThreadSafe manner,
> it does not guarantee that there won't be a legitimate reason to not do it.
>
> It costs very little to do this, so I give my +1 on it.
+1 from me. Sitemap already releases actions as other components - should not
be problems to do poolable actions.
Vadim
>
> ---------------------------------------------------------------------
> 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
Re: [end?]Re: Why does Action extend ThreadSafe ?
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
>
> > PLEASE COMMITERS vote on this:
> >
> > Is it best to remove the TheradSafe interface from the Action interface?
I am +1 on this move. See my analysis thread for the reasons why. (Same reason
I promoted not implementing LifeStyle interfaces in component work interfaces).
While Actions will be implemented 99 times out of 100 in a ThreadSafe manner,
it does not guarantee that there won't be a legitimate reason to not do it.
It costs very little to do this, so I give my +1 on it.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [end?]Re: Why does Action extend ThreadSafe ?
Posted by Carsten Ziegeler <cz...@sundn.de>.
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
Re: [end?]Re: Why does Action extend ThreadSafe ?
Posted by Sylvain Wallez <sy...@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 :)
>
> 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
Re: [end?]Re: Why does Action extend ThreadSafe ?
Posted by giacomo <gi...@apache.org>.
On Mon, 13 Aug 2001, Sylvain Wallez wrote:
>
>
> giacomo wrote:
> >
> > On Fri, 10 Aug 2001, Sylvain Wallez wrote:
> >
> > >
> > > giacomo wrote:
> > > >
> > > > On Thu, 9 Aug 2001, Sylvain Wallez wrote:
> > > >
> > > <snip/>
> > > > >
> > > > > 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.
> > > >
> > > IMO, Poolable means non thread-safe *and* heavyweight. If instanciating
> > > a non thread-safe component isn't costly then a new instance can be
> > > created for each request.
> > >
> > > But in fact, I misexplained the problem I wanted to outline : what if an
> > > action (stateless, thus potentially ThreadSafe) relies on a non
> > > thread-safe heavyweight object ? Should the action create and destroy a
> > > new instance of that object at each request ? That would be bad for
> > > performance : preferably, the object should be fetched from a pool.
> >
> > Make it a Component.
> >
> > > An important hypothesis here : this object is not a component handled by
> > > the ComponentManager holding the action, and thus the action cannot get
> > > an instance using CM.lookup().
> > >
> > > If Action does not extend ThreadSafe, each instance of our action can
> > > hold an instance of the object. The action consequently inherits the
> > > object's non-threadsafety, and can implement Poolable to benefit of
> > > automatic pool management by the CM. That's what I would like to be able
> > > to do.
> >
> > C'on, that's nonsens. You can always make a nonComponent a Component. In
> > a project we've made byte arrays into components to avoid garbage
> > collection. I'm still not conviced.
> >
> > >
> > > To illustrate this, here are two examples : first, as it must be now
> > > whith Action extending ThreadSafe, second with Action not extending
> > > ThreadSafe and the implementation beeing Poolable.
> > >
> > > //-------------------------------------------------
> > > // Action extends ThreadSafe
> > > //-------------------------------------------------
> > >
> > > public class MyAction extends AbstractConfigurableAction {
> > >
> > > Configuration heavyConf;
> > >
> > > public void configure(Configuration conf) {
> > > this.heavyConf = conf.getChild("heavy");
> > > // action configuration
> > > ...
> > > }
> > >
> > > public void act(...) {
> > > // costly creation of the heavy object
> > > HeavyStatefullObject heavyObj = new HeavyStatefullObject();
> > > heavyObj.configure(this.heavyConf);
> > >
> > > // do the action stuff using heavyObj
> > > ...
> > > // costly destruction of heavyObj
> > > }
> > > }
> > >
> > > //-------------------------------------------------
> > > // Action doesn't extend ThreadSafe
> > > //-------------------------------------------------
> > > public class MyAction extends AbstractConfigurableAction
> > > implements Poolable {
> > >
> > > HeavyStatefullObject heavyObj = new HeavyStatefullObject();
> > >
> > > public void configure (Configuration conf) {
> > > this.heavyObj.configure(conf.getChild("heavy"));
> > > // action configuration
> > > ...
> > > }
> > >
> > > public void act(...) {
> > > // do the action stuff using this.heavyObj
> > > ...
> > > }
> > > }
> > >
> > > Now, one could say that the action could remain ThreadSafe and
> > > instanciate its own pool and manage it manually. But such actions will
> > > loose the benefits of automatic pool management by the ComponentManager
> > > and have an increased complexity.
> > >
> > > I hope the problem is clear now, and you understand my point of view.
> >
> > Your problem is you don't understand how to benefit from Avalon. You try
> > to convince me to a solution which is IMO dead wrong. And Action is not
> > a object holder. Look at this:
> >
> > public interface HeavyStatefullObjectComponent {
> > String ROLE = "HeavyStatefullObjectComponent";
> > HeavyStatefullObject getHeavyStatefullObject();
> > }
> >
> > public class HeavyStatefullObjectComponentImpl
> > implements HeavyStatefullObjectComponent,
> > Configurable,
> > Poolable {
> > private HeavyStatefullObject heavyObj = new HeavyStatefullObject();
> >
> > public void configure(Configuration conf) {
> > heavyObj.configure(conf);
> > }
> >
> > public HeavyStatefullObject getHeavyStatefullObject() {
> > return heavyObject;
> > }
> > }
> >
> > You can make this even generic and pool every objet you like. As said
> > above, I'm still -1 to remove ThreadSafe from Action!
> >
> > Giacomo
> >
>
> 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:
PLEASE COMMITERS vote on this:
Is it best to remove the TheradSafe interface from the Action interface?
>
> 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.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org