Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
From: "Leo Sutic" <leo.sutic@inspireinfrastructure.com>
To: "'Avalon Developers List'" <avalon-dev@jakarta.apache.org>
Subject: RE: [Avalon4:PROPOSAL] Context Consensus
Date: Thu, 12 Dec 2002 14:12:28 +0100
Message-ID: <000b01c2a1e0$20f3a5a0$0801a8c0@Lagrange>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <200212122203.37915.darrell@apache.org>
Importance: Normal


> From: Darrell DeBoer [mailto:darrell@apache.org] 
> 
> G'day
> 
> On Wed, 11 Dec 2002 09:23, Leo Sutic wrote:
> > NOTE REGARDING consensus: Darrell voiced opposition to this scheme. 
> > However, it seemed to me that the objection was based on the 
> > assumption that the container would have a dependency on T. 
> Darrell, 
> > does your objection still stand?
> 
> I certainly don't plan to fight tooth and nail over it. 
> However, I've yet to see any argument where the benefits of 
> requiring a castable context outweigh the added complexity. 
> So yep, I still feel the same way; I'd rather keep the context 
> simple.

Are your opposition strong enough that you would veto it with a
-1, or is it of the "would accept it with a -0"-kind? (Read
below, I'll clarify some points.) The reason I'm asking is that
there is some consensus that this proposal would be acceptable
(not that everyone is crazy about it, but it is common ground,
which is more than we've had so far) to all.
 
> > There is consensus that a method of specifying a context 
> interface is 
> > needed in order to specify the Phoenix BlockContext given 
> its current 
> > usage pattern.
> 
> Only to make the current usage pattern concrete and required 
> as part of the 
> Avalon Framework contracts. There's no reason that we can't 
> declare the 
> current usage to be Phoenix-specific, keep it working in 
> Phoenix, provide a 
> better way, and *gently* encourage people to move over to it.

The reason why the usage pattern must be defined at a framework
level is because if it isn't then there's no way to express
in the metadata that the component can't run in a non-Phoenix
container.
 
> But *when* they decide to upgrade to the *new* Context-Meta 
> specification of 
> the framework, wouldn't it be good to encourage them to take 
> on a new, better 
> usage pattern as well. 

A Phoenix component may be distributed to a person who wants to
run it in their container. The person writing the component,
and the one writing the metainfo may be two very different
persons.

> * One that let's us add Context.has( String key ), so that 
> "optional" entries 
> can be easily tested for by the component author. (I guess 
> "instanceof" would 
> work for casting)

That one I'd like to see, too.

> And that's why I'm not. And I'm particularly impressed by the 
> arguments 
> *against* context-casting in the next section... :)
> 
> >
> > THE PROPOSAL ITSELF (AS IT IS NOW)
> >
> > A context is defined by two sets of parameters. The first is an 
> > interface or a class, called T below. If an interface, it is an 
> > interface that the supplied context interface must be 
> cast-able to. If 
> > it is a class, it is expected that the class is 
> instantiated with the 
> > T(Map,Context) constructor, and that the instance is passed to the 
> > component's contextualize method.
> 
> This makes me feel a bit icky. It *feels* like implementation details 
> impacting on framework design.

Since the class T is provided by the client (the component), it makes
sense to specify creation parameters for it.

> > NOTE: In the case where T is an interface, the container 
> must supply 
> > an implementation for all methods in the interface. This 
> may be done 
> > via a dynamic proxy that routes calls to appropriate handlers or by 
> > any other method. The set of methods that a container must 
> support is 
> > defined by the standard context interfaces in Framework (currently 
> > none).
> 
> Doesn't this sound very complex, for the simple declaration 
> of "what I want in 
> my context"? To me, it looks like the sort of thing that we'd 
> look back on 
> and say "what on earth were we thinking?!?". 
> 
> Maybe I'm misunderstanding:
> You mean we let the Component author declare *any* interface 
> (combination of 
> different bits and pieces) as it's context requirements? So I need a 
> getHomeDirectory() and a getShutdownRequestHandler() method, 
> so I can just 
> invent an interface with those 2? And the Container, if it 
> wants to run my 
> component, has to somehow come up with an implementation that 
> can cast to 
> that interface? Surely not?

Exactly that. This sounds like a demand that the container should
be able to sprout new code on demand, but isn't. I can create a 
dynamic proxy, and I can then check all method signatures in your
required interface and see if I have a provider for that method.

The requirement put on the container here is very satisfiable,
and not a request for pure magic.

> So why should it be different for BlockContext? Putting aside 
> the fact that 
> that's how Phoenix works today. If that's the *only* argument 
> for it, then 
> let's be honest and say so; if most people then agree that 
> it's valid, then 
> fair enough.

That *is* the only argument. To accomodate current usage patterns
in Phoenix. I'm sorry if I didn't make that clear. The part about
proxies in the proposal is a way to show that this can be done
without inducing coupling between Phoenix and the container (i.e.
having to compile against Phoenix jars).

I also think that most people believe it is valid.
 
> Sorry to be difficult, but this is just my feelings on the 
> matter. Then again, 
> since no-one else seems to be objecting, maybe I'm the odd 
> one out here?

Well, my feeling is that most people do agree that there
are better and more scalable ways to treat a context (although
we don't agree on just what those ways are), but that the
current usage pattern in Phoenix must be accomodated.

It's a tradeoff.

(No disrespect to Phoenix users/devs. I think my views on the
 release() method in ServiceManager is known - I want it -
 and the reason is to accomodate the usage pattern in Cocoon,
 ECM and Fortress, even though that pattern has no support
 in Framework. Tradeoffs like this is just another thing to
 live with.)

/LS


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>