You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by bu...@apache.org on 2002/01/18 10:35:03 UTC
DO NOT REPLY [Bug 5916] -
[PATCH] JTidy warning management - not to System.out anymore
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5916>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5916
[PATCH] JTidy warning management - not to System.out anymore
------- Additional Comments From xml-cocoon@nicolaken.com 2002-01-18 01:35 -------
Created an attachment (id=1030)
HTMLGenerator patch for Jtidy proper warning logging
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Excalibur hasComponent bug/feature
Posted by Vadim Gritsenko <va...@verizon.net>.
> 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
Re: Excalibur hasComponent bug/feature
Posted by Berin Loritsch <bl...@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.
> 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.
2) If the existence of a Component is required (i.e. your Component cannot
do its job without the supporting Component), simply look it up. If
you get a ComponentException, propogate it because your component is
useless without the other one.
All lookups fall into one of those categories.
> PS Patch also contains fix for NPE in hasComponent()
?? Ok, I will look at it.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Excalibur hasComponent bug/feature
Posted by Vadim Gritsenko <va...@verizon.net>.
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.
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.
PS Patch also contains fix for NPE in hasComponent()
Regards,
Vadim