> -----Original Message----- > From: Robertson, Jason [mailto:[EMAIL PROTECTED]] > Sent: 18 February 2002 19:50 > To: 'Cactus Users List' > Subject: RE: Log Hijacking > > 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,
I agree. Feel free to submit a patch when you do :-) > but > it's not a pressing priority since I did finally find my EJB's debug > statements. :) > Thanks for your feedback, -Vincent > Jason > > -----Original Message----- > From: Vincent Massol [mailto:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]] > > Sent: 15 February 2002 22:55 > > To: '[EMAIL PROTECTED]' > > 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: <mailto:cactus-user- > > [EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:cactus-user- > > [EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:cactus-user- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:cactus-user- > [EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
