Return-Path: Delivered-To: apmail-jakarta-cactus-user-archive@apache.org Received: (qmail 2988 invoked from network); 18 Feb 2002 19:58:34 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 18 Feb 2002 19:58:34 -0000 Received: (qmail 13335 invoked by uid 97); 18 Feb 2002 19:58:37 -0000 Delivered-To: qmlist-jakarta-archive-cactus-user@jakarta.apache.org Received: (qmail 13307 invoked by uid 97); 18 Feb 2002 19:58:37 -0000 Mailing-List: contact cactus-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Cactus Users List" Reply-To: "Cactus Users List" Delivered-To: mailing list cactus-user@jakarta.apache.org Received: (qmail 13296 invoked from network); 18 Feb 2002 19:58:36 -0000 Message-ID: From: "Robertson, Jason" To: 'Cactus Users List' Subject: RE: Log Hijacking Date: Mon, 18 Feb 2002 14:49:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hmmm, interesting "feature" ya got there! What concerned me the most, at first, was that after creating my test case things weren't working and I went to the jboss log to see how far my EJB had gotten - and none of my debug statements were there! After a bit, I found them in the cactus log, but that certainly wasn't the first place I looked. Your arguments all make sense, but I would think if the container already initialized things that cactus should just piggy pack onto that log. I'll look into it to see if there's anything I can find that would do that, but it's not a pressing priority since I did finally find my EJB's debug statements. :) Jason -----Original Message----- From: Vincent Massol [mailto:vmassol@octo.com] Sent: Saturday, February 16, 2002 5:01 AM To: 'Cactus Users List' Subject: RE: Log Hijacking Hi Jason, This is the way it is meant to be :-) (it's called a feature ;-)). Log Hijacking is the perfect way to describe it ! Ideally, Cactus logs would be completely independent of applications logs (and application server ones). However, this is not possible with Log4J 1.1.x. It is possible with Log4J 1.2 (with the notion of Repository). However, everyone is still using version 1.1 and version 1.2 is not out yet, thus Cactus cannot move to version 1.2 yet and probably for a while. That said, I tried to find the best approach. Here are some ideas so that you understand better my line of thoughts : 1/ Let's imagine that the code to test is already logging data using Log4J. Cactus is about unit testing methods. Thus, it will usually bypass any code that is used by the application to initialize its own logging system and hit directly the method to test. Thus, if Cactus does not initialize Log4J itself, nothing would be logged. 2/ Cactus logs are only interesting to debug Cactus and thus are not of interest most of the time. However, Cactus still need to initialize Log4J because of point 1/ above. Also, by default the logging level for Cactus is set to WARN, thus there should be no Cactus log in the Cactus log files. 3/ When you execute your application in test mode with Cactus, Cactus takes control and becomes the new container if you prefer (so to speak). Thus it is can be logical that it redirects all logs to its log files ... What about the case where log4J is initialized by the container engine ? This happens before Cactus initializes Log4J itself. However, Cactus re-initializes Log4J and thus any appender/category that would have been previously defined are ignored. This is potentially an area we could improve by telling log4J to append and not replace. I don't know of an easy to do it but it might exist. Feel free to submit a patch if you wish ! WRT to your problem, the solution if you want several log files is to add the different appenders and categories to log_server.properties I have no clue WRT the name of the file issue. I don't remember of any default name. Thanks -Vincent > -----Original Message----- > From: Robertson, Jason [mailto:Jason.Robertson@acs-inc.com] > Sent: 15 February 2002 22:55 > To: 'cactus-user@jakarta.apache.org' > Subject: Log Hijacking > > I'm running Cactus in JBoss, and as soon as I run a Cactus test case, all > logging goes into cactus_server.log. And I mean ALL logging: Cactus, my > tests, and JBoss. JBoss' server.log is never written to again. > > This may be a log4j issue, or a lack of understanding of log4j on my part, > but it sure doesn't seem right! And since it happens only after running a > Cactus test case, I'm asking here first. :) > > Adding to my confusion, I removed the cactus appender completely from my > log_server.properties file and I tell Cactus and my tests to use the JBoss > appenders, which are presumably already defined. This doesn't have any > affect, and even more interesting is that the line defining the name of > the > file is not there, but the file is still used. Is there a default > somewhere > or something? > > I've rebuilt from scratch, removed JBoss' temp deploy directory, > redeployed > several times and it make no difference. Any ideas? > > Jason > > -- > To unsubscribe, e-mail: unsubscribe@jakarta.apache.org> > For additional commands, e-mail: help@jakarta.apache.org> -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: