Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Vadim Gritsenko" <vadim.gritsenko@verizon.net>
To: <cocoon-dev@xml.apache.org>
Subject: RE: Excalibur hasComponent bug/feature
Date: Fri, 18 Jan 2002 14:58:41 -0500
Message-ID: <029801c1a05a$872208e0$90a4558b@vgritsenkopc>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-reply-to: <3C48727F.2020000@apache.org>
Importance: Normal

> From: Berin Loritsch [mailto:bloritsch@apache.org]
> 
> Vadim Gritsenko wrote:
> 
> > Hi to Avalon guys on this list,
> >
> > I guess I found a bug (thanks to Mark Butler) in an
> > ExcaliburComponentManager. Manager has a feature to have different
> > results for hasComponent and lookup methods: it could return false
even
> > if lookup returns component.
> 
> 
> I will take a look at the patch.
> 
> The issue behind this is that unless a Component has been defined in
> the configuration file, there is a good chance you don't want it.
This
> allows us to have entries in the roles file that will resolve to an
> implementation if we really need the component--but will be ignored
> if we don't want it, or it is optional.
> 
> Case and point would be the TraxTransformer and the DELI Component
> (BrowserCapabilities Component to be more precise).  Not everyone
want's
> to use the DELI component in their systems (I currently don't have a
> direct need yet--but will later).  In the mean time, if we simply ask
> the ECM (ExcaliburComponentManager) if the component exists we won't
> ever load the Component implicitly.  This is a good thing.  It makes
> DELI truly optional.  However, if the DELI component had an entry in
> the configuration file, we explicitly state we want this component
> in our systems.
> 
> If a Component merely looks up another Component from the ECM without
> checking if it exists yet, the ECM will attempt to devine the
> implementation from the RoleManager.  It assumes that the Component
> is *required* for operation.

This is clear. The problem is that I have a situation (current Cocoon in
CVS), that:
1. Component is declared in xconf
2. Component is initialized according to the System.out (chage
deliCocoonConfig.xml to print debug)
3. hasComponent returns false!


> > If this is a bug, patch is attached. If this is a feature (reading
the
> > comment on this method suggests that it could be so), then we have
some
> > amount of bugs in Cocoon code.
> 
> 
> And these are probably points of artificial requiring other
Components.
> 
> The general rule of thumb is this:
> 
> 1) If the existence of a Component is optional (i.e. your Component
can
>     get along without it--but will have more features if it exists),
>     use the hasComponent() method first.  If it returns false, don't
>     look it up.

But it is there, up and running, and hasComponent returns false :(


> > PS Patch also contains fix for NPE in hasComponent()
> 
> ?? Ok, I will look at it.

Role == null - check is present in lookup, but not in hasComponent


Vadim


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