Re: [JBoss-dev] org.jboss.logging.Logger

[Scott M Stark]

I'm not getting what your confusion is. We are not getting a 'static'
log4j Category, we are getting the log4j Category for name. If your
asking why we don't also keep a map of name to Logger instances
the reason is that Loggers are rarely created and I don't see the point
for yet another cache. If that is not what your asking show how you
would change Logger.

- Original Message - 
From: "Christian Riege" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 28, 2001 11:03 AM
Subject: Re: [JBoss-dev] org.jboss.logging.Logger


> Hi,
> 
> On Fri, 2001-12-28 at 18:52, Scott M Stark wrote:
> > Making this a singleton would require that all loggers
> > used the same category name and this is not what we want.
> 
> I'm still not getting it. In the constructor, we are getting a static
> log4j Category anyways for the given name:
> 
>   log = Category.getInstance(name);
> 
> I don't see how different loggers should be able to use different
> category names with a constructor like this. Wading through the code via
> 'grep getCategory' doesn't show any use of this either; could you give
> me a pointer on where this behaviour is actually used/implemented?
> 
> Best regards,
> Christian
> 
> 
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] org.jboss.logging.Logger

[Christian Riege]

Hi,

> On Fri, 2001-12-28 at 18:52, Scott M Stark wrote:
> > Making this a singleton would require that all loggers
> > used the same category name and this is not what we want.
> 
> I'm still not getting it. In the constructor, we are getting a static
> log4j Category anyways for the given name:
> 
> log = Category.getInstance(name);

replying to oneself makes you feel really stupid :).

OK, I get it, Category.getInstance(name) returns a NEW Category when a
Category for that name hasn't already been created. Forgot to read the
fineprint in the log4j API docs. Doh.

Regards,
Christian



msg15805/pgp0.pgp
Description: PGP signature

Re: [JBoss-dev] org.jboss.logging.Logger

[Christian Riege]

Hi,

On Fri, 2001-12-28 at 18:52, Scott M Stark wrote:
> Making this a singleton would require that all loggers
> used the same category name and this is not what we want.

I'm still not getting it. In the constructor, we are getting a static
log4j Category anyways for the given name:

  log = Category.getInstance(name);

I don't see how different loggers should be able to use different
category names with a constructor like this. Wading through the code via
'grep getCategory' doesn't show any use of this either; could you give
me a pointer on where this behaviour is actually used/implemented?

Best regards,
Christian



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] org.jboss.logging.Logger

[Scott M Stark]

Making this a singleton would require that all loggers
used the same category name and this is not what we want.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message - 
From: "Christian Riege" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 28, 2001 7:57 AM
Subject: [JBoss-dev] org.jboss.logging.Logger




___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] org.jboss.logging.Logger

[Christian Riege]

hi everybody,

I'm slightly confused about the org.jboss.logging.Logger class.

>From my point of view this should be implemented as a singleton; however
right now for every invocation of Logger.getLogger(...) it shells out a
*new* instance of itself:


   public static Logger getLogger(String name)
   {
  Logger logger = new Logger(name);
  return logger;
   }


Can anybody enlighten me on the reason behind this? It seems a bit
expensive to me with little added value ... of course I understand that
the underlying log4j Category object will be shared across all
instances, but still.

Best regards,
Christian



msg15798/pgp0.pgp
Description: PGP signature

Re: [JBoss-dev] org.jboss.logging.Logger priority usage recommendations

[Scott M Stark]

Its really just log4j stuff. All that we are doing is introducing a facade
over
the log4j Category to directly support the use of the custom trace priority
and hide all of the non-logging methods.

The first thing you need to decide is what is the category name your going
to use. This should be based on the class name of the component doing
the logging. If there are multiple instances of a component, and it is
associated with another meaningful name, this name will be
added as a subcategory to the component class name. For example,
the org.jboss.security.plugins.JaasSecurityManager class uses
a base category name equal to its class name. There can be
multiple JaasSecurityManager instances, and each is associated
with a security domain name. Therefore, the complete log4j
category name used by the JaasSecurityManager is
"org.jboss.security.plugins.JaasSecurityManager.securityDomain",
where the securityDomain value is the name of the associated
security domain.

To create a Logger for JaasSecurityManager this is the code snippet:

package org.jboss.security.plugins;

import org.jboss.logging.Logger;

public class JaasSecurityManager ...
{
Logger log;

public JaasSecurityManager (String securityDomain)
{
String name = JaasSecurityManager.class + '.' + securityDomain;
log = Logger.getLogger(name);
}
}

After that just use the log with whatever priority level is approriate.

Activating the TRACE level priority is done by adding a category threshold
statement to the log4j.properties file. To enable tracing for a particular
JaasSecurityManager security domain called other I would add:

log4j.category.org.jboss.security.plugins.JaasSecurityManager.other=TRACE#or
g.jboss.logging.log4j.TracePriority

To enable the TRACE level priority for all JaasSecurityManager instances I
would add:
log4j.category.org.jboss.security.plugins.JaasSecurityManager=TRACE#org.jbos
s.logging.log4j.TracePriority

To enable the TRACE level priority for all components in the security pkg:
log4j.category.org.jboss.security=TRACE#org.jboss.logging.log4j.TracePriorit
y

You can also redirect a given categories message to a seperate log file or
endpoint
by assiging it a different appender. For example, to redirect all security
output to
a security.log file, and set the security package threshold to TRACE use:

### The security.log file appender
log4j.appender.SecurityLog=org.apache.log4j.FileAppender
log4j.appender.SecurityLog.File=../log/security.log
log4j.appender.SecurityLog.layout=org.apache.log4j.PatternLayout
log4j.appender.SecurityLog.layout.ConversionPattern=[%c{1}] %m%n
log4j.appender.SecurityLog.Append=false
log4j.category.org.jboss.security=TRACE#org.jboss.logging.log4j.TracePriorit
y, SecurityLog

- Original Message -
From: "Dain Sundstrom" <[EMAIL PROTECTED]>
To: "'Scott M Stark'" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, November 15, 2001 3:34 PM
Subject: RE: [JBoss-dev] org.jboss.logging.Logger priority usage
recommendations


> Can you supply the quick 5 line example on properly creating loggers and
> logging a message.  I have been having trouble changing the log levels for
> cmp.  I tried and failed to turn only the CMP channel up to DEFAULT for
the
> console appender for my testing, so I end up turning up the entire console
> appender to DEFAULT. Do we have docs on this somewhere (not that you need
to
> write some, just wondering)?
>
> -dain
>



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] org.jboss.logging.Logger priority usage recommendations

[Dain Sundstrom]

Can you supply the quick 5 line example on properly creating loggers and
logging a message.  I have been having trouble changing the log levels for
cmp.  I tried and failed to turn only the CMP channel up to DEFAULT for the
console appender for my testing, so I end up turning up the entire console
appender to DEFAULT. Do we have docs on this somewhere (not that you need to
write some, just wondering)?

-dain 

> -Original Message-
> From: Scott M Stark [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 15, 2001 4:10 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] org.jboss.logging.Logger priority usage
> recommendations
> 
> 
> There was a copy and paste user error in the ERROR description. It
> should read:
> 
> ERROR, use the ERROR level priority for events that indicate
> a disruption in a request or the ability to service a request.
> A service should have some capacity to continue to service
> requests in the presence of ERRORs.
> 
> - Original Message -
> From: "Scott M Stark" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, November 15, 2001 1:59 PM
> Subject: [JBoss-dev] org.jboss.logging.Logger priority usage 
> recommendations
> 
> 
> > These are the log4j priority usage recommendations that I intend on
> > introducing into Main next week. Reply with any critque or 
> questions.
> >
> > TRACE, use TRACE the level priority for log messages that 
> are directly
> > associated with activity that corresponds requests. Further, such
> > messages should not be submitted to a Logger unless the 
> Logger category
> > priority threshold indicates that the message will be 
> rendered. Use the
> > Logger.isTraceEnabled() method to determine if the category priority
> > threshold is enabled. The point of the TRACE priority is to 
> allow for
> > deep probing of the JBoss server behavior when necessary. When the
> > TRACE level priority is enabled, you can expect the number 
> of messages
> > in the JBoss server log to grow at least a x N, where N is 
> the number of
> > requests received by the server, a some constant. The server log may
> > well grow as power of N depending on the request-handling 
> layer being
> > traced.
> >
> > DEBUG, use the DEBUG level priority for log messages that 
> convey extra
> > information regarding life-cycle events. Developer or in 
> depth information
> > required for support is the basis for this priority. The 
> important point
> > is that when the DEBUG level priority is enabled, the JBoss 
> server log
> > should not grow proportionally with the number of server requests.
> > Looking at the DEBUG and INFO messages for a given service category
> > should tell you exactly what state the service is in, as 
> well as what
> > server resources it is using: ports, interfaces, log files, etc.
> >
> > INFO, use the INFO level priority for service life-cycle 
> events and other
> > crucial related information. Looking at the INFO messages 
> for a given
> > service category should tell you exactly what state the 
> service is in.
> >
> > WARN, use the WARN level priority for events that may indicate a
> > non-critical service error. Resumable errors, or minor 
> breaches in request
> > expectations fall into this category. The distinction 
> between WARN and
> > ERROR may be hard to discern and so its up to the developer 
> to judge.
> > The simplest criterion is would this failure result in a 
> user support
> > call. If it would use ERROR. If it would not use WARN.
> >
> > ERROR, use the ERROR level priority for events that indicate
> > non-critical errors that do represent a disruption in a 
> request or the
> > ability to service a request. A service should have some capacity to
> > continue to service requests in the presence of ERRORs.
> >
> > FATAL, use the FATAL level priority for events that 
> indicate a critical
> > service failure. If a service issues a FATAL error it is completely
> > unable to service requests of any kind.
> >
> > 
> > Scott Stark
> > Chief Technology Officer
> > JBoss Group, LLC
> > 
> >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> 
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] org.jboss.logging.Logger priority usage recommendations

[Scott M Stark]

There was a copy and paste user error in the ERROR description. It
should read:

ERROR, use the ERROR level priority for events that indicate
a disruption in a request or the ability to service a request.
A service should have some capacity to continue to service
requests in the presence of ERRORs.

- Original Message -
From: "Scott M Stark" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 15, 2001 1:59 PM
Subject: [JBoss-dev] org.jboss.logging.Logger priority usage recommendations


> These are the log4j priority usage recommendations that I intend on
> introducing into Main next week. Reply with any critque or questions.
>
> TRACE, use TRACE the level priority for log messages that are directly
> associated with activity that corresponds requests. Further, such
> messages should not be submitted to a Logger unless the Logger category
> priority threshold indicates that the message will be rendered. Use the
> Logger.isTraceEnabled() method to determine if the category priority
> threshold is enabled. The point of the TRACE priority is to allow for
> deep probing of the JBoss server behavior when necessary. When the
> TRACE level priority is enabled, you can expect the number of messages
> in the JBoss server log to grow at least a x N, where N is the number of
> requests received by the server, a some constant. The server log may
> well grow as power of N depending on the request-handling layer being
> traced.
>
> DEBUG, use the DEBUG level priority for log messages that convey extra
> information regarding life-cycle events. Developer or in depth information
> required for support is the basis for this priority. The important point
> is that when the DEBUG level priority is enabled, the JBoss server log
> should not grow proportionally with the number of server requests.
> Looking at the DEBUG and INFO messages for a given service category
> should tell you exactly what state the service is in, as well as what
> server resources it is using: ports, interfaces, log files, etc.
>
> INFO, use the INFO level priority for service life-cycle events and other
> crucial related information. Looking at the INFO messages for a given
> service category should tell you exactly what state the service is in.
>
> WARN, use the WARN level priority for events that may indicate a
> non-critical service error. Resumable errors, or minor breaches in request
> expectations fall into this category. The distinction between WARN and
> ERROR may be hard to discern and so its up to the developer to judge.
> The simplest criterion is would this failure result in a user support
> call. If it would use ERROR. If it would not use WARN.
>
> ERROR, use the ERROR level priority for events that indicate
> non-critical errors that do represent a disruption in a request or the
> ability to service a request. A service should have some capacity to
> continue to service requests in the presence of ERRORs.
>
> FATAL, use the FATAL level priority for events that indicate a critical
> service failure. If a service issues a FATAL error it is completely
> unable to service requests of any kind.
>
> 
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
> 
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] org.jboss.logging.Logger priority usage recommendations

[Scott M Stark]

These are the log4j priority usage recommendations that I intend on
introducing into Main next week. Reply with any critque or questions.

TRACE, use TRACE the level priority for log messages that are directly
associated with activity that corresponds requests. Further, such
messages should not be submitted to a Logger unless the Logger category
priority threshold indicates that the message will be rendered. Use the
Logger.isTraceEnabled() method to determine if the category priority
threshold is enabled. The point of the TRACE priority is to allow for
deep probing of the JBoss server behavior when necessary. When the
TRACE level priority is enabled, you can expect the number of messages
in the JBoss server log to grow at least a x N, where N is the number of
requests received by the server, a some constant. The server log may
well grow as power of N depending on the request-handling layer being
traced.

DEBUG, use the DEBUG level priority for log messages that convey extra
information regarding life-cycle events. Developer or in depth information
required for support is the basis for this priority. The important point
is that when the DEBUG level priority is enabled, the JBoss server log
should not grow proportionally with the number of server requests.
Looking at the DEBUG and INFO messages for a given service category
should tell you exactly what state the service is in, as well as what
server resources it is using: ports, interfaces, log files, etc.

INFO, use the INFO level priority for service life-cycle events and other
crucial related information. Looking at the INFO messages for a given
service category should tell you exactly what state the service is in.

WARN, use the WARN level priority for events that may indicate a
non-critical service error. Resumable errors, or minor breaches in request
expectations fall into this category. The distinction between WARN and
ERROR may be hard to discern and so its up to the developer to judge.
The simplest criterion is would this failure result in a user support
call. If it would use ERROR. If it would not use WARN.

ERROR, use the ERROR level priority for events that indicate
non-critical errors that do represent a disruption in a request or the
ability to service a request. A service should have some capacity to
continue to service requests in the presence of ERRORs.

FATAL, use the FATAL level priority for events that indicate a critical
service failure. If a service issues a FATAL error it is completely
unable to service requests of any kind.


Scott Stark
Chief Technology Officer
JBoss Group, LLC




___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development