You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2002/07/23 05:45:05 UTC
[lang] Submission of Avalon.Excalibur.ThreadContext
According to the README, ThreadContext contains utilities for managing
thread context variables.
[no kidding :)].
To be honest I'm not entirely sure I get it. It appears to be a
thread-registry with pluggable mechanism for managing ThreadLocal-like
variables. Pluggable so policies can be set, I assume on pooling etc.
One major issue for me is that it is a framework, it has one central class
ThreadContext and it is expected that developers will supply their own
implementation of a ThreadPolicy. I'm not sure if this is always necessary
or if in most cases it functions on its own, it seems to always be
necessary.
While I like frameworks, I'm not in favour of them in a core reusable jar
like Commons.Lang. I don't think we should be expecting users to be
extending classes just to use the functionality.
However this might be my feeling that I'm 'not getting it' talking.
To see the code, check out jakarta-avalon-excalibur and goto:
jakarta-avalon-excalibur/threadcontext/src/java/org/apache/excalibur/threadcontext
Any views?
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Henri Yandell" <ba...@generationjava.com>
> While I like frameworks, I'm not in favour of them in a core reusable jar
> like Commons.Lang. I don't think we should be expecting users to be
> extending classes just to use the functionality.
As a general rule, 'no frameworks' is probably right.
But then Enum is an extension point too. And I maintain that most of
[pattern] should be part of [lang] ;-) (Actually, Enum could have been part
of Pattern)...So its not that simple....
Here's how I view the boundary between [lang] framework and non [lang]
framework.
"Is there a pluggable policy kind of interface to something central??"
Enum [lang] and [pattern] Factory, Predicate, Transformer & Command are
simple extension points. They need no configuring to work. The [pattern]
interfaces provide standard implemetations accessed via a factory Utils
class, but that doesn't require configuration.
ThreadContext, CPUParser [avalon] and [pattern] Identifier & Immutable are
frameworks. They require more knowledge of their use, and both ThreadContext
and Identifier demonstrate this by having separate impl subpackages.
So, I would push against the second group being in [lang] but support the
first group. Thus no ThreadContext. It would seem to fit closer with
[threading], and with the CPU stuff.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Henri Yandell <ba...@generationjava.com>.
> One major issue for me is that it is a framework, it has one central class
> ThreadContext and it is expected that developers will supply their own
> implementation of a ThreadPolicy. I'm not sure if this is always necessary
> or if in most cases it functions on its own, it seems to always be
> necessary.
Equally, the Enum classes are also a framework. I guess they feel more
comfortable as a concept.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>Basically, take the excalibur left-hand menu.
>>
>>- Containers -> stay in excalibur
>>- Components -> new cornerstone
>>- Resource Managers -> dunno
>>- Testing and Analysis -> dunno
>>- Utilities -> *all* to commons (except the ones improperly here)
>>
>>This is how I see the new excalibur, what do you think?
>>What should we do about Resource Managers? Make them just
>>new-cornerstone components?
>>Testing and Analysis can just remain part of excalibur.
>
>
>
> :/
>
> Resource Managers and Testing and Analysis should stay in
> Excalibur. We need the testing harness for components so
> that we can write proper tests for them.
I wrote: >>Testing and Analysis can just remain part of excalibur.
> The original concept was for Excalibur to house general Avalon
> components and Cornerstone to house Phoenix components. I would
> be -1 on any movement of the components to cornerstone until
> we have an official specification for Avalon components.
+1 Well, this was what I meant, I'm too proactive ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Thu, 25 Jul 2002 00:48, Nicola Ken Barozzi wrote:
>
>>Current active proposal:
>>
>>- avalon-framework: APIS
>>- avalon-excalibur: Container Implementations
>>- avalon-cornerstone: ComponentImplementations
>>- avalon-apps: Server applications
>>
>>In this view, they should go to Cornerstone...
>
>
> Thats your view not mine ;)
Not only mine, others too advocated such a separation, evem if the
module names weren't really discussed.
> Almost everything I develope will go into excalibur. Excalibur is basically
> the Avalon commons sans all the restrictions of actual commons.
-
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Peter Donald <pe...@apache.org>.
On Thu, 25 Jul 2002 00:48, Nicola Ken Barozzi wrote:
> Current active proposal:
>
> - avalon-framework: APIS
> - avalon-excalibur: Container Implementations
> - avalon-cornerstone: ComponentImplementations
> - avalon-apps: Server applications
>
> In this view, they should go to Cornerstone...
Thats your view not mine ;)
Almost everything I develope will go into excalibur. Excalibur is basically
the Avalon commons sans all the restrictions of actual commons.
--
Cheers,
Peter Donald
"The ability to quote is a serviceable substitute for wit." -- Maugham
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Leo Simons <le...@apache.org>.
let's not have this discussion just yet. It is clear there is some
reorganisation to be done at some point in the future. However, we
haven't even got proper alpha releases of a lot of stuff. Just moving
everything around again doesn't make sense at this point.
I say table the discussion; there will be much less of it later on when
things are more clear.
- Leo
> Well... if excalibur becomes the implementation of Containers,
> Cornerstone becomes what Excalibur has become now anyway... 8-S
>
> Ok, I'm confused. Why would you like to see them back in Excalibur?
>
> What do you propose as a role for the CVS modules?
>
> Current active proposal:
>
> - avalon-framework: APIS
> - avalon-excalibur: Container Implementations
> - avalon-cornerstone: ComponentImplementations
> - avalon-apps: Server applications
>
> In this view, they should go to Cornerstone...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Berin Loritsch <bl...@apache.org>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Peter Donald wrote:
> > On Wed, 24 Jul 2002 23:04, Berin Loritsch wrote:
> >
> >>The original concept was for Excalibur to house general Avalon
> >>components and Cornerstone to house Phoenix components. I
> would be -1
> >>on any movement of the components to cornerstone until we have an
> >>official specification for Avalon components.
> >
> > Personally I would prefer if cornerstone components moved back from
> > cornerstone to excalibur rather than the opposite way round.
>
> Well... if excalibur becomes the implementation of
> Containers, Cornerstone becomes what Excalibur has become now
> anyway... 8-S
>
> Ok, I'm confused. Why would you like to see them back in Excalibur?
>
> What do you propose as a role for the CVS modules?
>
> Current active proposal:
>
> - avalon-framework: APIS
> - avalon-excalibur: Container Implementations
> - avalon-cornerstone: ComponentImplementations
> - avalon-apps: Server applications
>
> In this view, they should go to Cornerstone...
So far you are the only one with that vision. Let's not cross this
bridge until we get there. There is a lot to be done now before we
could even imagine restructuring the CVS archives.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Wed, 24 Jul 2002 23:04, Berin Loritsch wrote:
>
>>The original concept was for Excalibur to house general Avalon
>>components and Cornerstone to house Phoenix components. I would
>>be -1 on any movement of the components to cornerstone until
>>we have an official specification for Avalon components.
>
> Personally I would prefer if cornerstone components moved back from
> cornerstone to excalibur rather than the opposite way round.
Well... if excalibur becomes the implementation of Containers,
Cornerstone becomes what Excalibur has become now anyway... 8-S
Ok, I'm confused. Why would you like to see them back in Excalibur?
What do you propose as a role for the CVS modules?
Current active proposal:
- avalon-framework: APIS
- avalon-excalibur: Container Implementations
- avalon-cornerstone: ComponentImplementations
- avalon-apps: Server applications
In this view, they should go to Cornerstone...
:-?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Peter Donald <pe...@apache.org>.
On Wed, 24 Jul 2002 23:04, Berin Loritsch wrote:
> The original concept was for Excalibur to house general Avalon
> components and Cornerstone to house Phoenix components. I would
> be -1 on any movement of the components to cornerstone until
> we have an official specification for Avalon components.
Personally I would prefer if cornerstone components moved back from
cornerstone to excalibur rather than the opposite way round.
--
Cheers,
Peter Donald
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Berin Loritsch <bl...@apache.org>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Basically, take the excalibur left-hand menu.
>
> - Containers -> stay in excalibur
> - Components -> new cornerstone
> - Resource Managers -> dunno
> - Testing and Analysis -> dunno
> - Utilities -> *all* to commons (except the ones improperly here)
>
> This is how I see the new excalibur, what do you think?
> What should we do about Resource Managers? Make them just
> new-cornerstone components?
> Testing and Analysis can just remain part of excalibur.
:/
Resource Managers and Testing and Analysis should stay in
Excalibur. We need the testing harness for components so
that we can write proper tests for them.
The original concept was for Excalibur to house general Avalon
components and Cornerstone to house Phoenix components. I would
be -1 on any movement of the components to cornerstone until
we have an official specification for Avalon components.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Tue, 23 Jul 2002 23:41, Berin Loritsch wrote:
>
>>>One major issue for me is that it is a framework, it has one
>>>central class ThreadContext and it is expected that
>>>developers will supply their own implementation of a
>>>ThreadPolicy. I'm not sure if this is always necessary or if
>>>in most cases it functions on its own, it seems to always be
>>>necessary.
>>
>
> At this stage it is partially necessary. There is a fairly basic
> implementation of the policy I believe. However there is a few "complete"
> implementations that can/will be moved back in time (at least when they
> stabilize). At which point it will not really be frameworky at all.
Makes sense.
> However I would recomend holding of moving threadcontext as it is not stable
> and still subject to change in future - possibly in backwards incompatible
> ways.
Threadcontext isn't really part af the
framework-containers-components-serverapps Avalon subdivision that's
taking place.
Since Commons sandbox is exactly for possibly common components that
still need to mature, I guess that we could still move it there and keep
working on it as if it were here... but with the advantage of having it
already in a common place where others can look at it and eventually
help making it better.
I think that this is the best policy.
Basically, take the excalibur left-hand menu.
- Containers -> stay in excalibur
- Components -> new cornerstone
- Resource Managers -> dunno
- Testing and Analysis -> dunno
- Utilities -> *all* to commons (except the ones improperly here)
This is how I see the new excalibur, what do you think?
What should we do about Resource Managers? Make them just
new-cornerstone components?
Testing and Analysis can just remain part of excalibur.
Comments?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Peter Donald <pe...@apache.org>.
On Tue, 23 Jul 2002 23:41, Berin Loritsch wrote:
> > One major issue for me is that it is a framework, it has one
> > central class ThreadContext and it is expected that
> > developers will supply their own implementation of a
> > ThreadPolicy. I'm not sure if this is always necessary or if
> > in most cases it functions on its own, it seems to always be
> > necessary.
At this stage it is partially necessary. There is a fairly basic
implementation of the policy I believe. However there is a few "complete"
implementations that can/will be moved back in time (at least when they
stabilize). At which point it will not really be frameworky at all.
However I would recomend holding of moving threadcontext as it is not stable
and still subject to change in future - possibly in backwards incompatible
ways.
--
Cheers,
Peter Donald
----------------------------------------
Whatever you do will be insignificant,
but it is very important that you do it.
--Gandhi
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 23 Jul 2002, Berin Loritsch wrote:
> > To be honest I'm not entirely sure I get it. It appears to be
> > a thread-registry with pluggable mechanism for managing
> > ThreadLocal-like variables. Pluggable so policies can be set,
> > I assume on pooling etc.
>
> I am forwarding this to Avalon Dev to see if I can get some
> answers from the author.
>
Thanks Berin.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 23 Jul 2002, Berin Loritsch wrote:
> > To be honest I'm not entirely sure I get it. It appears to be
> > a thread-registry with pluggable mechanism for managing
> > ThreadLocal-like variables. Pluggable so policies can be set,
> > I assume on pooling etc.
>
> I am forwarding this to Avalon Dev to see if I can get some
> answers from the author.
>
Thanks Berin.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Berin Loritsch <bl...@apache.org>.
> From: Henri Yandell [mailto:bayard@generationjava.com]
>
> According to the README, ThreadContext contains utilities for
> managing thread context variables. [no kidding :)].
:)
> To be honest I'm not entirely sure I get it. It appears to be
> a thread-registry with pluggable mechanism for managing
> ThreadLocal-like variables. Pluggable so policies can be set,
> I assume on pooling etc.
I am forwarding this to Avalon Dev to see if I can get some
answers from the author.
> One major issue for me is that it is a framework, it has one
> central class ThreadContext and it is expected that
> developers will supply their own implementation of a
> ThreadPolicy. I'm not sure if this is always necessary or if
> in most cases it functions on its own, it seems to always be
> necessary.
>
> While I like frameworks, I'm not in favour of them in a core
> reusable jar like Commons.Lang. I don't think we should be
> expecting users to be extending classes just to use the functionality.
>
> However this might be my feeling that I'm 'not getting it' talking.
>
> To see the code, check out jakarta-avalon-excalibur and goto:
>
> jakarta-avalon-excalibur/threadcontext/src/java/org/apache/exc
> alibur/threadcontext
>
> Any views?
>
> Hen
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] Submission of Avalon.Excalibur.ThreadContext
Posted by Berin Loritsch <bl...@apache.org>.
> From: Henri Yandell [mailto:bayard@generationjava.com]
>
> According to the README, ThreadContext contains utilities for
> managing thread context variables. [no kidding :)].
:)
> To be honest I'm not entirely sure I get it. It appears to be
> a thread-registry with pluggable mechanism for managing
> ThreadLocal-like variables. Pluggable so policies can be set,
> I assume on pooling etc.
I am forwarding this to Avalon Dev to see if I can get some
answers from the author.
> One major issue for me is that it is a framework, it has one
> central class ThreadContext and it is expected that
> developers will supply their own implementation of a
> ThreadPolicy. I'm not sure if this is always necessary or if
> in most cases it functions on its own, it seems to always be
> necessary.
>
> While I like frameworks, I'm not in favour of them in a core
> reusable jar like Commons.Lang. I don't think we should be
> expecting users to be extending classes just to use the functionality.
>
> However this might be my feeling that I'm 'not getting it' talking.
>
> To see the code, check out jakarta-avalon-excalibur and goto:
>
> jakarta-avalon-excalibur/threadcontext/src/java/org/apache/exc
> alibur/threadcontext
>
> Any views?
>
> Hen
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>