Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Content-Type: text/plain;
  charset="iso-8859-1"
From: Peter Donald <peter@realityforge.org>
To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Subject: Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date: Tue, 3 Dec 2002 21:52:22 +1100
User-Agent: KMail/1.4.2
References: <001401c29a47$0b4b6080$6401a8c0@LEIBNIZ>
 <200212032017.59793.adammurdoch@apache.org>
 <200212032145.08387.peter@realityforge.org>
In-Reply-To: <200212032145.08387.peter@realityforge.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200212032152.22852.peter@realityforge.org>

oops - sent when I meant to save as draft and finish later ... I clarify =
now=20
then.

On Tue, 3 Dec 2002 21:45, Peter Donald wrote:
> On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
> > Sure.  These are good examples of why everyone wins when there's a ni=
ce
> > match between what a resource means to a component, and how the resou=
rce
> > is delivered to the component.  If the component wants a logger, give=
 it
> > a logger.  If the component wants config, give it config.  etc.  Mayb=
e
> > the same resource is presented in different ways depending on how the
> > component asks for it.  Maybe not.  Component doesn't care.
> >
> > But the examples don't really answer the question:  Why is it useful,
> > when a component asks for a resource of a particular type, to disting=
uish
> > between resources of that type that are provided by the container, an=
d
> > resources of that type that are provided by other components?
>
> I don't really understand what you are getting at. If you are wanting t=
o
> unify the interface then this has already proposed - I actually created
> another service API recently that looked something like
>
> interface Composable
> {
>   void compose( Locator locator ) throws LocatorException;
> }
>
> interface Contextualizable
> {
>   void contextualizable( Locator locator ) throws LocatorException;
> }
>
> interface Locator
> {
>   Object lookup( String key ) throws LocatorException;
>   boolean exists( String key );
> }
>
> If thats what you mean then I think I agree. It resulted in cleaner cod=
e.
>
> If you mean merging Contextualizable and Composable then I disagree.

And I disagree because they are logically different resources.=20

Just like Logger or Configuration/Parameters or InstrumentationPoint reso=
urces=20
could be all added into a central directory and got in one sweep - we=20
separate out purely because of different usage patterns.=20

90% of generic component based apps will not use Contextualizable. Almost=
 100%=20
of typed/container-bound objects (ie Tasks, Mailets, Servlets, EJBs)=20
conceptually use Contextualizable.=20

Even in Servlets the service provision (JNDI) and interaction with contai=
ner=20
(ServletContext) are logically different access mechanisms and have diffe=
rent=20
usage patterns. ie I rarely use JNDI except when writing EJBs yet I use=20
ServletContext in every servlet app I write.

--=20
Cheers,

Peter Donald
------------------------------------
The two secrets to success:
   1- Don't tell anyone everything.
------------------------------------=20


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