avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date Tue, 03 Dec 2002 00:26:44 GMT


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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-dev-help@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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message