Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
From: Niclas Hedhman <niclas@hedhman.org>
Message-ID: <2322.211.24.132.30.1058161187.squirrel@www.hedhman.org>
Date: Mon, 14 Jul 2003 13:39:47 +0800 (MYT)
Subject: Re: [RT] The Ominous Context
To: <dev@avalon.apache.org>
In-Reply-To: <3F123017.5040405@apache.org>
References: <3F0C696B.7060207@apache.org>
        <1214.211.24.132.30.1057808624.squirrel@www.hedhman.org>
        <3F0D51EF.7050901@apache.org>
        <1942.211.24.132.30.1058153667.squirrel@www.hedhman.org>
        <3F123017.5040405@apache.org>
Importance: Normal
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


> Only if your context entry has a null construcor.  How are you going to
> diferrentiate between the establishment of a service and the creation of
>  a File instance? If context were removed, we would be forced to declare
>  factories for any "non-component" and that's not an attractive
> proposition.

Well, from the User Components point of view, it is completely irrelevant
of "How" the entry ended up in the ServiceManager's lookup, the container
could very well have a set of hardcoded entries, just like the hardcoded
entries in the Context today. But then I don't get the dependency checks I
am after. I probably would like to see that the entries being exposed for
dependency resoloution at assembly.

By moving the Context entries to the ServiceManager, then if a particular
container didn't expose a required value, one could adopt a it to support
the missing entries that components are looking for, by assembly
declarations.

Niclas


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