You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2002/02/26 20:17:06 UTC
AbstractPool logging
All,
currently the AbstractPool implementation in Excalibur logs failure to
instantiate a component with a DEBUG level.
I propose to change this to ERROR.
The same change for:
- when an exception is caught decomissioning an object.
- "factory created class was null so a new instance could not be created."
Motivation being that all three cases involve an Exception being caught and
not re-thrown or wrapped. Thus, if the log level is not set to DEBUG, the
client will just recieve a ComponentException ("could not find component")
with no further explanation.
+1 from me.
/LS
The patch is:
@@ -95,9 +95,9 @@
}
catch (Exception e)
{
- if (getLogger().isDebugEnabled())
+ if (getLogger().isErrorEnabled())
{
- getLogger().debug("Error decommissioning object", e);
+ getLogger().error("Error decommissioning object", e);
}
}
}
@@ -127,17 +127,17 @@
}
catch( final Exception e )
{
- if( null != getLogger() && getLogger().isDebugEnabled() )
+ if( null != getLogger() && getLogger().isErrorEnabled() )
{
Class createdClass = m_factory.getCreatedClass();
if (createdClass == null)
{
- getLogger().debug( "factory created class was null
so a new "
+ getLogger().error( "factory created class was null
so a new "
+ "instance could not be created.", e );
}
else
{
- getLogger().debug( createdClass.getName() +
+ getLogger().error( createdClass.getName() +
": could not be instantiated.",
e );
}
}
@@ -158,9 +158,9 @@
}
catch( final Exception e )
{
- if( null != getLogger() &&
getLogger().isDebugEnabled() )
+ if( null != getLogger() &&
getLogger().isErrorEnabled() )
{
- getLogger().debug(
m_factory.getCreatedClass().getName() +
+ getLogger().error(
m_factory.getCreatedClass().getName() +
": improperly decommissioned.",
e );
}
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AbstractPool logging
Posted by Vincent Tencé <vt...@sympatico.ca>.
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Tuesday, February 26, 2002 3:27 PM
Subject: Re: AbstractPool logging
> You might want to check your system clock (it
> thinks we are still in 2000).
Oups thx :-)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AbstractPool logging
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Leo Sutic wrote:
> >
> > (The ResourceLimitingPool will allow an exception thrown by the
> > ComponentFactory to propagate upwards and be wrapped in a
> > ComponentException,
> > so logging works fine there.)
>
> That is probably the most correct thing to do.
Agree.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AbstractPool logging
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>Actually, the fact that it logs at DEBUG is fine. It is there to catch
>>any issues with the Pool code itself. Therefore you don't really want
>>it shoving out several hundreds of messages if you can help it.
>>
>
> The only problem being that any exception thrown in the component's
> initialize()
> method gets logged at DEBUG level.
>
> The behaviour is also dissimilar to ECM's handling of this:
> The ThreadSafeComponentHandler will initialize its singleton instance
> in its own initialize() method. Any exception in the instance's initialize()
> is logged by ECM with an ERROR priority.
>
> The DefaultComponentHandler will allow the Exception thrown from
> initialize() to propagate up where it will be rethrown by ECM, wrapped
> in a ComponentException.
>
> Or - since the PoolableComponentHandler uses the ResourceLimitingPool
> now, is this issue moot as the AbstractPool is deprecated?
>
> (The ResourceLimitingPool will allow an exception thrown by the
> ComponentFactory to propagate upwards and be wrapped in a
> ComponentException,
> so logging works fine there.)
That is probably the most correct thing to do.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Excalibur and the new Service interfaces
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Gary Shea [mailto:shea@gtsdesign.com]
>
> I followed a bit of the Resolvable/Service/etc. debate, and am wondering
> if the outcome has made its way into Excalibur code yet.
The outcome made its way into the org.apache.avalon.framework.service
package. That's all there is for now.
> Any advice/hints?
If you can get away with it, *don't* use the newest conventions.
If you stick with Component / ComponentManager you have the ECM and
its associated classes. There is nothing similar for ServiceManager.
My advice is this: Stick with Component/ComponentManager. Once we
get around to Avalon 5, porting the code should be simple.
Of course, if you absolutely need to get rid of Component, go for
the service package.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Excalibur and the new Service interfaces
Posted by Stephen McConnell <mc...@apache.org>.
Hi Garry:
See notes in-line.
> -----Original Message-----
> From: Gary Shea [mailto:shea@gtsdesign.com]
> Sent: Tuesday, 26 February, 2002 22:31
> To: Avalon Developers List
> Subject: Excalibur and the new Service interfaces
>
>
> I followed a bit of the Resolvable/Service/etc. debate, and am wondering
> if the outcome has made its way into Excalibur code yet. I'm thinking
> of using Excalibur in a project I'm working on, and would like to be
> using the newest conventions...
>
> Any advice/hints?
>
Excalibur packages that are "clean" and independent of the
Component/Service interface question (i.e. Component is not passed
as a method parameter) include the following:
collections
concurrent,
i18n
io
logger
monitor
naming
property
proxy
In addition, all of the XML package is clean except one class that
has a dependency on ComponentManager (but I would need to closer to
address "real" dependence level this implies).
The problematic Excalibur packages include:
excalibur.component <-- component here, component there,
component everywhere ...!
excalibur.pool <-- implies Component on pooled resource
but could be easily updated to be Component neutral
excalibur.datasource <-- due to pool dependencies
The real problem concerns the component package, not only due to
the Component parameter issue, but also, it is heavily biased
towards the pooled resource model - which in turn requires pooled
object to implement the Pooled interface (which complicates life
much in the same way that Component complicating things in framework).
While excalibur.pool can be easily updated, the excalibur.component
package makes the broad assumption that everything is a Component and
it is itself dependent on the pool package - so updating pool would
break the component package. A practical solution would be to add
an excalibur.service package together with a excalibur.snooker (a
alternative to pool) package.
So if your serious about non-Component components, the practical
advise is not to use the Excalibur pool or component packages and
focus on leveraging the framework.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Excalibur and the new Service interfaces
Posted by Gary Shea <sh...@gtsdesign.com>.
I followed a bit of the Resolvable/Service/etc. debate, and am wondering
if the outcome has made its way into Excalibur code yet. I'm thinking
of using Excalibur in a project I'm working on, and would like to be
using the newest conventions...
Any advice/hints?
Thanks,
Gary
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AbstractPool logging
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Actually, the fact that it logs at DEBUG is fine. It is there to catch
> any issues with the Pool code itself. Therefore you don't really want
> it shoving out several hundreds of messages if you can help it.
The only problem being that any exception thrown in the component's
initialize()
method gets logged at DEBUG level.
The behaviour is also dissimilar to ECM's handling of this:
The ThreadSafeComponentHandler will initialize its singleton instance
in its own initialize() method. Any exception in the instance's initialize()
is logged by ECM with an ERROR priority.
The DefaultComponentHandler will allow the Exception thrown from
initialize() to propagate up where it will be rethrown by ECM, wrapped
in a ComponentException.
Or - since the PoolableComponentHandler uses the ResourceLimitingPool
now, is this issue moot as the AbstractPool is deprecated?
(The ResourceLimitingPool will allow an exception thrown by the
ComponentFactory to propagate upwards and be wrapped in a
ComponentException,
so logging works fine there.)
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AbstractPool logging
Posted by Berin Loritsch <bl...@apache.org>.
Vincent Tencé wrote:
> Hi,
>
> We had that reflexion some weeks ago at work and we came to the conclusion
> that reusable components like pools should not use ERROR but rather WARNING
> log level. The motivation is that the definition of ERROR is specific to the
> application and we dont want to have third-party components logging at that
> level. In production, when we turn ERROR on to monitor what's going on on
> the system, we want to be able to be selective on what is logged so the log
> file remains readable and problems are easier to spot.
>
> What do you guys think?
I pretty much agree. You might want to check your system clock (it
thinks we are still in 2000).
Actually, the fact that it logs at DEBUG is fine. It is there to catch
any issues with the Pool code itself. Therefore you don't really want
it shoving out several hundreds of messages if you can help it.
>
> Vicnent
>
> ----- Original Message -----
> From: "Leo Sutic" <le...@inspireinfrastructure.com>
> To: "Avalon Developer's List" <av...@jakarta.apache.org>
> Sent: Tuesday, February 26, 2002 2:17 PM
> Subject: AbstractPool logging
>
>
>
>>All,
>>
>>currently the AbstractPool implementation in Excalibur logs failure to
>>instantiate a component with a DEBUG level.
>>
>>I propose to change this to ERROR.
>>
>>The same change for:
>>
>> - when an exception is caught decomissioning an object.
>> - "factory created class was null so a new instance could not be
>>
> created."
>
>>Motivation being that all three cases involve an Exception being caught
>>
> and
>
>>not re-thrown or wrapped. Thus, if the log level is not set to DEBUG, the
>>client will just recieve a ComponentException ("could not find component")
>>with no further explanation.
>>
>>+1 from me.
>>
>>/LS
>>
>>The patch is:
>>
>>@@ -95,9 +95,9 @@
>> }
>> catch (Exception e)
>> {
>>- if (getLogger().isDebugEnabled())
>>+ if (getLogger().isErrorEnabled())
>> {
>>- getLogger().debug("Error decommissioning object", e);
>>+ getLogger().error("Error decommissioning object", e);
>> }
>> }
>> }
>>@@ -127,17 +127,17 @@
>> }
>> catch( final Exception e )
>> {
>>- if( null != getLogger() && getLogger().isDebugEnabled() )
>>+ if( null != getLogger() && getLogger().isErrorEnabled() )
>> {
>> Class createdClass = m_factory.getCreatedClass();
>> if (createdClass == null)
>> {
>>- getLogger().debug( "factory created class was
>>
> null
>
>>so a new "
>>+ getLogger().error( "factory created class was
>>
> null
>
>>so a new "
>> + "instance could not be created.", e );
>> }
>> else
>> {
>>- getLogger().debug( createdClass.getName() +
>>+ getLogger().error( createdClass.getName() +
>> ": could not be
>>
> instantiated.",
>
>>e );
>> }
>> }
>>@@ -158,9 +158,9 @@
>> }
>> catch( final Exception e )
>> {
>>- if( null != getLogger() &&
>>getLogger().isDebugEnabled() )
>>+ if( null != getLogger() &&
>>getLogger().isErrorEnabled() )
>> {
>>- getLogger().debug(
>>m_factory.getCreatedClass().getName() +
>>+ getLogger().error(
>>m_factory.getCreatedClass().getName() +
>> ": improperly
>>
> decommissioned.",
>
>>e );
>> }
>> }
>>
>>
>>--
>>To unsubscribe, e-mail:
>>
> <ma...@jakarta.apache.org>
>
>>For additional commands, e-mail:
>>
> <ma...@jakarta.apache.org>
>
>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>