RE: Questions on initial log4j instance
Agree -- private static final Logger is what I recommend. Modifiers are static then final, not vice versa. JLS section 8.3.1 defines the production FieldModifier: one of public protected private static final transient volatile and states, If two or more (distinct) field modifiers appear in a field declaration, it is customary, though not required, that they appear in the order consistent with that shown above in the production for FieldModifier. WRT to serialization, declaring a field both static and transient is redundant as static fields are not serialized by definition. Jim -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2003 7:55 AM To: Log4J Users List Subject: RE: Questions on initial log4j instance Howdy, Where did you see the transient one? The perfect syntax depends on your usage of the Logger. The most common one I think, as well as the one most frequently illustrated in the log4j documentation, is private final static (which should be private static final according to JLS recommendations ;)) Yoav Shapira Millennium ChemInformatics -Original Message- From: Yu Xiang Xi (Maveo) [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2003 4:58 AM To: 'Log4J Users List' Subject: Questions on initial log4j instance I have seen different usage of initial log4j instance like below private final static Logger logger = Logger.getLogger(some.name); and private final transient static Logger logger = Logger.getLogger(some.name); the second one has a additional keyword transient. Which way is recommended? Thanks in advance. Best Regards Xi Yuxiang Maveo Systems Limited - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log4J and EJBs
Hi, Jonathan. The EJB Spec (section 23.1.2 in the EJB 2.0 Spec) states that the intent of the specification is to describe the programming restrictions that a Bean Provider must follow to ensure that the enterprise bean is portable and can be deployed in any compliant EJB 2.0 Container. Thus, primarily portability -- not functional or operational concerns -- would seem to be at the heart of these restrictions. Restrictions which extend to the dependent classes used by an entity bean with CMP. The specific restriction on java.io is An enterprise bean must not use the java.io package to attempt to access files and directories in the file system. The important bit for designers is the why: The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC, to store data. File system characteristics vary widely between deployment environments and so effect the portability of a dependent application. File systems are not transactional so data stored to a file system cannot carry transactional guarantees. But are logs data? I mean, in the same way that user registration information is data? Or that your product catalog is data? Or that orders sent to a back-end fulfillment system are data? If you think yes, then definitely avoid using files for logs. If you think no, and portability is not an outstanding concern, then why not? Also consider, albeit poor practice, how much working EJB code you've seen that uses System.out and/or System.err. Clearly, these are (and must be) java.io.PrintStream instances. Furthermore, all implementations I've seen of PrintStream are internally synchronized to prevent output from multiple callers becoming commingled. IBM's WebSphere Best Practices document even cites this synchronization and the resultant performance decrease) as a reason for avoiding the use of System.out. However, their balanced view is to Avoid indiscriminate System.out.println statements. Since I've already touched on it, let's also consider thread synchronization which is used in the log4j Appenders. The EBJ Spec restriction is: An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances. This rule is required to ensure consistent runtime semantics because while some EJB Containers may use a single JVM to execute all enterprise bean's instances, others may distribute the instances across multiple JVMs. Synchronization would not work if the EJB Container distributed enterprise bean's instances across multiple JVMs. So thread synchronization isn't inherently a bad thing. The reason has to do with sequencing the activities of bean instances across multiple JVMs. But that isn't what we are doing here. We want to limit the access to a particular shared resource within a single JVM. That resource is not transactional so it presents no deadlock issues. In this case, as in the case with java.io.PrintStream (aka System.out), there may be performance or scalability issues to consider (like there aren't with JDBC or JMS?) but not functional issues -- and I mean the application fails to function correctly when moved to a new environment. Certainly, adhering to the spirit of the restrictions set out in the EJB specification is beneficial and a recommended practice. However, intelligent application of each restriction requires understanding the intent behind it and the possible impact of violating it. Best regards, Jim Cakalic -Original Message- From: Jonathan Whitall [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 9:05 AM To: [EMAIL PROTECTED] Subject: Log4J and EJBs Hello, This is more of a generic third-party logging question as opposed to a Log4J question, but I thought some of you might know the answer. The EJB specification says that an EJB should not perform file I/O. I was wondering why this is the case, and if using a third-party logging package (such as Log4J) constitutes a violation of this nature if it is set up to use a FileAppender. Thanks for your input, Jonathan __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in
RE: log4j presentation slides
You might have a look here: http://www.ociweb.com/javasig/knowledgebase/January2001/Log4J.ppt and one on java.logging and Lumberjack is here: http://www.ociweb.com/javasig/knowledgebase/2001Dec/Lumberjack.pdf HTH Jim Cakalic -Original Message- From: Lu, David [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 1:33 PM To: 'Log4J Users List' Subject: log4j presentation slides Hi, Can anyone point me to some informative slide presentations on log4j? Thanks in advance! DAvid ** This message, including any attachments, contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please contact sender immediately by reply e-mail and destroy all copies. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. TIAA-CREF ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: log4j and WSAD 5.0 anomalies and problems
Of course, that code is only executed if the default Logger initialization from a
properties file is not performed. Apparently, your log4j.properties file is not being
found.
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 11, 2003 10:16 AM
To: Log4J Users List
Subject: Re: log4j and WSAD 5.0 anomalies and problems
The culprit is the following code from
org.apache.commons.logging.impl.Log4JCategoryLog
private void initialize() {
Category root=Category.getRoot();
Enumeration appenders=root.getAllAppenders();
if( appenders==null || ! appenders.hasMoreElements() ) {
// No config, set some defaults ( consistent with
// commons-logging patterns ).
ConsoleAppender app=new ConsoleAppender(new PatternLayout( LAYOUT ),
ConsoleAppender.SYSTEM_ERR
);
app.setName(commons-logging);
root.addAppender( app );
root.setPriority( Priority.INFO );
}
initialized=true;
}
As you can see it sets the level (a.k.a. priority) of root logger (a.k.a. category) to
INFO.
This problem has been reported as bug #13201 to commons-logging.
You may want to comment/vote on this bug at
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201
At 10:58 11.02.2003 -0500, you wrote:
This is totally weird..
Check out the following test code:
try {
if (log.isDebugEnabled()) {
log.debug(About to log something
+log.isDebugEnabled());
}
}catch(IllegalStateException e) {
log.error(Something bad has happened: + e);
}
log.info(Just Testing a log message with priority set to DEBUG
=+log.isDebugEnabled());
log.info(Just testing a log message with priority set to INFO = +
log.isInfoEnabled());
log.warn(Just testing a log message with priority set to WARN =
+ log.isWarnEnabled());
log.error(Just testing a log message with priority set to ERROR =
+ log.isErrorEnabled());
log.fatal(Just testing a log message with priority set to FATAL =
+ log.isFatalEnabled());
And here is what the console tells me:
2/11/03 10:51:10:235 EST] 7ffa7525 SubsegListAct I
com.ibm.lansys.actions.SubsegListAction Just Testing a log message with priority
set to DEBUG =false
[2/11/03 10:51:10:235 EST] 7ffa7525 SubsegListAct I
com.ibm.lansys.actions.SubsegListAction Just testing a log message with priority
set to INFO = true
[2/11/03 10:51:10:235 EST] 7ffa7525 SubsegListAct W
com.ibm.lansys.actions.SubsegListAction Just testing a log message with priority
set to WARN = true
[2/11/03 10:51:10:245 EST] 7ffa7525 SubsegListAct E
com.ibm.lansys.actions.SubsegListAction Just testing a log message with priority
set to ERROR = true
[2/11/03 10:51:10:255 EST] 7ffa7525 SubsegListAct F
com.ibm.lansys.actions.SubsegListAction Just testing a log message with priority
set to FATAL = true
So , now I know that my DEBUG is NOT enabledbut I do not know
why. It appears to me that log4j isnt even
being called anywhere..simply because 1) i tried changing
ConversionPattern and so no changes on the console and 2) nothing is still being
written to file.
Please, help, this is making me crazy!
Thanks, Lydia
Lydia P wrote:
Has anyone successfully got log4j running under the Websphere Studio
Application Developer v 5.0?
I had to migrate my WSAD 4.03 application to WSAD 5.0, which has a
totally different tree structure, but WSAD 5.0
is supposed to recognize and retain WSAD 4.03 structures.
I am not seeing log4j initialize in the console, yet, I see the class
loggers append to the consolethe weird
thing is that I have them in the properties file logging to files - yet no files
are being created.
Maybe I dont fully understand how WSAD works with commons-logging and
log4j? I didnt think I had
to use a log4j initializing servlet which is mentioned in web.xml to make it work
- theoretically, my class
files should never have to change when I change logging tools?
Here is my setup:
I have commons-logging.jar and log4j-1.2.7.jar under the WEB-INF/lib
directory.
My commons-logging.properties file in the /WEB-INF/classes directory :
# commons logging config - use Log4J
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JCategoryLog
My log4j.properties file in the /WEB-INF/classes directory :
# log4j configuration file
# DEBUG, INFO, WARN, ERROR and FATAL
# Create three appenders, one called listout, one called stdout and
another called R
log4j.logger.com.com.ibm.lansys.actions=DEBUG, listout, stdout, R
log4j.logger.org.apache=DEBUG, listout ,stdout, R
# Create root (default) appender -default DEBUG and higher msgs go to the console
log4j.rootCategory=DEBUG, stdout
RE: Catching uncaught exceptions
Use Jim Moore's LoggingOutputStream. You'll find it in his log4j contrib directory in the release. The javadoc describes how to use it to redirect System.out and System.err. Best regards, Jim Cakalic -Original Message- From: Thomas Saxtoft [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 4:17 AM To: [EMAIL PROTECTED] Subject: Catching uncaught exceptions This is really two problems, but since it is concerned with logging I give you both. We have created a Java client, and now we wish to log all uncaught exceptions. As it is now exceptions thrown in threads and other uncaught exceptions are written to standard error out I believe. I think that I could redirect all exceptions to another output, but here is the second problem. I would like to write all these exceptions to a logger. So my two problems are: 1. How do I catch all uncaught exceptions? 2. And how do I write them to a logger? Thank you, Thomas Saxtoft -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] font size=1Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: %P and %H addition to PatternLayout
Hostname yes. Can't get pid without using native code. -Original Message- From: [EMAIL PROTECTED] [mailto:Daniel.Hannum;smed.com] Sent: Friday, November 08, 2002 10:04 AM To: Log4J Users List Subject: Re: %P and %H addition to PatternLayout I'd love for this to be addressed. I don't want this message to be quietly ignored, so... bump. These are required in my work. If we don't do this, then I'll have to hack it up myself. However, I believe Java doesn't provide a means to get a pid. I'm not sure if this is true, but it would throw a wrench in this. Does anyone know if these can be done? Or if the developers want this to be done? Cuz a patch is trivial if Java provides the functions. dan Mike Schilli [EMAIL PROTECTED] on 11/07/2002 09:34:43 PM Please respond to Log4J Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: %P and %H addition to PatternLayout Hi folks, the Log4perl group has been receiving requests on adding %P (current process id) and %H (hostname) to the PatternLayout format descriptors. These seem to be features many people want in their log files, for tracking which process wrote the message and on which host it happened if logging is centralized. What do you guys think, would you want to add them to log4j? -- -- Mike Mike Schilli [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:log4j-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:log4j-user-help;jakarta.apache.org --- This message and any included attachments are from Siemens Medical Solutions Health Services Corporation and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you -- To unsubscribe, e-mail: mailto:log4j-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:log4j-user-help;jakarta.apache.org font size=1Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you. -- To unsubscribe, e-mail: mailto:log4j-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:log4j-user-help;jakarta.apache.org
RE: ConsoleAppender and System.{out,err}.println
Every implementation of PrintStream (the class of System.out) that I have ever
reviewed synchronized on itself (the object) around the actual I/O. So all the public
print, println, and flush methods are synchronized. Whenever one of these methods is
called, the output will be written uninterrupted by another call.
Any problem would be when multiple PrintStream calls are used to write the detail for
a single event seeing as each call would be independent (synchronization-wise) of
every other call. ConsoleAppender relies on its WriterAppender superclass
implemetation of append which ultimately makes one write call with the result of the
layout format and then, if the layout ignoresThrowable, gets a String[] representing
the Throwable and writes each String with a separate write call followed by a separate
write of the LINE_SEPARATOR. So, depending on your layout, there could be quite a
variance of opportunity for a non-log4j writer to jump in.
An Appender introduces another level of synchronization so that multiple Loggers using
the same Appender cannot collide. So, if it is possible, the suggestion to use
LoggingOutputStream to replace the PrintStream represented by System.out (see the
javadoc) is probably a good way to minimize the collision between ConsoleAppender and
System.out users.
Of course, ultimately, you'll want to replace all the System.out calls :-)
Best regards,
Jim Cakalic
-Original Message-
From: Ceki Gülcü [mailto:ceki;qos.ch]
Sent: Tuesday, October 22, 2002 3:16 PM
To: Log4J Users List
Subject: Re: ConsoleAppender and System.{out,err}.println
AFAIK, System.out.println is synchronized.
At 16:19 22.10.2002 -0300, Daniel Serodio wrote:
I'm maintaining a Java app with tons of System.out.println's all around,
and I'm using log4j in my (new) code.
If I setup log4j to use a ConsoleAppender, will log4j's and println's
output be intermixed in a predictible way? I mean, will each log message
be logged until EOL at least?
Does anyone have any suggestions for using System.out.println and log4j
together in the same app?
Thanks in advance
--
[]'s
Daniel Serodio
--
Ceki
TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793
--
To unsubscribe, e-mail: mailto:log4j-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:log4j-user-help;jakarta.apache.org
font size=1Confidentiality Warning: This e-mail contains information intended
only for the use of the individual or entity named above. If the reader of this
e-mail is not the intended recipient or the employee or agent responsible for
delivering it to the intended recipient, any dissemination, publication or copying of
this e-mail is strictly prohibited. The sender does not accept any responsibility for
any loss, disruption or damage to your data or computer system that may occur while
using data contained in, or transmitted with, this e-mail. If you have received this
e-mail in error, please immediately notify us by return e-mail. Thank you.
--
To unsubscribe, e-mail: mailto:log4j-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:log4j-user-help;jakarta.apache.org
RE: Log4J design question: this.getClass() in super class
I've been the lead on several large projects now which have used log4j.
On each project there have been between 8 and 15 developers. The current
project has over 1200 Java classes. (I don't have stats for the previous
but they were equivalent in size.) The guidelines I give new developers
state that the declaration for a Logger should be:
private static final Logger _log =
Logger.getLogger(currentClass.class);
This seems to have worked just fine. You'll notice that because of the
private declaration there is no concern about subclasses sharing a
Logger instance and so preventing discrimination of which class is doing
the logging. Likewise, keeping it static means it can be used from
either a class or instance context. And declaring it final prevents it
from being reassigned elsewhere in the code.
As far as preventing sloppy Logger naming, I don't see how there is
much you can do about that but code review. You can't keep someone from
coding to a public API; you have to actively discourage it and then
reinforce by feedback. Maybe I've just been fortunate, but I've only had
a couple instances where something like that was being done. After I
took time to explain to the developer the recommended Logger naming
scheme and the benefits thereof, we fixed the code and it never happened
with that developer again.
In this case, communication, simplicity, and courage seem to have
worked.
:-)
Best regards,
Jim Cakalic
-Original Message-
From: Scott Doherty [mailto:sdoherty;kc.rr.com]
Sent: Wednesday, October 23, 2002 12:58 AM
To: [EMAIL PROTECTED]
Subject: Log4J design question: this.getClass() in super class
Design question about using Log4J in an application's framework.
I wish to leverage Log4j in applications being built at my company. I've
been reading quite a bit and watching this list for awhile now. I would
like your input into architecture and design using Log4j.
Logger log = Logger.getLog(myClass.class);
Logger log = Logger.getLog(this.getClass());
I'm debating the above choice for logger naming. It is sometimes common
that applications built in my company inherit from an Abstract class for
that application.
For example, if I am writing a Banking Application for my company, an
abstract class called BankingSkeleton might be used. Most of the objects
in this application would inherit from BankingSkeleton. BankingSkeleton
would provide behavior common to all objects in this application.
Public abstract class BankingSkeleton extends Object
{
}
Public abstract class Account extends BankingSkeleton
{
}
public class CheckingAccount extends Account
{
}
In the reading material about Log4j, it appears that the standard
approach to provide hierarchical based logging in each of these classes
would be to create a static attribute in each class using the class name
as the category's name.
package com.company.banking;
abstract class BankingSkeleton extends Object
{
}
class Account extends BankingSkeleton
{
static Logger log = Logger.getLog(Account.class);
}
class CheckingAccount extends Account
{
static Logger log = Logger.getLog(CheckingAccount.class);
}
If I were to log a message from a method in each of these classes, it
would look something like this if displaying the logger in the appender
using %c in the PatternLayout:
631 [main] DEBUG com.company.banking.Account - A message
1071 [main] DEBUG com.company.banking.CheckingAccount - A message
This is great with the exception of a few things. Many of our projects
are completed by a team of developers with varying experience. Each
developer needs to remember to place the log attribute in their class
instead of inheriting log from its super class. Each developer needs to
properly provide the logger name to honor the hierarchy of the logger
naming, for example, CheckingAccount.class instead of Account.class
when getting the log. When writing this email, I myself copied the log
attribute from the Account class to the CheckingAccount class and at
first, simply forgot to update the logger name in the Logger.getLog
method. If a developer of a class simply doesn't write any logging and
never creates the log attribute for that class, I can foresee production
support developers who need to get something logged to troubleshoot a
problem might sloppily add code inside a method that obtains a logger
something like the following:
class sloppyAccount extends BankingSkeleton
{
public void aSloppyMethod()
{
Logger.getLog(IDunno).debug(A message);
}
}
Notice that the logger, IDunno, is no longer in the hierarchy and
becomes less manageable via the Log4j configuration properties.
1452 [main] DEBUG IDunno - A message
I would like the BankingSkeleton to provide the log attribute to all of
its sub-classes, eliminating the need for each class developer to
concern themselves with getting the correct logger.
package
RE: JMSAppender in Container Managed Transactions
As you say, the problem is on the producer side. I think the real question has to do with whether the JMS drivers are XA-enabled and obtained through a container-defined resource manager. If so, the container is going to try to coordinate any transaction in progress across the JDBC and JMS resources. Usually, that is what you want. In this case, you want the logging to happen regardless of the transaction outcome. Fundamentally, the JMSAppender needs to obtain its JMS resources from a source other than the container so that the container is not aware of them and doesn't enlist them in the transaction. Jim -Original Message- From: Benary Klaus [mailto:[EMAIL PROTECTED]] Sent: Friday, September 06, 2002 8:16 AM To: '[EMAIL PROTECTED]' Subject: AW: JMSAppender in Container Managed Transactions Hi Steven, hi Ceki, There is a listener bean durably subscribed to the topic. The crucial part of the deployment descriptor is: message-driven display-name/display-name ejb-nameListenerBean/ejb-name ejb-classcom.jcoffee.base.sl.ListenerBean/ejb-class transaction-typeContainer/transaction-type acknowledge-modeAuto-acknowledge/acknowledge-mode message-driven-destination destination-typejavax.jms.Topic/destination-type subscription-durabilityDurable/subscription-durability /message-driven-destination resource-ref res-ref-namejdbc/DS/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref /message-driven But, I think that the consumer cannot be the reason for this behavior. The producer side would behave the same way even if there was no consumer subscribed at all. Besides: It is BEA 7.00 and WebLogic JMS according to JavaSoft JMS specification version 1.0.2. Klaus -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED]@GEHE Gesendet: Freitag, 6. September 2002 14:49 An: [EMAIL PROTECTED] Betreff: RE: JMSAppender in Container Managed Transactions JMSAppender opens its session to the JMS server in AUTO_ACKNOWLEDGE, non-transacted mode. Basically, this means the message should be delivered no matter what. So the JMSAppender is already set up to operate outside of currently running transactions. How are you processing the messages from the topic? MessageDrivenBean MessageListener implementation? What is the set up of this consumption piece? |-Original Message- |From: Benary Klaus [mailto:[EMAIL PROTECTED]] |Sent: Friday, September 06, 2002 7:21 AM |To: '[EMAIL PROTECTED]' |Subject: JMSAppender in Container Managed Transactions | | |How can I decouple logging via JMSAppender from the |contrainer transaction |in a stateless session EJB? |I want the JMSAppender to deliver logs even when I call |SessionContext.setRollbackOnly(). As a default, |JMS committs a message to the queue or topic only when the |contrainer |transaction committs. As a side |effect, a log within a failing contrainer transaction |shows up only in those |appenders that do not use JMS. |Am I missing something? |Any help would be appreciated. | |Klaus | | |-- |To unsubscribe, e-mail: |mailto:[EMAIL PROTECTED] |For additional commands, e-mail: |mailto:[EMAIL PROTECTED] | -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] font size=1Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JMSAppender in Container Managed Transactions
And this was my point, on which you vehemently contradicted me. The question was about
PRODUCING messages, not about CONSUMING them. And the producing was to be done in the
context of a container-managed transaction. In that scenario, local JMS Session
transactions cannot be used. The JMS Specification says quite clearly:
JTS or some other transaction monitor facility may be used to combine a
session's transaction with transactions on other resources (databases, other JMS
sessions, etc.). Since Java distributed transactions are controlled via the JTA
transaction demarcation API, use of the session's commit and rollback methods
in this context throws a JMS TransactionInProgressException.
That precludes use of JMS transacted Sessions when the Connection creating the Session
is participating in a JTA transaction.
The devil is in the configuration of the administered JMS resources (Destination and
ConnectionFactory). If they are configured to participate in container-managed JTA
transactions, then they will. (See
http://edocs.bea.com/wls/docs70/adminguide/jms.html#jms_connection_factories_config).
I stand by my original comments. You need to configure your way to a point that the
JMS work is considered outside the scope of any container-managed transaction. I've
done this with JDBC by getting Connections from a pool that was not managed by the
application server (WebSphere in this case). I don't know that a similar strategy
would work with the JMSAppender since the Topic and TopicConnectionFactory are
retrieved via JNDI lookup. I suppose another way of approaching this might be to have
another stateless session bean with log methods duplicating the log4j signatures with
a transaction attribute of RequiresNew? Then, when you used this new LogSessionBean
from another EJB, the container would put all its work in a separate transaction from
the one in progress.
Jim
-Original Message-
From: Ebersole, Steven [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 06, 2002 10:04 AM
To: 'Log4J Users List'
Subject: RE: JMSAppender in Container Managed Transactions
I am sure that it works for me. ;0)
Yes, I have session beans which are marked to let WebLogic manage its
transactions as Required. If something should go wrong in one of them, I
send a log message with the underlying exception, throw a custom exception,
and set the transaction for rollback only and that log message shows up in
the JMS queue and is processed by the MDB and is placed into the appropriate
log file.
I don't know what elese to tell you. I did have a lot of problems getting
this set up just right in WebLogic. In my case it was never a problem with
log4j or the JMSAppender, but more the WebLogic JMS implementation.
|-Original Message-
|From: Benary Klaus [mailto:[EMAIL PROTECTED]]
|Sent: Friday, September 06, 2002 9:24 AM
|To: '[EMAIL PROTECTED]'
|Subject: AW: JMSAppender in Container Managed Transactions
|
|
|I worry about one thing: As long as I do not roll back the
|contrainer
|transactions my listener MBD works really fine. But when I
|roll it back the
|onMessage() method of my MDB is not even touched. So, placing the
|acknowledgement whithin the method cannot be the clou.
|Are you really sure that (in a stateless session bean with
|trans-attribute=Required) you can do things like:
| try {
| something transactional
| } catch (Exception e) {
|someLogger.info(foo);
|ctx.setRollbackOnly();
| }
|
|If this works with WLS 6.1 it seems to me that BEA has
|garbled something on
|their way to 7.00.
|Anyway, I will try to get closer to your configuration
|(e.g. trying a queue
|instead of a topic).
|
|Thanks for your help
|Klaus
font size=1Confidentiality Warning: This e-mail contains information intended
only for the use of the individual or entity named above. If the reader of this
e-mail is not the intended recipient or the employee or agent responsible for
delivering it to the intended recipient, any dissemination, publication or copying of
this e-mail is strictly prohibited. The sender does not accept any responsibility for
any loss, disruption or damage to your data or computer system that may occur while
using data contained in, or transmitted with, this e-mail. If you have received this
e-mail in error, please immediately notify us by return e-mail. Thank you.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Performance between Log4j and custom in-house logger
Perhaps one telling comment is My logger does formattingwriting to log
file in a background thread. My question is, do your measurements
account for all background processing having been completed? If not,
this may explain why log4j performance appears to degrade in comparison
with mylogger as logging load increases -- assuming that I am reading
your results correctly.
Jim
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 03, 2002 9:40 AM
To: Log4J Users List
Subject: RE: Performance between Log4j and custom in-house logger
Hi,
There are always going to be difference between any two systems designed
to do the same thing. Your system was obviously designed for your
needs, and probably not much more. Log4j is designed to be generic,
useful to a very broad range of people / applications, easily
extensible, and yet fast.
At my organization, we carefully compared five or six in-house custom
logging systems and a couple of 3rd party ones. We included very
detailed performance comparisons and profilings. We found log4j to be
as fast or faster than nearly all the other implementation, while
providing the best range of features. As we need a lot of its features
(JDBC logging, SMTP logging, runtime configurability, JMS logging, daily
rolling, appender thresholds, object renderers, etc), we picked log4j,
and have been very very happy since.
So it's a question of what you need from your logging system. If your
system did everything you need, you probably wouldn't even be
considering log4j, right? ;) Maybe it';; easier to add just the
features you need to your own system, instead of migrating to log4j
completely?
The point is, if you want to help tune log4j you're welcome to. It's
open source and contributors are always welcome, right Ceki? ;)
However, having used log4j in numerous apps from very small to very
large, we've never had any complaints about its performance. There was
always a lot of tuning to be done on our own apps before logging
performance showed up as a blip on the profiler screen...
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: sk k [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 03, 2002 10:30 AM
To: [EMAIL PROTECTED]
Subject: Performance between Log4j and custom in-house logger
Hi,
We are planning to move from a custom in house logging
framework (MyLogger) to using Log4j and have been
doing some performance comparison between log4j and
MyLogger.
The numbers seem to be favoring mylogger over log4j.
Sample Numbers
==
Note: Timing includes logj startup time, mylogger
startup time and junitperf startup time.
1) Logging 2 strings, each of size: 128bytes
Request MyLogger(sec) Log4j(sec)
== === =
1001.221.29
1000 1.671.71
2000 2.122.01
2) Logging 4 strings, each of size: 128bytes
Request MyLogger(sec) Log4j(sec)
== === =
1001.211.25
1000 1.653 1.82
2000 2.242.56
3) Logging 8 strings, each of size: 128bytes
Request MyLogger(sec) Log4j(sec)
== === =
1001.351.35
4001.561.71
9001.8 2.35
4) Logging 80 strings, each of size: 128bytes
Request MyLogger(sec) Log4j(sec)
== === =
1001.251 1.7
1000 1.816.1
2000 2.1511.2
Sample code and configuration
===
log4j.properties
==
log4j.rootCategory=DEBUG,dest1
log4j.appender.dest1=org.apache.log4j.RollingFileAppender
log4j.appender.dest1.layout=org.apache.log4j.SimpleLayout
log4j.appender.dest1.File=c:/skk/cps/logger/test/test1.log
log4j.appender.dest1.MaxFileSize=4MB
log4j.appender.dest1.MaxBackupIndex=60
log4j.category.ut.log.Log4jPerfTest=DEBUG,dest2
log4j.additivity.Log4jPerfTest=false
log4j.appender.dest2=org.apache.log4j.RollingFileAppender
log4j.appender.dest1.layout=org.apache.log4j.TTCCLayout
log4j.appender.dest2.File=c:/skk/cps/logger/test/test.log
log4j.appender.dest2.MaxFileSize=4MB
log4j.appender.dest2.MaxBackupIndex=60
Test Logger code
===
Note: logMsgs is an array with strings of size 128
bytes.
public void test_Log4j() throws Exception {
int size = logMsgs.size();
for( int i=0; isize; i++ ) {
log4jLogger.info( (String)logMsgs.get(i)
);
}
}
Some of my questions
1) Is there anything that I can do to increase the
performance of log4j on my box( Pentium-3, 800Mhz,
512MB RAM)
2) I see some architectural difference between the way
mylogger and log4j is implemented namely
My logger does formattingwriting to log file in a
background thread whereas it seems that log4j doesn't
seem do the same. Is this true.
My logger uses the concept of observer and
observable.
Thanks.
__
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
--
To unsubscribe, e-mail: mailto:log4j-user-
[EMAIL
RE: Using Log4J in EJB server
Also consider, albeit poor practice, how much working EJB code you've seen that uses System.out and/or System.err. Clearly, these are (and must be) java.io.PrintStream instances. Furthermore, all implementations I've seen of PrintStream are internally synchronized to prevent output from multiple callers becoming commingled. IBM's WebSphere Best Practices document even cites this synchronization (and the resultant performance decrease) as a reason for avoiding the use of System.out. However, their balanced (italics mine :-) view is to Avoid indiscriminate System.out.println statements. The EJB spec section (23.1.2 in the EJB 2.0 Spec) states that the intent of the specification is to describe the programming restrictions that a Bean Provider must follow to ensure that the enterprise bean is portable and can be deployed in any compliant EJB 2.0 Container. Thus, primarily portability -- not functional or operational concerns -- would seem to be at the heart of these restrictions. Restrictions which extend to the dependent classes used by an entity bean with CMP. The specific restriction on java.io is An enterprise bean must not use the java.io package to attempt to access files and directories in the file system. The important bit for designers is the why: The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC, to store data. File system characteristics vary widely between deployment environments and so effect the portability of a dependent application. File systems are not transactional so data stored to a file system cannot carry transactional guarantees. But are logs data? I mean, in the same way that user registration information is data? Or that your product catalog is data? Or that orders sent to a back-end fulfillment system are data? If you think yes, then definitely avoid using files for logs. If you think no, and portability is not an outstanding concern, then why not? Consider again thread synchronization. The restriction is: An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances. This rule is required to ensure consistent runtime semantics because while some EJB Containers may use a single JVM to execute all enterprise bean's instances, others may distribute the instances across multiple JVMs. Synchronization would not work if the EJB Container distributed enterprise bean's instances across multiple JVMs. So thread synchronization isn't inherently a bad thing. The reason has to do with sequencing the activities of bean instances across multiple JVMs. But that isn't what we are doing here. We want to limit the access to a particular shared resource within a single JVM. That resource is not transactional so it presents no deadlock issues. In this case, as in the case with java.io.PrintStream (aka System.out), there may be performance or scalability issues to consider (like there aren't with JDBC or JMS?) but not functional issues -- and I mean the application fails to function correctly when moved to a new environment. Certainly, adhering to the spirit of the restrictions set out in the EJB specification is beneficial and a recommended practice. However, intelligent application of each restriction requires understanding the intent behind it and the possible impact of violating it. Best regards, Jim Cakalic -Original Message- From: Steve Ebersole [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 7:50 PM To: Log4J Users List Subject: Re: Using Log4J in EJB server Not to bemuse this point, but that is just not a complete truth (as is true for most generalizations). I'll give you two prime examples (though there are others) where not only is the use of classes from the java.io package used extensively in J2EE environments, but in fact validated directly by Sun in its tutorials and J2EE patterns: 1) A combination of java.io.StringWriter and java.io.PrintWriter as a means of maintaining stack trace information in inter-tier Exception classes 2) A combination of java.io.ByteArrayOutputStream/java.io.ObjectOutputStream and java.io.ByteArrayInputStream/java.io.ObjectInputStream as a quick way to perform deep copies of server objects for serialization. And lets not even get into java.io.Serializable/Externalizable Is it a good idea to perform direct file IO from within a J2EE app at all? Generally no. However, the reason is usually not for the first one you mentioned; rather the fact that you would need to know something of the file-system layout in order to perform direct file IO is usually the greatest concern. Although for me the new JMX implmentation for log4j would help alleviate that issue. And yes of course file IO has the potential to be a bottle neck (and you think database access won't). And FYI, the same holds true for thread synchronization. I use TopLink
RE: Performance of log4j
As you yourself noted, a major problem with the compile-time elimination of logging (debug or other) is that it then becomes impossible to enable same at run time. You don't really appreciate that ability until you've had to use it -- even once -- to diagnose a production problem. Another problem with compile-time eliminiation of logging is the possibility that correct behavior of the code is dependent on a side-effect of some part of the logging code. This is very bad style, of course, and no one would ever recommend doing it. But it happens nevertheless. If your test organization uses a development compilation then their tests might run just fine. The defect would only manifest itself in the production build where logging code was optimized away. My recommendation would be to reduce logging overhead for debug and info levels (the most likely levels to be disabled) using the enabled methods referred to in a previous message on this thread. The majority of overhead to logging when a level is disabled has to do with parameter construction which can be quite costly as in the case that several Strings are being concatenated to obtain the final message content. Checking whether the level is enabled eliminates this costly parameter value setup. Best regards, Jim Cakalic -Original Message- From: Edward Q. Bridges [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 8:57 AM To: Log4J Users List Subject: RE: Performance of log4j instead of using the method isDebugEnabled() at every occurence of a debugging statement, we have a final static boolean variable DEBUG_ENABLED in a base class which is initialized (once) by a call to logger.isDebugEnabled(). the advantages of this are twofold: first, you're not doing a method invocation for every debug statement in order to test whether or not debugging is enabled. second, when we release the code in production, we can assign a literal false value to the code and recompile. this renders all debugging statements unreachable and compiles them out of the code altogether. of course, this would prevent switching to debugging level at runtime to get detailed info on the system without recompiling. a similar arrangement can be done with isInfoEnabled(). HTH --e-- On Thu, 18 Apr 2002 09:10:44 -0400, Shapira, Yoav wrote: meaningful stuff and not logging too much. Definitely use logger.isDebugEnabled() for debug messages, as that could be a nearly -- Edward Q. Bridges http://www.teachscape.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: survey: Is the FATAL priority level useful?
OK. The link to it is IMO somewhat hard to find so I just wanted to make sure that you hadn't missed it. Jim -Original Message- From: Trent Mick [mailto:[EMAIL PROTECTED]] Sent: Monday, February 18, 2002 5:02 PM To: Log4J Users List Subject: Re: survey: Is the FATAL priority level useful? On Mon, Feb 18, 2002 at 05:08:15PM -0500, Cakalic, James wrote: Were you aware of the log4py project on sourceforge? http://sourceforge.net/projects/log4py/ Jim, Yes, I have looked briefly at log4py. Log4py is a little limited for what I would like to see in the Python core. It is a minimal port of log4j, eschewing the concept of subclassable Appenders and Filters, etc. I want the full meal deal. :) c.f. http://python.sourceforge.net/peps/pep-0282.html Thanks, Trent -- Trent Mick [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] font size=1Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
RE: survey: Is the FATAL priority level useful?
Were you aware of the log4py project on sourceforge?
http://sourceforge.net/projects/log4py/
Jim
-Original Message-
From: Trent Mick [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 18, 2002 3:52 PM
To: [EMAIL PROTECTED]
Subject: survey: Is the FATAL priority level useful?
Hello,
I am currently specing out a core logging module for the
Python language
which borrows from log4j. I would like to know if, in
practice, people have
found the FATAL priority level of use in a language with
exception handling
support.
The way I see it (not having the benefit of experience) the
ERROR level is
useful for identifying errors in user input before
terminating processing (or
stumbling along afterward). A FATAL problem is typically just
an uncaught
exception -- and if the exception is uncaught there really seems no
appropriate to actually *log* the problem.
The only appropriate senario that I see is having one exception catch
block around my entire application which will log a FATAL
error for any
unexpected exception.
public class MyApp {
static Logger logger = Logger.getLogger(MyApp.class);
public static void main(String[] args) {
try {
return dostuff();
} catch (Throwable t) {
logger.fatal(Something really bad happened.);
}
}
}
Are there other usage scenarios for which people have found
FATAL to be
handy.
Thanks,
Trent
--
Trent Mick
[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
font size=1Confidentiality Warning: This e-mail contains information intended
only for the use of the individual or entity named above. If the reader of this
e-mail is not the intended recipient or the employee or agent responsible for
delivering it to the intended recipient, any dissemination, publication or copying of
this e-mail is strictly prohibited. The sender does not accept any responsibility for
any loss, disruption or damage to your data or computer system that may occur while
using data contained in, or transmitted with, this e-mail. If you have received this
e-mail in error, please immediately notify us by return e-mail. Thank you.
RE: Log4C
Title: RE: Log4C Haven't looked at it yet. How similar is it, do you think, to the C++ version at http://sourceforge.net/projects/log4cpp/? -Original Message- From: (ti) Mark Mendel [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 25, 2001 4:12 PM To: [EMAIL PROTECTED] Subject: Log4C I just started a Sourceforge project for a C version. It includes an initial, feature-poor but working version. https://sourceforge.net/projects/log4c/ Tell your friends and neighbors! Add your favorite feature! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log4J in JSP??
Hmm. I
try to avoid 'method repositories' where possible. I also try to put as little
Java code in a JSP as possible. That way, I find that I don't often have much of
interest to log from a JSP. Anyway, here are a couple
suggestions.
First,
why not have a look at the Jakarta Log Tag Library. It may be just what you
need.
http://jakarta.apache.org/taglibs/doc/log-doc/log.html
If you
want to develop your own class, you might consider designing a JavaBean that you
could instantiate with page scope using the JSP useBean tag and use bean set
tags to set its properties -- like the name for the Category. Your bean would
have logging methods that duplicate those of Category. Itcould retrieve
the Category instance based on its name property and delegate calls to the
Category object.
Best
regards,
Jim
Cakalic
-Original Message-From: Seemantini Godbole
[mailto:[EMAIL PROTECTED]]Sent: Monday, July 23, 2001
10:27 AMTo: 'LOG4J Users Mailing List'Subject: RE: Log4J
in JSP??
Sumit,
You
may want to design a class with all static methods which will do logging to
log4j. It could have a method such as
public static void doInfoLog(String catName, String
message)
{
Category cat =
Category.getInstance(catName);
//log the message to this category
}
You
could use this class and method in your JSP.
Thanks,
seemantini
-Original Message-From: Sumit Mishra
[mailto:[EMAIL PROTECTED]]Sent: Monday, July 23, 2001
10:09 AMTo: '[EMAIL PROTECTED]'Subject:
Log4J in JSP??
Hi
guys,
This is my
first message to this list..
I just
wanted to figure out whether I could use log4j in JSPs for logging
purpose?
I have
already used log4j in Java class and
EJBs.
Thanx in
anticipation
Sumit Mishra
Everyone makes mistakes. The trick is to
make them when nobody is
looking.
DISCLAIMER: The information contained in this
message may be privileged and confidential and protected from disclosure. If
the reader of this message is not the intended recipient, or an employee or
agent responsible for delivering this message to the intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to the
message and deleting it from your computer.
Thank you.
CashTech
Solutions.
RE: Category.assert() disappointing
Title: RE: Category.assert() disappointing Of course, JUnit is a unit testing framework, not a logging framework. :-o -Original Message- From: Benjamin Russell Stocum [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 1:43 PM To: LOG4J Users Mailing List Subject: Re: Category.assert() disappointing Has anyone looked at JUnit? This is where you want to get all your asserts from :) Duplication is not necessary if its already done, and done right at that I might add. -Ben Stocum
RE: how can install tomcat as a service in Win 2000
Title: RE: how can install tomcat as a service in Win 2000 Not really a log4j question, but in the true community spirit ... Have a look at the Jakarta NT Service page http://jakarta.apache.org/tomcat/tomcat-3.2-doc/NT-Service-howto.html and also the Alexandria Software JavaService tool which is referenced there http://www.alexandriasc.com/software/JavaService/index.html Between what is provided with Tomcat (usable on JDK 1.2) and the Alexandria JavaService (open source NT service Java invoker for JDK 1.3), you should be set. I haven't used these to run Tomcat, but I have used JavaService to run other Java applications as services. Running a Java application that is an IBM WebSphere EJB client is no simple task. Try running it as an NT/2000 service! JavaService performed wonderfully. (No personal connection to the company. Just a satisfied and grateful user.) Best regards, Jim Cakalic -Original Message- From: sancho george [mailto:[EMAIL PROTECTED]] Sent: Friday, June 15, 2001 5:04 AM To: [EMAIL PROTECTED] Subject: how can install tomcat as a service in Win 2000 i have tomcat3.2.1 . i have to run the server in the background . please help __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: help with Wrapping/Buffering
Title: RE: help with Wrapping/Buffering Hi, Ross. Have a look at the source for org.apache.log4j.spi.LocationInfo. Best regards, Jim Cakalic -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 10, 2001 5:19 AM To: [EMAIL PROTECTED] Subject: help with Wrapping/Buffering Hi there, I've just started using log4j (and am still a newbie to java itself).I am using a wrapper class around log4j, and part of what my wrapper does is to buffer log items, only sending them to log4j when certain events occur. Clearly by doing this, I lose log4j's ability to automatically retrieve methods, line numbers etc. from the caller. It seems like what I have to do is to retrieve this information before I add an individual log to the buffer, then send it as part of the message string to log4j. Obviously I would lose some flexibility in the PatternLayout function, but this is not crucial. I understand that log4j somehow gets this information from a stack trace, but I am unsure of exactly how this works, or how I would go about getting the information for myself. Thanks in advance for any help, Ross Ovland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Formatting NT Event log
Title: RE: Formatting NT Event log The NTEventLogAppender could probably use some work, seeing as it doesn't currently support options. The only way, then, to set the event source is by virtue of one of the alternate constructors which permits specifying the source. The constructor will register the source. The category and event cannot currently be set. Adding the ability to set them could be problematic as there message resources must be delivered in a DLL and properly specified in the NT registry. Best regards, Jim Cakalic -Original Message- From: Srinivasa Chinimilli (Rapidigm) [mailto:[EMAIL PROTECTED]] Sent: Monday, March 26, 2001 4:16 PM To: 'LOG4J Users Mailing List' Subject: RE: Formatting NT Event log Even I was looking for that. I posted about the same query couple of weeks back, but I didn't get any response. Please let us know if anyone know how to modify them. thanks, srinivas -Original Message- From: Anderson, Bob [mailto:[EMAIL PROTECTED]] Sent: Monday, March 26, 2001 11:39 AM To: [EMAIL PROTECTED] Subject: Formatting NT Event log When using LOG4J for sending messages to an NT event log I would like to set the Source, Event ID, Category. Has anyone got this to work. If so can you show an example. Thanks, - Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
