You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <pa...@yahoo.com> on 2002/11/25 14:02:37 UTC
Context - a future
Can someone who is _not_ advocating any of the competing propositions for Context please lead this
task:
We need a 'roll-up' on this rapidly sprawling thread. Many people (incl me) are being lost in the
extensive detail.
1) What are the competing solutions .. hashmap style get(), cast to Context derived interfaces etc
...
2) What is the timescale we are trying aim for? Can it go into Phoenix and Merlin or is it a
revolution, thus only for uber-container?
The idea is that we get one summary of the choices. It may be that me, Stephen, Leo(s) post
comment and the rollup is modified. Best to leave the start of this to unaligned person though.
Nicola: Can you arbitrate if too many step forward?
PeterD: Can you post an opinion on Context?
Regards,
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context - a future
Posted by Leo Simons <le...@apache.org>.
On Mon, 2002-11-25 at 14:02, Paul Hammant wrote:
> Can someone who is _not_ advocating any of the competing propositions for Context please lead this
> task:
>
> We need a 'roll-up' on this rapidly sprawling thread. Many people (incl me) are being lost in the
> extensive detail.
>
> 1) What are the competing solutions .. hashmap style get(), cast to Context derived interfaces etc
> ...
not really actual or competing 'solutions' atm. Just discussion about
different ways to approach problems and which direction things should go
toward.
> 2) What is the timescale we are trying aim for? Can it go into Phoenix and Merlin or is it a
> revolution, thus only for uber-container?
none proposed, not talked about yet at all I think. I think this is
something for the info/meta/containerkit stuff, and it would be nice to
start using some of that sooner than later.
> The idea is that we get one summary of the choices. It may be that me, Stephen, Leo(s) post
> comment and the rollup is modified. Best to leave the start of this to unaligned person though.
I'll keep my mouth firmly shut then :D
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context - a future
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
>My intention was for someone other than you or me to lead this...
>
>
Paul:
I'm not attempting to lead anything - I am attempting to get some
clarification. Getting a response from you to this email and the
questions I have asked would be helpful for to understand what exactly
the problem is you are tying to address, secondly, if my understanding
of your objectives are correct or not, and thirdly, establishing if my
conclusions regarding solutions are consitent with your or not.
I look forward to that clarification.
Chers, Steve.
>-ph
>
> --- Stephen McConnell <mc...@apache.org> wrote: >
>
>
>>Paul:
>>
>>One thing missing from your message is the problem statement. I've been
>>really confussed about a lot of the posts on this subject because it has
>>been very unclear what peoples objective are.
>>
>>As I see things, we have some fixed and imutable facts
>>
>> 1. Context exists at the framework, and is not about to go away
>> 2. Extending the context interface has ramifications
>>
>> a) if we are providing a convinience interface only
>> then this is manageable, via
>>
>> - a small number of standard context accessors
>> interface enhancers that are handler by
>> container implemetations
>>
>> - maintaining correspondence with get( key ) so
>> that any component can fallback to the framework
>> contract if it chooses to
>>
>> - supplimented by a set of recognized standard
>> keys specifications
>>
>> b) if we are supplimenting context with behaviour, then
>> we are dealing with both a component (client) issue
>> and a container issue
>>
>> - this is an issue for a component author if the
>> author wants to maintain component portability
>>
>> - this is an concern of a container author if the
>> author wants to provide adaptability
>>
>> c) recognizing that there is a gray area between the
>> two extremes (a) and (b) where standard context entries
>> can be used to construct more sophisticated context
>> implemetations (i.e. interface does not do direct
>> mapping to data but behaviours are exclusively derived
>> from data accessible grom get( key ) )
>>
>> - this is resolvable by following standard
>> patterns on context implementation creation
>>
>> From the above - (a) is easy to do and should not disrupt anyone - (b)
>>is much more about context management in general under container space
>>and should be dealt with container implemetations for the time being as
>>there is a lot more thinking that can go into this area. Finally, (c)
>>is easy to do simply by following the existing framework patterns
>>establish for the creation of DefaultContext.
>>
>>If I understand your position correctly, I think it falls within the
>>scope of (a).
>>
>>In particular, if we look at cornerston components and thier depedence
>>on BlockContext - we see that this depedence is actually limited to
>>getWorkingDirectory() - or whatever the operation name is. It would be
>>better if we provided something like:
>>
>> /**
>> * This is a convinience accessor to the standard
>> * avalon context entry "avalon:work".
>> */
>> interface WorkingDirectoryProvider
>> {
>> File getWorkingDirectory();
>> }
>>
>>The Phoenix BlockContext could be revised to the following:
>>
>> interface BlockContext extends WorkingDirectoryProvider
>> {
>> // plus Phoeinix specific
>> }
>>
>>This would shift cornerstone components from being depedent on Phoneix
>>to being dependent on framework based interface.
>>
>>Does this help? Am I correctly interpriting the problem?
>>
>>Cheers, Steve.
>>
>>
>>
>>Paul Hammant wrote:
>>
>>
>>
>>>Can someone who is _not_ advocating any of the competing propositions for Context please lead
>>>
>>>
>>this
>>
>>
>>>task:
>>>
>>>We need a 'roll-up' on this rapidly sprawling thread. Many people (incl me) are being lost in
>>>
>>>
>>the
>>
>>
>>>extensive detail.
>>>
>>>1) What are the competing solutions .. hashmap style get(), cast to Context derived interfaces
>>>
>>>
>>etc
>>
>>
>>>...
>>>
>>>2) What is the timescale we are trying aim for? Can it go into Phoenix and Merlin or is it a
>>>revolution, thus only for uber-container?
>>>
>>>The idea is that we get one summary of the choices. It may be that me, Stephen, Leo(s) post
>>>comment and the rollup is modified. Best to leave the start of this to unaligned person
>>>
>>>
>>though.
>>
>>
>>>Nicola: Can you arbitrate if too many step forward?
>>>PeterD: Can you post an opinion on Context?
>>>
>>>Regards,
>>>
>>>- Paul
>>>
>>>
>>>__________________________________________________
>>>Do You Yahoo!?
>>>Everything you'll ever need on one web page
>>>
>>>
>>>from News and Sport to Email and Music Charts
>>
>>
>>>http://uk.my.yahoo.com
>>>
>>>--
>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>--
>>
>>Stephen J. McConnell
>>
>>OSM SARL
>>digital products for a global economy
>>mailto:mcconnell@osm.net
>>http://www.osm.net
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>>
>
>__________________________________________________
>Do You Yahoo!?
>Everything you'll ever need on one web page
>from News and Sport to Email and Music Charts
>http://uk.my.yahoo.com
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context - a future
Posted by Paul Hammant <pa...@yahoo.com>.
My intention was for someone other than you or me to lead this...
-ph
--- Stephen McConnell <mc...@apache.org> wrote: >
> Paul:
>
> One thing missing from your message is the problem statement. I've been
> really confussed about a lot of the posts on this subject because it has
> been very unclear what peoples objective are.
>
> As I see things, we have some fixed and imutable facts
>
> 1. Context exists at the framework, and is not about to go away
> 2. Extending the context interface has ramifications
>
> a) if we are providing a convinience interface only
> then this is manageable, via
>
> - a small number of standard context accessors
> interface enhancers that are handler by
> container implemetations
>
> - maintaining correspondence with get( key ) so
> that any component can fallback to the framework
> contract if it chooses to
>
> - supplimented by a set of recognized standard
> keys specifications
>
> b) if we are supplimenting context with behaviour, then
> we are dealing with both a component (client) issue
> and a container issue
>
> - this is an issue for a component author if the
> author wants to maintain component portability
>
> - this is an concern of a container author if the
> author wants to provide adaptability
>
> c) recognizing that there is a gray area between the
> two extremes (a) and (b) where standard context entries
> can be used to construct more sophisticated context
> implemetations (i.e. interface does not do direct
> mapping to data but behaviours are exclusively derived
> from data accessible grom get( key ) )
>
> - this is resolvable by following standard
> patterns on context implementation creation
>
> From the above - (a) is easy to do and should not disrupt anyone - (b)
> is much more about context management in general under container space
> and should be dealt with container implemetations for the time being as
> there is a lot more thinking that can go into this area. Finally, (c)
> is easy to do simply by following the existing framework patterns
> establish for the creation of DefaultContext.
>
> If I understand your position correctly, I think it falls within the
> scope of (a).
>
> In particular, if we look at cornerston components and thier depedence
> on BlockContext - we see that this depedence is actually limited to
> getWorkingDirectory() - or whatever the operation name is. It would be
> better if we provided something like:
>
> /**
> * This is a convinience accessor to the standard
> * avalon context entry "avalon:work".
> */
> interface WorkingDirectoryProvider
> {
> File getWorkingDirectory();
> }
>
> The Phoenix BlockContext could be revised to the following:
>
> interface BlockContext extends WorkingDirectoryProvider
> {
> // plus Phoeinix specific
> }
>
> This would shift cornerstone components from being depedent on Phoneix
> to being dependent on framework based interface.
>
> Does this help? Am I correctly interpriting the problem?
>
> Cheers, Steve.
>
>
>
> Paul Hammant wrote:
>
> >Can someone who is _not_ advocating any of the competing propositions for Context please lead
> this
> >task:
> >
> >We need a 'roll-up' on this rapidly sprawling thread. Many people (incl me) are being lost in
> the
> >extensive detail.
> >
> >1) What are the competing solutions .. hashmap style get(), cast to Context derived interfaces
> etc
> >...
> >
> >2) What is the timescale we are trying aim for? Can it go into Phoenix and Merlin or is it a
> >revolution, thus only for uber-container?
> >
> >The idea is that we get one summary of the choices. It may be that me, Stephen, Leo(s) post
> >comment and the rollup is modified. Best to leave the start of this to unaligned person
> though.
> >
> >Nicola: Can you arbitrate if too many step forward?
> >PeterD: Can you post an opinion on Context?
> >
> >Regards,
> >
> >- Paul
> >
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Everything you'll ever need on one web page
> >from News and Sport to Email and Music Charts
> >http://uk.my.yahoo.com
> >
> >--
> >To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
> >
> >
> >
>
> --
>
> Stephen J. McConnell
>
> OSM SARL
> digital products for a global economy
> mailto:mcconnell@osm.net
> http://www.osm.net
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context - a future
Posted by Stephen McConnell <mc...@apache.org>.
Paul:
One thing missing from your message is the problem statement. I've been
really confussed about a lot of the posts on this subject because it has
been very unclear what peoples objective are.
As I see things, we have some fixed and imutable facts
1. Context exists at the framework, and is not about to go away
2. Extending the context interface has ramifications
a) if we are providing a convinience interface only
then this is manageable, via
- a small number of standard context accessors
interface enhancers that are handler by
container implemetations
- maintaining correspondence with get( key ) so
that any component can fallback to the framework
contract if it chooses to
- supplimented by a set of recognized standard
keys specifications
b) if we are supplimenting context with behaviour, then
we are dealing with both a component (client) issue
and a container issue
- this is an issue for a component author if the
author wants to maintain component portability
- this is an concern of a container author if the
author wants to provide adaptability
c) recognizing that there is a gray area between the
two extremes (a) and (b) where standard context entries
can be used to construct more sophisticated context
implemetations (i.e. interface does not do direct
mapping to data but behaviours are exclusively derived
from data accessible grom get( key ) )
- this is resolvable by following standard
patterns on context implementation creation
From the above - (a) is easy to do and should not disrupt anyone - (b)
is much more about context management in general under container space
and should be dealt with container implemetations for the time being as
there is a lot more thinking that can go into this area. Finally, (c)
is easy to do simply by following the existing framework patterns
establish for the creation of DefaultContext.
If I understand your position correctly, I think it falls within the
scope of (a).
In particular, if we look at cornerston components and thier depedence
on BlockContext - we see that this depedence is actually limited to
getWorkingDirectory() - or whatever the operation name is. It would be
better if we provided something like:
/**
* This is a convinience accessor to the standard
* avalon context entry "avalon:work".
*/
interface WorkingDirectoryProvider
{
File getWorkingDirectory();
}
The Phoenix BlockContext could be revised to the following:
interface BlockContext extends WorkingDirectoryProvider
{
// plus Phoeinix specific
}
This would shift cornerstone components from being depedent on Phoneix
to being dependent on framework based interface.
Does this help? Am I correctly interpriting the problem?
Cheers, Steve.
Paul Hammant wrote:
>Can someone who is _not_ advocating any of the competing propositions for Context please lead this
>task:
>
>We need a 'roll-up' on this rapidly sprawling thread. Many people (incl me) are being lost in the
>extensive detail.
>
>1) What are the competing solutions .. hashmap style get(), cast to Context derived interfaces etc
>...
>
>2) What is the timescale we are trying aim for? Can it go into Phoenix and Merlin or is it a
>revolution, thus only for uber-container?
>
>The idea is that we get one summary of the choices. It may be that me, Stephen, Leo(s) post
>comment and the rollup is modified. Best to leave the start of this to unaligned person though.
>
>Nicola: Can you arbitrate if too many step forward?
>PeterD: Can you post an opinion on Context?
>
>Regards,
>
>- Paul
>
>
>__________________________________________________
>Do You Yahoo!?
>Everything you'll ever need on one web page
>from News and Sport to Email and Music Charts
>http://uk.my.yahoo.com
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Use Forrest for all Avalon docs
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Wed, 27 Nov 2002 09:28, Stefano Mazzocchi wrote:
>
>>Uh, don't you find it interesting that you didn't feel like there was
>>any need to discuss about this in public?
>
>
> Actually it was discussed except for the "database" stuff.
Can you please point me to the email messages where this happened?
>>3 Mb of DTDs? where is this?
>
>
> there was a few copies of docbook DTDs - each weighing in at just under 1 MB.
> Thats not even including the 10 different copies of the document.dtd and so
> forth.
I repeat my question: where is this?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Use Forrest for all Avalon docs
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 27 Nov 2002 09:28, Stefano Mazzocchi wrote:
> Uh, don't you find it interesting that you didn't feel like there was
> any need to discuss about this in public?
Actually it was discussed except for the "database" stuff. And that is just
something that is sitting in my head and may never be implemented. If it does
get implemented it will be discussed aswell.
> 3 Mb of DTDs? where is this?
there was a few copies of docbook DTDs - each weighing in at just under 1 MB.
Thats not even including the 10 different copies of the document.dtd and so
forth.
--
Cheers,
Peter Donald
----------------------------------------
"Liberty means responsibility. That is
why most men dread it." - Locke
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Use Forrest for all Avalon docs
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Tue, 26 Nov 2002 22:33, Nicola Ken Barozzi wrote:
>
>>>Anakia does it's job fine, is easier to use
>>>and much more lightweight. No need to ditch a tool that works.
>>
>>Then I'm confused.
>>Why did you consent for the change in Phoenix docs?
>
>
> Because I want to move to more advanced documentation generation features that
> cocoon provides. In particular generating single pdfs for guides but multiple
> html pages and being able to "suck" docs from other codebases into the
> phoenix docs (ie suck loader docs in as loader is used by phoenix etc).
> Integrate with javadocs and generate specific documentation from java/config
> source files. Also have a single "uber" pdf guide that encompases all phoenix
> docs. I also eventually want to move to "database" generated website.
Uh, don't you find it interesting that you didn't feel like there was
any need to discuss about this in public?
> By "database" I mean sucking in data from multiple sources such as
> /etc/passwd, /etc/groups, /home/cvs etc and then processing it with something
> like http://xineo.sourceforge.net/xil/
>
> Essentially I wanted to be able to do multi-format/channel publishing. While
> possible with anakia is no where as easy as it is in cocoon.
I'm glad to hear that but here you are showing your 'one-man show'ness
evidently and even more you expressed so with a simple '-1' and people
had to ask you 'explicitly' to share your thoughts with us in order to
be able to plans things together.
Do you start seeing why this community perceives you as working alone on
"your" stuff and 'tollerate' the presence of others?
I'll tell you: this is *very* annoying and frustrating, no matter how
impressive your end results are. And you know why? because this model of
yours is against the notion of software darwinism. Your mutations in the
code are huge steps and the community feedback is received only after
big steps are taken. This 'reduces' the ability of the environment (the
community and the users) to influence the evolution of the project in an
incremental way.
Do you realize that by making such big plans and actually implementing
them without early feedback you are actually 'hurting' the long term
technical evolution of this project?
>>Why did you create a framework Forrest branch?
>
>
> Because I was sick of hearing users complain. I get on average 6-7 complaints
> a month about the size of our CVS download or the size of our distributions
> or whatever. About 90% of that size is due to Cocoon jars and excess unused
> cruft in documentation tree (like 3 MB of DTDs).
3 Mb of DTDs? where is this?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Use Forrest for all Avalon docs
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 26 Nov 2002 22:33, Nicola Ken Barozzi wrote:
> > Anakia does it's job fine, is easier to use
> > and much more lightweight. No need to ditch a tool that works.
>
> Then I'm confused.
> Why did you consent for the change in Phoenix docs?
Because I want to move to more advanced documentation generation features that
cocoon provides. In particular generating single pdfs for guides but multiple
html pages and being able to "suck" docs from other codebases into the
phoenix docs (ie suck loader docs in as loader is used by phoenix etc).
Integrate with javadocs and generate specific documentation from java/config
source files. Also have a single "uber" pdf guide that encompases all phoenix
docs. I also eventually want to move to "database" generated website.
By "database" I mean sucking in data from multiple sources such as
/etc/passwd, /etc/groups, /home/cvs etc and then processing it with something
like http://xineo.sourceforge.net/xil/
Essentially I wanted to be able to do multi-format/channel publishing. While
possible with anakia is no where as easy as it is in cocoon.
> Why did you create a framework Forrest branch?
Because I was sick of hearing users complain. I get on average 6-7 complaints
a month about the size of our CVS download or the size of our distributions
or whatever. About 90% of that size is due to Cocoon jars and excess unused
cruft in documentation tree (like 3 MB of DTDs).
Moving to using forrest means we get to remove a bunch of jars from CVS which
means less complaints hopefully. (Besides our site was not actually building
prior to my starting due to malformed docbook docs).
> >>About the skin, what are your comments?
> >
> > The skin we have seems to work.
>
> The skin we have is incompatible with Forrest; or are you talking about
> the new avalon-tigris one? I don't know if others have seen it yet.
The avalon-tigris one is meant to be the same as our current site which is why
I originally created it.
--
Cheers,
Peter Donald
---------------------------------------------------
"Wise men don't need advice. Fools don't take it."
-Benjamin Franklin
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Use Forrest for all Avalon docs
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Tue, 26 Nov 2002 22:23, Nicola Ken Barozzi wrote:
>
>>Peter Donald wrote:
>>
>>>-1 mandating it everywhere.
>>>+1 for using it in framework cvs
>>
>>Please explain why.
>
> Theres no reason to mandate it.
Consistency, DTD validation, easier for users-developers to learn only
one tool, instant page changes via the embedded local webserver (thus
it's faster than any static generation system for editing).
> Anakia does it's job fine, is easier to use
> and much more lightweight. No need to ditch a tool that works.
Then I'm confused.
Why did you consent for the change in Phoenix docs?
Why did you create a framework Forrest branch?
>>About the skin, what are your comments?
>
> The skin we have seems to work.
The skin we have is incompatible with Forrest; or are you talking about
the new avalon-tigris one? I don't know if others have seen it yet.
--
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: [PROPOSAL] Use Forrest for all Avalon docs
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 26 Nov 2002 22:23, Nicola Ken Barozzi wrote:
> Peter Donald wrote:
> > -1 mandating it everywhere.
> > +1 for using it in framework cvs
>
> Please explain why.
Theres no reason to mandate it. Anakia does it's job fine, is easier to use
and much more lightweight. No need to ditch a tool that works.
> About the skin, what are your comments?
The skin we have seems to work.
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Use Forrest for all Avalon docs
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> Peter Donald wrote:
>
>> -1 mandating it everywhere. +1 for using it in framework cvs
>
>
> Please explain why.
Yes, Peter. A -1 without a reasonable explaination is equivalent of a
slap in a face.
Think about it: what if you proposed something and then I came to you
and say '-1'. Period. How could you possible understand how to fix your
proposal to match my needs if I didn't express them?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Use Forrest for all Avalon docs
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> -1 mandating it everywhere.
> +1 for using it in framework cvs
Please explain why.
About the skin, what are your 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: [PROPOSAL] Use Forrest for all Avalon docs
Posted by Peter Donald <pe...@realityforge.org>.
-1 mandating it everywhere.
+1 for using it in framework cvs
--
Cheers,
Peter Donald
Duct tape is like the force. It has a light side, and a dark side, and
it binds the universe together ...
-- Carl Zwanzig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Darrell DeBoer <da...@apache.org>.
On Mon, 2 Dec 2002 22:14, Peter Donald wrote:
> On Mon, 2 Dec 2002 22:38, Darrell DeBoer wrote:
> > I'm not sure that this is a great example. The MailetContext shares
> > little in common with the Avalon Context, other than a name. It's the way
> > that a MailetContainer (potentially very different from an Avalon
> > Container) provides contextual information to a Mailet, which is a
> > domain-specific component running in a well-defined environment.
>
> That pretty much defines the purpose of Avalons context ;)
>
> ie Take the ServletContext and remove configuration mechanisms (or
> Configuration/Parameters in Avaloon terms) and service provision mechanisms
> (or ServiceManager/ComponentManager in Avalon terms) and you are left with
> what should remain in the context.
Taking a look, you're correct; my mistake. I was actually thinking of the
ServletRequest and ServletResponse interfaces, not the ServletContext itself.
I don't have a firm or fixed view on this, and I'm sure we haven't decided one
way or another in james-dev. There are a few things we could look at moving
off the MailetContext interface, since they are more like MailServices.
Things like "bounce()" and "sendMail()" are examples. I'm jumping the gun of
course, since we've sworn not to talk about this until 2.1 final is out.
Back to the IMAP proposal...
--
cheers,
Darrell DeBoer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter M. Goldstein wrote:
> All,
[...]
> <minor-rant/>
[...]
A clarification: my bringing forward the MailetContext was not about
gathering user requiremnents about James, nor a misunderstanding, but an
opportunity to make a point.
As you have seen, different developers reacted differently seeing it.
Everyone here thinks they have the answer and know what a Context should
do, be it Avalon or any other implementation. The fact is that if we
want to make a better spec, we must have the same vision. The first step
in fixing a problem is admitting there is one, that's all.
Thank you for your explanation, it has been very clear and I'm sure will
really help us.
--
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: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'm not trying to have an argument dude....
Neither am I, Paul. :-) You indicated that "some time ago the JAMES
community got a bit pissed off with 'Avalon' and wanted rid of it", and that
this was one reason why you felt it important to distinguish between the
different aspects of the Avalon technologies. I am trying to get your take
on what you thought that the real issues were.
> There was an element of confusion concerning the differerence between
> our deliverables.
I can appreciate that. Especially since there was a transition to a new
(and different) version of the parts in that time frame. As you note, one
of the really helpful things that you did was to migrate the existing code
to the modified interfaces and help maintain the correct levels of Avalon
code (not just Phoenix, but also Excalibur, Cornerstone and other
dependents). That smoothed over quite a few feathers.
Right now we run something of a hybrid version, where we are current on some
areas, and backlevel on others. We expect to move forward after our next
release, when we'll make necessary changes.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Paul Hammant <Pa...@yahoo.com>.
Noel,
>>>>For example, some time ago the JAMES community got a bit pissed off with
>>>>'Avalon' and wanted rid of it.
>>>>
>>>>
>>>What was the real issue, in your view?
>>>
>>>
>>One of them dude. It is the one that made us rally and come into the
>>list. It may not have been true, but it appeared to be so.
>>
>>
>
>You didn't really answer my question. You indicated that you adopted the
>distinction between areas of Avalon to combat the above situation, but you
>didn't indicate which are of Avalon you believe was an issue, or even what
>the perceived issues were with Avalon.
>
I'm not trying to have an argument dude....
We arived back in the JAMES list after some absence. Previously there
were Avalon committers active in the project and continually defending
the faith. It was important for us to not have one of our flagship
projects abandon a) our Framework and b) our generation #1 container.
There was an element of confusion concerning the differerence between
our deliverables. It even continued after I became more active in the
list. For example one of the betas of Phoenix was booked into CVS as
'newAvalon' . Thus with all the dissent it become obvious to me that my
primary mission was education. I needed to help the JAMES team
understand the different elements of what was there from the Avalon
project, how it was compartmentalised and what the benefits of each
were. It took a considerable amount of effort to do, and was fairly
thankless for a time. I even volunteered to apply commits to the james
project concerning phoenix only. I was granted commit rights, but
(correctly) waived my right to vote and was careful to not exceed my
authority. I tried as far as I could to behave respectfully.
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by "Noel J. Bergman" <no...@devtech.com>.
>>>For example, some time ago the JAMES community got a bit pissed off with
>>>'Avalon' and wanted rid of it.
>>What was the real issue, in your view?
>One of them dude. It is the one that made us rally and come into the
>list. It may not have been true, but it appeared to be so.
You didn't really answer my question. You indicated that you adopted the
distinction between areas of Avalon to combat the above situation, but you
didn't indicate which are of Avalon you believe was an issue, or even what
the perceived issues were with Avalon.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Paul Hammant <Pa...@yahoo.com>.
Noel,
>>For example, some time ago the JAMES community got a bit pissed off with
>>'Avalon' and wanted rid of it.
>>
>>
>
>What was the real issue, in your view?
>
>
One of them dude. It is the one that made us rally and come into the
list. It may not have been true, but it appeared to be so.
>>[we] now have some more fans of Avalon (the project)... yourself included
>>
>>
>dude :-)
>
>I was the one asking you for a demonstration of what it would take to build
>a container to explore the idea of exposing Avalon notions in the Mailet
>API.
>
>
I know, I know.
I'll get round to it :-)
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by "Noel J. Bergman" <no...@devtech.com>.
> For example, some time ago the JAMES community got a bit pissed off with
> 'Avalon' and wanted rid of it.
What was the real issue, in your view?
> [we] now have some more fans of Avalon (the project)... yourself included
dude :-)
I was the one asking you for a demonstration of what it would take to build
a container to explore the idea of exposing Avalon notions in the Mailet
API.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Paul Hammant <Pa...@yahoo.com>.
Noel,
>>.... please differentiate between 'Avalon' (a project which is a
>>collection of tools), 'Avalon-Framework' (a set of very reusable
>>component interfaces), and Avalon-Framework recognising containers (such
>>as Phoenix).
>>
>>
>
>Is this really a particularly useful distinction, except to indicate where
>there are differences within the Avalon community?
>
It is to defeat FUD I'm afraid...
For example, some time ago the JAMES community got a bit pissed off with
'Avalon' and wanted rid of it. A few of us mobilised and came into your
list to defend the cause. One of our primary aims was to correct the
terminology used. I think we did that quite successfully and now have
some more fans of Avalon (the project)... yourself included dude :-)
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Avalon is the Community Project, whose intent is to provide a
>container-based model of application development. To do so the Community
>develops and publishes a Framework and [current: set of containers / future:
>scalable, profiled, container]. What is Java? The language, the library or
>the JVM? Which profile? J2ME, J2SE and J2EE?
>
>What is Avalon? IMO, it is the Community, the architecture, and the
>technologies that implement it.
>
+100
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by "Noel J. Bergman" <no...@devtech.com>.
> We'll note your desire to no longer refer to JAMES as if it were *our*
> project.
Well, it is yours in-so-far as you want to participate in that community
(you are welcome to come back at any time). :-) And it does consume the
range of Avalon (the project) technologies. As for confusing casual
readers, I think that more than just casual readers are confused about
various aspects of something as "basic" to building applications using
Avalon technologies as Context and Compose.
As a part of moving towards Avalon 5, I'd like to see the core notions
revisited and clarified as an essential exercise towards defining the
architecture and design.
> .... please differentiate between 'Avalon' (a project which is a
> collection of tools), 'Avalon-Framework' (a set of very reusable
> component interfaces), and Avalon-Framework recognising containers (such
> as Phoenix).
Is this really a particularly useful distinction, except to indicate where
there are differences within the Avalon community?
Avalon is the Community Project, whose intent is to provide a
container-based model of application development. To do so the Community
develops and publishes a Framework and [current: set of containers / future:
scalable, profiled, container]. What is Java? The language, the library or
the JVM? Which profile? J2ME, J2SE and J2EE?
What is Avalon? IMO, it is the Community, the architecture, and the
technologies that implement it.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>Now, on to the MailetContext. This has zero, zip, nada to do with the
>Avalon Context, Paul's desires notwithstanding. In fact, some
>discussions of the proper behavior of the Avalon Context (as a read-only
>repository of container-provided data) clearly don't seem to support the
>idea of implementing the MailetContext as an extension of Context.
>
We'll note your desire to no longer refer to JAMES as if it were *our*
project. We had been careful to indicate 'contentious' or 'perfect
world' (our point of view), but clearly that is not enough. It is going
to confuse casual readers of this list, thus we'll not refer to
MailetContext again.
Do *us* a favour though dude....
>Once
>again, it is critical that a developer writing a component or set of
>components that use Avalon be able to
>
.... please differentiate between 'Avalon' (a project which is a
collection of tools), 'Avalon-Framework' (a set of very reusable
component interfaces), and Avalon-Framework recognising containers (such
as Phoenix).
Cheers!
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Adam Murdoch wrote:
>On Wed, 4 Dec 2002 11:24 am, Stephen McConnell wrote:
>
>
>
>>>This is the problem. We all agree container-provided services are
>>>essential. They must be made available to components. But we're jumping
>>>straight to *how*, without answering the basic question: Are
>>>container-provided services *really* any different to the other types of
>>>services, from the component's POV? If the answer is no, then the *how*
>>>is already there: Whack them in ServiceManager. Done.
>>>
>>>
>>Throwing them into the service manager isn't a problem - and yes - the
>>component implementation should not know if something is from a
>>container or a peer. However - the container implementation, when
>>building a the component that its going to put into the service manager
>>- it needs to know if the component is requesting a privaliged service.
>>
>>
>
>Of course. But that's the container's problem, right? So long as the
>container gives the privileged service to the privileged component when it
>asks for it, and refuses to hand over the privileged service to a
>non-privileged component, then everyone's happy. There's nothing that needs
>to be added to framework to allow a container to do this: it's
>container-specific behaviour, driven (presumably) by container-specific
>assembly info.
>
Actually in the case of extensions - we defined specific interfaces and
meta to facilitate the explicit declaration by a component implemetation
that it is providing a privialiged function (in this case, handling a
lifecycle extension). Those interfaces and associated meta enable a
container to select candidates within the containment context as
distinct from the componet deployment context.
>
>
>The whole issue of access control of services might be a good thing to
>formalise and add to framework, at some point. But definitely out-of-scope
>for a 'what is a context?' discussion.
>
>
Yes - I agree (when we are looking at the question from the
implemetation of a component that it the recipient of context).
No - when we are looking at a component that is a candidae provider of
context.
>
>
>>If we take the same concept and apply it to contextualization - and we
>>want to extend contextualization in an open way
>>
>>
>
>Not sure what you mean here. Are you talking about some way for a component
>to contribute resources to another component?
>
>
Imagine you declare a component that needs to be contextualized and
somewhere is states that this is to be provided as a context that can be
narrow to VoteContext. Image also that your container has no idea of
what a VoteContext is. In effect, a container can interprit this as a
criteria expressed by the target component for the deployment of a
context provider component that provides context consistent with the
VoteContext criteria. So at some point the container starts hunting
around in the component types it knows about that (a) is a context
provider, and (b) provides support for the VoiteContext criteria. On
locating such a beast, the container can apply classic deployment of the
provider and bundle it within a context object implemetation. When the
clinet request the voting context, the context implementation just
delegates the request off to the context provider.
Alors... portable context!
>
>
>>>Answer my question, and I'll go away.
>>>Promise. (but only if you give the answer I want :)
>>>
>>>
>>My answer is that "classic" components should not be aware of where the
>>service or data comes from.
>>
>>:-)
>>
>>
>
>Ok, good. So why do "non-classic" components (whatever they are) care?
>
>
They (as implementions) don;t care - but the container needs extra info
to these "non-classic" providers. E.g.:
* lifecycle extension handler
* context provider
>And the second part of the question: Do components care whether data and
>services are delivered together, or separately? Why?
>
>
Because it feels right.
:-)
>
>
>>>>But if context/service seperation dissapeared I know I'm still missing
>>>>something important - and I think its about granulirity in lifecycle -
>>>>
>>>>
>>>Can you expand on what exactly you feel is missing? Is it just a vague
>>>feeling that something is not right? Or something more specific?
>>>
>>>
>>I have real requireements context level differentiation. I use in my
>>day-to-day work the notion of component profile (component type +
>>dependency spec + config). For any given profile I have cases of
>>multiple deployed component instances, differentiated by the context
>>that I'm providing them with.
>>
>>
>
>Not sure what you mean. Can you give some example (pseudo-) code? I'm
>interested in the contextualize() and service() methods of these components.
>
Consider the following:
component type: net.osm.vault.DefaultVault
deployment profile: vault
includes the Vault type plus persistence service
configration info and general vault configuration
info
appliance: CA vault
component profile "vault" supplied with a CA cert-chain
under context
appliance: RA vault
component profile "vault" supplied with a RA cert-chain
under context
In the case of CA vault and RA vault, the service model is the same -
the context model is different. There is no magic in the serviceable or
contextualizable implemetation - the magic is the container
configuration which knows about container abstractions of type, profile,
and appliance.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Adam Murdoch wrote:
>On Wed, 4 Dec 2002 11:24 am, Stephen McConnell wrote:
>
>
>
>>>This is the problem. We all agree container-provided services are
>>>essential. They must be made available to components. But we're jumping
>>>straight to *how*, without answering the basic question: Are
>>>container-provided services *really* any different to the other types of
>>>services, from the component's POV? If the answer is no, then the *how*
>>>is already there: Whack them in ServiceManager. Done.
>>>
>>>
>>Throwing them into the service manager isn't a problem - and yes - the
>>component implementation should not know if something is from a
>>container or a peer. However - the container implementation, when
>>building a the component that its going to put into the service manager
>>- it needs to know if the component is requesting a privaliged service.
>>
>>
>
>Of course. But that's the container's problem, right? So long as the
>container gives the privileged service to the privileged component when it
>asks for it, and refuses to hand over the privileged service to a
>non-privileged component, then everyone's happy. There's nothing that needs
>to be added to framework to allow a container to do this: it's
>container-specific behaviour, driven (presumably) by container-specific
>assembly info.
>
Actually in the case of extensions - we defined specific interfaces and
meta to facilitate the explicit declaration by a component implemetation
that it is providing a privialiged function (in this case, handling a
lifecycle extension). Those interfaces and associated meta enable a
container to select candidates within the containment context as
distinct from the componet deployment context.
>
>
>The whole issue of access control of services might be a good thing to
>formalise and add to framework, at some point. But definitely out-of-scope
>for a 'what is a context?' discussion.
>
>
Yes - I agree (when we are looking at the question from the
implemetation of a component that it the recipient of context).
No - when we are looking at a component that is a candidae provider of
context.
>
>
>>If we take the same concept and apply it to contextualization - and we
>>want to extend contextualization in an open way
>>
>>
>
>Not sure what you mean here. Are you talking about some way for a component
>to contribute resources to another component?
>
>
Imagine you declare a component that needs to be contextualized and
somewhere is states that this is to be provided as a context that can be
narrow to VoteContext. Image also that your container has no idea of
what a VoteContext is. In effect, a container can interprit this as a
criteria expressed by the target component for the deployment of a
context provider component that provides context consistent with the
VoteContext criteria. So at some point the container starts hunting
around in the component types it knows about that (a) is a context
provider, and (b) provides support for the VoiteContext criteria. On
locating such a beast, the container can apply classic deployment of the
provider and bundle it within a context object implemetation. When the
clinet request the voting context, the context implementation just
delegates the request off to the context provider.
Alors... portable context!
>
>
>>>Answer my question, and I'll go away.
>>>Promise. (but only if you give the answer I want :)
>>>
>>>
>>My answer is that "classic" components should not be aware of where the
>>service or data comes from.
>>
>>:-)
>>
>>
>
>Ok, good. So why do "non-classic" components (whatever they are) care?
>
>
They (as implementions) don;t care - but the container needs extra info
to these "non-classic" providers. E.g.:
* lifecycle extension handler
* context provider
>And the second part of the question: Do components care whether data and
>services are delivered together, or separately? Why?
>
>
Because it feels right.
:-)
>
>
>>>>But if context/service seperation dissapeared I know I'm still missing
>>>>something important - and I think its about granulirity in lifecycle -
>>>>
>>>>
>>>Can you expand on what exactly you feel is missing? Is it just a vague
>>>feeling that something is not right? Or something more specific?
>>>
>>>
>>I have real requireements context level differentiation. I use in my
>>day-to-day work the notion of component profile (component type +
>>dependency spec + config). For any given profile I have cases of
>>multiple deployed component instances, differentiated by the context
>>that I'm providing them with.
>>
>>
>
>Not sure what you mean. Can you give some example (pseudo-) code? I'm
>interested in the contextualize() and service() methods of these components.
>
Consider the following:
component type: net.osm.vault.DefaultVault
deployment profile: vault
includes the Vault type plus persistence service
configration info and general vault configuration
info
appliance: CA vault
component profile "vault" supplied with a CA cert-chain
under context
appliance: RA vault
component profile "vault" supplied with a RA cert-chain
under context
In the case of CA vault and RA vault, the service model is the same -
the context model is different. There is no magic in the serviceable or
contextualizable implemetation - the magic is the container
configuration which knows about container abstractions of type, profile,
and appliance.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Adam Murdoch wrote:
>On Wed, 4 Dec 2002 11:24 am, Stephen McConnell wrote:
>
>
>
>>>This is the problem. We all agree container-provided services are
>>>essential. They must be made available to components. But we're jumping
>>>straight to *how*, without answering the basic question: Are
>>>container-provided services *really* any different to the other types of
>>>services, from the component's POV? If the answer is no, then the *how*
>>>is already there: Whack them in ServiceManager. Done.
>>>
>>>
>>Throwing them into the service manager isn't a problem - and yes - the
>>component implementation should not know if something is from a
>>container or a peer. However - the container implementation, when
>>building a the component that its going to put into the service manager
>>- it needs to know if the component is requesting a privaliged service.
>>
>>
>
>Of course. But that's the container's problem, right? So long as the
>container gives the privileged service to the privileged component when it
>asks for it, and refuses to hand over the privileged service to a
>non-privileged component, then everyone's happy. There's nothing that needs
>to be added to framework to allow a container to do this: it's
>container-specific behaviour, driven (presumably) by container-specific
>assembly info.
>
Actually in the case of extensions - we defined specific interfaces and
meta to facilitate the explicit declaration by a component implemetation
that it is providing a privialiged function (in this case, handling a
lifecycle extension). Those interfaces and associated meta enable a
container to select candidates within the containment context as
distinct from the componet deployment context.
>
>
>The whole issue of access control of services might be a good thing to
>formalise and add to framework, at some point. But definitely out-of-scope
>for a 'what is a context?' discussion.
>
>
Yes - I agree (when we are looking at the question from the
implemetation of a component that it the recipient of context).
No - when we are looking at a component that is a candidae provider of
context.
>
>
>>If we take the same concept and apply it to contextualization - and we
>>want to extend contextualization in an open way
>>
>>
>
>Not sure what you mean here. Are you talking about some way for a component
>to contribute resources to another component?
>
>
Imagine you declare a component that needs to be contextualized and
somewhere is states that this is to be provided as a context that can be
narrow to VoteContext. Image also that your container has no idea of
what a VoteContext is. In effect, a container can interprit this as a
criteria expressed by the target component for the deployment of a
context provider component that provides context consistent with the
VoteContext criteria. So at some point the container starts hunting
around in the component types it knows about that (a) is a context
provider, and (b) provides support for the VoiteContext criteria. On
locating such a beast, the container can apply classic deployment of the
provider and bundle it within a context object implemetation. When the
clinet request the voting context, the context implementation just
delegates the request off to the context provider.
Alors... portable context!
>
>
>>>Answer my question, and I'll go away.
>>>Promise. (but only if you give the answer I want :)
>>>
>>>
>>My answer is that "classic" components should not be aware of where the
>>service or data comes from.
>>
>>:-)
>>
>>
>
>Ok, good. So why do "non-classic" components (whatever they are) care?
>
>
They (as implementions) don;t care - but the container needs extra info
to these "non-classic" providers. E.g.:
* lifecycle extension handler
* context provider
>And the second part of the question: Do components care whether data and
>services are delivered together, or separately? Why?
>
>
Because it feels right.
:-)
>
>
>>>>But if context/service seperation dissapeared I know I'm still missing
>>>>something important - and I think its about granulirity in lifecycle -
>>>>
>>>>
>>>Can you expand on what exactly you feel is missing? Is it just a vague
>>>feeling that something is not right? Or something more specific?
>>>
>>>
>>I have real requireements context level differentiation. I use in my
>>day-to-day work the notion of component profile (component type +
>>dependency spec + config). For any given profile I have cases of
>>multiple deployed component instances, differentiated by the context
>>that I'm providing them with.
>>
>>
>
>Not sure what you mean. Can you give some example (pseudo-) code? I'm
>interested in the contextualize() and service() methods of these components.
>
Consider the following:
component type: net.osm.vault.DefaultVault
deployment profile: vault
includes the Vault type plus persistence service
configration info and general vault configuration
info
appliance: CA vault
component profile "vault" supplied with a CA cert-chain
under context
appliance: RA vault
component profile "vault" supplied with a RA cert-chain
under context
In the case of CA vault and RA vault, the service model is the same -
the context model is different. There is no magic in the serviceable or
contextualizable implemetation - the magic is the container
configuration which knows about container abstractions of type, profile,
and appliance.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Wed, 4 Dec 2002 11:24 am, Stephen McConnell wrote:
> >This is the problem. We all agree container-provided services are
> > essential. They must be made available to components. But we're jumping
> > straight to *how*, without answering the basic question: Are
> > container-provided services *really* any different to the other types of
> > services, from the component's POV? If the answer is no, then the *how*
> > is already there: Whack them in ServiceManager. Done.
>
> Throwing them into the service manager isn't a problem - and yes - the
> component implementation should not know if something is from a
> container or a peer. However - the container implementation, when
> building a the component that its going to put into the service manager
> - it needs to know if the component is requesting a privaliged service.
Of course. But that's the container's problem, right? So long as the
container gives the privileged service to the privileged component when it
asks for it, and refuses to hand over the privileged service to a
non-privileged component, then everyone's happy. There's nothing that needs
to be added to framework to allow a container to do this: it's
container-specific behaviour, driven (presumably) by container-specific
assembly info.
The whole issue of access control of services might be a good thing to
formalise and add to framework, at some point. But definitely out-of-scope
for a 'what is a context?' discussion.
> If we take the same concept and apply it to contextualization - and we
> want to extend contextualization in an open way
Not sure what you mean here. Are you talking about some way for a component
to contribute resources to another component?
> >Answer my question, and I'll go away.
> >Promise. (but only if you give the answer I want :)
>
> My answer is that "classic" components should not be aware of where the
> service or data comes from.
>
> :-)
Ok, good. So why do "non-classic" components (whatever they are) care?
And the second part of the question: Do components care whether data and
services are delivered together, or separately? Why?
> >>But if context/service seperation dissapeared I know I'm still missing
> >>something important - and I think its about granulirity in lifecycle -
> >
> >Can you expand on what exactly you feel is missing? Is it just a vague
> >feeling that something is not right? Or something more specific?
>
> I have real requireements context level differentiation. I use in my
> day-to-day work the notion of component profile (component type +
> dependency spec + config). For any given profile I have cases of
> multiple deployed component instances, differentiated by the context
> that I'm providing them with.
Not sure what you mean. Can you give some example (pseudo-) code? I'm
interested in the contextualize() and service() methods of these components.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Wed, 4 Dec 2002 11:24 am, Stephen McConnell wrote:
> >This is the problem. We all agree container-provided services are
> > essential. They must be made available to components. But we're jumping
> > straight to *how*, without answering the basic question: Are
> > container-provided services *really* any different to the other types of
> > services, from the component's POV? If the answer is no, then the *how*
> > is already there: Whack them in ServiceManager. Done.
>
> Throwing them into the service manager isn't a problem - and yes - the
> component implementation should not know if something is from a
> container or a peer. However - the container implementation, when
> building a the component that its going to put into the service manager
> - it needs to know if the component is requesting a privaliged service.
Of course. But that's the container's problem, right? So long as the
container gives the privileged service to the privileged component when it
asks for it, and refuses to hand over the privileged service to a
non-privileged component, then everyone's happy. There's nothing that needs
to be added to framework to allow a container to do this: it's
container-specific behaviour, driven (presumably) by container-specific
assembly info.
The whole issue of access control of services might be a good thing to
formalise and add to framework, at some point. But definitely out-of-scope
for a 'what is a context?' discussion.
> If we take the same concept and apply it to contextualization - and we
> want to extend contextualization in an open way
Not sure what you mean here. Are you talking about some way for a component
to contribute resources to another component?
> >Answer my question, and I'll go away.
> >Promise. (but only if you give the answer I want :)
>
> My answer is that "classic" components should not be aware of where the
> service or data comes from.
>
> :-)
Ok, good. So why do "non-classic" components (whatever they are) care?
And the second part of the question: Do components care whether data and
services are delivered together, or separately? Why?
> >>But if context/service seperation dissapeared I know I'm still missing
> >>something important - and I think its about granulirity in lifecycle -
> >
> >Can you expand on what exactly you feel is missing? Is it just a vague
> >feeling that something is not right? Or something more specific?
>
> I have real requireements context level differentiation. I use in my
> day-to-day work the notion of component profile (component type +
> dependency spec + config). For any given profile I have cases of
> multiple deployed component instances, differentiated by the context
> that I'm providing them with.
Not sure what you mean. Can you give some example (pseudo-) code? I'm
interested in the contextualize() and service() methods of these components.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Wed, 4 Dec 2002 11:24 am, Stephen McConnell wrote:
> >This is the problem. We all agree container-provided services are
> > essential. They must be made available to components. But we're jumping
> > straight to *how*, without answering the basic question: Are
> > container-provided services *really* any different to the other types of
> > services, from the component's POV? If the answer is no, then the *how*
> > is already there: Whack them in ServiceManager. Done.
>
> Throwing them into the service manager isn't a problem - and yes - the
> component implementation should not know if something is from a
> container or a peer. However - the container implementation, when
> building a the component that its going to put into the service manager
> - it needs to know if the component is requesting a privaliged service.
Of course. But that's the container's problem, right? So long as the
container gives the privileged service to the privileged component when it
asks for it, and refuses to hand over the privileged service to a
non-privileged component, then everyone's happy. There's nothing that needs
to be added to framework to allow a container to do this: it's
container-specific behaviour, driven (presumably) by container-specific
assembly info.
The whole issue of access control of services might be a good thing to
formalise and add to framework, at some point. But definitely out-of-scope
for a 'what is a context?' discussion.
> If we take the same concept and apply it to contextualization - and we
> want to extend contextualization in an open way
Not sure what you mean here. Are you talking about some way for a component
to contribute resources to another component?
> >Answer my question, and I'll go away.
> >Promise. (but only if you give the answer I want :)
>
> My answer is that "classic" components should not be aware of where the
> service or data comes from.
>
> :-)
Ok, good. So why do "non-classic" components (whatever they are) care?
And the second part of the question: Do components care whether data and
services are delivered together, or separately? Why?
> >>But if context/service seperation dissapeared I know I'm still missing
> >>something important - and I think its about granulirity in lifecycle -
> >
> >Can you expand on what exactly you feel is missing? Is it just a vague
> >feeling that something is not right? Or something more specific?
>
> I have real requireements context level differentiation. I use in my
> day-to-day work the notion of component profile (component type +
> dependency spec + config). For any given profile I have cases of
> multiple deployed component instances, differentiated by the context
> that I'm providing them with.
Not sure what you mean. Can you give some example (pseudo-) code? I'm
interested in the contextualize() and service() methods of these components.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Adam Murdoch wrote:
>On Wed, 4 Dec 2002 04:50 am, Stephen McConnell wrote:
>
>
>
>>About all I can draw out of the requestShutdown example is that there is
>>perhaps a need for some standard interface that can be provided by a
>>container to handle child request - and, that the container
>>implememntation still needs to know that the handler needs privaliged
>>(i.e. container sourced) information.
>>
>>
>
>I don't think this follows at all. All the requestShutdown example shows is
>that some components need to use services provided by the container. You
>can't really draw any conclusions about how the component might get hold of
>the service.
>
>This is the problem. We all agree container-provided services are essential.
>They must be made available to components. But we're jumping straight to
>*how*, without answering the basic question: Are container-provided services
>*really* any different to the other types of services, from the component's
>POV? If the answer is no, then the *how* is already there: Whack them in
>ServiceManager. Done.
>
Throwing them into the service manager isn't a problem - and yes - the
component implementation should not know if something is from a
container or a peer. However - the container implementation, when
building a the component that its going to put into the service manager
- it needs to know if the component is requesting a privaliged service.
Let me explain this a little more.
Take the example of the extensions mechanism in Merlin. Here we have an
example of a clear destinction between a classic component and a
privaliged component. The classic component is the component that is
the target of extension - it does not know where the extension data is
comming from - it just knows that it is going to be extended in
accordance with the extension depedencies it declares. The privaliged
component is the extension handler - the handler is computationally part
of the containment solution and as such it is implicitly a privaliged
component.
If we take the same concept and apply it to contextualization - and we
want to extend contextualization in an open way, we need an equivalent
container-side privaliged component - something like a standard
ContextManager. An implemetation of this could be a
ShutdownRequestManager component - it it could potentially declare
depedencies on standard services within the containerment system
(service that are not normally available to classic components). But to
keep this open, this means the containerment API needs to be formal -
exposing things like a StartupService, etc.
>
>
>>But anyway - what I can draw from things at the moment is that there is
>>perhaps a meta model issue here. At the meta model level we have the
>>notions of context criteria and service depedencies as different
>>abstractions and container map these respective notions into the SM/CM
>>and Context implemetations provided to the component. Adam Murdoch is
>>persistently raising a bunch of good question that suggest that there
>>may be a more deeply rooted problem
>>
>>
>
>Sorry for being such a broken record.
>
Far from it - I think you getting to some very valid issues.
>Answer my question, and I'll go away.
>Promise. (but only if you give the answer I want :)
>
My answer is that "classic" components should not be aware of where the
service or data comes from.
:-)
>
>
>>But if context/service seperation dissapeared I know I'm still missing
>>something important - and I think its about granulirity in lifecycle -
>>
>>
>
>Can you expand on what exactly you feel is missing? Is it just a vague
>feeling that something is not right? Or something more specific?
>
>
I have real requireements context level differentiation. I use in my
day-to-day work the notion of component profile (component type +
dependency spec + config). For any given profile I have cases of
multiple deployed component instances, differentiated by the context
that I'm providing them with.
Hope that helps.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Adam Murdoch wrote:
>On Wed, 4 Dec 2002 04:50 am, Stephen McConnell wrote:
>
>
>
>>About all I can draw out of the requestShutdown example is that there is
>>perhaps a need for some standard interface that can be provided by a
>>container to handle child request - and, that the container
>>implememntation still needs to know that the handler needs privaliged
>>(i.e. container sourced) information.
>>
>>
>
>I don't think this follows at all. All the requestShutdown example shows is
>that some components need to use services provided by the container. You
>can't really draw any conclusions about how the component might get hold of
>the service.
>
>This is the problem. We all agree container-provided services are essential.
>They must be made available to components. But we're jumping straight to
>*how*, without answering the basic question: Are container-provided services
>*really* any different to the other types of services, from the component's
>POV? If the answer is no, then the *how* is already there: Whack them in
>ServiceManager. Done.
>
Throwing them into the service manager isn't a problem - and yes - the
component implementation should not know if something is from a
container or a peer. However - the container implementation, when
building a the component that its going to put into the service manager
- it needs to know if the component is requesting a privaliged service.
Let me explain this a little more.
Take the example of the extensions mechanism in Merlin. Here we have an
example of a clear destinction between a classic component and a
privaliged component. The classic component is the component that is
the target of extension - it does not know where the extension data is
comming from - it just knows that it is going to be extended in
accordance with the extension depedencies it declares. The privaliged
component is the extension handler - the handler is computationally part
of the containment solution and as such it is implicitly a privaliged
component.
If we take the same concept and apply it to contextualization - and we
want to extend contextualization in an open way, we need an equivalent
container-side privaliged component - something like a standard
ContextManager. An implemetation of this could be a
ShutdownRequestManager component - it it could potentially declare
depedencies on standard services within the containerment system
(service that are not normally available to classic components). But to
keep this open, this means the containerment API needs to be formal -
exposing things like a StartupService, etc.
>
>
>>But anyway - what I can draw from things at the moment is that there is
>>perhaps a meta model issue here. At the meta model level we have the
>>notions of context criteria and service depedencies as different
>>abstractions and container map these respective notions into the SM/CM
>>and Context implemetations provided to the component. Adam Murdoch is
>>persistently raising a bunch of good question that suggest that there
>>may be a more deeply rooted problem
>>
>>
>
>Sorry for being such a broken record.
>
Far from it - I think you getting to some very valid issues.
>Answer my question, and I'll go away.
>Promise. (but only if you give the answer I want :)
>
My answer is that "classic" components should not be aware of where the
service or data comes from.
:-)
>
>
>>But if context/service seperation dissapeared I know I'm still missing
>>something important - and I think its about granulirity in lifecycle -
>>
>>
>
>Can you expand on what exactly you feel is missing? Is it just a vague
>feeling that something is not right? Or something more specific?
>
>
I have real requireements context level differentiation. I use in my
day-to-day work the notion of component profile (component type +
dependency spec + config). For any given profile I have cases of
multiple deployed component instances, differentiated by the context
that I'm providing them with.
Hope that helps.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Adam Murdoch wrote:
>On Wed, 4 Dec 2002 04:50 am, Stephen McConnell wrote:
>
>
>
>>About all I can draw out of the requestShutdown example is that there is
>>perhaps a need for some standard interface that can be provided by a
>>container to handle child request - and, that the container
>>implememntation still needs to know that the handler needs privaliged
>>(i.e. container sourced) information.
>>
>>
>
>I don't think this follows at all. All the requestShutdown example shows is
>that some components need to use services provided by the container. You
>can't really draw any conclusions about how the component might get hold of
>the service.
>
>This is the problem. We all agree container-provided services are essential.
>They must be made available to components. But we're jumping straight to
>*how*, without answering the basic question: Are container-provided services
>*really* any different to the other types of services, from the component's
>POV? If the answer is no, then the *how* is already there: Whack them in
>ServiceManager. Done.
>
Throwing them into the service manager isn't a problem - and yes - the
component implementation should not know if something is from a
container or a peer. However - the container implementation, when
building a the component that its going to put into the service manager
- it needs to know if the component is requesting a privaliged service.
Let me explain this a little more.
Take the example of the extensions mechanism in Merlin. Here we have an
example of a clear destinction between a classic component and a
privaliged component. The classic component is the component that is
the target of extension - it does not know where the extension data is
comming from - it just knows that it is going to be extended in
accordance with the extension depedencies it declares. The privaliged
component is the extension handler - the handler is computationally part
of the containment solution and as such it is implicitly a privaliged
component.
If we take the same concept and apply it to contextualization - and we
want to extend contextualization in an open way, we need an equivalent
container-side privaliged component - something like a standard
ContextManager. An implemetation of this could be a
ShutdownRequestManager component - it it could potentially declare
depedencies on standard services within the containerment system
(service that are not normally available to classic components). But to
keep this open, this means the containerment API needs to be formal -
exposing things like a StartupService, etc.
>
>
>>But anyway - what I can draw from things at the moment is that there is
>>perhaps a meta model issue here. At the meta model level we have the
>>notions of context criteria and service depedencies as different
>>abstractions and container map these respective notions into the SM/CM
>>and Context implemetations provided to the component. Adam Murdoch is
>>persistently raising a bunch of good question that suggest that there
>>may be a more deeply rooted problem
>>
>>
>
>Sorry for being such a broken record.
>
Far from it - I think you getting to some very valid issues.
>Answer my question, and I'll go away.
>Promise. (but only if you give the answer I want :)
>
My answer is that "classic" components should not be aware of where the
service or data comes from.
:-)
>
>
>>But if context/service seperation dissapeared I know I'm still missing
>>something important - and I think its about granulirity in lifecycle -
>>
>>
>
>Can you expand on what exactly you feel is missing? Is it just a vague
>feeling that something is not right? Or something more specific?
>
>
I have real requireements context level differentiation. I use in my
day-to-day work the notion of component profile (component type +
dependency spec + config). For any given profile I have cases of
multiple deployed component instances, differentiated by the context
that I'm providing them with.
Hope that helps.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Wed, 4 Dec 2002 04:50 am, Stephen McConnell wrote:
> About all I can draw out of the requestShutdown example is that there is
> perhaps a need for some standard interface that can be provided by a
> container to handle child request - and, that the container
> implememntation still needs to know that the handler needs privaliged
> (i.e. container sourced) information.
I don't think this follows at all. All the requestShutdown example shows is
that some components need to use services provided by the container. You
can't really draw any conclusions about how the component might get hold of
the service.
This is the problem. We all agree container-provided services are essential.
They must be made available to components. But we're jumping straight to
*how*, without answering the basic question: Are container-provided services
*really* any different to the other types of services, from the component's
POV? If the answer is no, then the *how* is already there: Whack them in
ServiceManager. Done.
> But anyway - what I can draw from things at the moment is that there is
> perhaps a meta model issue here. At the meta model level we have the
> notions of context criteria and service depedencies as different
> abstractions and container map these respective notions into the SM/CM
> and Context implemetations provided to the component. Adam Murdoch is
> persistently raising a bunch of good question that suggest that there
> may be a more deeply rooted problem
Sorry for being such a broken record. Answer my question, and I'll go away.
Promise. (but only if you give the answer I want :)
> But if context/service seperation dissapeared I know I'm still missing
> something important - and I think its about granulirity in lifecycle -
Can you expand on what exactly you feel is missing? Is it just a vague
feeling that something is not right? Or something more specific?
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Wed, 4 Dec 2002 04:50 am, Stephen McConnell wrote:
> About all I can draw out of the requestShutdown example is that there is
> perhaps a need for some standard interface that can be provided by a
> container to handle child request - and, that the container
> implememntation still needs to know that the handler needs privaliged
> (i.e. container sourced) information.
I don't think this follows at all. All the requestShutdown example shows is
that some components need to use services provided by the container. You
can't really draw any conclusions about how the component might get hold of
the service.
This is the problem. We all agree container-provided services are essential.
They must be made available to components. But we're jumping straight to
*how*, without answering the basic question: Are container-provided services
*really* any different to the other types of services, from the component's
POV? If the answer is no, then the *how* is already there: Whack them in
ServiceManager. Done.
> But anyway - what I can draw from things at the moment is that there is
> perhaps a meta model issue here. At the meta model level we have the
> notions of context criteria and service depedencies as different
> abstractions and container map these respective notions into the SM/CM
> and Context implemetations provided to the component. Adam Murdoch is
> persistently raising a bunch of good question that suggest that there
> may be a more deeply rooted problem
Sorry for being such a broken record. Answer my question, and I'll go away.
Promise. (but only if you give the answer I want :)
> But if context/service seperation dissapeared I know I'm still missing
> something important - and I think its about granulirity in lifecycle -
Can you expand on what exactly you feel is missing? Is it just a vague
feeling that something is not right? Or something more specific?
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Wed, 4 Dec 2002 04:50 am, Stephen McConnell wrote:
> About all I can draw out of the requestShutdown example is that there is
> perhaps a need for some standard interface that can be provided by a
> container to handle child request - and, that the container
> implememntation still needs to know that the handler needs privaliged
> (i.e. container sourced) information.
I don't think this follows at all. All the requestShutdown example shows is
that some components need to use services provided by the container. You
can't really draw any conclusions about how the component might get hold of
the service.
This is the problem. We all agree container-provided services are essential.
They must be made available to components. But we're jumping straight to
*how*, without answering the basic question: Are container-provided services
*really* any different to the other types of services, from the component's
POV? If the answer is no, then the *how* is already there: Whack them in
ServiceManager. Done.
> But anyway - what I can draw from things at the moment is that there is
> perhaps a meta model issue here. At the meta model level we have the
> notions of context criteria and service depedencies as different
> abstractions and container map these respective notions into the SM/CM
> and Context implemetations provided to the component. Adam Murdoch is
> persistently raising a bunch of good question that suggest that there
> may be a more deeply rooted problem
Sorry for being such a broken record. Answer my question, and I'll go away.
Promise. (but only if you give the answer I want :)
> But if context/service seperation dissapeared I know I'm still missing
> something important - and I think its about granulirity in lifecycle -
Can you expand on what exactly you feel is missing? Is it just a vague
feeling that something is not right? Or something more specific?
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Neeme Praks wrote:
>
>
> Stephen McConnell ::
>
>> One or more component authors (like those James guys) - let's imagine
>> they want to lock a component into a suiside pact and as such - their
>> component needs a shutdown service. When the component hits
>> requestShutdown() their component is going die - ok, that's cool -
>> perhaps the component is running under the mailet API and what it really
>> needs is a reserection (but that's a thread for next year) - aside from
>> that - problem is their component needs to be able to say "I need to
>> make request to the thing that started me up in the first place". This
>> is not the same semantics as a classic lookup() or get(). The issue -
>> how can we convey that notion that the component is requesting a service
>> from a provider that it intrisic to its own existance - that's what I'm
>> trying to distinguish here - the notion of a privaliged request. Its
>> priviliged if it's from sibling to parent. A shutdown request is one
>> example, other examples include notification of state change, request
>> for re-deployment etc.
>
>
>
> I'm not really fond of the distinction between priviledged and
> non-priviledged services...
> How about then one more (optional) "lifescycle extension", e.g:
>
> public interface Child {
>
> void setParent(Parent parent);
>
> }
>
> And then this "parent" object would follow the same semantics as has
> been proposed for Context:
>
> ShutDownableParent shutDownableParent = (ShutDownableParent)
> parent.getInterface(ShutDownableParent.class);
> shutDownableParent.requestShutdown();
>
> (or whatever flavour of the extended context methods you prefer)
>
> Or am I totally wandering in the dark here...
If your wandering around in the dark - be careful - you will probably
bump in me becasue I'm wandering in the dark a little myself. I have
been thinking about the lifecycle extension take on this as well - and
my impressions is that for the case of "requestShutdown" etc. it a
cleaner approach than extending context - but at the same time I also
think that all it does is shift the real problem of access to a
priviledged parent-child context - after all - how does the extension
handler get a reference to the container ? Even if it has a reference
to the container - you still need an operation on the container to
request shutdown.
About all I can draw out of the requestShutdown example is that there is
perhaps a need for some standard interface that can be provided by a
container to handle child request - and, that the container
implememntation still needs to know that the handler needs privaliged
(i.e. container sourced) information.
But anyway - what I can draw from things at the moment is that there is
perhaps a meta model issue here. At the meta model level we have the
notions of context criteria and service depedencies as different
abstractions and container map these respective notions into the SM/CM
and Context implemetations provided to the component. Adam Murdoch is
persistently raising a bunch of good question that suggest that there
may be a more deeply rooted problem - for example, imagine I drop
Contextexulizable/Servicable seperation - I could rework stuff in the
containers I use to handle this - instead of apply
get("urn:avalon:work") to a context you could instead apply
lookup("urn:avalon:work) to a common handler.
But if context/service seperation dissapeared I know I'm still missing
something important - and I think its about granulirity in lifecycle -
i.e. does reservicing imply re contextualization - does
recontextualization imply reservicing. If recontextualization can occur
without reservicing than we have a distinct abstraction. But I'm well
an trully in the perculating thoughts stage on this.
Cheers, Steve.
>
> Rgds,
> Neeme
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Neeme Praks wrote:
>
>
> Stephen McConnell ::
>
>> One or more component authors (like those James guys) - let's imagine
>> they want to lock a component into a suiside pact and as such - their
>> component needs a shutdown service. When the component hits
>> requestShutdown() their component is going die - ok, that's cool -
>> perhaps the component is running under the mailet API and what it really
>> needs is a reserection (but that's a thread for next year) - aside from
>> that - problem is their component needs to be able to say "I need to
>> make request to the thing that started me up in the first place". This
>> is not the same semantics as a classic lookup() or get(). The issue -
>> how can we convey that notion that the component is requesting a service
>> from a provider that it intrisic to its own existance - that's what I'm
>> trying to distinguish here - the notion of a privaliged request. Its
>> priviliged if it's from sibling to parent. A shutdown request is one
>> example, other examples include notification of state change, request
>> for re-deployment etc.
>
>
>
> I'm not really fond of the distinction between priviledged and
> non-priviledged services...
> How about then one more (optional) "lifescycle extension", e.g:
>
> public interface Child {
>
> void setParent(Parent parent);
>
> }
>
> And then this "parent" object would follow the same semantics as has
> been proposed for Context:
>
> ShutDownableParent shutDownableParent = (ShutDownableParent)
> parent.getInterface(ShutDownableParent.class);
> shutDownableParent.requestShutdown();
>
> (or whatever flavour of the extended context methods you prefer)
>
> Or am I totally wandering in the dark here...
If your wandering around in the dark - be careful - you will probably
bump in me becasue I'm wandering in the dark a little myself. I have
been thinking about the lifecycle extension take on this as well - and
my impressions is that for the case of "requestShutdown" etc. it a
cleaner approach than extending context - but at the same time I also
think that all it does is shift the real problem of access to a
priviledged parent-child context - after all - how does the extension
handler get a reference to the container ? Even if it has a reference
to the container - you still need an operation on the container to
request shutdown.
About all I can draw out of the requestShutdown example is that there is
perhaps a need for some standard interface that can be provided by a
container to handle child request - and, that the container
implememntation still needs to know that the handler needs privaliged
(i.e. container sourced) information.
But anyway - what I can draw from things at the moment is that there is
perhaps a meta model issue here. At the meta model level we have the
notions of context criteria and service depedencies as different
abstractions and container map these respective notions into the SM/CM
and Context implemetations provided to the component. Adam Murdoch is
persistently raising a bunch of good question that suggest that there
may be a more deeply rooted problem - for example, imagine I drop
Contextexulizable/Servicable seperation - I could rework stuff in the
containers I use to handle this - instead of apply
get("urn:avalon:work") to a context you could instead apply
lookup("urn:avalon:work) to a common handler.
But if context/service seperation dissapeared I know I'm still missing
something important - and I think its about granulirity in lifecycle -
i.e. does reservicing imply re contextualization - does
recontextualization imply reservicing. If recontextualization can occur
without reservicing than we have a distinct abstraction. But I'm well
an trully in the perculating thoughts stage on this.
Cheers, Steve.
>
> Rgds,
> Neeme
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Neeme Praks wrote:
>
>
> Stephen McConnell ::
>
>> One or more component authors (like those James guys) - let's imagine
>> they want to lock a component into a suiside pact and as such - their
>> component needs a shutdown service. When the component hits
>> requestShutdown() their component is going die - ok, that's cool -
>> perhaps the component is running under the mailet API and what it really
>> needs is a reserection (but that's a thread for next year) - aside from
>> that - problem is their component needs to be able to say "I need to
>> make request to the thing that started me up in the first place". This
>> is not the same semantics as a classic lookup() or get(). The issue -
>> how can we convey that notion that the component is requesting a service
>> from a provider that it intrisic to its own existance - that's what I'm
>> trying to distinguish here - the notion of a privaliged request. Its
>> priviliged if it's from sibling to parent. A shutdown request is one
>> example, other examples include notification of state change, request
>> for re-deployment etc.
>
>
>
> I'm not really fond of the distinction between priviledged and
> non-priviledged services...
> How about then one more (optional) "lifescycle extension", e.g:
>
> public interface Child {
>
> void setParent(Parent parent);
>
> }
>
> And then this "parent" object would follow the same semantics as has
> been proposed for Context:
>
> ShutDownableParent shutDownableParent = (ShutDownableParent)
> parent.getInterface(ShutDownableParent.class);
> shutDownableParent.requestShutdown();
>
> (or whatever flavour of the extended context methods you prefer)
>
> Or am I totally wandering in the dark here...
If your wandering around in the dark - be careful - you will probably
bump in me becasue I'm wandering in the dark a little myself. I have
been thinking about the lifecycle extension take on this as well - and
my impressions is that for the case of "requestShutdown" etc. it a
cleaner approach than extending context - but at the same time I also
think that all it does is shift the real problem of access to a
priviledged parent-child context - after all - how does the extension
handler get a reference to the container ? Even if it has a reference
to the container - you still need an operation on the container to
request shutdown.
About all I can draw out of the requestShutdown example is that there is
perhaps a need for some standard interface that can be provided by a
container to handle child request - and, that the container
implememntation still needs to know that the handler needs privaliged
(i.e. container sourced) information.
But anyway - what I can draw from things at the moment is that there is
perhaps a meta model issue here. At the meta model level we have the
notions of context criteria and service depedencies as different
abstractions and container map these respective notions into the SM/CM
and Context implemetations provided to the component. Adam Murdoch is
persistently raising a bunch of good question that suggest that there
may be a more deeply rooted problem - for example, imagine I drop
Contextexulizable/Servicable seperation - I could rework stuff in the
containers I use to handle this - instead of apply
get("urn:avalon:work") to a context you could instead apply
lookup("urn:avalon:work) to a common handler.
But if context/service seperation dissapeared I know I'm still missing
something important - and I think its about granulirity in lifecycle -
i.e. does reservicing imply re contextualization - does
recontextualization imply reservicing. If recontextualization can occur
without reservicing than we have a distinct abstraction. But I'm well
an trully in the perculating thoughts stage on this.
Cheers, Steve.
>
> Rgds,
> Neeme
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Neeme Praks <ne...@apache.org>.
Stephen McConnell ::
> One or more component authors (like those James guys) - let's imagine
> they want to lock a component into a suiside pact and as such - their
> component needs a shutdown service. When the component hits
> requestShutdown() their component is going die - ok, that's cool -
> perhaps the component is running under the mailet API and what it really
> needs is a reserection (but that's a thread for next year) - aside from
> that - problem is their component needs to be able to say "I need to
> make request to the thing that started me up in the first place". This
> is not the same semantics as a classic lookup() or get(). The issue -
> how can we convey that notion that the component is requesting a service
> from a provider that it intrisic to its own existance - that's what I'm
> trying to distinguish here - the notion of a privaliged request. Its
> priviliged if it's from sibling to parent. A shutdown request is one
> example, other examples include notification of state change, request
> for re-deployment etc.
I'm not really fond of the distinction between priviledged and
non-priviledged services...
How about then one more (optional) "lifescycle extension", e.g:
public interface Child {
void setParent(Parent parent);
}
And then this "parent" object would follow the same semantics as has
been proposed for Context:
ShutDownableParent shutDownableParent = (ShutDownableParent)
parent.getInterface(ShutDownableParent.class);
shutDownableParent.requestShutdown();
(or whatever flavour of the extended context methods you prefer)
Or am I totally wandering in the dark here...
Rgds,
Neeme
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Neeme Praks <ne...@apache.org>.
Stephen McConnell ::
> One or more component authors (like those James guys) - let's imagine
> they want to lock a component into a suiside pact and as such - their
> component needs a shutdown service. When the component hits
> requestShutdown() their component is going die - ok, that's cool -
> perhaps the component is running under the mailet API and what it really
> needs is a reserection (but that's a thread for next year) - aside from
> that - problem is their component needs to be able to say "I need to
> make request to the thing that started me up in the first place". This
> is not the same semantics as a classic lookup() or get(). The issue -
> how can we convey that notion that the component is requesting a service
> from a provider that it intrisic to its own existance - that's what I'm
> trying to distinguish here - the notion of a privaliged request. Its
> priviliged if it's from sibling to parent. A shutdown request is one
> example, other examples include notification of state change, request
> for re-deployment etc.
I'm not really fond of the distinction between priviledged and
non-priviledged services...
How about then one more (optional) "lifescycle extension", e.g:
public interface Child {
void setParent(Parent parent);
}
And then this "parent" object would follow the same semantics as has
been proposed for Context:
ShutDownableParent shutDownableParent = (ShutDownableParent)
parent.getInterface(ShutDownableParent.class);
shutDownableParent.requestShutdown();
(or whatever flavour of the extended context methods you prefer)
Or am I totally wandering in the dark here...
Rgds,
Neeme
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Neeme Praks <ne...@apache.org>.
Stephen McConnell ::
> One or more component authors (like those James guys) - let's imagine
> they want to lock a component into a suiside pact and as such - their
> component needs a shutdown service. When the component hits
> requestShutdown() their component is going die - ok, that's cool -
> perhaps the component is running under the mailet API and what it really
> needs is a reserection (but that's a thread for next year) - aside from
> that - problem is their component needs to be able to say "I need to
> make request to the thing that started me up in the first place". This
> is not the same semantics as a classic lookup() or get(). The issue -
> how can we convey that notion that the component is requesting a service
> from a provider that it intrisic to its own existance - that's what I'm
> trying to distinguish here - the notion of a privaliged request. Its
> priviliged if it's from sibling to parent. A shutdown request is one
> example, other examples include notification of state change, request
> for re-deployment etc.
I'm not really fond of the distinction between priviledged and
non-priviledged services...
How about then one more (optional) "lifescycle extension", e.g:
public interface Child {
void setParent(Parent parent);
}
And then this "parent" object would follow the same semantics as has
been proposed for Context:
ShutDownableParent shutDownableParent = (ShutDownableParent)
parent.getInterface(ShutDownableParent.class);
shutDownableParent.requestShutdown();
(or whatever flavour of the extended context methods you prefer)
Or am I totally wandering in the dark here...
Rgds,
Neeme
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Adam Murdoch wrote:
>On Tue, 3 Dec 2002 02:23 pm, Stephen McConnell wrote:
>
>
>
>>>Third, how would you phrase the distinction between Context and
>>>ServiceManager? What is the key issue, in your mind, that separates
>>>items made available via Context and those made available via
>>>ServiceManager? How would you elucidate this to someone new to the
>>>Avalon Framework?
>>>
>>>
>>There are two views you can take here:
>>
>>* the state/service separation
>>* the container/peer separation
>>
>>
>
>This is the basic problem, it seems. These 2 dimensions just don't fit into
>Context.get() and ServiceManager.lookup(). How does a component writer ask
>for, say, a container-provided service, or peer-provided state? Or a
>particular service, whether container-provided or not?
>
>It would be really useful to take a step back and decide which of these
>groupings actually add value for the component writer, and are worth keeping
>distinct. Maybe both are, maybe neither are.
>
>Then, model the groupings explicitly in the framework interfaces. For
>example (and, please, they're nothing more than examples):
>
>If neither state/service or container/peer separation is useful, drop one of
>Context or ServiceManager. Change the contract of the remaining interface so
>that it delivers all resources (apart from Logger, config and params) to the
>component.
>
>If state/service separation is useful, change contracts so that, say, Context
>delivers state, and ServiceManager delivers services.
>
>If container/peer separation is useful, change contracts so that, say, Context
>delivers container provided resources and ServiceManager delivers peer
>provided resources. Probably rename ServiceManager to something more
>appropriate.
>
>If both are useful, well, there are a bucketload of ways to model that.
>Unfortunately, none (that I can think of) really appeal.
>
Hi Adam:
I'm convinced that theere is a religouse thing here - if I look at
Merlin standard edition it does provide any container based services -
nothing - all it does is run-up a bog standard Avalon component. On the
otherhand there is the Phoenix model which promotes containement
specialization at the level of context. I think there is middle ground
- but it requires an open cross-container standard solution.
>
>
>
>>My current thinking on this is that we need a separation notion -
>>*privalided" services and context dependencies. The notion of a
>>privileged service or context simply means "the container is responsible
>>for providing the service" and distinct from "the container is
>>responsible for mediating the service". If we were to provide two
>>FileService instances, one being privileged and other non-privileged -
>>the "non-privileged" notion corresponds to a peer, whereas the
>>privileged notion implies responsibilities on the container.
>>
>>
>
>So this would be a possible solution to the 'both are useful' case above.
>Presumably a component would be able to ask 'give me the non-privileged
>such-and-such service', or 'give me the privileged such-and-such state', or
>even 'give me the such-and-such service, I don't care if it's privileged or
>not'.
>
>Do you really think this is going to be useful to the component writer? Do
>you have some examples?
>
Yep.
One or more component authors (like those James guys) - let's imagine
they want to lock a component into a suiside pact and as such - their
component needs a shutdown service. When the component hits
requestShutdown() their component is going die - ok, that's cool -
perhaps the component is running under the mailet API and what it really
needs is a reserection (but that's a thread for next year) - aside from
that - problem is their component needs to be able to say "I need to
make request to the thing that started me up in the first place". This
is not the same semantics as a classic lookup() or get(). The issue -
how can we convey that notion that the component is requesting a service
from a provider that it intrisic to its own existance - that's what I'm
trying to distinguish here - the notion of a privaliged request. Its
priviliged if it's from sibling to parent. A shutdown request is one
example, other examples include notification of state change, request
for re-deployment etc.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Tue, 3 Dec 2002 02:23 pm, Stephen McConnell wrote:
> >Third, how would you phrase the distinction between Context and
> >ServiceManager? What is the key issue, in your mind, that separates
> >items made available via Context and those made available via
> >ServiceManager? How would you elucidate this to someone new to the
> >Avalon Framework?
>
> There are two views you can take here:
>
> * the state/service separation
> * the container/peer separation
This is the basic problem, it seems. These 2 dimensions just don't fit into
Context.get() and ServiceManager.lookup(). How does a component writer ask
for, say, a container-provided service, or peer-provided state? Or a
particular service, whether container-provided or not?
It would be really useful to take a step back and decide which of these
groupings actually add value for the component writer, and are worth keeping
distinct. Maybe both are, maybe neither are.
Then, model the groupings explicitly in the framework interfaces. For
example (and, please, they're nothing more than examples):
If neither state/service or container/peer separation is useful, drop one of
Context or ServiceManager. Change the contract of the remaining interface so
that it delivers all resources (apart from Logger, config and params) to the
component.
If state/service separation is useful, change contracts so that, say, Context
delivers state, and ServiceManager delivers services.
If container/peer separation is useful, change contracts so that, say, Context
delivers container provided resources and ServiceManager delivers peer
provided resources. Probably rename ServiceManager to something more
appropriate.
If both are useful, well, there are a bucketload of ways to model that.
Unfortunately, none (that I can think of) really appeal.
> My current thinking on this is that we need a separation notion -
> *privalided" services and context dependencies. The notion of a
> privileged service or context simply means "the container is responsible
> for providing the service" and distinct from "the container is
> responsible for mediating the service". If we were to provide two
> FileService instances, one being privileged and other non-privileged -
> the "non-privileged" notion corresponds to a peer, whereas the
> privileged notion implies responsibilities on the container.
So this would be a possible solution to the 'both are useful' case above.
Presumably a component would be able to ask 'give me the non-privileged
such-and-such service', or 'give me the privileged such-and-such state', or
even 'give me the such-and-such service, I don't care if it's privileged or
not'.
Do you really think this is going to be useful to the component writer? Do
you have some examples?
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Hi Peter:
There is a bunch of text below (usual long email) - but look out for the
notion of something privileged - it may be a solution to a conflicting
set of viewpoints I'm observing.
Peter M. Goldstein wrote:
>Stephen,
>
>
>>>It also seems compatible with what seems to me to be the natural
>>>separation between Contextualizable and Serviceable. Context
>>>involves data and services that are uniquely owned by the
>>>container (i.e. for Avalon Phoenix, getBaseDirectory(),
>>>requestShutdown() and for James Mailets, getPostmaster(),
>>>isLocalServer(String)). The essential distinction as I see it
>>>is that services should be user-defined and configured, while
>>>context-related items should be container-defined and not
>>>require configuration. Also, the services may include a
>>>configurable dependency chain, while Context implementations
>>>should be available before any services are loaded and should
>>>not have a configurable dependency chain.
>>>
>>>
>>>
>>Two things I want to take issue with:
>>
>>Firstly, I think the work "container" in the above context is
>>much too broad - a container deals with a lot of things - one
>>of these things is lifecycle mangement within which one aspect
>>is context - I guess in my head thare is a signifcant difference
>>between "container" (the system), "containement context" (the
>>container side context concern) and "context" (the client side
>>view of all of this). A "containment context" can be declared
>>by interface (e.g. BlockContext) - the container implemetation
>>can use this information to establish the "containerment
>>context" for the component by deploying the appropriate
>>"containment context provider".
>>
>
>I'm using container here in a very specific sense. A container is a
>piece of software that implements a particular lifecycle and the set of
>component/container contracts that go along with that lifecycle. So
>Phoenix would be an Avalon Framework container. James would be a Mailet
>API container. So, while I don't quite get all of what your saying in
>this paragraph (container side context concern?), from what I do
>understand container == system.
>
>
>>Second point - how a container establishes a particular container
>>context is a container concern - there should no constraints here
>>on how a container resolves the requirement- i.e. I don't agree
>>with the last sentence above.
>>
>
>That's fair. But I do have a couple of questions about this point of
>view.
>
>First, who establishes the dependency chain for the container context?
>Is this a user configurable feature, machine-configurable, or either in
>your view?
>
The component type declares context criteria. This covers two things (a)
the context interface that is expected, and (b) the key and class of
each context entry. From a container implementation point of view can
look at the context interface declaration as statement of a dependency
that component has, that needs to be mediated by the container. A
container can several different strategies to resolve this:
1. Require static (or dynamic) configuration of a context
provider as part of the container deployment
configuration.
2. Require static (or dynamic) configuration of a context
provider as part of the component deployment
configuration.
3. Separate the concerns of context provisioning from
the concern of context management, and then consider
the context manager or managers as services that are
dynamically wired into a contextaulization service
(where the contextualization service is just one
part of the container architecture).
Option 3 is my favorite because it means that I assembly my container
for the containment scope I interested in (Servlet, Avalon, Mailet, ORB
Initializer, etc.). We already know that (3) is possible based on the
Merlin/Fortress collaboration on extensions - the result of that is the
automatic discovery and establishment of lifecycle extension providers
for a component. Doing the same thing for context requires similar
specification of a standard context manager interface, and corresponding
meta in a manager declaring the context class or classes it supports.
>
>Second, does the dependency chain for the context have to be complete
>(specifically every element of the context is completely available) by
>the time the first user defined service is loaded? To me, this seems
>like a necessary requirement, but I'd like to hear other opinions.
>
It is a necessary requirement - and its not an issue - the client sees
some instance in response to a get( key ). The client does not need to
be concerned with the resolution process. An implementation of Context
could be holding references to a bunch of different context managers and
mediating requests.
>Third, how would you phrase the distinction between Context and
>ServiceManager? What is the key issue, in your mind, that separates
>items made available via Context and those made available via
>ServiceManager? How would you elucidate this to someone new to the
>Avalon Framework?
>
There are two views you can take here:
* the state/service separation
* the container/peer separation
On state/service view of the world, context entries are little thing
like files, timestamps, a meta-data instance, classloaders, etc. These
are typically used as arguments to internal operations within your
component implementation. On the other hand, service are more heavy
weight, you have to declare information about the fact that an component
class provides a particular service, you have notion of a service
version, to provide the service other component have to declare
dependencies. That overhead is the barrier from jumping from
"context-driven" to "service-driven". But the other side of the equation
is that service driven means that a good container will be able to do an
enormous amount of work for you - and the end result is that your code
shrinks, you establish well defined blocks of functionality with clear
specification of dependencies and good support for loose-coupling.
The container/peer view is complicated by a couple of things. If you
consider that context is aligned with a container, and that service is
aligned with peers of the component - you introduce a very different
idea of the responsibilities that these contract represent to a
component. I believe that the distinction between context and service
interfaces properly addresses the distinction between state and service,
but, I recognize that a strict line is complicated when we look at
context as the point of communication between component and its
container (as opposed to the notion that the SM interface represent peer
communication).
My current thinking on this is that we need a separation notion -
*privalided" services and context dependencies. The notion of a
privileged service or context simply means "the container is responsible
for providing the service" and distinct from "the container is
responsible for mediating the service". If we were to provide two
FileService instances, one being privileged and other non-privileged -
the "non-privileged" notion corresponds to a peer, whereas the
privileged notion implies responsibilities on the container.
The notion of *privileged* context entries and services would enable
elimination of the association of context with container, and IMHO, that
would be a very good thing.
>
>This last point is what most confuses me about loosening the restriction
>with which you take issue. I find the line grows blurry unless this is
>held. Do you have any explicit examples of a container-owned item that
>would require a configurable dependency chain? I haven't been able to
>come up with one that sounds reasonable.
>
Consider "urn:avalon:work", a java.io.File. This is an example where
context is best because you don't want to pollute your component with a
particular file service when all you is the state. However, the
"component-entry-provider-implementation-component" could well be a
service. This is also similar to a context entry containing the key
chain of the invoking principal - the context interface lets us get the
key chain value without concern for the service hat establishes the
value (which may be interceptor, backed by a vault service, backed by a
database service, etc).
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Stephen,
> >It also seems compatible with what seems to me to be the natural
> >separation between Contextualizable and Serviceable. Context
involves
> >data and services that are uniquely owned by the container (i.e. for
> >Avalon Phoenix, getBaseDirectory(), requestShutdown() and for James
> >Mailets, getPostmaster(), isLocalServer(String)). The essential
> >distinction as I see it is that services should be user-defined and
> >configured, while context-related items should be container-defined
and
> >not require configuration. Also, the services may include a
> >configurable dependency chain, while Context implementations should
be
> >available before any services are loaded and should not have a
> >configurable dependency chain.
> >
> >
>
> Two things I want to take issue with:
>
> Firstly, I think the work "container" in the above context is much too
> broad - a container deals with a lot of things - one of these things
is
> lifecycle mangement within which one aspect is context - I guess in my
> head thare is a signifcant difference between "container" (the
system),
> "containement context" (the container side context concern) and
> "context" (the client side view of all of this). A "containment
> context" can be declared by interface (e.g. BlockContext) - the
> container implemetation can use this information to establish the
> "containerment context" for the component by deploying the appropriate
> "containment context provider".
I'm using container here in a very specific sense. A container is a
piece of software that implements a particular lifecycle and the set of
component/container contracts that go along with that lifecycle. So
Phoenix would be an Avalon Framework container. James would be a Mailet
API container. So, while I don't quite get all of what your saying in
this paragraph (container side context concern?), from what I do
understand container == system.
> Second point - how a container establishes a particular container
> context is a container concern - there should no constraints here on
how
> a container resolves the requirement- i.e. I don't agree with the last
> sentence above.
That's fair. But I do have a couple of questions about this point of
view.
First, who establishes the dependency chain for the container context?
Is this a user configurable feature, machine-configurable, or either in
your view?
Second, does the dependency chain for the context have to be complete
(specifically every element of the context is completely available) by
the time the first user defined service is loaded? To me, this seems
like a necessary requirement, but I'd like to hear other opinions.
Third, how would you phrase the distinction between Context and
ServiceManager? What is the key issue, in your mind, that separates
items made available via Context and those made available via
ServiceManager? How would you elucidate this to someone new to the
Avalon Framework?
This last point is what most confuses me about loosening the restriction
with which you take issue. I find the line grows blurry unless this is
held. Do you have any explicit examples of a container-owned item that
would require a configurable dependency chain? I haven't been able to
come up with one that sounds reasonable.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Peter M. Goldstein wrote:
>All,
>
><minor-rant>
>
>
<snip>
></minor-rant>
>
>Might I kindly suggest that when you want to collect information about
>another project, you query the dev list for that project? Idle
>speculation by the Avalon developers is hardly profitable and is not
>really an effective way of evaluating customer needs. See my comments
>on the current discussion below.
>
>
>
>>>>I'm not sure that this is a great example. The MailetContext shares
>>>>
>>>>
>>little
>>
>>
>>>>in common with the Avalon Context, other than a name. It's the way
>>>>
>>>>
>that
>
>
>>a
>>
>>
>>>>MailetContainer (potentially very different from an Avalon
>>>>
>>>>
>Container)
>
>
>>>>provides contextual information to a Mailet, which is a
>>>>
>>>>
>domain-specific
>
>
>>>>component running in a well-defined environment.
>>>>
>>>>
>>>That pretty much defines the purpose of Avalons context ;)
>>>
>>>ie Take the ServletContext and remove configuration mechanisms (or
>>>Configuration/Parameters in Avaloon terms) and service provision
>>>
>>>
>>mechanisms
>>
>>
>>>(or ServiceManager/ComponentManager in Avalon terms) and you are
>>>
>>>
>left
>
>
>>with
>>
>>
>>>what should remain in the context.
>>>
>>>
>>Exactly what I thought. I preferred to use this Context instead of the
>>ServletContext because it's about something that uses Avalon; the fact
>>that it does not extend the Avalon Context though is another
>>
>>
>indication
>
>
>>of something that's not really ok.
>>
>>Leo Simons wrote:
>> > Apples 'n pears if you ask me.
>> >
>> > The JAMES MailetContext is not intimately related to the
>> > avalon Context
>> > at all. The MailetContext is used in a well-defined problem domain
>> > (e-mail; mailets), the avalon context is way more generic.
>>
>>So, how do we put this?
>>
>>It's evident to me that there is some kind of miosmatch here between
>>avalon devs them selves, and also avalon devs and users.
>>
>>
>
>This dialogue is not quite right. Let's clarify a few things:
>
>Here is the one and only way that the James source code currently uses
>the Avalon context. This is to obtain the application base directory,
>which is used in configuration URL resolution. This critical usage
>isn't even mentioned in the above discussion. But it appears to be
>consistent with all the divergent views of the Context, as the base
>directory is a containter-provided data value that is made available to
>the components.
>
>There is an additional location where the Phoenix-specific BlockContext
>should be used instead of the current code as written. In the
>RemoteManager code James shuts down the system by directly calling
>System.exit(0). That's not exactly a well behaved component, as it
>doesn't give the container a proper opportunity for cleanup.
>
>Instead, this code should call the requestShutdown() method of
>BlockContext for a clean shutdown. Of course, this would further couple
>us to Phoenix. And, from the recent discussion on the list, there
>appears to be confusion as to whether this sort of method (side-effect,
>no data) belongs in the Context. In any case, what James does is wrong,
>but it's not clear to me exactly what would be the correct thing to do,
>or even if Avalon has any ability to support the right thing in a way
>that doesn't lock us to one container.
>
>Now, on to the MailetContext. This has zero, zip, nada to do with the
>Avalon Context, Paul's desires notwithstanding. In fact, some
>discussions of the proper behavior of the Avalon Context (as a read-only
>repository of container-provided data) clearly don't seem to support the
>idea of implementing the MailetContext as an extension of Context.
>
>The MailetContext is primarily used by Mailets to execute actions (i.e.
>bouncing emails, placing an email on the processing queue) or to check
>values (i.e. checking a server name to see if it's local), neither of
>which seem to jibe with the read-only data container model espoused by
>some.
>
>Note that the current version of the Mailet API shouldn't be taken as
>the final word. Explicitly slated for the next revision of James is a
>redesign of the Mailet API. Some James developers (notably me) will be
>pushing to remove at least some of the above from the MailetContext
>(i.e. bounce logic). And we may find it desirable to add additional
>functionality to the James-provided Mailet context. But this discussion
>still lies in the future.
>
>As a prelude to future James requirements, I would say that the most
>important idea remains the contract(s) provided by a Context. Once
>again, it is critical that a developer writing a component or set of
>components that use Avalon be able to determine what contracts and
>associated interfaces are provided by a container in a
>container-independent way. Moreover some subset set of those
>contracts/interfaces must be container-independent if it is going to be
>possible to write components that are non-trivially
>container-independent. These are the essential points.
>
>
+1
>As far as the counter-argument that "containers have nothing in common",
>all I can say is that seems highly unlikely to me. If a container
>exposes the ability to address files in the file system, a unified
>interface seems possible. A container-independent interface for
>exposing container identity information (i.e. name, version string)
>seems easily within reach. A common interface that allows the component
>to request component and/or container shutdown from the container also
>seems feasible. Not all features need to be encapsulated in common
>interfaces, but some should. Honestly, these three would satisfy James
>entirely. And make it much more container portable. I think more
>attention is required on this front.
>
>
+1
>On a related note, I'm also going to say here that I really like the
>version of the Context logic that Noel was pushing, where the Context
>lookup involves passing in a contract interface to the lookup and
>retrieving a class that implements that interface. It seems an
>effective and extensible way to provide container-defined services.
>
>It also seems compatible with what seems to me to be the natural
>separation between Contextualizable and Serviceable. Context involves
>data and services that are uniquely owned by the container (i.e. for
>Avalon Phoenix, getBaseDirectory(), requestShutdown() and for James
>Mailets, getPostmaster(), isLocalServer(String)). The essential
>distinction as I see it is that services should be user-defined and
>configured, while context-related items should be container-defined and
>not require configuration. Also, the services may include a
>configurable dependency chain, while Context implementations should be
>available before any services are loaded and should not have a
>configurable dependency chain.
>
>
Two things I want to take issue with:
Firstly, I think the work "container" in the above context is much too
broad - a container deals with a lot of things - one of these things is
lifecycle mangement within which one aspect is context - I guess in my
head thare is a signifcant difference between "container" (the system),
"containement context" (the container side context concern) and
"context" (the client side view of all of this). A "containment
context" can be declared by interface (e.g. BlockContext) - the
container implemetation can use this information to establish the
"containerment context" for the component by deploying the appropriate
"containment context provider".
Second point - how a container establishes a particular container
context is a container concern - there should no constraints here on how
a container resolves the requirement- i.e. I don't agree with the last
sentence above.
>This distinction can be applied to any container/component model, not
>just Avalon. And it also demonstrates why nested containers should not
>necessarily simply pass through a Context from one level to another.
>
Agreed.
>The above definition is tightly tied to the nature of the container and
>the API it supports. Hence what is in the Context in a nested container
>might not naturally fall into the Context of its parent container.
>
>I will be raising this design suggestion as part of the discussion over
>the next revision of the Mailet API.
>
>
Looking forward to it.
Cheers, Steve.
>--Peter
>
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 21:38, Nicola Ken Barozzi wrote:
> The Context is an interface with a method. Then we must use *that*
> method.
We *can* use that method.
> Casting makes it simply another servicemanager, which really
> confuses, and makes boundaries very blurred.
Casting differentiatiates it from ServiceManager because in 99% of cases
ServiceManager is not cast to anything (though I have seen three containers
where it is cast and that is to deal with different service provision
models).
--
Cheers,
Peter Donald
"Artists can color the sky red because they know it's blue. Those of us who
aren't artists must color things the way they really are or people might
think we're stupid." -- Jules Feiffer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 21:38, Nicola Ken Barozzi wrote:
> The Context is an interface with a method. Then we must use *that*
> method.
We *can* use that method.
> Casting makes it simply another servicemanager, which really
> confuses, and makes boundaries very blurred.
Casting differentiatiates it from ServiceManager because in 99% of cases
ServiceManager is not cast to anything (though I have seen three containers
where it is cast and that is to deal with different service provision
models).
--
Cheers,
Peter Donald
"Artists can color the sky red because they know it's blue. Those of us who
aren't artists must color things the way they really are or people might
think we're stupid." -- Jules Feiffer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 21:38, Nicola Ken Barozzi wrote:
> The Context is an interface with a method. Then we must use *that*
> method.
We *can* use that method.
> Casting makes it simply another servicemanager, which really
> confuses, and makes boundaries very blurred.
Casting differentiatiates it from ServiceManager because in 99% of cases
ServiceManager is not cast to anything (though I have seen three containers
where it is cast and that is to deal with different service provision
models).
--
Cheers,
Peter Donald
"Artists can color the sky red because they know it's blue. Those of us who
aren't artists must color things the way they really are or people might
think we're stupid." -- Jules Feiffer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 5 Dec 2002 12:08, Adam Murdoch wrote:
> Is this such a problem now that all the containers support auto-assembly,
> where the assembler's view goes from 'container-supplied vs
> application-supplied' to 'automatically-supplied vs explicitly-supplied'?
It is possible but I prefer to make things simpler for users. Requiring tools
because the underlying tech is not as simple as possible (and no simpler)
makes me go ick. Look to EJB to see a technology where you need oodles of
configurable tools ala EJBGen/XDoclet to just do basic things. And even then
it is a quagmire of complexity.
> > If the services are things that the container provides to the component
> > as part of it's environment then the user perceives them as different to
> > services that the component uses. I can't think of one API that actually
> > merges the two concepts.
>
> Here's a couple:
> * EJBs and DataSources are both delivered via JNDI.
They are both services.
> * Myrmidon's TaskContext.getService() provides access to both container
> services and antlib-contributed services.
But Myrmidon did not allow asssemblers to map in services to tasks. Tasks just
access an existing set of services and as far as the task is concerned they
are all container provided.
The fact that a task could modify the set of container tasks for other tasks
not withstanding ;)
> Don't forget that many domain-specific APIs (mailets, for example) don't
> provide *any* access to arbitrary services, and so can't go merging them
> with container provided services.
EJBs/Servlets do. They both provide access to arbitary resources via JNDI.
They also access container-specific services via context... sorta.
Actually EJBs (and Servlets?) actually provide most container-specific
services via context except for transactions in which they expose container
specific UserTransaction (or whatyever it is called) in JNDI.
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "The whole problem with the world is that fools and |
| fanatics are always so certain of themselves, but |
| wiser people so full of doubts." - Bertand Russle |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Wed, 4 Dec 2002 08:56 pm, Peter Donald wrote:
> On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote:
> > These are useful things, no question. Components need some way to get at
> > data and services that are supplied by the container. Again, why do they
> > care that a particular service or piece of data was supplied by the
> > container or a peer?
>
> Components don't care what the origins of the resource are - all of it is
> potentially "contextualized" on a per component basis and all generally has
> certain criteria to adhere to but beyond that it is about it. The different
> resources are separated out for the sake of humans and no other reason.
>
> Context is separated from ServiceManager because humans see them as
> different things - especially during the assembly process.
Good point.
Is this such a problem now that all the containers support auto-assembly,
where the assembler's view goes from 'container-supplied vs
application-supplied' to 'automatically-supplied vs explicitly-supplied'?
It strikes me as unfortunate that the assembler's world view, being largely
container-specific, should force an abstraction that means nothing to the
component onto the component writer's world view. (Assuming that it *is*
meaningless, which is what we're trying to figure out). An artifical
abstraction is going to cause 'cognitive dissonance' of it's own. Consider
the poor assembler that has to port or maintain an application across a bunch
of containers, where services are container supplied in some containers, and
application supplied in others. Or a collaboration between container and
application in others.
> > Yes, I know that they're "different logical things". But so are, say,
> > authentication services and persistence services. We don't use different
> > mechanisms to deliver those services to components. It would be
> > pointless to do so:
>
> I disagree. If persistence were provided to the component and the component
> was effectively made to be an OJB object or something like that then we
> would likely provide persistence/transaction capabilities in a very
> different manner. Most likely via some transparent EJB-like manner.
>
> In the same way if AAA services were provided to a component as part of
> it's environment then it would likely also follow an EJB/Servlet style
> setup where the container does it via interception and allows components to
> access it programatically via something like
>
> getServletContext().isPrincipleInRole( String role, Principle p );
> getSessionContext().isCallerInRole( String role );
> (or insert real examples here or JAAS).
Of course. I should have qualified my comment a little better. What we're
talking about is how to slice and dice the 'left-overs': The resources that
a component needs, which are not explicitly modelled by framework. So, we're
not talking about a logger, or configuration, or parameters. Nor are we
talking about transparent services that just happen. Nor would we be talking
about AAA services modelled as part of framework - they wouldn't be
'left-overs' any more.
However, AAA services that aren't modelled as part of framework are in scope.
But we're back to the old question: Why is this:
AuthenticationService = (AuthenticationService)context;
better than this:
AuthenticationService = (AuthenticationService)serviceManager.lookup(
AuthenticationService.ROLE );
> If the services are things that the container provides to the component as
> part of it's environment then the user perceives them as different to
> services that the component uses. I can't think of one API that actually
> merges the two concepts.
Here's a couple:
* EJBs and DataSources are both delivered via JNDI.
* Myrmidon's TaskContext.getService() provides access to both container
services and antlib-contributed services.
Don't forget that many domain-specific APIs (mailets, for example) don't
provide *any* access to arbitrary services, and so can't go merging them with
container provided services.
Honestly, I don't really put much credence in the 'no-one else does it'
argument (except to ask why not?). I can't think of another API that splits
resource delivery over multiple lifecycle methods, but, well ...
> > 5. Who cares? Why are you bothering me with these questions?
> >
> :)
Not too late to vote for 5 :)
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Sun, 8 Dec 2002 13:56, Adam Murdoch wrote:
> By "common" services, I don't mean mandatory services that all containers
> must provide (of which there are probably none, as you say). What I mean
> is general-purpose services that are optional for a container to provide.
>
> Some possibilities (random thoughts):
> - Request that this component be stopped.
> - Create a proxy for this component, to hand off to other classes.
> - Locate a named classloader, etc.
> - For containers that support the notion of an application:
> - Locate an application resource.
> - Get information about the application (name, work-dir, etc).
> - Stop or restart the application.
You may want to check out the other service frameworks (HPs CSF, OSGi
specifications, etc). Because the above are relatively widely accepted as
features of service frameworks in one form or another. The more general form
would be something like;
- allow a component to set it's own state (which may result in component
shutdown or suspending or deactivation or ...).
- create proxies for this component and other object when passing to other
clients. The proxy may be client-specifc. ie If passing to remote client
would create a remote proxy while if passing to local client may create a
local proxy.
- access metadata about current components type
- access metadata about current components instance
- access metadata about current partition/application instance
- access metadata about deployment unit that currently in (ie .sar/.war file)
- access resources from deployment unit that currently in
(ie getResourceAsStream)
> - Add or remove other components. Or sub-components.
> - Provide config for other components.
> - Provide data for other components.
> - Provide lifecycle extensions for other components.
> - Etc.
The above are less widely used and fairly container specific. But most
containsers that support this do it via a directory ala JNDI. A lot of what
you are talking about (management) is ususally done via another management
system that is othogonal to component concerns.
> Do you think these kinds of things would be good to define in framework?
eventually. Unfortunately no current Avalon container is comprehensive enough
to define either set. Until we have seen the interface in action I don't
think that there is any reason to commit to one at the framework level.
> Ignore how they might be delivered to components, and how components
> declare dependencies, for the time being.
>
> > > Fair enough. Can you expand on this? How do you view MailetContext
> > > and ServletContext and EntityContext and friends in relation to Context
> > > and framework?
> >
> > XContext == Logger + Context + ServiceManager + Configuration/Parameters
>
> So is Context all the left-overs when Logger, ServiceManager, Configuration
> and Parameters have been extracted from XContext?
mostly.
> Or is it something more significant?
It also contains "runtime" values - ie stuff that the user doesn't provide the
component (either through configuration or assembly processes).
> How do things like ServletConfig, or MailetConfig,
Configuration/Parameters for component accessed via the XContext.
> or JNDI fit in?
JNDI is slightly different in that it is just an access API and different
frameworks use it for different things. Many use them as just a
ServiceManager but some also stuff in Avalon Context and Configuration stuff.
> I
> assume they are part of a larger "XContext".
largely.
--
Cheers,
Peter Donald
"Man's mind stretched to a new idea never goes back to its original
dimensions." -Oliver Wendell Holmes
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > 1. (String)context.get( "name.key" );
> > 2. ((NameContext)context).getName();
> In what way does (2) have stronger coupling? Since there is logical
> equivalence between having a "name.key" entry and a NameContext
> interface:
There are two flaws with the second approach. The first is that in the
second case, you force me to have a upon a NameContext, which I couldn't
care less about, in the case of that example.
More importantly, the second example makes a mistake of tying IMPLEMENTATION
of the Context into the INTERFACE. I have no problem with:
String s = ((T)context.get("urn:foo:bar")).f()
where we acquire a reference to a object of type T from the context, convert
the reference, and invoke the operation. In that case, even if the context
returns itself, we have decoupled the caller from knowing that information.
We have eliminated an implementation dependency.
Is this clearer? The second issue is the far more serious one.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
>
> > 1. (String)context.get( "name.key" );
> > 2. ((NameContext)context).getName();
>
> As I believe I have repeatedly pointed out, these are not
> equivalent.
>
> This extends to objects that provide services, not just
> simple data types. IMO, the access mechanism provided to
> components should be DECOUPLING from implementations, not
> COUPLING via inheritance.
In what way does (2) have stronger coupling? Since there is logical
equivalence between having a "name.key" entry and a NameContext
interface:
Context has a "name.key" entry <-> Context implements NameContext
There is no stronger coupling, as I see it. I could even argue that (2)
has less coupling, as you access items via type-safe accessors instead
of a type-unsafe map, giving (2) two advantages:
+ return type is checked by compiler. (The (String) cast can't)
+ name of method is checked by compiler. ("name.key" isn't)
Part of this effort is to see if it is possible to get away from the
hyper-abstract interface Context interface we have now. After all,
since we don't design our objects like this:
public class MyClass {
public Object performOperation (Object op) { ... };
}
There is no need to have a:
public interface Context {
public Object get (String);
}
for bean-like objects.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by "Noel J. Bergman" <no...@devtech.com>.
> In a word no. Interfaces that define methods to get at data are just
> syntactic sugar. ie Whats the difference between
>
> 1. (String)context.get( "name.key" );
> 2. ((NameContext)context).getName();
As I believe I have repeatedly pointed out, these are not equivalent. In
the latter case, the context is cast to a particular type, which means that
it must have an an inheritance relationship with the desired type. In the
latter case, the context simply needs to have a reference to a suitable
object.
This extends to objects that provide services, not just simple data types.
IMO, the access mechanism provided to components should be DECOUPLING from
implementations, not COUPLING via inheritance.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Sun, 8 Dec 2002 11:51 am, Peter Donald wrote:
> > Do you think it would be useful for framwork to include a set of
> > container-independent interfaces that cover some of the common ways that
> > a component interacts with the container?
>
> In a word no. Interfaces that define methods to get at data are just
> syntactic sugar. ie Whats the difference between
>
> 1. (String)context.get( "name.key" );
> 2. ((NameContext)context).getName();
>
> and which would you prefer to use? (1) is easier to use (for both component
> and container writers) and is more lightly coupled. So why do we need (2) ?
I agree, if it's just data we're talking about. However ...
> If rather than data you are talking about services then I am not sure there
> is any set of common services.
I was wondering about services. In particular, services where the component
requests that the container do something (where that "something" might, I
guess, include handing over some data). That is, services that represent
*the container itself*.
By "common" services, I don't mean mandatory services that all containers
must provide (of which there are probably none, as you say). What I mean is
general-purpose services that are optional for a container to provide.
Some possibilities (random thoughts):
- Request that this component be stopped.
- Create a proxy for this component, to hand off to other classes.
- Locate a named classloader, etc.
- For containers that support the notion of an application:
- Locate an application resource.
- Get information about the application (name, work-dir, etc).
- Stop or restart the application.
- Add or remove other components. Or sub-components.
- Provide config for other components.
- Provide data for other components.
- Provide lifecycle extensions for other components.
- Etc.
Do you think these kinds of things would be good to define in framework?
Ignore how they might be delivered to components, and how components declare
dependencies, for the time being.
> > Fair enough. Can you expand on this? How do you view MailetContext and
> > ServletContext and EntityContext and friends in relation to Context and
> > framework?
>
> XContext == Logger + Context + ServiceManager + Configuration/Parameters
So is Context all the left-overs when Logger, ServiceManager, Configuration
and Parameters have been extracted from XContext? Or is it something more
significant? Or both?
How do things like ServletConfig, or MailetConfig, or JNDI fit in? I assume
they are part of a larger "XContext".
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Sun, 8 Dec 2002 11:13, Adam Murdoch wrote:
> On Thu, 5 Dec 2002 09:38 pm, Peter Donald wrote:
> > On Thu, 5 Dec 2002 13:48, Adam Murdoch wrote:
> > > One problem is that it doesn't take long before you hit avalon's
> > > enormous scope. It's difficult (impossible?) to come up with a useful
> > > set of mandatory services that will span this scope. Even the
> > > canonical getHomeDir() example is a problem for lightweight containers
> > > with no such concept, or tightly sandboxed containers that don't (or
> > > can't) allow file system access.
> >
> > The one common one is getName().
>
> Do you think it would be useful for framwork to include a set of
> container-independent interfaces that cover some of the common ways that a
> component interacts with the container?
In a word no. Interfaces that define methods to get at data are just syntactic
sugar. ie Whats the difference between
1. (String)context.get( "name.key" );
2. ((NameContext)context).getName();
and which would you prefer to use? (1) is easier to use (for both component
and container writers) and is more lightly coupled. So why do we need (2) ?
If rather than data you are talking about services then I am not sure there is
any set of common services. For a list of common keys for data see;
http://jakarta.apache.org/avalon/excalibur/info/context.html
though it is not completely up to date. This
> Fair enough. Can you expand on this? How do you view MailetContext and
> ServletContext and EntityContext and friends in relation to Context and
> framework?
XContext == Logger + Context + ServiceManager + Configuration/Parameters
--
Cheers,
Peter Donald
------------------------------------------------
| We shall not cease from exploration, and the |
| end of all our exploring will be to arrive |
| where we started and know the place for the |
| first time -- T.S. Eliot |
------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Thu, 5 Dec 2002 09:38 pm, Peter Donald wrote:
> On Thu, 5 Dec 2002 13:48, Adam Murdoch wrote:
> > One problem is that it doesn't take long before you hit avalon's enormous
> > scope. It's difficult (impossible?) to come up with a useful set of
> > mandatory services that will span this scope. Even the canonical
> > getHomeDir() example is a problem for lightweight containers with no such
> > concept, or tightly sandboxed containers that don't (or can't) allow file
> > system access.
>
> The one common one is getName().
Do you think it would be useful for framwork to include a set of
container-independent interfaces that cover some of the common ways that a
component interacts with the container?
They wouldn't cover every possible interaction - that can remain
container-dependent - but just the usual cases. Something more concrete than
get().
> > Honestly, MailetContext and ServletContext were always just noise.
> > There's nothing in common between these and framework's Context except
> > the word 'Context' in their names, and the fact that they each deliver a
> > subset of the resources used by components.
>
> I dunno. They are precisely the sort of things I draw on when thinking
> about it :)
Fair enough. Can you expand on this? How do you view MailetContext and
ServletContext and EntityContext and friends in relation to Context and
framework?
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Thu, 5 Dec 2002 13:48, Adam Murdoch wrote:
>
[...]
>>Honestly, MailetContext and ServletContext were always just noise. There's
>>nothing in common between these and framework's Context except the word
>>'Context' in their names, and the fact that they each deliver a subset of
>>the resources used by components.
>
> I dunno. They are precisely the sort of things I draw on when thinking about
> it :)
I see an interface called Context, with a method that makes me take an
Object by giving a key.
When I think about a context in general, as I have explained in a
previous mail, I have in mind threadContexts (*).
"Because Interceptors are stateless, information about the state of the
call then must be added to the context of the calling thread. So all of
the information is piggybacked on the thread context, and each
Interceptor can read, add, change, or remove data from the thread
context. Figure 1 is a simple diagram of an Interceptor Stack embedded
in a container like, in JBoss, the EJB Container."
http://www.onjava.com/onjava/2002/07/24/graphics/jboss_image002.gif
Actually these per-thread contexts are no different from global context
for the user, thus I define them simply as contexts.
I agree that this notion is not exactly that of the current Context
interface, since it has the notion of putting stuff on the Context,
which is not present.
(*)http://www.onjava.com/pub/a/onjava/2002/07/24/jboss_stack.html
--
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: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 5 Dec 2002 13:48, Adam Murdoch wrote:
> One problem is that it doesn't take long before you hit avalon's enormous
> scope. It's difficult (impossible?) to come up with a useful set of
> mandatory services that will span this scope. Even the canonical
> getHomeDir() example is a problem for lightweight containers with no such
> concept, or tightly sandboxed containers that don't (or can't) allow file
> system access.
The one common one is getName().
> Honestly, MailetContext and ServletContext were always just noise. There's
> nothing in common between these and framework's Context except the word
> 'Context' in their names, and the fact that they each deliver a subset of
> the resources used by components.
I dunno. They are precisely the sort of things I draw on when thinking about
it :)
--
Cheers,
Peter Donald
------------------------------------------------
"No. Try not. Do. Or do not. There is no try."
-- Yoda
------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Thu, 5 Dec 2002 06:43 am, Darrell DeBoer wrote:
> This example is giving me a few troubles:
> > > getServletContext().isPrincipleInRole( String role, Principle p );
> > > getSessionContext().isCallerInRole( String role );
>
> These are container provided services, and it would "feel" right that they
> would be split out from the provision of other services. But then you
> realise: - these interfaces are defined as part of a specification. The
> container can't choose whether or not to provides these things, they are
> required. And the container can't arbitrarily provide new stuff in this
> way, since then a component would become non-portable.
>
> So I can't see the argument for the Container-provided/Peer-provided
> divide. But I can see an argument for a logical and code separation of
> services defined in the spec (and therefore part of the Avalon-Framework
> contracts), and other services (both container and peer).
This is pretty much my view, too. To separate out resources that are modelled
in framework is useful. To separate out resources that are not modelled in
framework is pointless.
> At the moment, I don't think any such services exist. Maybe we should come
> up with some, and *maybe* they should be provided in a separate mechanism
> to regular services. But since they are part of the spec, components won't
> need to "declare" the context they require
It would be really handy to have some framework-level cross-container services
that allow better interaction with the container. This is possibly the
missing piece that we're struggling with.
One problem is that it doesn't take long before you hit avalon's enormous
scope. It's difficult (impossible?) to come up with a useful set of
mandatory services that will span this scope. Even the canonical
getHomeDir() example is a problem for lightweight containers with no such
concept, or tightly sandboxed containers that don't (or can't) allow file
system access.
So whatever we come up with will have to be optional. And ideally more
strongly-typed than:
(ApplicationDeployer)context;
or
(ApplicationDeployer)context.get( ApplicationDeployer.ROLE );
or
(ApplicationDeployer)serviceManager.lookup( ApplicationDeployer.ROLE );
There are heaps of options:
(note: below, 'these services' means 'those services defined by framework,
which the container supports', not 'any arbitrary services'):
1. Don't bother.
2. Deliver these services via Context.get().
3. Deliver these services via ServiceManager.lookup().
4. Deliver these services via a ServiceManager equivalent and a new lifecycle
stage. Eg the ContainerServiceable that Gary suggested.
5. Deliver each of these services via a new lifecycle stage. Eg
DeployerEnabled.deloyerEnable( Deployer ), ShutdownEnabled.shutdownEnable(
ShutdownRequester ), etc.
6. Deliver each of these services via a typed getter on Context. Eg
Context.getApplicationDeployer(), Context.getShutdownRequester().
7. Any of the above, on a per-service basis.
Again, I'm only talking about services that are defined by framework, not
container-specific services.
> things like MailetContext
> and ServletContext are removed from these arguments, since they aren't part
> of the Avalon-Framework contracts.
Honestly, MailetContext and ServletContext were always just noise. There's
nothing in common between these and framework's Context except the word
'Context' in their names, and the fact that they each deliver a subset of the
resources used by components.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations?
Posted by Stephen McConnell <mc...@apache.org>.
Adam Murdoch wrote:
>Hi,
>
>It would be really useful to take a step back, and first figure out *what* a
>Context is, and *what* a ServiceManager. Let's leave figuring out *how* to
>populate them until we know what they are. We don't even know whether
>they're distinct things yet.
>
>
If you take out the container constraint of "what is a context supplied
object" you left with lifecycle aspects as the only distinguishing feature.
>For example, the only real answer to the 'what is the difference between a
>context and a service manager?' question I've had so far is 'they're
>different because people think of them as different things'. Which is fine,
>except no-one seems to be able to explain what the difference is, and why
>that difference is important enough to model in framework.
>
>This is the crux of the matter. Not whether it's *possible* to make the
>distinction, but whether it is *useful* to make the distinction. Maybe it
>is, maybe it isn't. (Hint: the distinction must be meaningful across *all*
>containers. It can't be "well, it means this sometimes, and it means that at
>other times").
>
>I also wonder how much of "people think of them as different things" is due to
>the fact that framework has a thing called "Context" and another thing called
>"ServiceManager", and "well .. um .. of course they're different things,
>otherwise they wouldn't be there". In other words, are we trying to invent a
>meaning for Context because Context currently happens to be part of
>framework?
>
>
I can't argue against this!
>On Sun, 8 Dec 2002 05:42 am, Stephen McConnell wrote:
>
>
>
>>A second interesting point is that the component author has 100% control
>>over which services and locators are mapped to the context abstraction
>>as opposed to the service abstraction.
>>
>>
>
>and later:
>
>
>
>> From here, the differentiating factor between contextualization and
>>services phases is reduced to the ordered sequence in the lifecycle.
>>
>>
>
>But service() is called immediately after contextualize(). How is it useful
>for the component writer to be able to map resources between these methods
>when they're called one-after-the-other? Why bother?
>
Because I feel real comfortable with the destinction - and the
distinction I'm applying is data centric versus service centric - and
yes their both objects - but that's not important - what's important is
that it feels right.
:-)
>Surely it would be
>easier for everyone involved to simply collapse those 2 methods?
>
>
Aside from feeling good, this gets into the "Recontextualizable" area.
In just about all of the components I work with, the context values
tend to be the state that the components uses relative to a set of
underlying services, combined with its own logic.
I have several specific instances of components that could benefit
greatly by container supplied recontextualization. The service mapping
remains the same - only the data supplied to the component changes.
Consider the following sequence:
-> contextualize
-> service
-> initialize
-> start
... stuff happens
-> suspend
-> recontextualize
-> resume
... stuff happens
-> stop
-> dispose
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations?
Posted by Adam Murdoch <ad...@apache.org>.
Hi,
It would be really useful to take a step back, and first figure out *what* a
Context is, and *what* a ServiceManager. Let's leave figuring out *how* to
populate them until we know what they are. We don't even know whether
they're distinct things yet.
For example, the only real answer to the 'what is the difference between a
context and a service manager?' question I've had so far is 'they're
different because people think of them as different things'. Which is fine,
except no-one seems to be able to explain what the difference is, and why
that difference is important enough to model in framework.
This is the crux of the matter. Not whether it's *possible* to make the
distinction, but whether it is *useful* to make the distinction. Maybe it
is, maybe it isn't. (Hint: the distinction must be meaningful across *all*
containers. It can't be "well, it means this sometimes, and it means that at
other times").
I also wonder how much of "people think of them as different things" is due to
the fact that framework has a thing called "Context" and another thing called
"ServiceManager", and "well .. um .. of course they're different things,
otherwise they wouldn't be there". In other words, are we trying to invent a
meaning for Context because Context currently happens to be part of
framework?
On Sun, 8 Dec 2002 05:42 am, Stephen McConnell wrote:
> A second interesting point is that the component author has 100% control
> over which services and locators are mapped to the context abstraction
> as opposed to the service abstraction.
and later:
> From here, the differentiating factor between contextualization and
> services phases is reduced to the ordered sequence in the lifecycle.
But service() is called immediately after contextualize(). How is it useful
for the component writer to be able to map resources between these methods
when they're called one-after-the-other? Why bother? Surely it would be
easier for everyone involved to simply collapse those 2 methods?
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations?
Posted by Stephen McConnell <mc...@apache.org>.
I've read with a lot of interest the thoughts and requirements coming
out of this thread - in particular the comments from Daz, Gary, and
Adam. One of comments that I found profound but obvious was the
observation that current concepts/thinking is very container
architecture driven. I've been thinking and thinking about this and
I've reached some sort of a conclusion that would enable the end user to
express component relationships independently of the context/service split.
The the avalon-sandbox info and meta packages both force the container
driven perspective on context/service separation - and I've come to the
conclusion the (a) this is not needed, and (b) that potable context can
be provided - if we rehash the meta model.
If you familiar with either the info or meta package you will be aware
of the following pattern:
[meta-info-for-component]
* [general-info-block]
* [context-block]
* [services-provided-block]
* [service-dependencies-block]
I'm starting to think about an alternative approach. I've identified
three distinct groups that can be both consumed and provided (from a
container perspective). These include the following:
* Service providers
These are the classic services that can be assembled
based on consumption and production declarations.
* Service locator
This is a new concept that is very similar to the
Merlin extension handler. It a component that provides
a plug-in lookup solution that can be narrowed to a
particular interface (and can be located by the container
using the interface name as the key). A service locator
can be applied to the following three areas:
* context value lookup
* service lookup
* lifecycle stage handler lookup
If we re-examine things from the the component authors perspective, it
seems reasonable to describe the mapping of a service, context and
lifecycle in terms of production and consumption relationships.
[meta-info]
* [general-info]
* [consumption-info]
* [production-info]
From this model we can esily map in the container view of the world by
doing something like the following:
[meta-info]
* [general-info]
* [consumption-info]
* [context]
* [service-dependencies]
* [locator-dependencies]
* [service]
* [services-dependencies]
* [locator-dependencies]
* [lifecycle]
* [stage-dependencies]
* [production-info]
* [service-provision]
* [locator-provision]
* [stage-provision]
What's interesting about the above is that (a) the object model for
context and service is parallel. This means that the client can narrow
a supplied context instance to a particular interface, and can do the
same thing with a supplied service manager. The container author can
forget about declaring typed context entries, and instead, he/she can
simply declare a set of locator dependencies - e.g. an author may want a
BlockContext locator and a MailetContext locator. The container can
handle the establishment of the respective context and service managers
so that any pure key based request still map to the appropriate locator
and any casting against interfaces supported by the set of associated
locators can be wrapped in a composite proxy.
A second interesting point is that the component author has 100% control
over which services and locators are mapped to the context abstraction
as opposed to the service abstraction. The component author would be to
include totally different locators into a single context without any
client side impact relative to current framework interfaces. And most
importantly, the entire models can portable across containers that
support a standard locator object model.
From the container authors point of view locators can be treated as
components and as such that can have their own dependencies. This means
that something like a BlockContext locator can plugged into the system
and the container simply assembles it and assigns it as appropriate.
A complete DTD for component model on the above with both consumption
and production features would look something like:
<type>
<info name="demo" version="2.0"/>
<consumes>
<lifecycle>
<stage type="org.demo.Demonstratable"/>
</lifecycle>
<context>
<locator type="org.a.a.f.context.SystemLocator" version="4.1.2"/>
<locator type="org.a.j.MailetLocator" version="2"/>
<service type="org.demo.SimpleService" key="simple" version="1"/>
</context>
<services>
<service type="org.demo.Store" key="vault"/>
<locator type="org.demo.SecurityLocator" version="4.1.2"/>
<services>
</consumes>
<produces>
<service type="org.demo.PathResolver" version="3.2" />
<locator type="org.demo.Directory" />
<stage type="org.demo.Exploitable" version=2"/>
</produces>
</type>
From the point of view of current framework interfaces, it would be
feasible to incorporate a framework level Locator interface as a
super-type of both ServiceManager and Context so that operations on the
supplied parameter to contextualize and service could be treated in the
same way. It would even be possible to incorporate migration interfaces
into 4.2 version of Contextulizable and Serviceable under which a
Locator is passed as the parameter.
E.g.
public void contextualize( Locator locator ) throws LocatorException
{
SystemLocator system = (SystemLocator) locator;
File base = system.getWorkingDirectory();
m_name = locator.locate( "urn:avalon:name" );
}
public void service( Locator locator ) throws LocatorException
{
SecurityLocator sec = (SecurityLocator) locator;
Privalege[] sec.getPrivaliges( m_name );
// etc.
}
From here, the differentiating factor between contextualization and
services phases is reduced to the ordered sequence in the lifecycle.
Any thoughts ?
Darrell DeBoer wrote:
>Thanks Gary,
>
>It's funny, I woke up this morning with a similar conclusion. Yesterday, for
>the first time, I could see both Peter's and Stephen's arguments for a
>distinction between Container-supplied and Peer-supplied services (or
>"(non)priviledged" as Stephen is calling the distinction).
>
>The problem with both of these distinctions is that they are about Container
>implementation. My take on it is thus:
>
>Peter wants to distinguish Container-provided services, because the person
>doing the assembly doesn't have to specify them in the assembly file.
>Unfortunately, it's quite easy to imagine one container which provides a
>certain service directly, and a different one which requries a
>user-configured component to provide the same service. So by distinguishing
>between these in *code*, the component will be inherently non-portable.
>(Whereas the assembly file can be thought of as container-specific? - At
>least it's easy to change for a new deployment).
>
>Stephen wants to have the notion of priviledged services, so he can implement
>life-cycle handlers and context providers as components (at least this is
>what I've garnered from the emails, I don't know the code). While this sounds
>cool from the design perspective, it seems like this notion should be kept
>out of Framework, as it's a specific requirement of the Merlin container.
>Other containers may want to provide extensibility in a completely different
>way (maybe the "interceptors" Pete has eluded to fall into this). What
>follows is that regular components which rely just on Framework contracts
>will be portable, whereas Merlin lifecycle extension components don't need to
>be, so they can use a Merlin-specific contracts and interfaces.
>
>(Who says having competing container implementations is a bad thing? ;)
>
>This example is giving me a few troubles:
>
>
>>>getServletContext().isPrincipleInRole( String role, Principle p );
>>>getSessionContext().isCallerInRole( String role );
>>>
>>>
>
>These are container provided services, and it would "feel" right that they
>would be split out from the provision of other services. But then you
>realise: - these interfaces are defined as part of a specification. The
>container can't choose whether or not to provides these things, they are
>required. And the container can't arbitrarily provide new stuff in this way,
>since then a component would become non-portable.
>
>So I can't see the argument for the Container-provided/Peer-provided divide.
>But I can see an argument for a logical and code separation of services
>defined in the spec (and therefore part of the Avalon-Framework contracts),
>and other services (both container and peer).
>
>At the moment, I don't think any such services exist. Maybe we should come up
>with some, and *maybe* they should be provided in a separate mechanism to
>regular services. But since they are part of the spec, components won't need
>to "declare" the context they require, and things like MailetContext and
>ServletContext are removed from these arguments, since they aren't part of
>the Avalon-Framework contracts.
>
>This is my take on the matter, anyhow.
>
>ciao
>Daz
>
>On Thu, 5 Dec 2002 04:05, Gary Shea wrote:
>
>
>>I've been following this thread with a great deal of interest, since I
>>have the same questions as Adam has been asking. My experience with
>>using Avalon is that Context is great until you get someone else's
>>container involved in the picture. At that point it becomes a minor
>>nightmare, since each container sees it differently.
>>
>>My views are from the perspective of a component writer who wants to
>>avoid container lock-in.
>>
>>I've been willing to adopt the data/services distinction, because the
>>container I want to use (merlin) does so. But the data/services
>>paradigm turns Context into either a less-capable Configuration or a
>>declaratively-driven object builder. The idea of Context as an object
>>builder feels kind of baroque to me, and I can't imagine that all
>>containers will do it, so in merlin I don't use Context at all.
>>
>>The container-provided/peer-provided view is one I'd be willing to adopt
>>also. In this view, Context is container-dependent, and is simply
>>anathema to the component writer who wants to maintain cross-container
>>portability. That's the extent of my interest. I can see how this
>>view would be useful to someone building a tightly-coupled
>>component/container system, but my goal is to avoid that at all costs.
>>
>>As you can see, I wouldn't use Context under either of the data/service
>>or container/peer paradigms. I think that's ok.
>>
>>If this discussion had to end today, I'd say Context is a red herring
>>and should be discarded. It would be replaced with two new stages:
>>ObjectConfigurable and ContainerServiceable.
>>
>> Gary
>>
>>[2002-12-04 21:56 +1100] Peter Donald (peter@realityforge.org) wrote:
>>
>>
>>>On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote:
>>>
>>>
>>>>These are useful things, no question. Components need some way to get
>>>>at data and services that are supplied by the container. Again, why do
>>>>they care that a particular service or piece of data was supplied by
>>>>the container or a peer?
>>>>
>>>>
>>>Components don't care what the origins of the resource are - all of it is
>>>potentially "contextualized" on a per component basis and all generally
>>>has certain criteria to adhere to but beyond that it is about it. The
>>>different resources are separated out for the sake of humans and no other
>>>reason.
>>>
>>>Context is separated from ServiceManager because humans see them as
>>>different things - especially during the assembly process.
>>>
>>>
>>>
>>>>Yes, I know that they're "different logical things". But so are, say,
>>>>authentication services and persistence services. We don't use
>>>>different mechanisms to deliver those services to components. It would
>>>>be pointless to do so:
>>>>
>>>>
>>>I disagree. If persistence were provided to the component and the
>>>component was effectively made to be an OJB object or something like that
>>>then we would likely provide persistence/transaction capabilities in a
>>>very different manner. Most likely via some transparent EJB-like manner.
>>>
>>>In the same way if AAA services were provided to a component as part of
>>>it's environment then it would likely also follow an EJB/Servlet style
>>>setup where the container does it via interception and allows components
>>>to access it programatically via something like
>>>
>>>getServletContext().isPrincipleInRole( String role, Principle p );
>>>getSessionContext().isCallerInRole( String role );
>>>(or insert real examples here or JAAS).
>>>
>>>If the services are things that the container provides to the component
>>>as part of it's environment then the user perceives them as different to
>>>services that the component uses. I can't think of one API that actually
>>>merges the two concepts.
>>>
>>>When we tried to merge the two things together the primary reason we
>>>separated them out again was because of user complaints. ie If a
>>>resources requires resources A, B and C and C is container provided. All
>>>three are accessed in the same way so the person sees them as much the
>>>same (like the component sees them as much the same). However during
>>>assembly they are only required to assemble A and B - which creates a
>>>cognitive dissonance because they are treated as identical in one place
>>>but different in another.
>>>
>>>
>>>
>>>>So which of these cases do you think offer the most benefit to the
>>>>component writer? Assume logger, config, params have been split out
>>>>already: 1. No separation.
>>>>2. Separate data and services.
>>>>3. Separate container-provided resources and peer-provided resources.
>>>>
>>>>
>>>+1
>>>
>>>
>>>
>>>>4. Separate container-provided data, container-provided services,
>>>>peer-provided data, and peer-provided services.
>>>>5. Who cares? Why are you bothering me with these questions?
>>>>
>>>>
>>>>
>>>:)
>>>
>>>--
>>>Cheers,
>>>
>>>Peter Donald
>>>*------------------------------------------------*
>>>
>>>| Those who know how to think need no teachers. |
>>>| - Gandhi |
>>>
>>>*------------------------------------------------*
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>><ma...@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>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Darrell DeBoer <da...@apache.org>.
Thanks Gary,
It's funny, I woke up this morning with a similar conclusion. Yesterday, for
the first time, I could see both Peter's and Stephen's arguments for a
distinction between Container-supplied and Peer-supplied services (or
"(non)priviledged" as Stephen is calling the distinction).
The problem with both of these distinctions is that they are about Container
implementation. My take on it is thus:
Peter wants to distinguish Container-provided services, because the person
doing the assembly doesn't have to specify them in the assembly file.
Unfortunately, it's quite easy to imagine one container which provides a
certain service directly, and a different one which requries a
user-configured component to provide the same service. So by distinguishing
between these in *code*, the component will be inherently non-portable.
(Whereas the assembly file can be thought of as container-specific? - At
least it's easy to change for a new deployment).
Stephen wants to have the notion of priviledged services, so he can implement
life-cycle handlers and context providers as components (at least this is
what I've garnered from the emails, I don't know the code). While this sounds
cool from the design perspective, it seems like this notion should be kept
out of Framework, as it's a specific requirement of the Merlin container.
Other containers may want to provide extensibility in a completely different
way (maybe the "interceptors" Pete has eluded to fall into this). What
follows is that regular components which rely just on Framework contracts
will be portable, whereas Merlin lifecycle extension components don't need to
be, so they can use a Merlin-specific contracts and interfaces.
(Who says having competing container implementations is a bad thing? ;)
This example is giving me a few troubles:
> > getServletContext().isPrincipleInRole( String role, Principle p );
> > getSessionContext().isCallerInRole( String role );
These are container provided services, and it would "feel" right that they
would be split out from the provision of other services. But then you
realise: - these interfaces are defined as part of a specification. The
container can't choose whether or not to provides these things, they are
required. And the container can't arbitrarily provide new stuff in this way,
since then a component would become non-portable.
So I can't see the argument for the Container-provided/Peer-provided divide.
But I can see an argument for a logical and code separation of services
defined in the spec (and therefore part of the Avalon-Framework contracts),
and other services (both container and peer).
At the moment, I don't think any such services exist. Maybe we should come up
with some, and *maybe* they should be provided in a separate mechanism to
regular services. But since they are part of the spec, components won't need
to "declare" the context they require, and things like MailetContext and
ServletContext are removed from these arguments, since they aren't part of
the Avalon-Framework contracts.
This is my take on the matter, anyhow.
ciao
Daz
On Thu, 5 Dec 2002 04:05, Gary Shea wrote:
> I've been following this thread with a great deal of interest, since I
> have the same questions as Adam has been asking. My experience with
> using Avalon is that Context is great until you get someone else's
> container involved in the picture. At that point it becomes a minor
> nightmare, since each container sees it differently.
>
> My views are from the perspective of a component writer who wants to
> avoid container lock-in.
>
> I've been willing to adopt the data/services distinction, because the
> container I want to use (merlin) does so. But the data/services
> paradigm turns Context into either a less-capable Configuration or a
> declaratively-driven object builder. The idea of Context as an object
> builder feels kind of baroque to me, and I can't imagine that all
> containers will do it, so in merlin I don't use Context at all.
>
> The container-provided/peer-provided view is one I'd be willing to adopt
> also. In this view, Context is container-dependent, and is simply
> anathema to the component writer who wants to maintain cross-container
> portability. That's the extent of my interest. I can see how this
> view would be useful to someone building a tightly-coupled
> component/container system, but my goal is to avoid that at all costs.
>
> As you can see, I wouldn't use Context under either of the data/service
> or container/peer paradigms. I think that's ok.
>
> If this discussion had to end today, I'd say Context is a red herring
> and should be discarded. It would be replaced with two new stages:
> ObjectConfigurable and ContainerServiceable.
>
> Gary
>
> [2002-12-04 21:56 +1100] Peter Donald (peter@realityforge.org) wrote:
> > On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote:
> > > These are useful things, no question. Components need some way to get
> > > at data and services that are supplied by the container. Again, why do
> > > they care that a particular service or piece of data was supplied by
> > > the container or a peer?
> >
> > Components don't care what the origins of the resource are - all of it is
> > potentially "contextualized" on a per component basis and all generally
> > has certain criteria to adhere to but beyond that it is about it. The
> > different resources are separated out for the sake of humans and no other
> > reason.
> >
> > Context is separated from ServiceManager because humans see them as
> > different things - especially during the assembly process.
> >
> > > Yes, I know that they're "different logical things". But so are, say,
> > > authentication services and persistence services. We don't use
> > > different mechanisms to deliver those services to components. It would
> > > be pointless to do so:
> >
> > I disagree. If persistence were provided to the component and the
> > component was effectively made to be an OJB object or something like that
> > then we would likely provide persistence/transaction capabilities in a
> > very different manner. Most likely via some transparent EJB-like manner.
> >
> > In the same way if AAA services were provided to a component as part of
> > it's environment then it would likely also follow an EJB/Servlet style
> > setup where the container does it via interception and allows components
> > to access it programatically via something like
> >
> > getServletContext().isPrincipleInRole( String role, Principle p );
> > getSessionContext().isCallerInRole( String role );
> > (or insert real examples here or JAAS).
> >
> > If the services are things that the container provides to the component
> > as part of it's environment then the user perceives them as different to
> > services that the component uses. I can't think of one API that actually
> > merges the two concepts.
> >
> > When we tried to merge the two things together the primary reason we
> > separated them out again was because of user complaints. ie If a
> > resources requires resources A, B and C and C is container provided. All
> > three are accessed in the same way so the person sees them as much the
> > same (like the component sees them as much the same). However during
> > assembly they are only required to assemble A and B - which creates a
> > cognitive dissonance because they are treated as identical in one place
> > but different in another.
> >
> > > So which of these cases do you think offer the most benefit to the
> > > component writer? Assume logger, config, params have been split out
> > > already: 1. No separation.
> > > 2. Separate data and services.
> > > 3. Separate container-provided resources and peer-provided resources.
> >
> > +1
> >
> > > 4. Separate container-provided data, container-provided services,
> > > peer-provided data, and peer-provided services.
> > > 5. Who cares? Why are you bothering me with these questions?
> > >
> > :)
> >
> > --
> > Cheers,
> >
> > Peter Donald
> > *------------------------------------------------*
> >
> > | Those who know how to think need no teachers. |
> > | - Gandhi |
> >
> > *------------------------------------------------*
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@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: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Darrell DeBoer <da...@apache.org>.
Thanks Gary,
It's funny, I woke up this morning with a similar conclusion. Yesterday, for
the first time, I could see both Peter's and Stephen's arguments for a
distinction between Container-supplied and Peer-supplied services (or
"(non)priviledged" as Stephen is calling the distinction).
The problem with both of these distinctions is that they are about Container
implementation. My take on it is thus:
Peter wants to distinguish Container-provided services, because the person
doing the assembly doesn't have to specify them in the assembly file.
Unfortunately, it's quite easy to imagine one container which provides a
certain service directly, and a different one which requries a
user-configured component to provide the same service. So by distinguishing
between these in *code*, the component will be inherently non-portable.
(Whereas the assembly file can be thought of as container-specific? - At
least it's easy to change for a new deployment).
Stephen wants to have the notion of priviledged services, so he can implement
life-cycle handlers and context providers as components (at least this is
what I've garnered from the emails, I don't know the code). While this sounds
cool from the design perspective, it seems like this notion should be kept
out of Framework, as it's a specific requirement of the Merlin container.
Other containers may want to provide extensibility in a completely different
way (maybe the "interceptors" Pete has eluded to fall into this). What
follows is that regular components which rely just on Framework contracts
will be portable, whereas Merlin lifecycle extension components don't need to
be, so they can use a Merlin-specific contracts and interfaces.
(Who says having competing container implementations is a bad thing? ;)
This example is giving me a few troubles:
> > getServletContext().isPrincipleInRole( String role, Principle p );
> > getSessionContext().isCallerInRole( String role );
These are container provided services, and it would "feel" right that they
would be split out from the provision of other services. But then you
realise: - these interfaces are defined as part of a specification. The
container can't choose whether or not to provides these things, they are
required. And the container can't arbitrarily provide new stuff in this way,
since then a component would become non-portable.
So I can't see the argument for the Container-provided/Peer-provided divide.
But I can see an argument for a logical and code separation of services
defined in the spec (and therefore part of the Avalon-Framework contracts),
and other services (both container and peer).
At the moment, I don't think any such services exist. Maybe we should come up
with some, and *maybe* they should be provided in a separate mechanism to
regular services. But since they are part of the spec, components won't need
to "declare" the context they require, and things like MailetContext and
ServletContext are removed from these arguments, since they aren't part of
the Avalon-Framework contracts.
This is my take on the matter, anyhow.
ciao
Daz
On Thu, 5 Dec 2002 04:05, Gary Shea wrote:
> I've been following this thread with a great deal of interest, since I
> have the same questions as Adam has been asking. My experience with
> using Avalon is that Context is great until you get someone else's
> container involved in the picture. At that point it becomes a minor
> nightmare, since each container sees it differently.
>
> My views are from the perspective of a component writer who wants to
> avoid container lock-in.
>
> I've been willing to adopt the data/services distinction, because the
> container I want to use (merlin) does so. But the data/services
> paradigm turns Context into either a less-capable Configuration or a
> declaratively-driven object builder. The idea of Context as an object
> builder feels kind of baroque to me, and I can't imagine that all
> containers will do it, so in merlin I don't use Context at all.
>
> The container-provided/peer-provided view is one I'd be willing to adopt
> also. In this view, Context is container-dependent, and is simply
> anathema to the component writer who wants to maintain cross-container
> portability. That's the extent of my interest. I can see how this
> view would be useful to someone building a tightly-coupled
> component/container system, but my goal is to avoid that at all costs.
>
> As you can see, I wouldn't use Context under either of the data/service
> or container/peer paradigms. I think that's ok.
>
> If this discussion had to end today, I'd say Context is a red herring
> and should be discarded. It would be replaced with two new stages:
> ObjectConfigurable and ContainerServiceable.
>
> Gary
>
> [2002-12-04 21:56 +1100] Peter Donald (peter@realityforge.org) wrote:
> > On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote:
> > > These are useful things, no question. Components need some way to get
> > > at data and services that are supplied by the container. Again, why do
> > > they care that a particular service or piece of data was supplied by
> > > the container or a peer?
> >
> > Components don't care what the origins of the resource are - all of it is
> > potentially "contextualized" on a per component basis and all generally
> > has certain criteria to adhere to but beyond that it is about it. The
> > different resources are separated out for the sake of humans and no other
> > reason.
> >
> > Context is separated from ServiceManager because humans see them as
> > different things - especially during the assembly process.
> >
> > > Yes, I know that they're "different logical things". But so are, say,
> > > authentication services and persistence services. We don't use
> > > different mechanisms to deliver those services to components. It would
> > > be pointless to do so:
> >
> > I disagree. If persistence were provided to the component and the
> > component was effectively made to be an OJB object or something like that
> > then we would likely provide persistence/transaction capabilities in a
> > very different manner. Most likely via some transparent EJB-like manner.
> >
> > In the same way if AAA services were provided to a component as part of
> > it's environment then it would likely also follow an EJB/Servlet style
> > setup where the container does it via interception and allows components
> > to access it programatically via something like
> >
> > getServletContext().isPrincipleInRole( String role, Principle p );
> > getSessionContext().isCallerInRole( String role );
> > (or insert real examples here or JAAS).
> >
> > If the services are things that the container provides to the component
> > as part of it's environment then the user perceives them as different to
> > services that the component uses. I can't think of one API that actually
> > merges the two concepts.
> >
> > When we tried to merge the two things together the primary reason we
> > separated them out again was because of user complaints. ie If a
> > resources requires resources A, B and C and C is container provided. All
> > three are accessed in the same way so the person sees them as much the
> > same (like the component sees them as much the same). However during
> > assembly they are only required to assemble A and B - which creates a
> > cognitive dissonance because they are treated as identical in one place
> > but different in another.
> >
> > > So which of these cases do you think offer the most benefit to the
> > > component writer? Assume logger, config, params have been split out
> > > already: 1. No separation.
> > > 2. Separate data and services.
> > > 3. Separate container-provided resources and peer-provided resources.
> >
> > +1
> >
> > > 4. Separate container-provided data, container-provided services,
> > > peer-provided data, and peer-provided services.
> > > 5. Who cares? Why are you bothering me with these questions?
> > >
> > :)
> >
> > --
> > Cheers,
> >
> > Peter Donald
> > *------------------------------------------------*
> >
> > | Those who know how to think need no teachers. |
> > | - Gandhi |
> >
> > *------------------------------------------------*
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@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: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Darrell DeBoer <da...@apache.org>.
Thanks Gary,
It's funny, I woke up this morning with a similar conclusion. Yesterday, for
the first time, I could see both Peter's and Stephen's arguments for a
distinction between Container-supplied and Peer-supplied services (or
"(non)priviledged" as Stephen is calling the distinction).
The problem with both of these distinctions is that they are about Container
implementation. My take on it is thus:
Peter wants to distinguish Container-provided services, because the person
doing the assembly doesn't have to specify them in the assembly file.
Unfortunately, it's quite easy to imagine one container which provides a
certain service directly, and a different one which requries a
user-configured component to provide the same service. So by distinguishing
between these in *code*, the component will be inherently non-portable.
(Whereas the assembly file can be thought of as container-specific? - At
least it's easy to change for a new deployment).
Stephen wants to have the notion of priviledged services, so he can implement
life-cycle handlers and context providers as components (at least this is
what I've garnered from the emails, I don't know the code). While this sounds
cool from the design perspective, it seems like this notion should be kept
out of Framework, as it's a specific requirement of the Merlin container.
Other containers may want to provide extensibility in a completely different
way (maybe the "interceptors" Pete has eluded to fall into this). What
follows is that regular components which rely just on Framework contracts
will be portable, whereas Merlin lifecycle extension components don't need to
be, so they can use a Merlin-specific contracts and interfaces.
(Who says having competing container implementations is a bad thing? ;)
This example is giving me a few troubles:
> > getServletContext().isPrincipleInRole( String role, Principle p );
> > getSessionContext().isCallerInRole( String role );
These are container provided services, and it would "feel" right that they
would be split out from the provision of other services. But then you
realise: - these interfaces are defined as part of a specification. The
container can't choose whether or not to provides these things, they are
required. And the container can't arbitrarily provide new stuff in this way,
since then a component would become non-portable.
So I can't see the argument for the Container-provided/Peer-provided divide.
But I can see an argument for a logical and code separation of services
defined in the spec (and therefore part of the Avalon-Framework contracts),
and other services (both container and peer).
At the moment, I don't think any such services exist. Maybe we should come up
with some, and *maybe* they should be provided in a separate mechanism to
regular services. But since they are part of the spec, components won't need
to "declare" the context they require, and things like MailetContext and
ServletContext are removed from these arguments, since they aren't part of
the Avalon-Framework contracts.
This is my take on the matter, anyhow.
ciao
Daz
On Thu, 5 Dec 2002 04:05, Gary Shea wrote:
> I've been following this thread with a great deal of interest, since I
> have the same questions as Adam has been asking. My experience with
> using Avalon is that Context is great until you get someone else's
> container involved in the picture. At that point it becomes a minor
> nightmare, since each container sees it differently.
>
> My views are from the perspective of a component writer who wants to
> avoid container lock-in.
>
> I've been willing to adopt the data/services distinction, because the
> container I want to use (merlin) does so. But the data/services
> paradigm turns Context into either a less-capable Configuration or a
> declaratively-driven object builder. The idea of Context as an object
> builder feels kind of baroque to me, and I can't imagine that all
> containers will do it, so in merlin I don't use Context at all.
>
> The container-provided/peer-provided view is one I'd be willing to adopt
> also. In this view, Context is container-dependent, and is simply
> anathema to the component writer who wants to maintain cross-container
> portability. That's the extent of my interest. I can see how this
> view would be useful to someone building a tightly-coupled
> component/container system, but my goal is to avoid that at all costs.
>
> As you can see, I wouldn't use Context under either of the data/service
> or container/peer paradigms. I think that's ok.
>
> If this discussion had to end today, I'd say Context is a red herring
> and should be discarded. It would be replaced with two new stages:
> ObjectConfigurable and ContainerServiceable.
>
> Gary
>
> [2002-12-04 21:56 +1100] Peter Donald (peter@realityforge.org) wrote:
> > On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote:
> > > These are useful things, no question. Components need some way to get
> > > at data and services that are supplied by the container. Again, why do
> > > they care that a particular service or piece of data was supplied by
> > > the container or a peer?
> >
> > Components don't care what the origins of the resource are - all of it is
> > potentially "contextualized" on a per component basis and all generally
> > has certain criteria to adhere to but beyond that it is about it. The
> > different resources are separated out for the sake of humans and no other
> > reason.
> >
> > Context is separated from ServiceManager because humans see them as
> > different things - especially during the assembly process.
> >
> > > Yes, I know that they're "different logical things". But so are, say,
> > > authentication services and persistence services. We don't use
> > > different mechanisms to deliver those services to components. It would
> > > be pointless to do so:
> >
> > I disagree. If persistence were provided to the component and the
> > component was effectively made to be an OJB object or something like that
> > then we would likely provide persistence/transaction capabilities in a
> > very different manner. Most likely via some transparent EJB-like manner.
> >
> > In the same way if AAA services were provided to a component as part of
> > it's environment then it would likely also follow an EJB/Servlet style
> > setup where the container does it via interception and allows components
> > to access it programatically via something like
> >
> > getServletContext().isPrincipleInRole( String role, Principle p );
> > getSessionContext().isCallerInRole( String role );
> > (or insert real examples here or JAAS).
> >
> > If the services are things that the container provides to the component
> > as part of it's environment then the user perceives them as different to
> > services that the component uses. I can't think of one API that actually
> > merges the two concepts.
> >
> > When we tried to merge the two things together the primary reason we
> > separated them out again was because of user complaints. ie If a
> > resources requires resources A, B and C and C is container provided. All
> > three are accessed in the same way so the person sees them as much the
> > same (like the component sees them as much the same). However during
> > assembly they are only required to assemble A and B - which creates a
> > cognitive dissonance because they are treated as identical in one place
> > but different in another.
> >
> > > So which of these cases do you think offer the most benefit to the
> > > component writer? Assume logger, config, params have been split out
> > > already: 1. No separation.
> > > 2. Separate data and services.
> > > 3. Separate container-provided resources and peer-provided resources.
> >
> > +1
> >
> > > 4. Separate container-provided data, container-provided services,
> > > peer-provided data, and peer-provided services.
> > > 5. Who cares? Why are you bothering me with these questions?
> > >
> > :)
> >
> > --
> > Cheers,
> >
> > Peter Donald
> > *------------------------------------------------*
> >
> > | Those who know how to think need no teachers. |
> > | - Gandhi |
> >
> > *------------------------------------------------*
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@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: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Gary Shea <sh...@gtsdesign.com>.
I've been following this thread with a great deal of interest, since I
have the same questions as Adam has been asking. My experience with
using Avalon is that Context is great until you get someone else's
container involved in the picture. At that point it becomes a minor
nightmare, since each container sees it differently.
My views are from the perspective of a component writer who wants to
avoid container lock-in.
I've been willing to adopt the data/services distinction, because the
container I want to use (merlin) does so. But the data/services
paradigm turns Context into either a less-capable Configuration or a
declaratively-driven object builder. The idea of Context as an object
builder feels kind of baroque to me, and I can't imagine that all
containers will do it, so in merlin I don't use Context at all.
The container-provided/peer-provided view is one I'd be willing to adopt
also. In this view, Context is container-dependent, and is simply
anathema to the component writer who wants to maintain cross-container
portability. That's the extent of my interest. I can see how this
view would be useful to someone building a tightly-coupled
component/container system, but my goal is to avoid that at all costs.
As you can see, I wouldn't use Context under either of the data/service
or container/peer paradigms. I think that's ok.
If this discussion had to end today, I'd say Context is a red herring
and should be discarded. It would be replaced with two new stages:
ObjectConfigurable and ContainerServiceable.
Gary
[2002-12-04 21:56 +1100] Peter Donald (peter@realityforge.org) wrote:
> On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote:
> > These are useful things, no question. Components need some way to get at
> > data and services that are supplied by the container. Again, why do they
> > care that a particular service or piece of data was supplied by the
> > container or a peer?
>
> Components don't care what the origins of the resource are - all of it is
> potentially "contextualized" on a per component basis and all generally has
> certain criteria to adhere to but beyond that it is about it. The different
> resources are separated out for the sake of humans and no other reason.
>
> Context is separated from ServiceManager because humans see them as different
> things - especially during the assembly process.
>
>
>
> > Yes, I know that they're "different logical things". But so are, say,
> > authentication services and persistence services. We don't use different
> > mechanisms to deliver those services to components. It would be pointless
> > to do so:
>
> I disagree. If persistence were provided to the component and the component
> was effectively made to be an OJB object or something like that then we would
> likely provide persistence/transaction capabilities in a very different
> manner. Most likely via some transparent EJB-like manner.
>
> In the same way if AAA services were provided to a component as part of it's
> environment then it would likely also follow an EJB/Servlet style setup where
> the container does it via interception and allows components to access it
> programatically via something like
>
> getServletContext().isPrincipleInRole( String role, Principle p );
> getSessionContext().isCallerInRole( String role );
> (or insert real examples here or JAAS).
>
> If the services are things that the container provides to the component as
> part of it's environment then the user perceives them as different to
> services that the component uses. I can't think of one API that actually
> merges the two concepts.
>
> When we tried to merge the two things together the primary reason we separated
> them out again was because of user complaints. ie If a resources requires
> resources A, B and C and C is container provided. All three are accessed in
> the same way so the person sees them as much the same (like the component
> sees them as much the same). However during assembly they are only required
> to assemble A and B - which creates a cognitive dissonance because they are
> treated as identical in one place but different in another.
>
> > So which of these cases do you think offer the most benefit to the
> > component writer? Assume logger, config, params have been split out
> > already: 1. No separation.
> > 2. Separate data and services.
> > 3. Separate container-provided resources and peer-provided resources.
>
> +1
>
> > 4. Separate container-provided data, container-provided services,
> > peer-provided data, and peer-provided services.
> > 5. Who cares? Why are you bothering me with these questions?
>
> :)
>
> --
> Cheers,
>
> Peter Donald
> *------------------------------------------------*
> | Those who know how to think need no teachers. |
> | - Gandhi |
> *------------------------------------------------*
>
>
> --
> To unsubscribe, e-mail: <ma...@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: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Gary Shea <sh...@gtsdesign.com>.
I've been following this thread with a great deal of interest, since I
have the same questions as Adam has been asking. My experience with
using Avalon is that Context is great until you get someone else's
container involved in the picture. At that point it becomes a minor
nightmare, since each container sees it differently.
My views are from the perspective of a component writer who wants to
avoid container lock-in.
I've been willing to adopt the data/services distinction, because the
container I want to use (merlin) does so. But the data/services
paradigm turns Context into either a less-capable Configuration or a
declaratively-driven object builder. The idea of Context as an object
builder feels kind of baroque to me, and I can't imagine that all
containers will do it, so in merlin I don't use Context at all.
The container-provided/peer-provided view is one I'd be willing to adopt
also. In this view, Context is container-dependent, and is simply
anathema to the component writer who wants to maintain cross-container
portability. That's the extent of my interest. I can see how this
view would be useful to someone building a tightly-coupled
component/container system, but my goal is to avoid that at all costs.
As you can see, I wouldn't use Context under either of the data/service
or container/peer paradigms. I think that's ok.
If this discussion had to end today, I'd say Context is a red herring
and should be discarded. It would be replaced with two new stages:
ObjectConfigurable and ContainerServiceable.
Gary
[2002-12-04 21:56 +1100] Peter Donald (peter@realityforge.org) wrote:
> On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote:
> > These are useful things, no question. Components need some way to get at
> > data and services that are supplied by the container. Again, why do they
> > care that a particular service or piece of data was supplied by the
> > container or a peer?
>
> Components don't care what the origins of the resource are - all of it is
> potentially "contextualized" on a per component basis and all generally has
> certain criteria to adhere to but beyond that it is about it. The different
> resources are separated out for the sake of humans and no other reason.
>
> Context is separated from ServiceManager because humans see them as different
> things - especially during the assembly process.
>
>
>
> > Yes, I know that they're "different logical things". But so are, say,
> > authentication services and persistence services. We don't use different
> > mechanisms to deliver those services to components. It would be pointless
> > to do so:
>
> I disagree. If persistence were provided to the component and the component
> was effectively made to be an OJB object or something like that then we would
> likely provide persistence/transaction capabilities in a very different
> manner. Most likely via some transparent EJB-like manner.
>
> In the same way if AAA services were provided to a component as part of it's
> environment then it would likely also follow an EJB/Servlet style setup where
> the container does it via interception and allows components to access it
> programatically via something like
>
> getServletContext().isPrincipleInRole( String role, Principle p );
> getSessionContext().isCallerInRole( String role );
> (or insert real examples here or JAAS).
>
> If the services are things that the container provides to the component as
> part of it's environment then the user perceives them as different to
> services that the component uses. I can't think of one API that actually
> merges the two concepts.
>
> When we tried to merge the two things together the primary reason we separated
> them out again was because of user complaints. ie If a resources requires
> resources A, B and C and C is container provided. All three are accessed in
> the same way so the person sees them as much the same (like the component
> sees them as much the same). However during assembly they are only required
> to assemble A and B - which creates a cognitive dissonance because they are
> treated as identical in one place but different in another.
>
> > So which of these cases do you think offer the most benefit to the
> > component writer? Assume logger, config, params have been split out
> > already: 1. No separation.
> > 2. Separate data and services.
> > 3. Separate container-provided resources and peer-provided resources.
>
> +1
>
> > 4. Separate container-provided data, container-provided services,
> > peer-provided data, and peer-provided services.
> > 5. Who cares? Why are you bothering me with these questions?
>
> :)
>
> --
> Cheers,
>
> Peter Donald
> *------------------------------------------------*
> | Those who know how to think need no teachers. |
> | - Gandhi |
> *------------------------------------------------*
>
>
> --
> To unsubscribe, e-mail: <ma...@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: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Gary Shea <sh...@gtsdesign.com>.
I've been following this thread with a great deal of interest, since I
have the same questions as Adam has been asking. My experience with
using Avalon is that Context is great until you get someone else's
container involved in the picture. At that point it becomes a minor
nightmare, since each container sees it differently.
My views are from the perspective of a component writer who wants to
avoid container lock-in.
I've been willing to adopt the data/services distinction, because the
container I want to use (merlin) does so. But the data/services
paradigm turns Context into either a less-capable Configuration or a
declaratively-driven object builder. The idea of Context as an object
builder feels kind of baroque to me, and I can't imagine that all
containers will do it, so in merlin I don't use Context at all.
The container-provided/peer-provided view is one I'd be willing to adopt
also. In this view, Context is container-dependent, and is simply
anathema to the component writer who wants to maintain cross-container
portability. That's the extent of my interest. I can see how this
view would be useful to someone building a tightly-coupled
component/container system, but my goal is to avoid that at all costs.
As you can see, I wouldn't use Context under either of the data/service
or container/peer paradigms. I think that's ok.
If this discussion had to end today, I'd say Context is a red herring
and should be discarded. It would be replaced with two new stages:
ObjectConfigurable and ContainerServiceable.
Gary
[2002-12-04 21:56 +1100] Peter Donald (peter@realityforge.org) wrote:
> On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote:
> > These are useful things, no question. Components need some way to get at
> > data and services that are supplied by the container. Again, why do they
> > care that a particular service or piece of data was supplied by the
> > container or a peer?
>
> Components don't care what the origins of the resource are - all of it is
> potentially "contextualized" on a per component basis and all generally has
> certain criteria to adhere to but beyond that it is about it. The different
> resources are separated out for the sake of humans and no other reason.
>
> Context is separated from ServiceManager because humans see them as different
> things - especially during the assembly process.
>
>
>
> > Yes, I know that they're "different logical things". But so are, say,
> > authentication services and persistence services. We don't use different
> > mechanisms to deliver those services to components. It would be pointless
> > to do so:
>
> I disagree. If persistence were provided to the component and the component
> was effectively made to be an OJB object or something like that then we would
> likely provide persistence/transaction capabilities in a very different
> manner. Most likely via some transparent EJB-like manner.
>
> In the same way if AAA services were provided to a component as part of it's
> environment then it would likely also follow an EJB/Servlet style setup where
> the container does it via interception and allows components to access it
> programatically via something like
>
> getServletContext().isPrincipleInRole( String role, Principle p );
> getSessionContext().isCallerInRole( String role );
> (or insert real examples here or JAAS).
>
> If the services are things that the container provides to the component as
> part of it's environment then the user perceives them as different to
> services that the component uses. I can't think of one API that actually
> merges the two concepts.
>
> When we tried to merge the two things together the primary reason we separated
> them out again was because of user complaints. ie If a resources requires
> resources A, B and C and C is container provided. All three are accessed in
> the same way so the person sees them as much the same (like the component
> sees them as much the same). However during assembly they are only required
> to assemble A and B - which creates a cognitive dissonance because they are
> treated as identical in one place but different in another.
>
> > So which of these cases do you think offer the most benefit to the
> > component writer? Assume logger, config, params have been split out
> > already: 1. No separation.
> > 2. Separate data and services.
> > 3. Separate container-provided resources and peer-provided resources.
>
> +1
>
> > 4. Separate container-provided data, container-provided services,
> > peer-provided data, and peer-provided services.
> > 5. Who cares? Why are you bothering me with these questions?
>
> :)
>
> --
> Cheers,
>
> Peter Donald
> *------------------------------------------------*
> | Those who know how to think need no teachers. |
> | - Gandhi |
> *------------------------------------------------*
>
>
> --
> To unsubscribe, e-mail: <ma...@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: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote:
> These are useful things, no question. Components need some way to get at
> data and services that are supplied by the container. Again, why do they
> care that a particular service or piece of data was supplied by the
> container or a peer?
Components don't care what the origins of the resource are - all of it is
potentially "contextualized" on a per component basis and all generally has
certain criteria to adhere to but beyond that it is about it. The different
resources are separated out for the sake of humans and no other reason.
Context is separated from ServiceManager because humans see them as different
things - especially during the assembly process.
> Yes, I know that they're "different logical things". But so are, say,
> authentication services and persistence services. We don't use different
> mechanisms to deliver those services to components. It would be pointless
> to do so:
I disagree. If persistence were provided to the component and the component
was effectively made to be an OJB object or something like that then we would
likely provide persistence/transaction capabilities in a very different
manner. Most likely via some transparent EJB-like manner.
In the same way if AAA services were provided to a component as part of it's
environment then it would likely also follow an EJB/Servlet style setup where
the container does it via interception and allows components to access it
programatically via something like
getServletContext().isPrincipleInRole( String role, Principle p );
getSessionContext().isCallerInRole( String role );
(or insert real examples here or JAAS).
If the services are things that the container provides to the component as
part of it's environment then the user perceives them as different to
services that the component uses. I can't think of one API that actually
merges the two concepts.
When we tried to merge the two things together the primary reason we separated
them out again was because of user complaints. ie If a resources requires
resources A, B and C and C is container provided. All three are accessed in
the same way so the person sees them as much the same (like the component
sees them as much the same). However during assembly they are only required
to assemble A and B - which creates a cognitive dissonance because they are
treated as identical in one place but different in another.
> So which of these cases do you think offer the most benefit to the
> component writer? Assume logger, config, params have been split out
> already: 1. No separation.
> 2. Separate data and services.
> 3. Separate container-provided resources and peer-provided resources.
+1
> 4. Separate container-provided data, container-provided services,
> peer-provided data, and peer-provided services.
> 5. Who cares? Why are you bothering me with these questions?
:)
--
Cheers,
Peter Donald
*------------------------------------------------*
| Those who know how to think need no teachers. |
| - Gandhi |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote:
> These are useful things, no question. Components need some way to get at
> data and services that are supplied by the container. Again, why do they
> care that a particular service or piece of data was supplied by the
> container or a peer?
Components don't care what the origins of the resource are - all of it is
potentially "contextualized" on a per component basis and all generally has
certain criteria to adhere to but beyond that it is about it. The different
resources are separated out for the sake of humans and no other reason.
Context is separated from ServiceManager because humans see them as different
things - especially during the assembly process.
> Yes, I know that they're "different logical things". But so are, say,
> authentication services and persistence services. We don't use different
> mechanisms to deliver those services to components. It would be pointless
> to do so:
I disagree. If persistence were provided to the component and the component
was effectively made to be an OJB object or something like that then we would
likely provide persistence/transaction capabilities in a very different
manner. Most likely via some transparent EJB-like manner.
In the same way if AAA services were provided to a component as part of it's
environment then it would likely also follow an EJB/Servlet style setup where
the container does it via interception and allows components to access it
programatically via something like
getServletContext().isPrincipleInRole( String role, Principle p );
getSessionContext().isCallerInRole( String role );
(or insert real examples here or JAAS).
If the services are things that the container provides to the component as
part of it's environment then the user perceives them as different to
services that the component uses. I can't think of one API that actually
merges the two concepts.
When we tried to merge the two things together the primary reason we separated
them out again was because of user complaints. ie If a resources requires
resources A, B and C and C is container provided. All three are accessed in
the same way so the person sees them as much the same (like the component
sees them as much the same). However during assembly they are only required
to assemble A and B - which creates a cognitive dissonance because they are
treated as identical in one place but different in another.
> So which of these cases do you think offer the most benefit to the
> component writer? Assume logger, config, params have been split out
> already: 1. No separation.
> 2. Separate data and services.
> 3. Separate container-provided resources and peer-provided resources.
+1
> 4. Separate container-provided data, container-provided services,
> peer-provided data, and peer-provided services.
> 5. Who cares? Why are you bothering me with these questions?
:)
--
Cheers,
Peter Donald
*------------------------------------------------*
| Those who know how to think need no teachers. |
| - Gandhi |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote:
> These are useful things, no question. Components need some way to get at
> data and services that are supplied by the container. Again, why do they
> care that a particular service or piece of data was supplied by the
> container or a peer?
Components don't care what the origins of the resource are - all of it is
potentially "contextualized" on a per component basis and all generally has
certain criteria to adhere to but beyond that it is about it. The different
resources are separated out for the sake of humans and no other reason.
Context is separated from ServiceManager because humans see them as different
things - especially during the assembly process.
> Yes, I know that they're "different logical things". But so are, say,
> authentication services and persistence services. We don't use different
> mechanisms to deliver those services to components. It would be pointless
> to do so:
I disagree. If persistence were provided to the component and the component
was effectively made to be an OJB object or something like that then we would
likely provide persistence/transaction capabilities in a very different
manner. Most likely via some transparent EJB-like manner.
In the same way if AAA services were provided to a component as part of it's
environment then it would likely also follow an EJB/Servlet style setup where
the container does it via interception and allows components to access it
programatically via something like
getServletContext().isPrincipleInRole( String role, Principle p );
getSessionContext().isCallerInRole( String role );
(or insert real examples here or JAAS).
If the services are things that the container provides to the component as
part of it's environment then the user perceives them as different to
services that the component uses. I can't think of one API that actually
merges the two concepts.
When we tried to merge the two things together the primary reason we separated
them out again was because of user complaints. ie If a resources requires
resources A, B and C and C is container provided. All three are accessed in
the same way so the person sees them as much the same (like the component
sees them as much the same). However during assembly they are only required
to assemble A and B - which creates a cognitive dissonance because they are
treated as identical in one place but different in another.
> So which of these cases do you think offer the most benefit to the
> component writer? Assume logger, config, params have been split out
> already: 1. No separation.
> 2. Separate data and services.
> 3. Separate container-provided resources and peer-provided resources.
+1
> 4. Separate container-provided data, container-provided services,
> peer-provided data, and peer-provided services.
> 5. Who cares? Why are you bothering me with these questions?
:)
--
Cheers,
Peter Donald
*------------------------------------------------*
| Those who know how to think need no teachers. |
| - Gandhi |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
[This is a kinda long, general response]
On Tue, 3 Dec 2002 11:00 pm, Peter Donald wrote:
> On Tue, 3 Dec 2002 23:38, Adam Murdoch wrote:
> > * If it turns out that both are beneficial, we have some more work ahead
> > of us, as neither Context nor ServiceManager reflect this.
>
> Both are beneficial. Useful elements from context;
>
> data:
> - names (including component, partition and application)
> - classloader(s)
> - base deployment directory (potentially work directory aswell)
>
> services:
> - access to input streams of resources stored in deployment package.
> - access to proxying/interceptor chains for current block and ability
> to construct new chains for objects you want to pass around
> - access to "manager" element for current application or parts of current
> application
These are useful things, no question. Components need some way to get at data
and services that are supplied by the container. Again, why do they care
that a particular service or piece of data was supplied by the container or a
peer? To put it in code terms, why is this:
public void contextualize( Context context )
{
proxyFactory = (ProxyFactory)context.get( ProxyFactory.ROLE );
// or, say, proxyFactory = (ProxyFactory)context;
}
public void service( ServiceManager serviceManager )
{
myService = (MyService)serviceManager.lookup( MyService.ROLE );
}
better *for the component writer* than this:
public void service ( ServiceManager serviceManager )
{
proxyFactory = (ProxyFactory)serviceManager.lookup( ProxyFactory.ROLE );
myService = (MyService)serviceManager.lookup( MyService.ROLE );
}
Yes, I know that they're "different logical things". But so are, say,
authentication services and persistence services. We don't use different
mechanisms to deliver those services to components. It would be pointless to
do so:
public void service( ServiceManager serviceManager )
{
authService = (MyAuthenticationService)serviceManager.getAuthService(
MyAuthenticationService.ROLE );
persistService = (MyPersistService)serviceManager.getPersistService(
MyPersistService.ROLE );
}
Why bother? And I'm wondering the same thing of container-provided vs
peer-provided services: Why bother? Does the component care?
Let's look at this another way. As you pointed out, the most general case is
to cram every resource into a single directory:
public void contextualize( Context context )
{
config = (Config)context.get( "well-known-config-name" );
logger = (Logger)context.get( "well-known-logger-name" );
homeDir = (File)context.get( "homedir.name" );
shutdownService = (ShutdownService)context.get( ShutdownService.ROLE );
myService = (MyService)context.get( MyService.ROLE );
}
But this is pretty useless. Much better if the meaning of a resource is
reflected in the framework. The easy ones first:
public void contextualize( Context context )
{
config = context.getConfig();
logger = context.getLogger();
homeDir = (File)context.get( "homedir.name" );
myResource = (String)context.get( "myresource.name" );
shutdownService = (ShutdownService)context.get( ShutdownService.ROLE );
myService = (MyService)context.get( MyService.ROLE );
}
Move the resource types we've identified (config and logger) from
contextualize() to a separate lifecycle method (but that's beside the point
here).
Now let's try to categorise the remaining resources. Once we find a good way
of separating them, then we can add lifecycle methods based on that.
First, try separating passive data and active services:
public void contextualize( Context context )
{
homeDir = (File)context.get( "homedir.name" );
myResource = (String)context.get( "myresource.name" );
shutdownService = (ShutdownService)context.getService(
ShutdownService.ROLE );
myService = (MyService)context.getService( MyService.ROLE );
}
Not too bad, kinda matches how I might use the resources in my code: I treat
homeDir and myResource as immutable pieces of data, and I ask shutdownService
and myService to do stuff for me.
Next, try splitting on container-provided vs peer-provided:
public void contextualize( Context context )
{
homeDir = (File)context.getContainerResource( "homedir.name" );
myResource = (String)context.getPeerResource( "myresource.name" );
shutdownService = (ShutdownService)context.getContainerResource(
ShutdownService.ROLE );
myService = (MyService)context.getPeerResource( MyService.ROLE );
}
This one doesn't really work. The component doesn't care that homeDir was
provided by the container. Would the component use it any differently if it
used getPeerResource() to find it? No. To the component, a home directory
is a home directory. It is not a container-provided home directory or a
peer-provided home directory. Same for the services. A shutdown service is
a shutdown service. Nothing more.
The final case is to split on both container-provided vs peer-provided and
data vs service:
public void contextualize( Context context )
{
homeDir = (File)context.getContainerData( "homedir.name" );
myResource = (String)context.getPeerData( "myresource.name" );
shutdownService = (ShutdownService)context.getContainerService(
ShutdownService.ROLE );
myService = (MyService)context.getPeerService( MyService.ROLE );
}
Ug. Pass :)
So which of these cases do you think offer the most benefit to the component
writer? Assume logger, config, params have been split out already:
1. No separation.
2. Separate data and services.
3. Separate container-provided resources and peer-provided resources.
4. Separate container-provided data, container-provided services,
peer-provided data, and peer-provided services.
5. Who cares? Why are you bothering me with these questions?
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
[This is a kinda long, general response]
On Tue, 3 Dec 2002 11:00 pm, Peter Donald wrote:
> On Tue, 3 Dec 2002 23:38, Adam Murdoch wrote:
> > * If it turns out that both are beneficial, we have some more work ahead
> > of us, as neither Context nor ServiceManager reflect this.
>
> Both are beneficial. Useful elements from context;
>
> data:
> - names (including component, partition and application)
> - classloader(s)
> - base deployment directory (potentially work directory aswell)
>
> services:
> - access to input streams of resources stored in deployment package.
> - access to proxying/interceptor chains for current block and ability
> to construct new chains for objects you want to pass around
> - access to "manager" element for current application or parts of current
> application
These are useful things, no question. Components need some way to get at data
and services that are supplied by the container. Again, why do they care
that a particular service or piece of data was supplied by the container or a
peer? To put it in code terms, why is this:
public void contextualize( Context context )
{
proxyFactory = (ProxyFactory)context.get( ProxyFactory.ROLE );
// or, say, proxyFactory = (ProxyFactory)context;
}
public void service( ServiceManager serviceManager )
{
myService = (MyService)serviceManager.lookup( MyService.ROLE );
}
better *for the component writer* than this:
public void service ( ServiceManager serviceManager )
{
proxyFactory = (ProxyFactory)serviceManager.lookup( ProxyFactory.ROLE );
myService = (MyService)serviceManager.lookup( MyService.ROLE );
}
Yes, I know that they're "different logical things". But so are, say,
authentication services and persistence services. We don't use different
mechanisms to deliver those services to components. It would be pointless to
do so:
public void service( ServiceManager serviceManager )
{
authService = (MyAuthenticationService)serviceManager.getAuthService(
MyAuthenticationService.ROLE );
persistService = (MyPersistService)serviceManager.getPersistService(
MyPersistService.ROLE );
}
Why bother? And I'm wondering the same thing of container-provided vs
peer-provided services: Why bother? Does the component care?
Let's look at this another way. As you pointed out, the most general case is
to cram every resource into a single directory:
public void contextualize( Context context )
{
config = (Config)context.get( "well-known-config-name" );
logger = (Logger)context.get( "well-known-logger-name" );
homeDir = (File)context.get( "homedir.name" );
shutdownService = (ShutdownService)context.get( ShutdownService.ROLE );
myService = (MyService)context.get( MyService.ROLE );
}
But this is pretty useless. Much better if the meaning of a resource is
reflected in the framework. The easy ones first:
public void contextualize( Context context )
{
config = context.getConfig();
logger = context.getLogger();
homeDir = (File)context.get( "homedir.name" );
myResource = (String)context.get( "myresource.name" );
shutdownService = (ShutdownService)context.get( ShutdownService.ROLE );
myService = (MyService)context.get( MyService.ROLE );
}
Move the resource types we've identified (config and logger) from
contextualize() to a separate lifecycle method (but that's beside the point
here).
Now let's try to categorise the remaining resources. Once we find a good way
of separating them, then we can add lifecycle methods based on that.
First, try separating passive data and active services:
public void contextualize( Context context )
{
homeDir = (File)context.get( "homedir.name" );
myResource = (String)context.get( "myresource.name" );
shutdownService = (ShutdownService)context.getService(
ShutdownService.ROLE );
myService = (MyService)context.getService( MyService.ROLE );
}
Not too bad, kinda matches how I might use the resources in my code: I treat
homeDir and myResource as immutable pieces of data, and I ask shutdownService
and myService to do stuff for me.
Next, try splitting on container-provided vs peer-provided:
public void contextualize( Context context )
{
homeDir = (File)context.getContainerResource( "homedir.name" );
myResource = (String)context.getPeerResource( "myresource.name" );
shutdownService = (ShutdownService)context.getContainerResource(
ShutdownService.ROLE );
myService = (MyService)context.getPeerResource( MyService.ROLE );
}
This one doesn't really work. The component doesn't care that homeDir was
provided by the container. Would the component use it any differently if it
used getPeerResource() to find it? No. To the component, a home directory
is a home directory. It is not a container-provided home directory or a
peer-provided home directory. Same for the services. A shutdown service is
a shutdown service. Nothing more.
The final case is to split on both container-provided vs peer-provided and
data vs service:
public void contextualize( Context context )
{
homeDir = (File)context.getContainerData( "homedir.name" );
myResource = (String)context.getPeerData( "myresource.name" );
shutdownService = (ShutdownService)context.getContainerService(
ShutdownService.ROLE );
myService = (MyService)context.getPeerService( MyService.ROLE );
}
Ug. Pass :)
So which of these cases do you think offer the most benefit to the component
writer? Assume logger, config, params have been split out already:
1. No separation.
2. Separate data and services.
3. Separate container-provided resources and peer-provided resources.
4. Separate container-provided data, container-provided services,
peer-provided data, and peer-provided services.
5. Who cares? Why are you bothering me with these questions?
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
[This is a kinda long, general response]
On Tue, 3 Dec 2002 11:00 pm, Peter Donald wrote:
> On Tue, 3 Dec 2002 23:38, Adam Murdoch wrote:
> > * If it turns out that both are beneficial, we have some more work ahead
> > of us, as neither Context nor ServiceManager reflect this.
>
> Both are beneficial. Useful elements from context;
>
> data:
> - names (including component, partition and application)
> - classloader(s)
> - base deployment directory (potentially work directory aswell)
>
> services:
> - access to input streams of resources stored in deployment package.
> - access to proxying/interceptor chains for current block and ability
> to construct new chains for objects you want to pass around
> - access to "manager" element for current application or parts of current
> application
These are useful things, no question. Components need some way to get at data
and services that are supplied by the container. Again, why do they care
that a particular service or piece of data was supplied by the container or a
peer? To put it in code terms, why is this:
public void contextualize( Context context )
{
proxyFactory = (ProxyFactory)context.get( ProxyFactory.ROLE );
// or, say, proxyFactory = (ProxyFactory)context;
}
public void service( ServiceManager serviceManager )
{
myService = (MyService)serviceManager.lookup( MyService.ROLE );
}
better *for the component writer* than this:
public void service ( ServiceManager serviceManager )
{
proxyFactory = (ProxyFactory)serviceManager.lookup( ProxyFactory.ROLE );
myService = (MyService)serviceManager.lookup( MyService.ROLE );
}
Yes, I know that they're "different logical things". But so are, say,
authentication services and persistence services. We don't use different
mechanisms to deliver those services to components. It would be pointless to
do so:
public void service( ServiceManager serviceManager )
{
authService = (MyAuthenticationService)serviceManager.getAuthService(
MyAuthenticationService.ROLE );
persistService = (MyPersistService)serviceManager.getPersistService(
MyPersistService.ROLE );
}
Why bother? And I'm wondering the same thing of container-provided vs
peer-provided services: Why bother? Does the component care?
Let's look at this another way. As you pointed out, the most general case is
to cram every resource into a single directory:
public void contextualize( Context context )
{
config = (Config)context.get( "well-known-config-name" );
logger = (Logger)context.get( "well-known-logger-name" );
homeDir = (File)context.get( "homedir.name" );
shutdownService = (ShutdownService)context.get( ShutdownService.ROLE );
myService = (MyService)context.get( MyService.ROLE );
}
But this is pretty useless. Much better if the meaning of a resource is
reflected in the framework. The easy ones first:
public void contextualize( Context context )
{
config = context.getConfig();
logger = context.getLogger();
homeDir = (File)context.get( "homedir.name" );
myResource = (String)context.get( "myresource.name" );
shutdownService = (ShutdownService)context.get( ShutdownService.ROLE );
myService = (MyService)context.get( MyService.ROLE );
}
Move the resource types we've identified (config and logger) from
contextualize() to a separate lifecycle method (but that's beside the point
here).
Now let's try to categorise the remaining resources. Once we find a good way
of separating them, then we can add lifecycle methods based on that.
First, try separating passive data and active services:
public void contextualize( Context context )
{
homeDir = (File)context.get( "homedir.name" );
myResource = (String)context.get( "myresource.name" );
shutdownService = (ShutdownService)context.getService(
ShutdownService.ROLE );
myService = (MyService)context.getService( MyService.ROLE );
}
Not too bad, kinda matches how I might use the resources in my code: I treat
homeDir and myResource as immutable pieces of data, and I ask shutdownService
and myService to do stuff for me.
Next, try splitting on container-provided vs peer-provided:
public void contextualize( Context context )
{
homeDir = (File)context.getContainerResource( "homedir.name" );
myResource = (String)context.getPeerResource( "myresource.name" );
shutdownService = (ShutdownService)context.getContainerResource(
ShutdownService.ROLE );
myService = (MyService)context.getPeerResource( MyService.ROLE );
}
This one doesn't really work. The component doesn't care that homeDir was
provided by the container. Would the component use it any differently if it
used getPeerResource() to find it? No. To the component, a home directory
is a home directory. It is not a container-provided home directory or a
peer-provided home directory. Same for the services. A shutdown service is
a shutdown service. Nothing more.
The final case is to split on both container-provided vs peer-provided and
data vs service:
public void contextualize( Context context )
{
homeDir = (File)context.getContainerData( "homedir.name" );
myResource = (String)context.getPeerData( "myresource.name" );
shutdownService = (ShutdownService)context.getContainerService(
ShutdownService.ROLE );
myService = (MyService)context.getPeerService( MyService.ROLE );
}
Ug. Pass :)
So which of these cases do you think offer the most benefit to the component
writer? Assume logger, config, params have been split out already:
1. No separation.
2. Separate data and services.
3. Separate container-provided resources and peer-provided resources.
4. Separate container-provided data, container-provided services,
peer-provided data, and peer-provided services.
5. Who cares? Why are you bothering me with these questions?
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 01:30, Berin Loritsch wrote:
> Link?
It was part of the initial documentation dump that went with JSR111 that you
are part of. HP has since mothballed development of it but you can see the
remanents of it at;
http://www.hpmiddleware.com/SaISAPI.dll/SaServletEngine.class/products/core_services_framework/default.jsp
> And I fail to see why we can't have stuff like that handled
> for us automatically....
It can when it manages the creation and passing of references. What happens
when a component wants to pass a reference to itself but wants the reference
to be the proxy (and thus isolated/protected).
Under CSF you did something like
Object me = getServiceContext().getProxy()
//pass me to foreign component here
Or if you wanted to create a new object and pass that object - but make sure
it was correctly proxied and isolated you would do something like
MagicEventListener listener = new MyMagicEventListenerImpl()
MagicEventListener safeListener = (MagicEventListener)
getServiceContext().getProxy( MagicEventListener.class, listener );
//pass safeListener to the foreign event service here
To do anything like this requires interaction with the container and sharing
of the isolation stuff that opnly the container maintains.
--
Cheers,
Peter Donald
-----------------------------------------------
"Only two things are infinite, the universe and
human stupidity, and I'm not sure about the
former." -Albert Einstein
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 01:30, Berin Loritsch wrote:
> Link?
It was part of the initial documentation dump that went with JSR111 that you
are part of. HP has since mothballed development of it but you can see the
remanents of it at;
http://www.hpmiddleware.com/SaISAPI.dll/SaServletEngine.class/products/core_services_framework/default.jsp
> And I fail to see why we can't have stuff like that handled
> for us automatically....
It can when it manages the creation and passing of references. What happens
when a component wants to pass a reference to itself but wants the reference
to be the proxy (and thus isolated/protected).
Under CSF you did something like
Object me = getServiceContext().getProxy()
//pass me to foreign component here
Or if you wanted to create a new object and pass that object - but make sure
it was correctly proxied and isolated you would do something like
MagicEventListener listener = new MyMagicEventListenerImpl()
MagicEventListener safeListener = (MagicEventListener)
getServiceContext().getProxy( MagicEventListener.class, listener );
//pass safeListener to the foreign event service here
To do anything like this requires interaction with the container and sharing
of the isolation stuff that opnly the container maintains.
--
Cheers,
Peter Donald
-----------------------------------------------
"Only two things are infinite, the universe and
human stupidity, and I'm not sure about the
former." -Albert Einstein
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 01:30, Berin Loritsch wrote:
> Link?
It was part of the initial documentation dump that went with JSR111 that you
are part of. HP has since mothballed development of it but you can see the
remanents of it at;
http://www.hpmiddleware.com/SaISAPI.dll/SaServletEngine.class/products/core_services_framework/default.jsp
> And I fail to see why we can't have stuff like that handled
> for us automatically....
It can when it manages the creation and passing of references. What happens
when a component wants to pass a reference to itself but wants the reference
to be the proxy (and thus isolated/protected).
Under CSF you did something like
Object me = getServiceContext().getProxy()
//pass me to foreign component here
Or if you wanted to create a new object and pass that object - but make sure
it was correctly proxied and isolated you would do something like
MagicEventListener listener = new MyMagicEventListenerImpl()
MagicEventListener safeListener = (MagicEventListener)
getServiceContext().getProxy( MagicEventListener.class, listener );
//pass safeListener to the foreign event service here
To do anything like this requires interaction with the container and sharing
of the isolation stuff that opnly the container maintains.
--
Cheers,
Peter Donald
-----------------------------------------------
"Only two things are infinite, the universe and
human stupidity, and I'm not sure about the
former." -Albert Einstein
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Wed, 4 Dec 2002 00:16, Berin Loritsch wrote:
> > > - access to proxying/interceptor chains for current
> block and ability
> > > to construct new chains for objects you want to pass around
> > >
> > :/ Just make it a decent library.
>
> That will happen anyways but that has little to do with what
> I am talking
> about. A block has to have access to the current runtime
> state of the chain
> and has to be able to bind components to existing chains to
> maintain the
> correct isolation contexts. Have a look at how HPs CSF does
> it and more
> importantly their documentation on why they do it.
Link?
And I fail to see why we can't have stuff like that handled
for us automatically....
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Wed, 4 Dec 2002 00:16, Berin Loritsch wrote:
> > > - access to proxying/interceptor chains for current
> block and ability
> > > to construct new chains for objects you want to pass around
> > >
> > :/ Just make it a decent library.
>
> That will happen anyways but that has little to do with what
> I am talking
> about. A block has to have access to the current runtime
> state of the chain
> and has to be able to bind components to existing chains to
> maintain the
> correct isolation contexts. Have a look at how HPs CSF does
> it and more
> importantly their documentation on why they do it.
Link?
And I fail to see why we can't have stuff like that handled
for us automatically....
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Wed, 4 Dec 2002 00:16, Berin Loritsch wrote:
> > > - access to proxying/interceptor chains for current
> block and ability
> > > to construct new chains for objects you want to pass around
> > >
> > :/ Just make it a decent library.
>
> That will happen anyways but that has little to do with what
> I am talking
> about. A block has to have access to the current runtime
> state of the chain
> and has to be able to bind components to existing chains to
> maintain the
> correct isolation contexts. Have a look at how HPs CSF does
> it and more
> importantly their documentation on why they do it.
Link?
And I fail to see why we can't have stuff like that handled
for us automatically....
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 00:16, Berin Loritsch wrote:
> > - access to proxying/interceptor chains for current block and ability
> > to construct new chains for objects you want to pass around
> >
> :/ Just make it a decent library.
That will happen anyways but that has little to do with what I am talking
about. A block has to have access to the current runtime state of the chain
and has to be able to bind components to existing chains to maintain the
correct isolation contexts. Have a look at how HPs CSF does it and more
importantly their documentation on why they do it.
--
Cheers,
Peter Donald
*----------------------------------------------------------*
The phrase "computer literate user" really means the person
has been hurt so many times that the scar tissue is thick
enough so he no longer feels the pain.
-- Alan Cooper, The Inmates are Running the Asylum
*----------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Wed, 4 Dec 2002 00:16, Berin Loritsch wrote:
> > I have never yielded on this one point: A component should
> never, ever
> > be able to tell a container what to do. Period.
>
> And strangely enough "requestShutDown()" does not tell a
> container what to do
> - it requests that a container make a change. A container is
> free to ignore
> that request if it so desires ;)
It is still a dangerous construct. It leaves the door wide
open for a naive implementation. It also begs to be abused.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Wed, 4 Dec 2002 00:16, Berin Loritsch wrote:
> > I have never yielded on this one point: A component should
> never, ever
> > be able to tell a container what to do. Period.
>
> And strangely enough "requestShutDown()" does not tell a
> container what to do
> - it requests that a container make a change. A container is
> free to ignore
> that request if it so desires ;)
It is still a dangerous construct. It leaves the door wide
open for a naive implementation. It also begs to be abused.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Wed, 4 Dec 2002 00:16, Berin Loritsch wrote:
> > I have never yielded on this one point: A component should
> never, ever
> > be able to tell a container what to do. Period.
>
> And strangely enough "requestShutDown()" does not tell a
> container what to do
> - it requests that a container make a change. A container is
> free to ignore
> that request if it so desires ;)
It is still a dangerous construct. It leaves the door wide
open for a naive implementation. It also begs to be abused.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 00:16, Berin Loritsch wrote:
> I have never yielded on this one point: A component should never, ever
> be able to tell a container what to do. Period.
And strangely enough "requestShutDown()" does not tell a container what to do
- it requests that a container make a change. A container is free to ignore
that request if it so desires ;)
--
Cheers,
Peter Donald
Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 00:16, Berin Loritsch wrote:
> > - access to proxying/interceptor chains for current block and ability
> > to construct new chains for objects you want to pass around
> >
> :/ Just make it a decent library.
That will happen anyways but that has little to do with what I am talking
about. A block has to have access to the current runtime state of the chain
and has to be able to bind components to existing chains to maintain the
correct isolation contexts. Have a look at how HPs CSF does it and more
importantly their documentation on why they do it.
--
Cheers,
Peter Donald
*----------------------------------------------------------*
The phrase "computer literate user" really means the person
has been hurt so many times that the scar tissue is thick
enough so he no longer feels the pain.
-- Alan Cooper, The Inmates are Running the Asylum
*----------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 00:16, Berin Loritsch wrote:
> > - access to proxying/interceptor chains for current block and ability
> > to construct new chains for objects you want to pass around
> >
> :/ Just make it a decent library.
That will happen anyways but that has little to do with what I am talking
about. A block has to have access to the current runtime state of the chain
and has to be able to bind components to existing chains to maintain the
correct isolation contexts. Have a look at how HPs CSF does it and more
importantly their documentation on why they do it.
--
Cheers,
Peter Donald
*----------------------------------------------------------*
The phrase "computer literate user" really means the person
has been hurt so many times that the scar tissue is thick
enough so he no longer feels the pain.
-- Alan Cooper, The Inmates are Running the Asylum
*----------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 00:16, Berin Loritsch wrote:
> I have never yielded on this one point: A component should never, ever
> be able to tell a container what to do. Period.
And strangely enough "requestShutDown()" does not tell a container what to do
- it requests that a container make a change. A container is free to ignore
that request if it so desires ;)
--
Cheers,
Peter Donald
Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 00:16, Berin Loritsch wrote:
> I have never yielded on this one point: A component should never, ever
> be able to tell a container what to do. Period.
And strangely enough "requestShutDown()" does not tell a container what to do
- it requests that a container make a change. A container is free to ignore
that request if it so desires ;)
--
Cheers,
Peter Donald
Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Berin,
> I have never yielded on this one point: A component should never, ever
> be able to tell a container what to do. Period.
Ok, why? If you mean force a container to do something, I agree with
you. If you mean request that a container carry out an action, I don't
see why it's a problem.
> The process of shutting down a container should be done by a
management
> system exposed to the administrator, but not from any child component.
> I don't know if any of you have kids, but imagine one of them
defiantly
> telling you where to go.... It doesn't fly, and it doesn't work. If
> you allow your natural kids to run your lives your house would be in
> chaos. How can that work for components--esp. when some might be
truly
> evil or poorly written.
Why can't a component ask (i.e. request) that the system be shut down?
More specifically, why couldn't a component ask that it be stopped? Or
that some set of components be stopped? This would be a request made of
the container...
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Berin,
> I have never yielded on this one point: A component should never, ever
> be able to tell a container what to do. Period.
Ok, why? If you mean force a container to do something, I agree with
you. If you mean request that a container carry out an action, I don't
see why it's a problem.
> The process of shutting down a container should be done by a
management
> system exposed to the administrator, but not from any child component.
> I don't know if any of you have kids, but imagine one of them
defiantly
> telling you where to go.... It doesn't fly, and it doesn't work. If
> you allow your natural kids to run your lives your house would be in
> chaos. How can that work for components--esp. when some might be
truly
> evil or poorly written.
Why can't a component ask (i.e. request) that the system be shut down?
More specifically, why couldn't a component ask that it be stopped? Or
that some set of components be stopped? This would be a request made of
the container...
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Berin,
> I have never yielded on this one point: A component should never, ever
> be able to tell a container what to do. Period.
Ok, why? If you mean force a container to do something, I agree with
you. If you mean request that a container carry out an action, I don't
see why it's a problem.
> The process of shutting down a container should be done by a
management
> system exposed to the administrator, but not from any child component.
> I don't know if any of you have kids, but imagine one of them
defiantly
> telling you where to go.... It doesn't fly, and it doesn't work. If
> you allow your natural kids to run your lives your house would be in
> chaos. How can that work for components--esp. when some might be
truly
> evil or poorly written.
Why can't a component ask (i.e. request) that the system be shut down?
More specifically, why couldn't a component ask that it be stopped? Or
that some set of components be stopped? This would be a request made of
the container...
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Tue, 3 Dec 2002 23:38, Adam Murdoch wrote:
> > * If it turns out that both are beneficial, we have some
> more work ahead of
> > us, as neither Context nor ServiceManager reflect this.
>
> Both are beneficial. Useful elements from context;
>
> data:
> - names (including component, partition and application)
> - classloader(s)
> - base deployment directory (potentially work directory aswell)
Keep in mind that a work directory can be a temporary directory
that is completely separate.
> services:
> - access to input streams of resources stored in deployment package.
I consider this data.
> - access to proxying/interceptor chains for current block and ability
> to construct new chains for objects you want to pass around
:/ Just make it a decent library.
> - access to "manager" element for current application or
> parts of current
> application
I have never yielded on this one point: A component should never, ever
be able to tell a container what to do. Period.
The fact that the BlockContext has the "requestShutDown()" method is
a testimony to the disservice that having Phoenix-Dev separate from
the rest of Avalon-Dev.
The process of shutting down a container should be done by a management
system exposed to the administrator, but not from any child component.
I don't know if any of you have kids, but imagine one of them defiantly
telling you where to go.... It doesn't fly, and it doesn't work. If
you allow your natural kids to run your lives your house would be in
chaos. How can that work for components--esp. when some might be truly
evil or poorly written.
If there was a way to override System.exit(), I would do that to fully
prevent any component from forcing a shutdown.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context is flawed, long live Context
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-12-03 at 15:31, Peter Donald wrote:
> On Wed, 4 Dec 2002 00:28, Berin Loritsch wrote:
> > Truth be told, the best we can do with Avalon's context is define
> > standards for what information gets bound in there. That will be
> > the Avalon context. There are other application specific components
> > that follow a different model from Avalon--examples include EJBs,
> > Servlets, and Axis components (web services). Each of those need
> > a container for their components that is domain specific. The new
> > container needs to be extensible enough to satisfy them.
>
> Do I get to say I told you so yet ? ;)
not yet, you don't ;)
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context is flawed, long live Context
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-12-03 at 15:31, Peter Donald wrote:
> On Wed, 4 Dec 2002 00:28, Berin Loritsch wrote:
> > Truth be told, the best we can do with Avalon's context is define
> > standards for what information gets bound in there. That will be
> > the Avalon context. There are other application specific components
> > that follow a different model from Avalon--examples include EJBs,
> > Servlets, and Axis components (web services). Each of those need
> > a container for their components that is domain specific. The new
> > container needs to be extensible enough to satisfy them.
>
> Do I get to say I told you so yet ? ;)
not yet, you don't ;)
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context is flawed, long live Context
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-12-03 at 15:31, Peter Donald wrote:
> On Wed, 4 Dec 2002 00:28, Berin Loritsch wrote:
> > Truth be told, the best we can do with Avalon's context is define
> > standards for what information gets bound in there. That will be
> > the Avalon context. There are other application specific components
> > that follow a different model from Avalon--examples include EJBs,
> > Servlets, and Axis components (web services). Each of those need
> > a container for their components that is domain specific. The new
> > container needs to be extensible enough to satisfy them.
>
> Do I get to say I told you so yet ? ;)
not yet, you don't ;)
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context is flawed, long live Context
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 01:29, Berin Loritsch wrote:
> > From: Peter Donald [mailto:peter@realityforge.org]
> >
> > On Wed, 4 Dec 2002 00:28, Berin Loritsch wrote:
> > > Truth be told, the best we can do with Avalon's context is define
> > > standards for what information gets bound in there. That will be
> > > the Avalon context. There are other application specific components
> > > that follow a different model from Avalon--examples include EJBs,
> > > Servlets, and Axis components (web services). Each of those need
> > > a container for their components that is domain specific. The new
> > > container needs to be extensible enough to satisfy them.
> >
> > Do I get to say I told you so yet ? ;)
>
> No, because history shows that you introduced Context.
Not quite - Context was here before I got here. I believe it predates
ComponentManager which was split out from it.
--
Cheers,
Peter Donald
*------------------------------------------------*
| Those who know how to think need no teachers. |
| - Gandhi |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context is flawed, long live Context
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 01:29, Berin Loritsch wrote:
> > From: Peter Donald [mailto:peter@realityforge.org]
> >
> > On Wed, 4 Dec 2002 00:28, Berin Loritsch wrote:
> > > Truth be told, the best we can do with Avalon's context is define
> > > standards for what information gets bound in there. That will be
> > > the Avalon context. There are other application specific components
> > > that follow a different model from Avalon--examples include EJBs,
> > > Servlets, and Axis components (web services). Each of those need
> > > a container for their components that is domain specific. The new
> > > container needs to be extensible enough to satisfy them.
> >
> > Do I get to say I told you so yet ? ;)
>
> No, because history shows that you introduced Context.
Not quite - Context was here before I got here. I believe it predates
ComponentManager which was split out from it.
--
Cheers,
Peter Donald
*------------------------------------------------*
| Those who know how to think need no teachers. |
| - Gandhi |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context is flawed, long live Context
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 01:29, Berin Loritsch wrote:
> > From: Peter Donald [mailto:peter@realityforge.org]
> >
> > On Wed, 4 Dec 2002 00:28, Berin Loritsch wrote:
> > > Truth be told, the best we can do with Avalon's context is define
> > > standards for what information gets bound in there. That will be
> > > the Avalon context. There are other application specific components
> > > that follow a different model from Avalon--examples include EJBs,
> > > Servlets, and Axis components (web services). Each of those need
> > > a container for their components that is domain specific. The new
> > > container needs to be extensible enough to satisfy them.
> >
> > Do I get to say I told you so yet ? ;)
>
> No, because history shows that you introduced Context.
Not quite - Context was here before I got here. I believe it predates
ComponentManager which was split out from it.
--
Cheers,
Peter Donald
*------------------------------------------------*
| Those who know how to think need no teachers. |
| - Gandhi |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context is flawed, long live Context
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Wed, 4 Dec 2002 00:28, Berin Loritsch wrote:
> > Truth be told, the best we can do with Avalon's context is define
> > standards for what information gets bound in there. That will be
> > the Avalon context. There are other application specific components
> > that follow a different model from Avalon--examples include EJBs,
> > Servlets, and Axis components (web services). Each of those need
> > a container for their components that is domain specific. The new
> > container needs to be extensible enough to satisfy them.
>
> Do I get to say I told you so yet ? ;)
No, because history shows that you introduced Context.
BTW, the "I told you so" remarks do not help to build
community. Can you tell yourself "so"?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context is flawed, long live Context
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Wed, 4 Dec 2002 00:28, Berin Loritsch wrote:
> > Truth be told, the best we can do with Avalon's context is define
> > standards for what information gets bound in there. That will be
> > the Avalon context. There are other application specific components
> > that follow a different model from Avalon--examples include EJBs,
> > Servlets, and Axis components (web services). Each of those need
> > a container for their components that is domain specific. The new
> > container needs to be extensible enough to satisfy them.
>
> Do I get to say I told you so yet ? ;)
No, because history shows that you introduced Context.
BTW, the "I told you so" remarks do not help to build
community. Can you tell yourself "so"?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context is flawed, long live Context
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Wed, 4 Dec 2002 00:28, Berin Loritsch wrote:
> > Truth be told, the best we can do with Avalon's context is define
> > standards for what information gets bound in there. That will be
> > the Avalon context. There are other application specific components
> > that follow a different model from Avalon--examples include EJBs,
> > Servlets, and Axis components (web services). Each of those need
> > a container for their components that is domain specific. The new
> > container needs to be extensible enough to satisfy them.
>
> Do I get to say I told you so yet ? ;)
No, because history shows that you introduced Context.
BTW, the "I told you so" remarks do not help to build
community. Can you tell yourself "so"?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context is flawed, long live Context
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 00:28, Berin Loritsch wrote:
> Truth be told, the best we can do with Avalon's context is define
> standards for what information gets bound in there. That will be
> the Avalon context. There are other application specific components
> that follow a different model from Avalon--examples include EJBs,
> Servlets, and Axis components (web services). Each of those need
> a container for their components that is domain specific. The new
> container needs to be extensible enough to satisfy them.
Do I get to say I told you so yet ? ;)
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Religion is what the common people see as true, the |
| wise people see as false, and the rulers see as |
| useful" --Seneca |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context is flawed, long live Context
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 00:28, Berin Loritsch wrote:
> Truth be told, the best we can do with Avalon's context is define
> standards for what information gets bound in there. That will be
> the Avalon context. There are other application specific components
> that follow a different model from Avalon--examples include EJBs,
> Servlets, and Axis components (web services). Each of those need
> a container for their components that is domain specific. The new
> container needs to be extensible enough to satisfy them.
Do I get to say I told you so yet ? ;)
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Religion is what the common people see as true, the |
| wise people see as false, and the rulers see as |
| useful" --Seneca |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context is flawed, long live Context
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 00:28, Berin Loritsch wrote:
> Truth be told, the best we can do with Avalon's context is define
> standards for what information gets bound in there. That will be
> the Avalon context. There are other application specific components
> that follow a different model from Avalon--examples include EJBs,
> Servlets, and Axis components (web services). Each of those need
> a container for their components that is domain specific. The new
> container needs to be extensible enough to satisfy them.
Do I get to say I told you so yet ? ;)
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Religion is what the common people see as true, the |
| wise people see as false, and the rulers see as |
| useful" --Seneca |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Context is flawed, long live Context
Posted by Berin Loritsch <bl...@citi-us.com>.
I honestly have to say that the Context object in and of itself
is a flawed implementation. Don't get me wrong, the idea behind
it is wonderful. The problem with the whole Context concept is
that the Context is very dependent on its environment.
Concidering all the hubbub surrounding this one innocent looking
object, no-one can come to agreement on its best use. In order
to better understand how and when to use a Context we need to
look at other systems that have their own Context object. Those
include Servlets, Mailets, and Phoenix Context (AKA BlockContext).
Truth be told, we don't have a unified concept beyond we get
Objects by name out of it. The Phoenix variation exposes what
IMNSHO are dangerous services that no component should ever have
access to. However it shares a few things in common with Servlets,
but not Mailets. Same thing with the other two. There really is
only one thing that might be the same across all three--but that
is summed up in the current Context interface.
Truth be told, the best we can do with Avalon's context is define
standards for what information gets bound in there. That will be
the Avalon context. There are other application specific components
that follow a different model from Avalon--examples include EJBs,
Servlets, and Axis components (web services). Each of those need
a container for their components that is domain specific. The new
container needs to be extensible enough to satisfy them.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Tue, 3 Dec 2002 23:38, Adam Murdoch wrote:
> > * If it turns out that both are beneficial, we have some
> more work ahead of
> > us, as neither Context nor ServiceManager reflect this.
>
> Both are beneficial. Useful elements from context;
>
> data:
> - names (including component, partition and application)
> - classloader(s)
> - base deployment directory (potentially work directory aswell)
Keep in mind that a work directory can be a temporary directory
that is completely separate.
> services:
> - access to input streams of resources stored in deployment package.
I consider this data.
> - access to proxying/interceptor chains for current block and ability
> to construct new chains for objects you want to pass around
:/ Just make it a decent library.
> - access to "manager" element for current application or
> parts of current
> application
I have never yielded on this one point: A component should never, ever
be able to tell a container what to do. Period.
The fact that the BlockContext has the "requestShutDown()" method is
a testimony to the disservice that having Phoenix-Dev separate from
the rest of Avalon-Dev.
The process of shutting down a container should be done by a management
system exposed to the administrator, but not from any child component.
I don't know if any of you have kids, but imagine one of them defiantly
telling you where to go.... It doesn't fly, and it doesn't work. If
you allow your natural kids to run your lives your house would be in
chaos. How can that work for components--esp. when some might be truly
evil or poorly written.
If there was a way to override System.exit(), I would do that to fully
prevent any component from forcing a shutdown.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Tue, 3 Dec 2002 23:38, Adam Murdoch wrote:
> > * If it turns out that both are beneficial, we have some
> more work ahead of
> > us, as neither Context nor ServiceManager reflect this.
>
> Both are beneficial. Useful elements from context;
>
> data:
> - names (including component, partition and application)
> - classloader(s)
> - base deployment directory (potentially work directory aswell)
Keep in mind that a work directory can be a temporary directory
that is completely separate.
> services:
> - access to input streams of resources stored in deployment package.
I consider this data.
> - access to proxying/interceptor chains for current block and ability
> to construct new chains for objects you want to pass around
:/ Just make it a decent library.
> - access to "manager" element for current application or
> parts of current
> application
I have never yielded on this one point: A component should never, ever
be able to tell a container what to do. Period.
The fact that the BlockContext has the "requestShutDown()" method is
a testimony to the disservice that having Phoenix-Dev separate from
the rest of Avalon-Dev.
The process of shutting down a container should be done by a management
system exposed to the administrator, but not from any child component.
I don't know if any of you have kids, but imagine one of them defiantly
telling you where to go.... It doesn't fly, and it doesn't work. If
you allow your natural kids to run your lives your house would be in
chaos. How can that work for components--esp. when some might be truly
evil or poorly written.
If there was a way to override System.exit(), I would do that to fully
prevent any component from forcing a shutdown.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Context is flawed, long live Context
Posted by Berin Loritsch <bl...@citi-us.com>.
I honestly have to say that the Context object in and of itself
is a flawed implementation. Don't get me wrong, the idea behind
it is wonderful. The problem with the whole Context concept is
that the Context is very dependent on its environment.
Concidering all the hubbub surrounding this one innocent looking
object, no-one can come to agreement on its best use. In order
to better understand how and when to use a Context we need to
look at other systems that have their own Context object. Those
include Servlets, Mailets, and Phoenix Context (AKA BlockContext).
Truth be told, we don't have a unified concept beyond we get
Objects by name out of it. The Phoenix variation exposes what
IMNSHO are dangerous services that no component should ever have
access to. However it shares a few things in common with Servlets,
but not Mailets. Same thing with the other two. There really is
only one thing that might be the same across all three--but that
is summed up in the current Context interface.
Truth be told, the best we can do with Avalon's context is define
standards for what information gets bound in there. That will be
the Avalon context. There are other application specific components
that follow a different model from Avalon--examples include EJBs,
Servlets, and Axis components (web services). Each of those need
a container for their components that is domain specific. The new
container needs to be extensible enough to satisfy them.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Context is flawed, long live Context
Posted by Berin Loritsch <bl...@citi-us.com>.
I honestly have to say that the Context object in and of itself
is a flawed implementation. Don't get me wrong, the idea behind
it is wonderful. The problem with the whole Context concept is
that the Context is very dependent on its environment.
Concidering all the hubbub surrounding this one innocent looking
object, no-one can come to agreement on its best use. In order
to better understand how and when to use a Context we need to
look at other systems that have their own Context object. Those
include Servlets, Mailets, and Phoenix Context (AKA BlockContext).
Truth be told, we don't have a unified concept beyond we get
Objects by name out of it. The Phoenix variation exposes what
IMNSHO are dangerous services that no component should ever have
access to. However it shares a few things in common with Servlets,
but not Mailets. Same thing with the other two. There really is
only one thing that might be the same across all three--but that
is summed up in the current Context interface.
Truth be told, the best we can do with Avalon's context is define
standards for what information gets bound in there. That will be
the Avalon context. There are other application specific components
that follow a different model from Avalon--examples include EJBs,
Servlets, and Axis components (web services). Each of those need
a container for their components that is domain specific. The new
container needs to be extensible enough to satisfy them.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 23:38, Adam Murdoch wrote:
> * If it turns out that both are beneficial, we have some more work ahead of
> us, as neither Context nor ServiceManager reflect this.
Both are beneficial. Useful elements from context;
data:
- names (including component, partition and application)
- classloader(s)
- base deployment directory (potentially work directory aswell)
services:
- access to input streams of resources stored in deployment package.
- access to proxying/interceptor chains for current block and ability
to construct new chains for objects you want to pass around
- access to "manager" element for current application or parts of current
application
However the distinction between data and services may be artificial because
any data element can be represented as a service (the service being the thing
that provides data elements).
--
Cheers,
Peter Donald
*-------------------------------------------------*
| An eye for eye only ends up making the whole |
| world blind. - Gandhi |
*-------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 23:38, Adam Murdoch wrote:
> * If it turns out that both are beneficial, we have some more work ahead of
> us, as neither Context nor ServiceManager reflect this.
Both are beneficial. Useful elements from context;
data:
- names (including component, partition and application)
- classloader(s)
- base deployment directory (potentially work directory aswell)
services:
- access to input streams of resources stored in deployment package.
- access to proxying/interceptor chains for current block and ability
to construct new chains for objects you want to pass around
- access to "manager" element for current application or parts of current
application
However the distinction between data and services may be artificial because
any data element can be represented as a service (the service being the thing
that provides data elements).
--
Cheers,
Peter Donald
*-------------------------------------------------*
| An eye for eye only ends up making the whole |
| world blind. - Gandhi |
*-------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 23:38, Adam Murdoch wrote:
> * If it turns out that both are beneficial, we have some more work ahead of
> us, as neither Context nor ServiceManager reflect this.
Both are beneficial. Useful elements from context;
data:
- names (including component, partition and application)
- classloader(s)
- base deployment directory (potentially work directory aswell)
services:
- access to input streams of resources stored in deployment package.
- access to proxying/interceptor chains for current block and ability
to construct new chains for objects you want to pass around
- access to "manager" element for current application or parts of current
application
However the distinction between data and services may be artificial because
any data element can be represented as a service (the service being the thing
that provides data elements).
--
Cheers,
Peter Donald
*-------------------------------------------------*
| An eye for eye only ends up making the whole |
| world blind. - Gandhi |
*-------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Tue, 3 Dec 2002 08:52 pm, Peter Donald wrote:
> oops - sent when I meant to save as draft and finish later ... I clarify
> now then.
>
> On Tue, 3 Dec 2002 21:45, Peter Donald wrote:
> > On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
> > > Sure. These are good examples of why everyone wins when there's a nice
> > > match between what a resource means to a component, and how the
> > > resource is delivered to the component. If the component wants a
> > > logger, give it a logger. If the component wants config, give it
> > > config. etc. Maybe the same resource is presented in different ways
> > > depending on how the component asks for it. Maybe not. Component
> > > doesn't care.
> > >
> > > But the examples don't really answer the question: Why is it useful,
> > > when a component asks for a resource of a particular type, to
> > > distinguish between resources of that type that are provided by the
> > > container, and resources of that type that are provided by other
> > > components?
> >
> > I don't really understand what you are getting at.
Yeah, good question :)
I don't necessarily want to change anything. I started off wondering what,
exactly, Context is all about; What it means, and what it gives me as a
component writer. The framework doesn't clearly define what a Context is,
and the interface itself is useless: Object get( Object )? Please.
And it seems there is no real consensus on avalon-dev about what Context
means. In fact, avalon-dev seems to advocate using Context for 2 unrelated
things:
* Container-provided data and services. Peer-provided services end up in
ServiceManager, and presumably there's no such thing as peer-provided data.
* Data (presumably container-provided, but not really clear). Services end up
in ServiceManager.
All warning signs: A poorly-defined contract (or poorly understood, at
least), a hyper-abstract interface, 2 separate usages, unresolved discussions
about what it should mean. All suggest something's wrong with the current
abstractions. Maybe there's a new abstraction that needs to be split out;
maybe a real abstraction has been fragmented; maybe there's an artificial
abstraction that needs to be done away with. I don't know.
To me, the best way to figure this out to start with the 2 use cases above,
and question whether they really are useful to a component writer. Once we
know that, the solution is considerably easier:
* If it turns out that neither are really beneficial, well, then there's no
real point in keeping Context.
* If it turns out that one use case is beneficial and the other isn't, tighten
up the contract on Context to reflect this. And maybe make Context and
ServiceManager consistent like you've suggested.
* If it turns out that both are beneficial, we have some more work ahead of
us, as neither Context nor ServiceManager reflect this.
So, I'm not advocating any code change, because I don't know what form that
should take. Hence all the questions :)
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Tue, 3 Dec 2002 08:52 pm, Peter Donald wrote:
> oops - sent when I meant to save as draft and finish later ... I clarify
> now then.
>
> On Tue, 3 Dec 2002 21:45, Peter Donald wrote:
> > On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
> > > Sure. These are good examples of why everyone wins when there's a nice
> > > match between what a resource means to a component, and how the
> > > resource is delivered to the component. If the component wants a
> > > logger, give it a logger. If the component wants config, give it
> > > config. etc. Maybe the same resource is presented in different ways
> > > depending on how the component asks for it. Maybe not. Component
> > > doesn't care.
> > >
> > > But the examples don't really answer the question: Why is it useful,
> > > when a component asks for a resource of a particular type, to
> > > distinguish between resources of that type that are provided by the
> > > container, and resources of that type that are provided by other
> > > components?
> >
> > I don't really understand what you are getting at.
Yeah, good question :)
I don't necessarily want to change anything. I started off wondering what,
exactly, Context is all about; What it means, and what it gives me as a
component writer. The framework doesn't clearly define what a Context is,
and the interface itself is useless: Object get( Object )? Please.
And it seems there is no real consensus on avalon-dev about what Context
means. In fact, avalon-dev seems to advocate using Context for 2 unrelated
things:
* Container-provided data and services. Peer-provided services end up in
ServiceManager, and presumably there's no such thing as peer-provided data.
* Data (presumably container-provided, but not really clear). Services end up
in ServiceManager.
All warning signs: A poorly-defined contract (or poorly understood, at
least), a hyper-abstract interface, 2 separate usages, unresolved discussions
about what it should mean. All suggest something's wrong with the current
abstractions. Maybe there's a new abstraction that needs to be split out;
maybe a real abstraction has been fragmented; maybe there's an artificial
abstraction that needs to be done away with. I don't know.
To me, the best way to figure this out to start with the 2 use cases above,
and question whether they really are useful to a component writer. Once we
know that, the solution is considerably easier:
* If it turns out that neither are really beneficial, well, then there's no
real point in keeping Context.
* If it turns out that one use case is beneficial and the other isn't, tighten
up the contract on Context to reflect this. And maybe make Context and
ServiceManager consistent like you've suggested.
* If it turns out that both are beneficial, we have some more work ahead of
us, as neither Context nor ServiceManager reflect this.
So, I'm not advocating any code change, because I don't know what form that
should take. Hence all the questions :)
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Tue, 3 Dec 2002 08:52 pm, Peter Donald wrote:
> oops - sent when I meant to save as draft and finish later ... I clarify
> now then.
>
> On Tue, 3 Dec 2002 21:45, Peter Donald wrote:
> > On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
> > > Sure. These are good examples of why everyone wins when there's a nice
> > > match between what a resource means to a component, and how the
> > > resource is delivered to the component. If the component wants a
> > > logger, give it a logger. If the component wants config, give it
> > > config. etc. Maybe the same resource is presented in different ways
> > > depending on how the component asks for it. Maybe not. Component
> > > doesn't care.
> > >
> > > But the examples don't really answer the question: Why is it useful,
> > > when a component asks for a resource of a particular type, to
> > > distinguish between resources of that type that are provided by the
> > > container, and resources of that type that are provided by other
> > > components?
> >
> > I don't really understand what you are getting at.
Yeah, good question :)
I don't necessarily want to change anything. I started off wondering what,
exactly, Context is all about; What it means, and what it gives me as a
component writer. The framework doesn't clearly define what a Context is,
and the interface itself is useless: Object get( Object )? Please.
And it seems there is no real consensus on avalon-dev about what Context
means. In fact, avalon-dev seems to advocate using Context for 2 unrelated
things:
* Container-provided data and services. Peer-provided services end up in
ServiceManager, and presumably there's no such thing as peer-provided data.
* Data (presumably container-provided, but not really clear). Services end up
in ServiceManager.
All warning signs: A poorly-defined contract (or poorly understood, at
least), a hyper-abstract interface, 2 separate usages, unresolved discussions
about what it should mean. All suggest something's wrong with the current
abstractions. Maybe there's a new abstraction that needs to be split out;
maybe a real abstraction has been fragmented; maybe there's an artificial
abstraction that needs to be done away with. I don't know.
To me, the best way to figure this out to start with the 2 use cases above,
and question whether they really are useful to a component writer. Once we
know that, the solution is considerably easier:
* If it turns out that neither are really beneficial, well, then there's no
real point in keeping Context.
* If it turns out that one use case is beneficial and the other isn't, tighten
up the contract on Context to reflect this. And maybe make Context and
ServiceManager consistent like you've suggested.
* If it turns out that both are beneficial, we have some more work ahead of
us, as neither Context nor ServiceManager reflect this.
So, I'm not advocating any code change, because I don't know what form that
should take. Hence all the questions :)
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
oops - sent when I meant to save as draft and finish later ... I clarify now
then.
On Tue, 3 Dec 2002 21:45, Peter Donald wrote:
> On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
> > Sure. These are good examples of why everyone wins when there's a nice
> > match between what a resource means to a component, and how the resource
> > is delivered to the component. If the component wants a logger, give it
> > a logger. If the component wants config, give it config. etc. Maybe
> > the same resource is presented in different ways depending on how the
> > component asks for it. Maybe not. Component doesn't care.
> >
> > But the examples don't really answer the question: Why is it useful,
> > when a component asks for a resource of a particular type, to distinguish
> > between resources of that type that are provided by the container, and
> > resources of that type that are provided by other components?
>
> I don't really understand what you are getting at. If you are wanting to
> unify the interface then this has already proposed - I actually created
> another service API recently that looked something like
>
> interface Composable
> {
> void compose( Locator locator ) throws LocatorException;
> }
>
> interface Contextualizable
> {
> void contextualizable( Locator locator ) throws LocatorException;
> }
>
> interface Locator
> {
> Object lookup( String key ) throws LocatorException;
> boolean exists( String key );
> }
>
> If thats what you mean then I think I agree. It resulted in cleaner code.
>
> If you mean merging Contextualizable and Composable then I disagree.
And I disagree because they are logically different resources.
Just like Logger or Configuration/Parameters or InstrumentationPoint resources
could be all added into a central directory and got in one sweep - we
separate out purely because of different usage patterns.
90% of generic component based apps will not use Contextualizable. Almost 100%
of typed/container-bound objects (ie Tasks, Mailets, Servlets, EJBs)
conceptually use Contextualizable.
Even in Servlets the service provision (JNDI) and interaction with container
(ServletContext) are logically different access mechanisms and have different
usage patterns. ie I rarely use JNDI except when writing EJBs yet I use
ServletContext in every servlet app I write.
--
Cheers,
Peter Donald
------------------------------------
The two secrets to success:
1- Don't tell anyone everything.
------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
oops - sent when I meant to save as draft and finish later ... I clarify now
then.
On Tue, 3 Dec 2002 21:45, Peter Donald wrote:
> On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
> > Sure. These are good examples of why everyone wins when there's a nice
> > match between what a resource means to a component, and how the resource
> > is delivered to the component. If the component wants a logger, give it
> > a logger. If the component wants config, give it config. etc. Maybe
> > the same resource is presented in different ways depending on how the
> > component asks for it. Maybe not. Component doesn't care.
> >
> > But the examples don't really answer the question: Why is it useful,
> > when a component asks for a resource of a particular type, to distinguish
> > between resources of that type that are provided by the container, and
> > resources of that type that are provided by other components?
>
> I don't really understand what you are getting at. If you are wanting to
> unify the interface then this has already proposed - I actually created
> another service API recently that looked something like
>
> interface Composable
> {
> void compose( Locator locator ) throws LocatorException;
> }
>
> interface Contextualizable
> {
> void contextualizable( Locator locator ) throws LocatorException;
> }
>
> interface Locator
> {
> Object lookup( String key ) throws LocatorException;
> boolean exists( String key );
> }
>
> If thats what you mean then I think I agree. It resulted in cleaner code.
>
> If you mean merging Contextualizable and Composable then I disagree.
And I disagree because they are logically different resources.
Just like Logger or Configuration/Parameters or InstrumentationPoint resources
could be all added into a central directory and got in one sweep - we
separate out purely because of different usage patterns.
90% of generic component based apps will not use Contextualizable. Almost 100%
of typed/container-bound objects (ie Tasks, Mailets, Servlets, EJBs)
conceptually use Contextualizable.
Even in Servlets the service provision (JNDI) and interaction with container
(ServletContext) are logically different access mechanisms and have different
usage patterns. ie I rarely use JNDI except when writing EJBs yet I use
ServletContext in every servlet app I write.
--
Cheers,
Peter Donald
------------------------------------
The two secrets to success:
1- Don't tell anyone everything.
------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
oops - sent when I meant to save as draft and finish later ... I clarify now
then.
On Tue, 3 Dec 2002 21:45, Peter Donald wrote:
> On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
> > Sure. These are good examples of why everyone wins when there's a nice
> > match between what a resource means to a component, and how the resource
> > is delivered to the component. If the component wants a logger, give it
> > a logger. If the component wants config, give it config. etc. Maybe
> > the same resource is presented in different ways depending on how the
> > component asks for it. Maybe not. Component doesn't care.
> >
> > But the examples don't really answer the question: Why is it useful,
> > when a component asks for a resource of a particular type, to distinguish
> > between resources of that type that are provided by the container, and
> > resources of that type that are provided by other components?
>
> I don't really understand what you are getting at. If you are wanting to
> unify the interface then this has already proposed - I actually created
> another service API recently that looked something like
>
> interface Composable
> {
> void compose( Locator locator ) throws LocatorException;
> }
>
> interface Contextualizable
> {
> void contextualizable( Locator locator ) throws LocatorException;
> }
>
> interface Locator
> {
> Object lookup( String key ) throws LocatorException;
> boolean exists( String key );
> }
>
> If thats what you mean then I think I agree. It resulted in cleaner code.
>
> If you mean merging Contextualizable and Composable then I disagree.
And I disagree because they are logically different resources.
Just like Logger or Configuration/Parameters or InstrumentationPoint resources
could be all added into a central directory and got in one sweep - we
separate out purely because of different usage patterns.
90% of generic component based apps will not use Contextualizable. Almost 100%
of typed/container-bound objects (ie Tasks, Mailets, Servlets, EJBs)
conceptually use Contextualizable.
Even in Servlets the service provision (JNDI) and interaction with container
(ServletContext) are logically different access mechanisms and have different
usage patterns. ie I rarely use JNDI except when writing EJBs yet I use
ServletContext in every servlet app I write.
--
Cheers,
Peter Donald
------------------------------------
The two secrets to success:
1- Don't tell anyone everything.
------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
>
>>Sure. These are good examples of why everyone wins when there's a nice
>>match between what a resource means to a component, and how the resource is
>>delivered to the component. If the component wants a logger, give it a
>>logger. If the component wants config, give it config. etc. Maybe the
>>same resource is presented in different ways depending on how the component
>>asks for it. Maybe not. Component doesn't care.
>>
>>But the examples don't really answer the question: Why is it useful, when
>>a component asks for a resource of a particular type, to distinguish
>>between resources of that type that are provided by the container, and
>>resources of that type that are provided by other components?
>
>
> I don't really understand what you are getting at. If you are wanting to unify
> the interface then this has already proposed - I actually created another
> service API recently that looked something like
>
> interface Composable
> {
> void compose( Locator locator ) throws LocatorException;
> }
>
> interface Contextualizable
> {
> void contextualizable( Locator locator ) throws LocatorException;
> }
>
> interface Locator
> {
> Object lookup( String key ) throws LocatorException;
> boolean exists( String key );
> }
>
> If thats what you mean then I think I agree. It resulted in cleaner code.
The fact that Composable and Contextualizable have basically the same
signature is an issue IMHO.
LogEnabled, Confisurable, et all were made indipendent, and each give a
*different* thing (Logger, Configuration, etc).
Having two methods of getting Objects (because whatever we can say in
Java they *are* Objects), causes confusion and concern overlap.
The Context is an interface with a method. Then we must use *that*
method. Casting makes it simply another servicemanager, which really
confuses, and makes boundaries very blurred.
> If you mean merging Contextualizable and Composable then I disagree.
--
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: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
>
>>Sure. These are good examples of why everyone wins when there's a nice
>>match between what a resource means to a component, and how the resource is
>>delivered to the component. If the component wants a logger, give it a
>>logger. If the component wants config, give it config. etc. Maybe the
>>same resource is presented in different ways depending on how the component
>>asks for it. Maybe not. Component doesn't care.
>>
>>But the examples don't really answer the question: Why is it useful, when
>>a component asks for a resource of a particular type, to distinguish
>>between resources of that type that are provided by the container, and
>>resources of that type that are provided by other components?
>
>
> I don't really understand what you are getting at. If you are wanting to unify
> the interface then this has already proposed - I actually created another
> service API recently that looked something like
>
> interface Composable
> {
> void compose( Locator locator ) throws LocatorException;
> }
>
> interface Contextualizable
> {
> void contextualizable( Locator locator ) throws LocatorException;
> }
>
> interface Locator
> {
> Object lookup( String key ) throws LocatorException;
> boolean exists( String key );
> }
>
> If thats what you mean then I think I agree. It resulted in cleaner code.
The fact that Composable and Contextualizable have basically the same
signature is an issue IMHO.
LogEnabled, Confisurable, et all were made indipendent, and each give a
*different* thing (Logger, Configuration, etc).
Having two methods of getting Objects (because whatever we can say in
Java they *are* Objects), causes confusion and concern overlap.
The Context is an interface with a method. Then we must use *that*
method. Casting makes it simply another servicemanager, which really
confuses, and makes boundaries very blurred.
> If you mean merging Contextualizable and Composable then I disagree.
--
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: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
>
>>Sure. These are good examples of why everyone wins when there's a nice
>>match between what a resource means to a component, and how the resource is
>>delivered to the component. If the component wants a logger, give it a
>>logger. If the component wants config, give it config. etc. Maybe the
>>same resource is presented in different ways depending on how the component
>>asks for it. Maybe not. Component doesn't care.
>>
>>But the examples don't really answer the question: Why is it useful, when
>>a component asks for a resource of a particular type, to distinguish
>>between resources of that type that are provided by the container, and
>>resources of that type that are provided by other components?
>
>
> I don't really understand what you are getting at. If you are wanting to unify
> the interface then this has already proposed - I actually created another
> service API recently that looked something like
>
> interface Composable
> {
> void compose( Locator locator ) throws LocatorException;
> }
>
> interface Contextualizable
> {
> void contextualizable( Locator locator ) throws LocatorException;
> }
>
> interface Locator
> {
> Object lookup( String key ) throws LocatorException;
> boolean exists( String key );
> }
>
> If thats what you mean then I think I agree. It resulted in cleaner code.
The fact that Composable and Contextualizable have basically the same
signature is an issue IMHO.
LogEnabled, Confisurable, et all were made indipendent, and each give a
*different* thing (Logger, Configuration, etc).
Having two methods of getting Objects (because whatever we can say in
Java they *are* Objects), causes confusion and concern overlap.
The Context is an interface with a method. Then we must use *that*
method. Casting makes it simply another servicemanager, which really
confuses, and makes boundaries very blurred.
> If you mean merging Contextualizable and Composable then I disagree.
--
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: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
> Sure. These are good examples of why everyone wins when there's a nice
> match between what a resource means to a component, and how the resource is
> delivered to the component. If the component wants a logger, give it a
> logger. If the component wants config, give it config. etc. Maybe the
> same resource is presented in different ways depending on how the component
> asks for it. Maybe not. Component doesn't care.
>
> But the examples don't really answer the question: Why is it useful, when
> a component asks for a resource of a particular type, to distinguish
> between resources of that type that are provided by the container, and
> resources of that type that are provided by other components?
I don't really understand what you are getting at. If you are wanting to unify
the interface then this has already proposed - I actually created another
service API recently that looked something like
interface Composable
{
void compose( Locator locator ) throws LocatorException;
}
interface Contextualizable
{
void contextualizable( Locator locator ) throws LocatorException;
}
interface Locator
{
Object lookup( String key ) throws LocatorException;
boolean exists( String key );
}
If thats what you mean then I think I agree. It resulted in cleaner code.
If you mean merging Contextualizable and Composable then I disagree.
--
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: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
> Sure. These are good examples of why everyone wins when there's a nice
> match between what a resource means to a component, and how the resource is
> delivered to the component. If the component wants a logger, give it a
> logger. If the component wants config, give it config. etc. Maybe the
> same resource is presented in different ways depending on how the component
> asks for it. Maybe not. Component doesn't care.
>
> But the examples don't really answer the question: Why is it useful, when
> a component asks for a resource of a particular type, to distinguish
> between resources of that type that are provided by the container, and
> resources of that type that are provided by other components?
I don't really understand what you are getting at. If you are wanting to unify
the interface then this has already proposed - I actually created another
service API recently that looked something like
interface Composable
{
void compose( Locator locator ) throws LocatorException;
}
interface Contextualizable
{
void contextualizable( Locator locator ) throws LocatorException;
}
interface Locator
{
Object lookup( String key ) throws LocatorException;
boolean exists( String key );
}
If thats what you mean then I think I agree. It resulted in cleaner code.
If you mean merging Contextualizable and Composable then I disagree.
--
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: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
> Sure. These are good examples of why everyone wins when there's a nice
> match between what a resource means to a component, and how the resource is
> delivered to the component. If the component wants a logger, give it a
> logger. If the component wants config, give it config. etc. Maybe the
> same resource is presented in different ways depending on how the component
> asks for it. Maybe not. Component doesn't care.
>
> But the examples don't really answer the question: Why is it useful, when
> a component asks for a resource of a particular type, to distinguish
> between resources of that type that are provided by the container, and
> resources of that type that are provided by other components?
I don't really understand what you are getting at. If you are wanting to unify
the interface then this has already proposed - I actually created another
service API recently that looked something like
interface Composable
{
void compose( Locator locator ) throws LocatorException;
}
interface Contextualizable
{
void contextualizable( Locator locator ) throws LocatorException;
}
interface Locator
{
Object lookup( String key ) throws LocatorException;
boolean exists( String key );
}
If thats what you mean then I think I agree. It resulted in cleaner code.
If you mean merging Contextualizable and Composable then I disagree.
--
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: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Tue, 3 Dec 2002 03:42 pm, Peter Donald wrote:
> On Tue, 3 Dec 2002 13:17, Adam Murdoch wrote:
> > Hence my question: Does the component *really* care whether a particular
> > resource is provided by the container or not provided by the container?
> > Is this an artificial distinction? Why is it useful to the component
> > writer to split them?
>
> Essentially it comes down to the context wrt the resources is requested.
> For example lets consider Logger. Historically we had LogManager as a
> service that components depended on to get at their logger. So it would
> look something like;
>
> class MyComponent
> {
> void service( ServiceManager sm )
> {
> LoggerManager lm = (LoggerManager)sm.lookup( LoggerManager.ROLE );
> m_logger = lm.getLogger( "my-channel" );
> }
> }
>
> In this case you are passing component specific context (ie string
> "my-channel") into LoggerManager. Now if you wanted two different instances
> of MyComponent - say one production and one testing - they would both log
> to the same channel or we would have to create multiple instances of
> LoggerManager.
>
> However when the container manages allocation of Logger resource they can
> be remapped without the Component writer knowing about it or caring.
>
> Everything available in the context can either be made into a service or
> blended into configuration or both. The problem is that when the resource
> (data or service) requires per-component context you end up having a "fake"
> provider component per component. So assembly requires mapping of several
> "fake" components to the dependencies in the "real" components (ie the ones
> you actually care about). You also end up duplicating data between
> different stages. ie assembly process names components and links them to
> resources resources and those same names need to placed in configuration of
> "fake" provider components.
Sure. These are good examples of why everyone wins when there's a nice match
between what a resource means to a component, and how the resource is
delivered to the component. If the component wants a logger, give it a
logger. If the component wants config, give it config. etc. Maybe the same
resource is presented in different ways depending on how the component asks
for it. Maybe not. Component doesn't care.
But the examples don't really answer the question: Why is it useful, when a
component asks for a resource of a particular type, to distinguish between
resources of that type that are provided by the container, and resources of
that type that are provided by other components?
(where 'type' = config, or parameter, or data, or service, or whatever).
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Tue, 3 Dec 2002 03:42 pm, Peter Donald wrote:
> On Tue, 3 Dec 2002 13:17, Adam Murdoch wrote:
> > Hence my question: Does the component *really* care whether a particular
> > resource is provided by the container or not provided by the container?
> > Is this an artificial distinction? Why is it useful to the component
> > writer to split them?
>
> Essentially it comes down to the context wrt the resources is requested.
> For example lets consider Logger. Historically we had LogManager as a
> service that components depended on to get at their logger. So it would
> look something like;
>
> class MyComponent
> {
> void service( ServiceManager sm )
> {
> LoggerManager lm = (LoggerManager)sm.lookup( LoggerManager.ROLE );
> m_logger = lm.getLogger( "my-channel" );
> }
> }
>
> In this case you are passing component specific context (ie string
> "my-channel") into LoggerManager. Now if you wanted two different instances
> of MyComponent - say one production and one testing - they would both log
> to the same channel or we would have to create multiple instances of
> LoggerManager.
>
> However when the container manages allocation of Logger resource they can
> be remapped without the Component writer knowing about it or caring.
>
> Everything available in the context can either be made into a service or
> blended into configuration or both. The problem is that when the resource
> (data or service) requires per-component context you end up having a "fake"
> provider component per component. So assembly requires mapping of several
> "fake" components to the dependencies in the "real" components (ie the ones
> you actually care about). You also end up duplicating data between
> different stages. ie assembly process names components and links them to
> resources resources and those same names need to placed in configuration of
> "fake" provider components.
Sure. These are good examples of why everyone wins when there's a nice match
between what a resource means to a component, and how the resource is
delivered to the component. If the component wants a logger, give it a
logger. If the component wants config, give it config. etc. Maybe the same
resource is presented in different ways depending on how the component asks
for it. Maybe not. Component doesn't care.
But the examples don't really answer the question: Why is it useful, when a
component asks for a resource of a particular type, to distinguish between
resources of that type that are provided by the container, and resources of
that type that are provided by other components?
(where 'type' = config, or parameter, or data, or service, or whatever).
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Tue, 3 Dec 2002 03:42 pm, Peter Donald wrote:
> On Tue, 3 Dec 2002 13:17, Adam Murdoch wrote:
> > Hence my question: Does the component *really* care whether a particular
> > resource is provided by the container or not provided by the container?
> > Is this an artificial distinction? Why is it useful to the component
> > writer to split them?
>
> Essentially it comes down to the context wrt the resources is requested.
> For example lets consider Logger. Historically we had LogManager as a
> service that components depended on to get at their logger. So it would
> look something like;
>
> class MyComponent
> {
> void service( ServiceManager sm )
> {
> LoggerManager lm = (LoggerManager)sm.lookup( LoggerManager.ROLE );
> m_logger = lm.getLogger( "my-channel" );
> }
> }
>
> In this case you are passing component specific context (ie string
> "my-channel") into LoggerManager. Now if you wanted two different instances
> of MyComponent - say one production and one testing - they would both log
> to the same channel or we would have to create multiple instances of
> LoggerManager.
>
> However when the container manages allocation of Logger resource they can
> be remapped without the Component writer knowing about it or caring.
>
> Everything available in the context can either be made into a service or
> blended into configuration or both. The problem is that when the resource
> (data or service) requires per-component context you end up having a "fake"
> provider component per component. So assembly requires mapping of several
> "fake" components to the dependencies in the "real" components (ie the ones
> you actually care about). You also end up duplicating data between
> different stages. ie assembly process names components and links them to
> resources resources and those same names need to placed in configuration of
> "fake" provider components.
Sure. These are good examples of why everyone wins when there's a nice match
between what a resource means to a component, and how the resource is
delivered to the component. If the component wants a logger, give it a
logger. If the component wants config, give it config. etc. Maybe the same
resource is presented in different ways depending on how the component asks
for it. Maybe not. Component doesn't care.
But the examples don't really answer the question: Why is it useful, when a
component asks for a resource of a particular type, to distinguish between
resources of that type that are provided by the container, and resources of
that type that are provided by other components?
(where 'type' = config, or parameter, or data, or service, or whatever).
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Adam Murdoch wrote:
>On Tue, 3 Dec 2002 04:05 pm, Stephen McConnell wrote:
>
>
>
>> > Does the component *really* care whether a particular
>> > resource is provided by the container or not provided
>> > by the container? Is this an artificial distinction?
>> > Why is it useful to the component writer to split them?
>>
>>
>
>
>
>>So lets explore something like a shutdown service. Presumably a sutdown
>>service does something along the lines of shutting down a component.
>>Which component? Should the component instance be part of the argument
>>to the service ? No. That will be problematic. In effect, we have a
>>"context" - what the component actually wanted was "give me a handle to
>>the thing that started me up so that I can tell it that I'm done".
>>
>>
>
>Or, arguably, "give me the thing that I can tell that I'm done". I don't
>think the component cares either way about the "handle to the thing that
>started me up".
>
>
>
>>That
>>request is not a peer request - it's a container request - and that is
>>the distinguishing feature here - it's that fact that the component is
>>responding to a stimulus - the stimulus is the startup service.
>>
>>
>
>There's no question that some resources will almost always be provided by the
>container. A shutdown service is a perfect example. But why is it useful to
>expose this fact to the component? Does it care that a shutdown service is
>provided by the container? I don't believe so. All it cares about is that
>it is provided with a resource it can notify when it is finished doing
>whatever it does.
>
I agree (very strongly) with you that the component should not care
where the service comes from.
>Assume that the framework will include some way for the container to deliver
>arbitrary services to a component, and some cross-container way for the
>component to describe the services it is expecting. Given this, is there any
>*real* benefit to the component writer, of adding a second mechanism for
>describing and delivering arbitrary container-provided services to the
>component? Will the component writer have to write more code, or less code?
>Write more meta-data or less meta-data? Will the component be more portable,
>or less portable? Is there more documentation to read? More abstractions to
>figure out?
>
>Of course, a shutdown service might not actually be such a good example. A
>case could certainly be made that component shutdown should be dealt with as
>part of the Startable lifecycle thing (phase? step? stage? what's the correct
>terminology?). For example, Startable.start() could take as a parameter the
>resource that the component may use to request that it be stopped.
>
There is a long thread in the archives on stage/phase. Based on the
conclusions reached there ... a phase is something container one or more
stages. A component lifecycle goes though two phases - startup and
shutdown. A startup phase is composed of a series of stages (logging,
contextualization, initialization etc.). A particular stage can be
viewed as a phase - e.g. Initialization appears as a stage in a startup
phase, but initialization my be implemented as a phase covering
extension handler deployment following by final initialization (two
distinct sub-stages).
Now that made things totally clear didn't it ;-)
Anyway back to the topic.
The requestShutdown is probably a bad example because it is something
that is directly linked to the service that is managing the lifecycle of
a component. That's complicating the general issue of context management.
Instead - if both the Serviceable/Composable model is reconsidered as
something capable of providing services and data objects from a
containers computational perspective - we can shift focus to "what is it
that the component writer wants" and look at context service seperation
based on a needs as oppposed to container implemetation perspective.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Adam Murdoch wrote:
>On Tue, 3 Dec 2002 04:05 pm, Stephen McConnell wrote:
>
>
>
>> > Does the component *really* care whether a particular
>> > resource is provided by the container or not provided
>> > by the container? Is this an artificial distinction?
>> > Why is it useful to the component writer to split them?
>>
>>
>
>
>
>>So lets explore something like a shutdown service. Presumably a sutdown
>>service does something along the lines of shutting down a component.
>>Which component? Should the component instance be part of the argument
>>to the service ? No. That will be problematic. In effect, we have a
>>"context" - what the component actually wanted was "give me a handle to
>>the thing that started me up so that I can tell it that I'm done".
>>
>>
>
>Or, arguably, "give me the thing that I can tell that I'm done". I don't
>think the component cares either way about the "handle to the thing that
>started me up".
>
>
>
>>That
>>request is not a peer request - it's a container request - and that is
>>the distinguishing feature here - it's that fact that the component is
>>responding to a stimulus - the stimulus is the startup service.
>>
>>
>
>There's no question that some resources will almost always be provided by the
>container. A shutdown service is a perfect example. But why is it useful to
>expose this fact to the component? Does it care that a shutdown service is
>provided by the container? I don't believe so. All it cares about is that
>it is provided with a resource it can notify when it is finished doing
>whatever it does.
>
I agree (very strongly) with you that the component should not care
where the service comes from.
>Assume that the framework will include some way for the container to deliver
>arbitrary services to a component, and some cross-container way for the
>component to describe the services it is expecting. Given this, is there any
>*real* benefit to the component writer, of adding a second mechanism for
>describing and delivering arbitrary container-provided services to the
>component? Will the component writer have to write more code, or less code?
>Write more meta-data or less meta-data? Will the component be more portable,
>or less portable? Is there more documentation to read? More abstractions to
>figure out?
>
>Of course, a shutdown service might not actually be such a good example. A
>case could certainly be made that component shutdown should be dealt with as
>part of the Startable lifecycle thing (phase? step? stage? what's the correct
>terminology?). For example, Startable.start() could take as a parameter the
>resource that the component may use to request that it be stopped.
>
There is a long thread in the archives on stage/phase. Based on the
conclusions reached there ... a phase is something container one or more
stages. A component lifecycle goes though two phases - startup and
shutdown. A startup phase is composed of a series of stages (logging,
contextualization, initialization etc.). A particular stage can be
viewed as a phase - e.g. Initialization appears as a stage in a startup
phase, but initialization my be implemented as a phase covering
extension handler deployment following by final initialization (two
distinct sub-stages).
Now that made things totally clear didn't it ;-)
Anyway back to the topic.
The requestShutdown is probably a bad example because it is something
that is directly linked to the service that is managing the lifecycle of
a component. That's complicating the general issue of context management.
Instead - if both the Serviceable/Composable model is reconsidered as
something capable of providing services and data objects from a
containers computational perspective - we can shift focus to "what is it
that the component writer wants" and look at context service seperation
based on a needs as oppposed to container implemetation perspective.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Adam Murdoch wrote:
>On Tue, 3 Dec 2002 04:05 pm, Stephen McConnell wrote:
>
>
>
>> > Does the component *really* care whether a particular
>> > resource is provided by the container or not provided
>> > by the container? Is this an artificial distinction?
>> > Why is it useful to the component writer to split them?
>>
>>
>
>
>
>>So lets explore something like a shutdown service. Presumably a sutdown
>>service does something along the lines of shutting down a component.
>>Which component? Should the component instance be part of the argument
>>to the service ? No. That will be problematic. In effect, we have a
>>"context" - what the component actually wanted was "give me a handle to
>>the thing that started me up so that I can tell it that I'm done".
>>
>>
>
>Or, arguably, "give me the thing that I can tell that I'm done". I don't
>think the component cares either way about the "handle to the thing that
>started me up".
>
>
>
>>That
>>request is not a peer request - it's a container request - and that is
>>the distinguishing feature here - it's that fact that the component is
>>responding to a stimulus - the stimulus is the startup service.
>>
>>
>
>There's no question that some resources will almost always be provided by the
>container. A shutdown service is a perfect example. But why is it useful to
>expose this fact to the component? Does it care that a shutdown service is
>provided by the container? I don't believe so. All it cares about is that
>it is provided with a resource it can notify when it is finished doing
>whatever it does.
>
I agree (very strongly) with you that the component should not care
where the service comes from.
>Assume that the framework will include some way for the container to deliver
>arbitrary services to a component, and some cross-container way for the
>component to describe the services it is expecting. Given this, is there any
>*real* benefit to the component writer, of adding a second mechanism for
>describing and delivering arbitrary container-provided services to the
>component? Will the component writer have to write more code, or less code?
>Write more meta-data or less meta-data? Will the component be more portable,
>or less portable? Is there more documentation to read? More abstractions to
>figure out?
>
>Of course, a shutdown service might not actually be such a good example. A
>case could certainly be made that component shutdown should be dealt with as
>part of the Startable lifecycle thing (phase? step? stage? what's the correct
>terminology?). For example, Startable.start() could take as a parameter the
>resource that the component may use to request that it be stopped.
>
There is a long thread in the archives on stage/phase. Based on the
conclusions reached there ... a phase is something container one or more
stages. A component lifecycle goes though two phases - startup and
shutdown. A startup phase is composed of a series of stages (logging,
contextualization, initialization etc.). A particular stage can be
viewed as a phase - e.g. Initialization appears as a stage in a startup
phase, but initialization my be implemented as a phase covering
extension handler deployment following by final initialization (two
distinct sub-stages).
Now that made things totally clear didn't it ;-)
Anyway back to the topic.
The requestShutdown is probably a bad example because it is something
that is directly linked to the service that is managing the lifecycle of
a component. That's complicating the general issue of context management.
Instead - if both the Serviceable/Composable model is reconsidered as
something capable of providing services and data objects from a
containers computational perspective - we can shift focus to "what is it
that the component writer wants" and look at context service seperation
based on a needs as oppposed to container implemetation perspective.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Tue, 3 Dec 2002 04:05 pm, Stephen McConnell wrote:
> > Does the component *really* care whether a particular
> > resource is provided by the container or not provided
> > by the container? Is this an artificial distinction?
> > Why is it useful to the component writer to split them?
> So lets explore something like a shutdown service. Presumably a sutdown
> service does something along the lines of shutting down a component.
> Which component? Should the component instance be part of the argument
> to the service ? No. That will be problematic. In effect, we have a
> "context" - what the component actually wanted was "give me a handle to
> the thing that started me up so that I can tell it that I'm done".
Or, arguably, "give me the thing that I can tell that I'm done". I don't
think the component cares either way about the "handle to the thing that
started me up".
> That
> request is not a peer request - it's a container request - and that is
> the distinguishing feature here - it's that fact that the component is
> responding to a stimulus - the stimulus is the startup service.
There's no question that some resources will almost always be provided by the
container. A shutdown service is a perfect example. But why is it useful to
expose this fact to the component? Does it care that a shutdown service is
provided by the container? I don't believe so. All it cares about is that
it is provided with a resource it can notify when it is finished doing
whatever it does.
Assume that the framework will include some way for the container to deliver
arbitrary services to a component, and some cross-container way for the
component to describe the services it is expecting. Given this, is there any
*real* benefit to the component writer, of adding a second mechanism for
describing and delivering arbitrary container-provided services to the
component? Will the component writer have to write more code, or less code?
Write more meta-data or less meta-data? Will the component be more portable,
or less portable? Is there more documentation to read? More abstractions to
figure out?
Of course, a shutdown service might not actually be such a good example. A
case could certainly be made that component shutdown should be dealt with as
part of the Startable lifecycle thing (phase? step? stage? what's the correct
terminology?). For example, Startable.start() could take as a parameter the
resource that the component may use to request that it be stopped.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Tue, 3 Dec 2002 04:05 pm, Stephen McConnell wrote:
> > Does the component *really* care whether a particular
> > resource is provided by the container or not provided
> > by the container? Is this an artificial distinction?
> > Why is it useful to the component writer to split them?
> So lets explore something like a shutdown service. Presumably a sutdown
> service does something along the lines of shutting down a component.
> Which component? Should the component instance be part of the argument
> to the service ? No. That will be problematic. In effect, we have a
> "context" - what the component actually wanted was "give me a handle to
> the thing that started me up so that I can tell it that I'm done".
Or, arguably, "give me the thing that I can tell that I'm done". I don't
think the component cares either way about the "handle to the thing that
started me up".
> That
> request is not a peer request - it's a container request - and that is
> the distinguishing feature here - it's that fact that the component is
> responding to a stimulus - the stimulus is the startup service.
There's no question that some resources will almost always be provided by the
container. A shutdown service is a perfect example. But why is it useful to
expose this fact to the component? Does it care that a shutdown service is
provided by the container? I don't believe so. All it cares about is that
it is provided with a resource it can notify when it is finished doing
whatever it does.
Assume that the framework will include some way for the container to deliver
arbitrary services to a component, and some cross-container way for the
component to describe the services it is expecting. Given this, is there any
*real* benefit to the component writer, of adding a second mechanism for
describing and delivering arbitrary container-provided services to the
component? Will the component writer have to write more code, or less code?
Write more meta-data or less meta-data? Will the component be more portable,
or less portable? Is there more documentation to read? More abstractions to
figure out?
Of course, a shutdown service might not actually be such a good example. A
case could certainly be made that component shutdown should be dealt with as
part of the Startable lifecycle thing (phase? step? stage? what's the correct
terminology?). For example, Startable.start() could take as a parameter the
resource that the component may use to request that it be stopped.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Tue, 3 Dec 2002 04:05 pm, Stephen McConnell wrote:
> > Does the component *really* care whether a particular
> > resource is provided by the container or not provided
> > by the container? Is this an artificial distinction?
> > Why is it useful to the component writer to split them?
> So lets explore something like a shutdown service. Presumably a sutdown
> service does something along the lines of shutting down a component.
> Which component? Should the component instance be part of the argument
> to the service ? No. That will be problematic. In effect, we have a
> "context" - what the component actually wanted was "give me a handle to
> the thing that started me up so that I can tell it that I'm done".
Or, arguably, "give me the thing that I can tell that I'm done". I don't
think the component cares either way about the "handle to the thing that
started me up".
> That
> request is not a peer request - it's a container request - and that is
> the distinguishing feature here - it's that fact that the component is
> responding to a stimulus - the stimulus is the startup service.
There's no question that some resources will almost always be provided by the
container. A shutdown service is a perfect example. But why is it useful to
expose this fact to the component? Does it care that a shutdown service is
provided by the container? I don't believe so. All it cares about is that
it is provided with a resource it can notify when it is finished doing
whatever it does.
Assume that the framework will include some way for the container to deliver
arbitrary services to a component, and some cross-container way for the
component to describe the services it is expecting. Given this, is there any
*real* benefit to the component writer, of adding a second mechanism for
describing and delivering arbitrary container-provided services to the
component? Will the component writer have to write more code, or less code?
Write more meta-data or less meta-data? Will the component be more portable,
or less portable? Is there more documentation to read? More abstractions to
figure out?
Of course, a shutdown service might not actually be such a good example. A
case could certainly be made that component shutdown should be dealt with as
part of the Startable lifecycle thing (phase? step? stage? what's the correct
terminology?). For example, Startable.start() could take as a parameter the
resource that the component may use to request that it be stopped.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Tue, 3 Dec 2002 13:17, Adam Murdoch wrote:
>
>
>>Hence my question: Does the component *really* care whether a particular
>>resource is provided by the container or not provided by the container? Is
>>this an artificial distinction? Why is it useful to the component writer
>>to split them?
>>
>>
>
>Essentially it comes down to the context wrt the resources is requested. For
>example lets consider Logger. Historically we had LogManager as a service
>that components depended on to get at their logger. So it would look
>something like;
>
>class MyComponent
>{
> void service( ServiceManager sm )
> {
> LoggerManager lm = (LoggerManager)sm.lookup( LoggerManager.ROLE );
> m_logger = lm.getLogger( "my-channel" );
> }
>}
>
>In this case you are passing component specific context (ie string
>"my-channel") into LoggerManager. Now if you wanted two different instances
>of MyComponent - say one production and one testing - they would both log to
>the same channel or we would have to create multiple instances of
>LoggerManager.
>
>However when the container manages allocation of Logger resource they can be
>remapped without the Component writer knowing about it or caring.
>
>Everything available in the context can either be made into a service or
>blended into configuration or both. The problem is that when the resource
>(data or service) requires per-component context you end up having a "fake"
>provider component per component. So assembly requires mapping of several
>"fake" components to the dependencies in the "real" components (ie the ones
>you actually care about). You also end up duplicating data between different
>stages. ie assembly process names components and links them to resources
>resources and those same names need to placed in configuration of "fake"
>provider components.
>
>You could say that this could all be auotmated with some PFM but when we went
>this path in the past the users complained about the complexity of assembly
>process because you have to be aware of the minute details of how the
>container does the PFM and so you have not made it easier on users unless
>they are already know everything (which are not the ones who need help
>anyways).
>
>When more advanced assembly processes come into play (ie different interceptor
>chains per component client) you duplicate much more information and add much
>more magic. Too complex to manage without a tool and I don't think it is in
>our best interests to require a tool to write applications.
>
>
Umm, ... does this answer providing a conclusion to the question ...
I don't think so.
Let's reprint the question:
> Does the component *really* care whether a particular
> resource is provided by the container or not provided
> by the container? Is this an artificial distinction?
> Why is it useful to the component writer to split them?
The issue here concerns expectations that the component author has to
the services and state it is provided with. The component author does
not give a diddly-bob about the problems, loops and hurdles a container
author has to jump though in order to meet the requirements they have -
they have the requirements - and they are right.
So lets explore something like a shutdown service. Presumably a sutdown
service does something along the lines of shutting down a component.
Which component? Should the component instance be part of the argument
to the service ? No. That will be problematic. In effect, we have a
"context" - what the component actually wanted was "give me a handle to
the thing that started me up so that I can tell it that I'm done". That
request is not a peer request - it's a container request - and that is
the distinguishing feature here - it's that fact that the component is
responding to a stimulus - the stimulus is the startup service.
There is nothing in the framework contract for service or context that
lets us distinguish between peer versus containment context.
But we can fix this is meta.
:-)
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 13:17, Adam Murdoch wrote:
> Hence my question: Does the component *really* care whether a particular
> resource is provided by the container or not provided by the container? Is
> this an artificial distinction? Why is it useful to the component writer
> to split them?
Essentially it comes down to the context wrt the resources is requested. For
example lets consider Logger. Historically we had LogManager as a service
that components depended on to get at their logger. So it would look
something like;
class MyComponent
{
void service( ServiceManager sm )
{
LoggerManager lm = (LoggerManager)sm.lookup( LoggerManager.ROLE );
m_logger = lm.getLogger( "my-channel" );
}
}
In this case you are passing component specific context (ie string
"my-channel") into LoggerManager. Now if you wanted two different instances
of MyComponent - say one production and one testing - they would both log to
the same channel or we would have to create multiple instances of
LoggerManager.
However when the container manages allocation of Logger resource they can be
remapped without the Component writer knowing about it or caring.
Everything available in the context can either be made into a service or
blended into configuration or both. The problem is that when the resource
(data or service) requires per-component context you end up having a "fake"
provider component per component. So assembly requires mapping of several
"fake" components to the dependencies in the "real" components (ie the ones
you actually care about). You also end up duplicating data between different
stages. ie assembly process names components and links them to resources
resources and those same names need to placed in configuration of "fake"
provider components.
You could say that this could all be auotmated with some PFM but when we went
this path in the past the users complained about the complexity of assembly
process because you have to be aware of the minute details of how the
container does the PFM and so you have not made it easier on users unless
they are already know everything (which are not the ones who need help
anyways).
When more advanced assembly processes come into play (ie different interceptor
chains per component client) you duplicate much more information and add much
more magic. Too complex to manage without a tool and I don't think it is in
our best interests to require a tool to write applications.
--
Cheers,
Peter Donald
*------------------------------------------------*
| The student who is never required to do what |
| he cannot do never does what he can do. |
| - John Stuart Mill |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Tue, 3 Dec 2002 11:34 am, Peter Donald wrote:
> On Tue, 3 Dec 2002 11:46, Adam Murdoch wrote:
> > Could someone explain why the distinction between resources provided by
> > the container and resources not provided by the container is important
> > *to the component* itself? Why does it care? And if it does, why is it
> > useful that the component should use one mechanism for looking up one
> > group of resources, and a different mechanism for looking up the others
> > (and presumably separate mechanisms to describe to the container the
> > resources it is expecting)? Ignore the fact that some resources are
> > passive, immutable 'data' and other resources are active 'services' -
> > that's a separate distinction.
>
> Take this to it's logical end. Why use different mechanisms for looking up
> different types of resources in any component? ie Why do loggers have their
> own lifecycle interface? Could not you just look up the Logger this
> directory? Or why don't you just lookup the Configuration object in this
> directory? Is this not what JNDI is - so why not use that instead of our
> own mechanisms?
That's not what I asked. From the component's POV, the distinction between,
say, configuration and a logger, is clear. I wasn't asking why is it useful
to separate groups of resources that have clear and distinct meanings to the
component. I don't need convincing it's a good thing (who does?). But
there's a tension there - cut things too finely and you're just creating
pointless extra work for everyone. Same for cutting in the wrong spots.
Hence my question: Does the component *really* care whether a particular
resource is provided by the container or not provided by the container? Is
this an artificial distinction? Why is it useful to the component writer to
split them?
> So why separate out container provided resources and peer provided
> resources? Mainly as they follow different usage patterns.
Can you give a little more detail? Aren't the 'different usage patterns' due
to the fact that framework *right now* makes such a distinction and splits
the container and not-container provided resources across Context and
ServiceManager?
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 11:46, Adam Murdoch wrote:
> Could someone explain why the distinction between resources provided by the
> container and resources not provided by the container is important *to the
> component* itself? Why does it care? And if it does, why is it useful
> that the component should use one mechanism for looking up one group of
> resources, and a different mechanism for looking up the others (and
> presumably separate mechanisms to describe to the container the resources
> it is expecting)? Ignore the fact that some resources are passive,
> immutable 'data' and other resources are active 'services' - that's a
> separate distinction.
Take this to it's logical end. Why use different mechanisms for looking up
different types of resources in any component? ie Why do loggers have their
own lifecycle interface? Could not you just look up the Logger this
directory? Or why don't you just lookup the Configuration object in this
directory? Is this not what JNDI is - so why not use that instead of our own
mechanisms?
ie It would end up looking like
public void init( java.naming.Context ctx )
{
//Replace ... with correct path according to J2EE recomendations
m_logger = (Logger)ctx.lookup( "java: ... Logger" );
m_configuration = (Configuration)ctx.lookup( "java: ... Configuration" );
m_service = (MyService)ctx.lookup( "java: ... MyService" );
}
FWIW I believe this was the original apporach and it has gradually had the
concerns separated. The reason for separation was based on usage patterns. ie
The above seemed overly complex mechanism if you just wanted to get a logger
or just wanted to get at configuration etc.
So we broke out things based on usage patterns. IIRC Configuration + Context
were already separate when I started lurking in Avalon. Then someone (Fede?)
broken out ServiceManager because that had a distinctive usage pattern. Later
on LogEnabled and Parameterizable got separated out because they also had
distinctive usage patterns.
By breaking things down by how we use them makes it possible for more scalable
design and we don't have any monolithic pieces. We can essentially mix and
match to get what you want.
So why separate out container provided resources and peer provided resources?
Mainly as they follow different usage patterns.
--
Cheers,
Peter Donald
--------------------------------------------------
"An intellectual is someone who has been educated
beyond their intelligence."
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Could someone explain why the distinction between resources provided by
the
> container and resources not provided by the container is important *to the
> component* itself?
Good question. And I agree with you that the Context and Compose (oh,
excuse me, Service) look awfully similar. The primary difference, from what
I can see, from the perspective of a component appears to be a lifecycle
issue. Context is available early in the lifecycle, Services are available
later in the lifecycle.
Once there is a scalable container that allows pluggable profiles, there is
no reason why an application could not provide its own context namespace(s)
as well as component Services. I think that this is still an open issue,
architecturally, as evidenced by the disparate views appearing from Avalon
Committers.
I trust that we'll learn something from correction(s) to the above.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Adam Murdoch <ad...@apache.org>.
On Tue, 3 Dec 2002 08:44 am, Peter Donald wrote:
> On Tue, 3 Dec 2002 08:08, Peter M. Goldstein wrote:
> > It also seems compatible with what seems to me to be the natural
> > separation between Contextualizable and Serviceable. Context involves
> > data and services that are uniquely owned by the container (i.e. for
> > Avalon Phoenix, getBaseDirectory(), requestShutdown() and for James
> > Mailets, getPostmaster(), isLocalServer(String)). The essential
> > distinction as I see it is that services should be user-defined and
> > configured, while context-related items should be container-defined and
> > not require configuration. Also, the services may include a
> > configurable dependency chain, while Context implementations should be
> > available before any services are loaded and should not have a
> > configurable dependency chain.
>
> Thats essentially how it is defined now and how I think it should be.
Could someone explain why the distinction between resources provided by the
container and resources not provided by the container is important *to the
component* itself? Why does it care? And if it does, why is it useful that
the component should use one mechanism for looking up one group of resources,
and a different mechanism for looking up the others (and presumably separate
mechanisms to describe to the container the resources it is expecting)?
Ignore the fact that some resources are passive, immutable 'data' and other
resources are active 'services' - that's a separate distinction.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 12:16, Peter M. Goldstein wrote:
> I guess our disagreement is that I believe that there is substantial
> common ground here, and that it would be of tremendous value to formally
> define it. I don't know if you agree - from your comments I don't think
> you do.
I do. I even started to write up a document describing the parts that could be
shared. See
http://jakarta.apache.org/avalon/excalibur/info/context.html
> i) Documentation - If the common ground is formalized, then users don't
> have to "try it and see" as to whether their components will work in a
> particular container. Formalizing and clarifying the shared territories
> makes all the containers better. Making it possible for a container to
> declare exactly what subset of this common ground it supports allows
> component authors and deployers to quickly and intelligently evaluate
> containers
Right. The mechanism for components to declare their requirements is
documented at
http://jakarta.apache.org/avalon/excalibur/info/index.html
The mechanism for components/containers to declare "features" that they
support is documented at
http://jakarta.apache.org/avalon/excalibur/info/features.html
Feel free to submit patches to add bits where you think additions can be made.
--
Cheers,
Peter Donald
Duct tape is like the force. It has a light side, and a dark side, and
it binds the universe together ...
-- Carl Zwanzig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Peter,
> The problem is that people disagree. However if you look at
implemented
> containers (here and elsewhere) the released implementations mainly
follow
> those guidelines.
Ok, fair enough. Let's see if we can figure out the points of
disagreement and find some common ground.
I guess our disagreement is that I believe that there is substantial
common ground here, and that it would be of tremendous value to formally
define it. I don't know if you agree - from your comments I don't think
you do. If you don't, I'd like you to take a few minutes and reconsider
this aspect of the situation. IMHO, this commonality can be achieved
without sacrificing the flexibility/extensibility that is necessary to
support a plethora of containers. If you don't agree, I'd like to hear
what in your opinion specifically prevents this.
> If you use the Context you are binding to container specific
assumptions -
> some of these assumptions may be shared between containers but some
(like
> shutting down app, bouncing mail, evaluating a property etc) are
container
> specific.
Again, expanding the common ground here tremendously increases the value
of the proposition. Especially if it becomes possible for the code to
determine what contracts the container provides through the Context.
There are two ways in which this is the case:
i) Documentation - If the common ground is formalized, then users don't
have to "try it and see" as to whether their components will work in a
particular container. Formalizing and clarifying the shared territories
makes all the containers better. Making it possible for a container to
declare exactly what subset of this common ground it supports allows
component authors and deployers to quickly and intelligently evaluate
containers
ii) Smarter, less tightly-coupled code - The code has the option of not
only "failing" in the case that a particular contract is not supported
by the container. For example, if requestShutdown() isn't supported by
a container, then the RemoteManager component could print an appropriate
error message back to the client when a shutdown command is received.
And the RemoteManager code wouldn't have to reference the Phoenix-owned
BlockContext interface.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 09:53, Peter M. Goldstein wrote:
> > Thats essentially how it is defined now and how I think it should be.
>
> Well, I'm glad you concur but I don't think there is a general consensus
> among the participants in Avalon-dev. I certainly don't see this
> definition (or anything like it) clearly elucidated in the docs. To me,
> this paragraph seems like a natural starting point from which to build
> such a consensus as to the proper responsibilities of Context and
> ServiceManager.
The problem is that people disagree. However if you look at implemented
containers (here and elsewhere) the released implementations mainly follow
those guidelines.
The way Avalon context kinda came to be is that you take ServletContext and
separate out concerns that are Container agnostic (such as Logging, service
provision, configuration) and leave the remainder in the context.
So
Context = ServletContext - Logger - Configuration - ServiceManager
If you use the Context you are binding to container specific assumptions -
some of these assumptions may be shared between containers but some (like
shutting down app, bouncing mail, evaluating a property etc) are container
specific.
> Absolutely. And the inner Context can provide a nice abstraction
> barrier that insulates one container from another.
yep. Thats the way it was intended to work - kinda based on other service
frameworks.
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Peter,
> On Tue, 3 Dec 2002 08:08, Peter M. Goldstein wrote:
> > It also seems compatible with what seems to me to be the natural
> > separation between Contextualizable and Serviceable. Context
involves
> > data and services that are uniquely owned by the container (i.e. for
> > Avalon Phoenix, getBaseDirectory(), requestShutdown() and for James
> > Mailets, getPostmaster(), isLocalServer(String)). The essential
> > distinction as I see it is that services should be user-defined and
> > configured, while context-related items should be container-defined
and
> > not require configuration. Also, the services may include a
> > configurable dependency chain, while Context implementations should
be
> > available before any services are loaded and should not have a
> > configurable dependency chain.
>
> Thats essentially how it is defined now and how I think it should be.
Well, I'm glad you concur but I don't think there is a general consensus
among the participants in Avalon-dev. I certainly don't see this
definition (or anything like it) clearly elucidated in the docs. To me,
this paragraph seems like a natural starting point from which to build
such a consensus as to the proper responsibilities of Context and
ServiceManager.
> > The above definition is tightly tied to the nature of the container
and
> > the API it supports. Hence what is in the Context in a nested
container
> > might not naturally fall into the Context of its parent container.
>
> yep - and most likely the elements inside a nested containers context
are
> possibly defined by services that the parent containre offers.
Absolutely. And the inner Context can provide a nice abstraction
barrier that insulates one container from another.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > The above definition is tightly tied to the nature of the container and
> > the API it supports. Hence what is in the Context in a nested container
> > might not naturally fall into the Context of its parent container.
> yep - and most likely the elements inside a nested containers context are
> possibly defined by services that the parent containre offers.
Seems to me that in the concept of a scalable container, the elements are
likely to be provided by container plug-ins used to make up the profiles.
The core container code might not need any specific involvement with that
facility other than to provide a unified means to access it.
The notion of a "Context" in a profile-based container might be considered a
federation of contexts, not a nesting. If I might use the RFC 2141 example,
the NID identifies a context from the federation, and NSS identifies
something provided by that context.
This is independent of what kinds of data/services are provided by a
context.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 08:08, Peter M. Goldstein wrote:
> It also seems compatible with what seems to me to be the natural
> separation between Contextualizable and Serviceable. Context involves
> data and services that are uniquely owned by the container (i.e. for
> Avalon Phoenix, getBaseDirectory(), requestShutdown() and for James
> Mailets, getPostmaster(), isLocalServer(String)). The essential
> distinction as I see it is that services should be user-defined and
> configured, while context-related items should be container-defined and
> not require configuration. Also, the services may include a
> configurable dependency chain, while Context implementations should be
> available before any services are loaded and should not have a
> configurable dependency chain.
Thats essentially how it is defined now and how I think it should be.
> The above definition is tightly tied to the nature of the container and
> the API it supports. Hence what is in the Context in a nested container
> might not naturally fall into the Context of its parent container.
yep - and most likely the elements inside a nested containers context are
possibly defined by services that the parent containre offers.
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Religion is what the common people see as true, the |
| wise people see as false, and the rulers see as |
| useful" --Seneca |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
<minor-rant>
This appears to be another example where the Avalon developers are
making conclusions about another project's code without actually
understanding it. This happened with the ComponentManager discussion
and we all know (or if you don't know please read the archives) how well
that turned out. This sort of behavior really hurts the Avalon
reputation and frustrates those of us who are largely impressed with
Avalon from a technical standpoint, but question some of the social
practices manifested here.
</minor-rant>
Might I kindly suggest that when you want to collect information about
another project, you query the dev list for that project? Idle
speculation by the Avalon developers is hardly profitable and is not
really an effective way of evaluating customer needs. See my comments
on the current discussion below.
> >>I'm not sure that this is a great example. The MailetContext shares
> little
> >>in common with the Avalon Context, other than a name. It's the way
that
> a
> >>MailetContainer (potentially very different from an Avalon
Container)
> >>provides contextual information to a Mailet, which is a
domain-specific
> >>component running in a well-defined environment.
> >
> >
> > That pretty much defines the purpose of Avalons context ;)
> >
> > ie Take the ServletContext and remove configuration mechanisms (or
> > Configuration/Parameters in Avaloon terms) and service provision
> mechanisms
> > (or ServiceManager/ComponentManager in Avalon terms) and you are
left
> with
> > what should remain in the context.
>
> Exactly what I thought. I preferred to use this Context instead of the
> ServletContext because it's about something that uses Avalon; the fact
> that it does not extend the Avalon Context though is another
indication
> of something that's not really ok.
>
> Leo Simons wrote:
> > Apples 'n pears if you ask me.
> >
> > The JAMES MailetContext is not intimately related to the
> > avalon Context
> > at all. The MailetContext is used in a well-defined problem domain
> > (e-mail; mailets), the avalon context is way more generic.
>
> So, how do we put this?
>
> It's evident to me that there is some kind of miosmatch here between
> avalon devs them selves, and also avalon devs and users.
This dialogue is not quite right. Let's clarify a few things:
Here is the one and only way that the James source code currently uses
the Avalon context. This is to obtain the application base directory,
which is used in configuration URL resolution. This critical usage
isn't even mentioned in the above discussion. But it appears to be
consistent with all the divergent views of the Context, as the base
directory is a containter-provided data value that is made available to
the components.
There is an additional location where the Phoenix-specific BlockContext
should be used instead of the current code as written. In the
RemoteManager code James shuts down the system by directly calling
System.exit(0). That's not exactly a well behaved component, as it
doesn't give the container a proper opportunity for cleanup.
Instead, this code should call the requestShutdown() method of
BlockContext for a clean shutdown. Of course, this would further couple
us to Phoenix. And, from the recent discussion on the list, there
appears to be confusion as to whether this sort of method (side-effect,
no data) belongs in the Context. In any case, what James does is wrong,
but it's not clear to me exactly what would be the correct thing to do,
or even if Avalon has any ability to support the right thing in a way
that doesn't lock us to one container.
Now, on to the MailetContext. This has zero, zip, nada to do with the
Avalon Context, Paul's desires notwithstanding. In fact, some
discussions of the proper behavior of the Avalon Context (as a read-only
repository of container-provided data) clearly don't seem to support the
idea of implementing the MailetContext as an extension of Context.
The MailetContext is primarily used by Mailets to execute actions (i.e.
bouncing emails, placing an email on the processing queue) or to check
values (i.e. checking a server name to see if it's local), neither of
which seem to jibe with the read-only data container model espoused by
some.
Note that the current version of the Mailet API shouldn't be taken as
the final word. Explicitly slated for the next revision of James is a
redesign of the Mailet API. Some James developers (notably me) will be
pushing to remove at least some of the above from the MailetContext
(i.e. bounce logic). And we may find it desirable to add additional
functionality to the James-provided Mailet context. But this discussion
still lies in the future.
As a prelude to future James requirements, I would say that the most
important idea remains the contract(s) provided by a Context. Once
again, it is critical that a developer writing a component or set of
components that use Avalon be able to determine what contracts and
associated interfaces are provided by a container in a
container-independent way. Moreover some subset set of those
contracts/interfaces must be container-independent if it is going to be
possible to write components that are non-trivially
container-independent. These are the essential points.
As far as the counter-argument that "containers have nothing in common",
all I can say is that seems highly unlikely to me. If a container
exposes the ability to address files in the file system, a unified
interface seems possible. A container-independent interface for
exposing container identity information (i.e. name, version string)
seems easily within reach. A common interface that allows the component
to request component and/or container shutdown from the container also
seems feasible. Not all features need to be encapsulated in common
interfaces, but some should. Honestly, these three would satisfy James
entirely. And make it much more container portable. I think more
attention is required on this front.
On a related note, I'm also going to say here that I really like the
version of the Context logic that Noel was pushing, where the Context
lookup involves passing in a contract interface to the lookup and
retrieving a class that implements that interface. It seems an
effective and extensible way to provide container-defined services.
It also seems compatible with what seems to me to be the natural
separation between Contextualizable and Serviceable. Context involves
data and services that are uniquely owned by the container (i.e. for
Avalon Phoenix, getBaseDirectory(), requestShutdown() and for James
Mailets, getPostmaster(), isLocalServer(String)). The essential
distinction as I see it is that services should be user-defined and
configured, while context-related items should be container-defined and
not require configuration. Also, the services may include a
configurable dependency chain, while Context implementations should be
available before any services are loaded and should not have a
configurable dependency chain.
This distinction can be applied to any container/component model, not
just Avalon. And it also demonstrates why nested containers should not
necessarily simply pass through a Context from one level to another.
The above definition is tightly tied to the nature of the container and
the API it supports. Hence what is in the Context in a nested container
might not naturally fall into the Context of its parent container.
I will be raising this design suggestion as part of the discussion over
the next revision of the Mailet API.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Mon, 2 Dec 2002 22:38, Darrell DeBoer wrote:
>
>>I'm not sure that this is a great example. The MailetContext shares little
>>in common with the Avalon Context, other than a name. It's the way that a
>>MailetContainer (potentially very different from an Avalon Container)
>>provides contextual information to a Mailet, which is a domain-specific
>>component running in a well-defined environment.
>
>
> That pretty much defines the purpose of Avalons context ;)
>
> ie Take the ServletContext and remove configuration mechanisms (or
> Configuration/Parameters in Avaloon terms) and service provision mechanisms
> (or ServiceManager/ComponentManager in Avalon terms) and you are left with
> what should remain in the context.
Exactly what I thought. I preferred to use this Context instead of the
ServletContext because it's about something that uses Avalon; the fact
that it does not extend the Avalon Context though is another indication
of something that's not really ok.
Leo Simons wrote:
> Apples 'n pears if you ask me.
>
> The JAMES MailetContext is not intimately related to the
> avalon Context
> at all. The MailetContext is used in a well-defined problem domain
> (e-mail; mailets), the avalon context is way more generic.
So, how do we put this?
It's evident to me that there is some kind of miosmatch here between
avalon devs them selves, and also avalon devs and users.
--
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: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 2 Dec 2002 22:38, Darrell DeBoer wrote:
> I'm not sure that this is a great example. The MailetContext shares little
> in common with the Avalon Context, other than a name. It's the way that a
> MailetContainer (potentially very different from an Avalon Container)
> provides contextual information to a Mailet, which is a domain-specific
> component running in a well-defined environment.
That pretty much defines the purpose of Avalons context ;)
ie Take the ServletContext and remove configuration mechanisms (or
Configuration/Parameters in Avaloon terms) and service provision mechanisms
(or ServiceManager/ComponentManager in Avalon terms) and you are left with
what should remain in the context.
--
Cheers,
Peter Donald
He strains to hear a whisper who refuses to hear a shout.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Darrell DeBoer <da...@apache.org>.
On Mon, 2 Dec 2002 21:16, Paul Hammant wrote:
> Nicola,
>
> > This is how James uses the Context:
> > http://jakarta.apache.org/james/mailet/org/apache/mailet/MailetContext.ht
> >ml
> >
> > - What would data-only-usage Context advocates do with it? What problems
> > does it pose?
> > - Why is this (for method-containing Context advocates) the best
> > solution? - Why do I have a Context interface when in fact the Context is
> > used even without actually needing the specified method?
> >
> > If we don't discuss on real code, we won't get anywhere.
>
> A perfect world (contentious) JAMES would have MailetContext extending
> Context and being handed in to a component by Contextualize. This is not
> the case now.
>
> I agree though that it would represent a good real world case if that were
> so.
I'm not sure that this is a great example. The MailetContext shares little in
common with the Avalon Context, other than a name. It's the way that a
MailetContainer (potentially very different from an Avalon Container)
provides contextual information to a Mailet, which is a domain-specific
component running in a well-defined environment.
I'd like to see the base MailetContext stay Avalon-unaware if possible. If
it's possible (and we'll be discussing this in the up-and-coming James3
development round), then you may as well be using the ServletContext as a
model for your discussions.
One possibility (thinking out loud now), is that James could provide 2 set of
context to Mailets:- a MailetContext and an AvalonContext. So a mailet writer
could choose to be Mailet-container-agnostic and only use the Avalon-unaware
MailetContext, but they could also choose to implement Contextualizable and
get the full power of Avalon and all the services provided. In the latter
case, however, they wouldn't be able to run on the rival MailetContainer
secretly being developed by the JBoss team :).
--
cheers,
Darrell DeBoer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Paul Hammant <pa...@yahoo.com>.
Nicola,
> This is how James uses the Context:
> http://jakarta.apache.org/james/mailet/org/apache/mailet/MailetContext.html
>
> - What would data-only-usage Context advocates do with it? What problems
> does it pose?
> - Why is this (for method-containing Context advocates) the best solution?
> - Why do I have a Context interface when in fact the Context is used
> even without actually needing the specified method?
>
> If we don't discuss on real code, we won't get anywhere.
A perfect world (contentious) JAMES would have MailetContext extending Context and being handed in
to a component by Contextualize. This is not the case now.
I agree though that it would represent a good real world case if that were so.
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Leo Simons <le...@apache.org>.
On Mon, 2002-12-02 at 11:21, Nicola Ken Barozzi wrote:
> Now it's time for some meat.
>
> This is how James uses the Context:
> http://jakarta.apache.org/james/mailet/org/apache/mailet/MailetContext.html
>
> - What would data-only-usage Context advocates do with it? What problems
> does it pose?
> - Why is this (for method-containing Context advocates) the best solution?
> - Why do I have a Context interface when in fact the Context is used
> even without actually needing the specified method?
>
> If we don't discuss on real code, we won't get anywhere.
Apples 'n pears if you ask me.
The JAMES MailetContext is not intimately related to the avalon Context
at all. The MailetContext is used in a well-defined problem domain
(e-mail; mailets), the avalon context is way more generic. If one were
to refactor the mailet API to create a closer coupling between it and
avalon framework, there's a lot of things to change. Stuff like log(),
bounce(), store() and send() would not make sense in the scope of an
avalon context.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Peter Donald wrote:
>
>> On Tue, 26 Nov 2002 21:40, Nicola Ken Barozzi wrote:
>>
>>> _Context_ and _Contextualizable_ are *the* way in which the Container
>>> can give the Component some *data*.
>>
>>
>> Thats not how it is used nor how it is described in javadocs. To
>> extract some words from the javadocs
>
> My description was also based on the last comments by other developers,
> which implied that a shift in usage pattern may be needed.
Now it's time for some meat.
This is how James uses the Context:
http://jakarta.apache.org/james/mailet/org/apache/mailet/MailetContext.html
- What would data-only-usage Context advocates do with it? What problems
does it pose?
- Why is this (for method-containing Context advocates) the best solution?
- Why do I have a Context interface when in fact the Context is used
even without actually needing the specified method?
If we don't discuss on real code, we won't get anywhere.
--
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: [SUMMARY] Context
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Tue, 26 Nov 2002 21:40, Nicola Ken Barozzi wrote:
>
>>_Context_ and _Contextualizable_ are *the* way in which the Container
>>can give the Component some *data*.
>
> Thats not how it is used nor how it is described in javadocs. To extract some
> words from the javadocs
My description was also based on the last comments by other developers,
which implied that a shift in usage pattern may be needed.
--
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: [SUMMARY] Context
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 26 Nov 2002 21:40, Nicola Ken Barozzi wrote:
> _Context_ and _Contextualizable_ are *the* way in which the Container
> can give the Component some *data*.
Thats not how it is used nor how it is described in javadocs. To extract some
words from the javadocs
* Each Container-Component relationship will also involve defining
* a contract between two entities. This contract will specify the
* services, settings and information that is supplied by the
* Container to the Component.
*
* The values placed in the context are runtime values that can
* only be provided by the container. The Context should <b>NOT</b> be
* used to retrieve configuration values or services that can be provided
* by peer components.
So essentially it defines runtime values (data and services) that are only
capable of being supplied by the container. There is no need to mix concerns
between peer/user provided values and container provided values.
Examples of container provided services that should not be provided by peers;
/**
* A block can request that the application it resides in be
* shut down. This method will schedule the blocks application
* for shutdown. Note that this is just a request and the kernel
* may or may not honour the request (by default the request will
* be honored).
*/
void requestShutdown();
/**
* Retrieve a resource from the SAR file. The specified
* name is relative the root of the archive. So you could
* use it to retrieve a html page from within sar by loading
* the resource named "data/main.html" or similar.
* Names may be prefixed with '/' character.
*
* @param name the name of resource
* @return the InputStream for resource or null if no such resource
*/
InputStream getResourceAsStream( String name );
/**
* Retrieve the proxy for this object.
* Each Block is referenced by other Blocks via their Proxy. When Phoenix
* shuts down the Block, it can automatically invalidate the proxy. Thus
* any attempt to call a method on a "dead"/shutdown object will result in
* an {@link IllegalStateException}. This is desirable as it will
* stop objects from using the Block when it is in an invalid state.
*
* <p>The proxy also allows Phoenix to associate "Context" information
with
* the object. For instance, a Block may expect to run with a
* specific ContextClassLoader set. However if this Block were to be
passed
* to another component that processed the Block in a thread that did not
* have the correct context information setup, then the Block could fail
* to perform as expected. By passing the proxy instead, the correct
context
* information is maintained by Phoenix.</p>
*
* <p>Note that only interfaces that the Block declares as offered
services
* will actually be implemented by the proxy.</p>
*/
Object getProxy();
/**
* This method is similar to {@link #getProxy()} except that it operates
* on arbitrary objects. It will in effect proxy all interfaces that the
* component supports.
*
* <p>Proxying arbitrary objects is useful for the same reason it is
useful
* to proxy the Block. Thus it is recomended that when needed you pass
* Proxys of objects to minimize the chance of incorrect behaviour.</p>
*/
Object getProxy( Object other );
/**
* This method generates a Proxy of the specified object using the
* specified interfaces. In other respects it is identical to
* getProxy( Object other )
*/
Object getProxy( Object other, Class[] interfaces );
--
Cheers,
Peter Donald
---------------------------------------------------
Murphy's law - "Anything that can go wrong, will."
(Actually, this is Finagle's law, which in itself
shows that Finagle was right.)
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Use Forrest for all Avalon docs
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> On Wed, 2002-11-27 at 12:08, Leo Simons wrote:
>
>>I think it would be real good to make this move, but I don't want to put
>>in the effort to make these changes right now. As for skins, I can live
>>with any of them; the krysalis looks real nice :D
>
> on a related note, the avalon excalibur front page has a <warn> tag for
> the sources but no red flagging of any kind shows up on the generated
> docs. I can't really figure out where/how to fix this?
The current forrest document11 DTD is here
http://xml.apache.org/forrest/document-v11.dtdx.html
Since the Cocoon in the jakarta-avalon repo is no more to remain, we
should port at least all docs currently done by Cocoon (it was
effectively a modified Forrest) to Forrest.
I've merged the old skin with the new one in Forrest-CVS, so that with
latest Forrest CVS (which also has better error reporting), the pages
render exactly like the ones on the main site now. This is to prevent us
to get tangled again in skin decisions ATM.
--
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: [PROPOSAL] Use Forrest for all Avalon docs
Posted by Leo Simons <le...@apache.org>.
On Wed, 2002-11-27 at 12:08, Leo Simons wrote:
> I think it would be real good to make this move, but I don't want to put
> in the effort to make these changes right now. As for skins, I can live
> with any of them; the krysalis looks real nice :D
on a related note, the avalon excalibur front page has a <warn> tag for
the sources but no red flagging of any kind shows up on the generated
docs. I can't really figure out where/how to fix this?
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Use Forrest for all Avalon docs
Posted by Leo Simons <le...@apache.org>.
I'm +0.
I think it would be real good to make this move, but I don't want to put
in the effort to make these changes right now. As for skins, I can live
with any of them; the krysalis looks real nice :D
cheers,
- Leo
On Tue, 2002-11-26 at 11:59, Nicola Ken Barozzi wrote:
> This proposal should mark the end to our doc discussions.
>
> Forrest has grown since the start, and the Phoenix guys have accepted to
> convert the documentation format to Forrest format.
> Forrest is being actively developed and maintained, and projects like
> incubator.apache.org and commons.apache.org are using/going to use it.
>
> I want to propose that all projects in Avalon-land have documentation in
> Forrest format.
>
> As for the skin, it's (again) to be decided, and it must be the same one
> for all.
>
> Avaliable are the forrest skin, the new avalon-site one similar to the
> current one, and the new krysalis one
> (http://www.krysalis.org/centipede/beta3/).
>
> All can be customized in font sizes and color schemes, and the Forrest
> one will (soon) be changed to a CSS-only version.
>
> Please let me know what you prefer.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PROPOSAL] Use Forrest for all Avalon docs
Posted by Nicola Ken Barozzi <ni...@apache.org>.
This proposal should mark the end to our doc discussions.
Forrest has grown since the start, and the Phoenix guys have accepted to
convert the documentation format to Forrest format.
Forrest is being actively developed and maintained, and projects like
incubator.apache.org and commons.apache.org are using/going to use it.
I want to propose that all projects in Avalon-land have documentation in
Forrest format.
As for the skin, it's (again) to be decided, and it must be the same one
for all.
Avaliable are the forrest skin, the new avalon-site one similar to the
current one, and the new krysalis one
(http://www.krysalis.org/centipede/beta3/).
All can be customized in font sizes and color schemes, and the Forrest
one will (soon) be changed to a CSS-only version.
Please let me know what you prefer.
--
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>
[SUMMARY] Context
Posted by Nicola Ken Barozzi <ni...@apache.org>.
I've been reading all your mails about the Context with great interest,
and will try here to summarize the things that IMHO have emerged.
-oOo-
_Context_ and _Contextualizable_ are *the* way in which the Container
can give the Component some *data*.
It's similar to a "ServiceManager", but it gives the Component some
information, not services. Data objects are different from a service
objects, because are not used to /act/, but to give simple pure data info.
The signature of the Context interface is very similar to the
ServiceManager one, but the difference is that it gives data instead of
services. This cannot be enforced as in Java Objects contain both
informations, but it's a behavioural contract nevertheless.
As Services are cast to the correct service interface, each data item is
cast to his correct interface.
As ServiceManagers are not cast to something else, Contexts should not
be cast to anything else.
Services are declared beforehand to be served by the ServiceManager.
In the same fashion context data should be declared beforehand.
But since in the Context there are some values that are needed by most
use-cases, it's sensible to define some standard keys beforehand, by
using a URN, that all containers must honor.
This is to maximize portability of Components/Services between containers.
Non-standard keys are permitted, but limit the portability of the
Components that rely on them. Becasue we want to make our components
portable, all Components made here must ship without extra key
dependencies. If it's not possible, we must come to a general definition
of the required key/s and honor them for all containers.
--
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: Context - a future
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Peter Donald [mailto:peter@realityforge.org]
>>
>>On Tue, 26 Nov 2002 01:31, Berin Loritsch wrote:
>>
>>>>2) What is the timescale we are trying aim for? Can it go
>>>>into Phoenix and Merlin or is it a
>>>>revolution, thus only for uber-container?
>>>
>>>It is a refinement of the Container/Component contracts.
>>>
>>>I do not think that we have to preclude the casting of the
>>>generic Context to a more specific context. I do think we
>>>should have a minimal standard set of values that are always
>>>bound to the Context--things that configurations won't be
>>>able to handle.
>>
>>The only truly generic entry is "name". There are others that
>>may be supplied
>>(directory, work directory, classloader) but they are far
>>from common among
>>all containers.
>
>
> The rest of those would fit in the SE (Standard Edition)
> container, but the "name" is all that would be required for
> ME.
Seems ok to define different profiles for different containers.
So that components would be compatible with a given profile or higher.
--
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: Context - a future
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Tue, 26 Nov 2002 01:31, Berin Loritsch wrote:
> > > 2) What is the timescale we are trying aim for? Can it go
> > > into Phoenix and Merlin or is it a
> > > revolution, thus only for uber-container?
> >
> > It is a refinement of the Container/Component contracts.
> >
> > I do not think that we have to preclude the casting of the
> > generic Context to a more specific context. I do think we
> > should have a minimal standard set of values that are always
> > bound to the Context--things that configurations won't be
> > able to handle.
>
> The only truly generic entry is "name". There are others that
> may be supplied
> (directory, work directory, classloader) but they are far
> from common among
> all containers.
The rest of those would fit in the SE (Standard Edition)
container, but the "name" is all that would be required for
ME.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context - a future
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 26 Nov 2002 01:31, Berin Loritsch wrote:
> > 2) What is the timescale we are trying aim for? Can it go
> > into Phoenix and Merlin or is it a
> > revolution, thus only for uber-container?
>
> It is a refinement of the Container/Component contracts.
>
> I do not think that we have to preclude the casting of the
> generic Context to a more specific context. I do think we
> should have a minimal standard set of values that are always
> bound to the Context--things that configurations won't be
> able to handle.
The only truly generic entry is "name". There are others that may be supplied
(directory, work directory, classloader) but they are far from common among
all containers.
--
Cheers,
Peter Donald
--------------------------------------------------
"An intellectual is someone who has been educated
beyond their intelligence."
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context - a future
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Paul Hammant [mailto:paul_hammant@yahoo.com]
>
> Can someone who is _not_ advocating any of the competing
> propositions for Context please lead this
> task:
>
> We need a 'roll-up' on this rapidly sprawling thread. Many
> people (incl me) are being lost in the
> extensive detail.
>
> 1) What are the competing solutions .. hashmap style get(),
> cast to Context derived interfaces etc
> ...
Concider the comments from my other post: "On Context". That
was its purpose. There will be certain instances where it
is better to have the Container take care of the Context building
and pass it to specific components like this:
Servlet {
initialize( ServletConfiguration config );
}
ServletConfiguration {
ServletContext getContext();
}
It could be something like Cocoon would want to pass the ServletContext
like CocoonContext to all its components via the contextualize()
method. If so, the user would have the option of casting the
context to a CocoonContext object--forever scoping their component
to Cocoon, or using the more generic version of the interface.
There are pros and cons. Anytime a Context is used, hopefully
there is some sort of "living area" for the set of components
in an application. That living area can be a directory on the
server, or it can be a work area that all the different components
share. Those can be constants to the Context object (it would
work for Servlets and Blocks).
It is not an easy thing to say "This is how we do it".
> 2) What is the timescale we are trying aim for? Can it go
> into Phoenix and Merlin or is it a
> revolution, thus only for uber-container?
It is a refinement of the Container/Component contracts.
I do not think that we have to preclude the casting of the
generic Context to a more specific context. I do think we
should have a minimal standard set of values that are always
bound to the Context--things that configurations won't be
able to handle.
> The idea is that we get one summary of the choices. It may
> be that me, Stephen, Leo(s) post
> comment and the rollup is modified. Best to leave the start
> of this to unaligned person though.
I fail to see what the major issue is? We need to add warnings
that if the Context is cast to something more specific, you are
effectively limiting your components to a specific container.
Alternatively, we may want to simply pass in a typed context. In
that case we would need a way to intelligently alter the lifecycle.
That would require Peter's solution to be done and adopted, and
that would be a revolution and slated for Avalon 5.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>