You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/09/06 12:05:41 UTC
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
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).
--
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: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Stephen McConnell <mc...@apache.org>.
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).
>
Absolutely correct - there is not valid reason to extend context.
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: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> 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.
Yep.
>
> Solution: declare it! ;-)
Exactly.
>
>
> 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.
>
I completely agree.
Context is no less a dependency condition that a service dependency -
they are handled differently (a service depedency reference a component
that may have dependencies, etc. whereas a context depedency is a
dependecy on an java.lang.Object or derived type). This issue here is
"declaration" which I think is comming sometime soon. Based on the
updates on the CVS to seperate a release Phoenix from ongoping
development I'm happy to withdraw my -1s because I'm confident that we
will see declaration of context criteria inside Phoenix in the near
future. Assuming extensions are put in place such that they respect the
underlying context rules (i.e. access to an typed object via a key -
then we will not have a problem or at least reduce the scope of the
problem to identifed non-portable component types).
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: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> - Now it seems to me that BlockContext would be an excellent candidate
> for the containerkit Context.
> I would humbly propose to maybe put the BlockContext in containerkit,
> deprecate the one in Phoenix, make the Phoenix one extend the
> containerkit one for compatibility, and make Cornestone blocks, which
> IIUC Peter also would like to see a components in excalibur (or
> something like that), use the containerkit context.
>
> What do you think, is it viable?
We have Context interface and that is completely workable. With the
two meta-info models that exist (excalibur/meta and excalibur/info) you
the ability to declare that a component has a requirement for the supply
of a context object such that it can be narrowed to some other
interface. However, you alway have the constraint that we are talking
about a Context derivative. Context works well if you respect its
purpose and function. Introducing something like BlockContext into
either the meta or info packages does not make sence because that are
about describing something like a BlockContext. Introducing
BlockContext into excalibur/container would make sence if there is
agreement across at least a couple of container projects. Introducing
BlockContext into containerkit is equivalent to leaving it where it is
Phoenix.
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: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Nicola,
>
>>>> There is now 2 -1s on BlockContext.
>>>
>>>
>>>
>>>
>>> I like BlockContext. +1
>>>
>>> ( By my reckoning you are now at only -1 )
>>
>>
>>
>> Naa, he withdrew them.
>
>
> Yup bloody partially threaded mail (poor substiture for NNTP).
>
>> Paul, it's not about what I like or what you like or what John Doe
>> likes.
>> BlockContext is a dependency to Phoenix, and *if* we want to make
>> cross-container compatible components, it's not a solution.
>
>
> BlockContext is a dependancy to Phoenix's hosted compoent API
> (phoenix-client.jar). You do not need the rest of Phoenix to mount
> blocks. It is easy to be compatible,
>
>> It binds you to Phoenix, but I assume that it's not a problem for
>> you, you also made a GUI in Phoenix, so I understand you don't see
>> the point.
>
>
> It does not bind you to phoenix per se. It binds you to the small
> redistrubitable phoenix-client.jar and the classes it contains. This
> is true interface/impl separated API, and not a 'blessed' API like
> Sun's Servlet or JMX (and other I presume).
True.
And today with Phoenix as is - it defines a variant of a the Avalon
Component Model. That's ok providing the users of the API understand
the implications of coding against a container specific API. Those
implications are generally bad and should be documeted as
"not-best-practice".
>
>> But Avalon is not only Phoenix, and as Peter pointed out he would
>> like to be able to use Cocoon components.
>> I would like to use Phoenix components.
>
>
> There is no reason that a container could not afford a contextualize()
> that supports castability to BlockContext, CocoonContext, FooContext
> and BarContext.
Only if (a) you have a meta-info model in place that declares the
context derivative, and (b) the derivatibve implementation documents its
contract relative to the pure Context interface. Without those two
things in-place there is one good reason - your component will not run
outside of the Phoinix environment.
>
>> If I make the Cocoon components dependent on CocoonContext, it would
>> not make reuse by Phoenix possible.
>
>
> Maybe an kernel extended Phoenix could support CocoonContext and
> BlockContext (see above).
I think that is the wrong way to look at the problem. User's should not
be consered with "workarounds" - that should be able to build and deploy
components without concern for the containerment environment. In the
rare cases where something additional is needed, a good container will
provide plug-in mechanisms that provide a means for extension of the
container. In the long term its possible for such containement
extensions to become standard - but only with the emergence of several
different contains and a vested interest by respective champions to
achieve a common platform. Out there in the real world there are clear
economic reasons for doing that - in the open-source world things are a
lot more gray.
>
>> Think about this, instead of just saying "I like it".
>
>
> You unfairly trivialize my posting.
>
>> Let me be more clear if I can: Phoenix has a specific Context that it
>> only can use. It's needed, regardless to how itthere; it's needed,
>> and from a functionality POV I like it too.
>
>
> You make your case well. You are wrong that it is the only container
> than can use the years old BlockContext. I have outlined a number of
> times ways that aloternate containers can be compatible with
> BlockContext. The committer have taken a vote on the recommendation
> that phoenix-client.jar be considered the way that these alternate
> containers be compatible with BlockContext. I really don't see where
> the problem is.
Phonieix today does not provide any support for context declaration
which means Phoenix depedency components are locked into (a) using the
client jar file AND providing an alternative implemetation of
BlockContext. Paul - that's a big "AND" that I think you may have
forgotten about. Every addition to the BlockContext interface is
another problem to be dealt with. The practicle solution is for other
container to fall-back to common denominator position - the Avalon
Framework - Context interface. This at least places the responsibility
onto component authors to be careful about containment depedencies.
>
>
>> So the thing should be dealt with on two levels, which we are doing:
>>
>> 1) define common attributes and possibly common Context keys to
>> access common functionality
>>
>> - thus we need to have a simpèle way of telling in the descriptor
>> what Context is needed.
>
>
> Personally I am only willing to get embroiled in an attributes
> discussion if you will cede to and honor a simple often repeated point
>
> Other containers *can* be compatible with BlockContext, it is not
> tied to the Phoenix impl, it is reimplementable.
Sure - and I could join the Republican Party - but is it a good idea?.
;-)
>
>> 2) provide a "standard" implementation for "standard" containers of
>> concrete implementations of the framework, which is Containerkit.
>>
>> - Now it seems to me that BlockContext would be an excellent
>> candidate for the containerkit Context.
>> I would humbly propose to maybe put the BlockContext in containerkit,
>> deprecate the one in Phoenix, make the Phoenix one extend the
>> containerkit one for compatibility, and make Cornestone blocks, which
>> IIUC Peter also would like to see a components in excalibur (or
>> something like that), use the containerkit context.
>
>
> This is perfectly possible.
Anything is possible.
> It would work as a strategy,
A strategy towards what objective ?
With the seperation of the meta-info content from containerkit -
containerkit is just another container API that will probably end up
inside Phoenix.
> It might please people who don't want any phoenix package imports in
> their components. However, there is no proven need for it given the
> fact that phoenix-client.jar is usable by alternative containers.
Providing every other container provides the implemetations for Phonix
specific stuff - can someone explain to me why this is good thing?
Steve.
>
> - Paul
>
>
>
> --
> 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: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> Nicola,
>
>>>> There is now 2 -1s on BlockContext.
>>>
>>>
>>> I like BlockContext. +1
>>>
>>> ( By my reckoning you are now at only -1 )
>>
>> Naa, he withdrew them.
>
>
> Yup bloody partially threaded mail (poor substiture for NNTP).
>
>> Paul, it's not about what I like or what you like or what John Doe likes.
>> BlockContext is a dependency to Phoenix, and *if* we want to make
>> cross-container compatible components, it's not a solution.
>
> BlockContext is a dependancy to Phoenix's hosted compoent API
> (phoenix-client.jar). You do not need the rest of Phoenix to mount
> blocks. It is easy to be compatible,
Many are deprecated, and Peter has clearly said he is moving to an
improved component model... which I think is even better BTW :-)
>> It binds you to Phoenix, but I assume that it's not a problem for you,
>> you also made a GUI in Phoenix, so I understand you don't see the point.
>
> It does not bind you to phoenix per se. It binds you to the small
> redistrubitable phoenix-client.jar and the classes it contains. This is
> true interface/impl separated API, and not a 'blessed' API like Sun's
> Servlet or JMX (and other I presume).
Hmmm...
>> But Avalon is not only Phoenix, and as Peter pointed out he would like
>> to be able to use Cocoon components.
>> I would like to use Phoenix components.
>
> There is no reason that a container could not afford a contextualize()
> that supports castability to BlockContext, CocoonContext, FooContext and
> BarContext.
All in one? :-?
>> If I make the Cocoon components dependent on CocoonContext, it would
>> not make reuse by Phoenix possible.
>
> Maybe an kernel extended Phoenix could support CocoonContext and
> BlockContext (see above).
You mean that in contextualize(), the context I get will be castable to
any of the above or that the container gives the appropriate context to
the appropriate component?
Ok, probably the case is the latter.
From containerkit:
<context type="MyContextInterface">
<entry key="base" type="java.io.File"/>
<entry key="mode" type="java.lang.Object" optional="TRUE"/>
</context>
I'm cool with it :-)
>> Let me be more clear if I can: Phoenix has a specific Context that it
>> only can use. It's needed, regardless to how itthere; it's needed, and
>> from a functionality POV I like it too.
>
> You make your case well. You are wrong that it is the only container
> than can use the years old BlockContext. I have outlined a number of
> times ways that aloternate containers can be compatible with
> BlockContext. The committer have taken a vote on the recommendation
> that phoenix-client.jar be considered the way that these alternate
> containers be compatible with BlockContext. I really don't see where
> the problem is.
It's not a problem.
But since many things from there have somewhat landed in containerkit, I
was asking myself if it could go in excalibur as a common block; Phoenix
might have his own context that extends it still, but maybe it's time we
push it to a "standard" that is not only de-facto.
>> So the thing should be dealt with on two levels, which we are doing:
>>
>> 1) define common attributes and possibly common Context keys to access
>> common functionality
>>
>> - thus we need to have a simpèle way of telling in the descriptor what
>> Context is needed.
>
>
> Personally I am only willing to get embroiled in an attributes
> discussion if you will cede to and honor a simple often repeated point
Naaa, we can discuss on this too without fear, also since containerkit
already has the notion of a context desctiption.
> Other containers *can* be compatible with BlockContext, it is not tied
> to the Phoenix impl, it is reimplementable.
Ok, yes, ja, oui, it's true.
BlockContext is part of a Phoenix API, and is reimplementable and usable
outside of the Phoenix implementation.
>> 2) provide a "standard" implementation for "standard" containers of
>> concrete implementations of the framework, which is Containerkit.
>>
>> - Now it seems to me that BlockContext would be an excellent candidate
>> for the containerkit Context.
>> I would humbly propose to maybe put the BlockContext in containerkit,
>> deprecate the one in Phoenix, make the Phoenix one extend the
>> containerkit one for compatibility, and make Cornestone blocks, which
>> IIUC Peter also would like to see a components in excalibur (or
>> something like that), use the containerkit context.
>
>
> This is perfectly possible. It would work as a strategy, It might
> please people who don't want any phoenix package imports in their
> components. However, there is no proven need for it given the fact that
> phoenix-client.jar is usable by alternative containers.
Paul, it's not about not wanting Phoenix imports.
It's about opportunity.
The opportunity to officially push defacto standards that are useful to
a real Avalon standard.
If I want to use httpclient, I use httpclient. In your line of
reasoning, I should have used slide-client.
There is a reason why it was put in commons, and the same reason applies
to phoenix-client, well much of it.
Peter has made his view on the "common" stuff quite clear, and
containerkit is the right direction.
Think about this in that perspective.
--
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: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Paul Hammant <Pa...@yahoo.com>.
Nicola,
>>> There is now 2 -1s on BlockContext.
>>
>>
>>
>> I like BlockContext. +1
>>
>> ( By my reckoning you are now at only -1 )
>
>
> Naa, he withdrew them.
Yup bloody partially threaded mail (poor substiture for NNTP).
> Paul, it's not about what I like or what you like or what John Doe likes.
> BlockContext is a dependency to Phoenix, and *if* we want to make
> cross-container compatible components, it's not a solution.
BlockContext is a dependancy to Phoenix's hosted compoent API
(phoenix-client.jar). You do not need the rest of Phoenix to mount
blocks. It is easy to be compatible,
> It binds you to Phoenix, but I assume that it's not a problem for you,
> you also made a GUI in Phoenix, so I understand you don't see the point.
It does not bind you to phoenix per se. It binds you to the small
redistrubitable phoenix-client.jar and the classes it contains. This is
true interface/impl separated API, and not a 'blessed' API like Sun's
Servlet or JMX (and other I presume).
> But Avalon is not only Phoenix, and as Peter pointed out he would like
> to be able to use Cocoon components.
> I would like to use Phoenix components.
There is no reason that a container could not afford a contextualize()
that supports castability to BlockContext, CocoonContext, FooContext and
BarContext.
> If I make the Cocoon components dependent on CocoonContext, it would
> not make reuse by Phoenix possible.
Maybe an kernel extended Phoenix could support CocoonContext and
BlockContext (see above).
> Think about this, instead of just saying "I like it".
You unfairly trivialize my posting.
> Let me be more clear if I can: Phoenix has a specific Context that it
> only can use. It's needed, regardless to how itthere; it's needed, and
> from a functionality POV I like it too.
You make your case well. You are wrong that it is the only container
than can use the years old BlockContext. I have outlined a number of
times ways that aloternate containers can be compatible with
BlockContext. The committer have taken a vote on the recommendation
that phoenix-client.jar be considered the way that these alternate
containers be compatible with BlockContext. I really don't see where
the problem is.
> So the thing should be dealt with on two levels, which we are doing:
>
> 1) define common attributes and possibly common Context keys to access
> common functionality
>
> - thus we need to have a simpèle way of telling in the descriptor what
> Context is needed.
Personally I am only willing to get embroiled in an attributes
discussion if you will cede to and honor a simple often repeated point
Other containers *can* be compatible with BlockContext, it is not tied
to the Phoenix impl, it is reimplementable.
> 2) provide a "standard" implementation for "standard" containers of
> concrete implementations of the framework, which is Containerkit.
>
> - Now it seems to me that BlockContext would be an excellent candidate
> for the containerkit Context.
> I would humbly propose to maybe put the BlockContext in containerkit,
> deprecate the one in Phoenix, make the Phoenix one extend the
> containerkit one for compatibility, and make Cornestone blocks, which
> IIUC Peter also would like to see a components in excalibur (or
> something like that), use the containerkit context.
This is perfectly possible. It would work as a strategy, It might
please people who don't want any phoenix package imports in their
components.
However, there is no proven need for it given the fact that
phoenix-client.jar is usable by alternative containers.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> Stephen,
>
>> There is now 2 -1s on BlockContext.
>
>
> I like BlockContext.
> +1
>
> ( By my reckoning you are now at only -1 )
Naa, he withdrew them.
Paul, it's not about what I like or what you like or what John Doe likes.
BlockContext is a dependency to Phoenix, and *if* we want to make
cross-container compatible components, it's not a solution.
It binds you to Phoenix, but I assume that it's not a problem for you,
you also made a GUI in Phoenix, so I understand you don't see the point.
But Avalon is not only Phoenix, and as Peter pointed out he would like
to be able to use Cocoon components.
I would like to use Phoenix components.
If I make the Cocoon components dependent on CocoonContext, it would not
make reuse by Phoenix possible.
Think about this, instead of just saying "I like it".
Let me be more clear if I can: Phoenix has a specific Context that it
only can use. It's needed, regardless to how itthere; it's needed, and
from a functionality POV I like it too.
But we also like to see components be able to work accross containers,
so the dependency has to be quite strong IMHO, or else it means that the
functionality it provides is general enough for quite all containers.
Now, given that most containers have some need from this stuff, Peter
rightly went on with containerkit, so that similar containers can share
the same underlying system.
And introduced attributes which are a terrific way to specify additional
stuff.
So the thing should be dealt with on two levels, which we are doing:
1) define common attributes and possibly common Context keys to access
common functionality
- thus we need to have a simpèle way of telling in the descriptor what
Context is needed.
2) provide a "standard" implementation for "standard" containers of
concrete implementations of the framework, which is Containerkit.
- Now it seems to me that BlockContext would be an excellent candidate
for the containerkit Context.
I would humbly propose to maybe put the BlockContext in containerkit,
deprecate the one in Phoenix, make the Phoenix one extend the
containerkit one for compatibility, and make Cornestone blocks, which
IIUC Peter also would like to see a components in excalibur (or
something like that), use the containerkit context.
What do you think, is it viable?
--
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: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
> There is now 2 -1s on BlockContext.
I like BlockContext.
+1
( By my reckoning you are now at only -1 )
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Stephen McConnell <mc...@apache.org>.
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()
>
> This is not 2 -1s on BlockContext (there is also the requestShutdown
> method addition that has not been rectified).
Correction:
There is now 2 -1s on BlockContext.
>
>
> 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: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Stephen McConnell <mc...@apache.org>.
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()
This is not 2 -1s on BlockContext (there is also the requestShutdown
method addition that has not been rectified).
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: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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...
--
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>