avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces ApplicationContext.java Kernel.java
Date Fri, 06 Sep 2002 19:49:36 GMT

Stephen McConnell wrote:
> 
> 
> Nicola Ken Barozzi wrote:
> 
>>
>> Nicola Ken Barozzi wrote:
>>
>>>
>>> donaldp@apache.org wrote:
>>>
>>>> donaldp     2002/09/06 02:42:35
>>>>
>>> ...
>>>
>>>>   Log:
>>>>   Implement BlockContext.getResourceAsStream() so that a block is 
>>>> capable of
>>>>   locating resources in the sar file. This method will retrieve the 
>>>> resource
>>>>   regardless of where it is located.
>>>>     This allows blocks to aquire resources regardless of where they 
>>>> are located;
>>>>   * in base directory
>>>>   * in work directory
>>>>   * in .sar file (in future)
>>>>   * in some vfs (in future)
>>>
>>>
>>> This is a non-standard implementation of a Context...
>>>
>>> -1  *if* Blocks must aquire it using a cast, because it makes them
>>> unnecessarily dependent on Phoenix. Unnecessarily since this is a 
>>> general
>>> concept.
>>>
>>> This can be done also as a Service, so it gets inserted as a 
>>> dependency; if it must stay in the Context, it should be gotten from 
>>> the context via a key that is declared in xinfo (I propose it to be 
>>> standard).
>>
>> I really didn't mean to veto formally, just regard this as an opinion 
>> on how it could also be done...
>>
> 
> In which case I'll veto this formally.
> 
> -1 to the addition of BlockContext.getResourceAsStream()

Stephen, I have been thinking about this today, and I looked at mail 
archives and at other widely used Contexts (ServletContext), and came to 
the conclusion that it's not an issue.

What we both think is bad, it to have to cast a Context to a specific 
Context instance, which sounds as bad as casting a ServiceManager to a 
specific ServiceManager.

Why?
Because it's not declared in the descriptor.

Solution: declare it! ;-)

Simply declare it, and the problem will vanish, since having 
dependencies to a Context or to the objecs in the Context is equivalent, 
there is just a further deferencing level, but the dependency is still 
there, you cannot remove it.

Also, think of how other context are, they are like the BlockContext, 
and this is how users want it.

For example, i was quite confused by the deferencing that the Cocoon 
Context does; to use the objectmodel methods I have to get the Context, 
then get the objectmodel from it, and then call some method!

Honestly I now think that it's better for some cases that the users to 
have the context be declared as a dependency itself.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
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