logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Puiu <stefan.p...@axetel.com>
Subject Re: log4j, JBoss, EJBs
Date Tue, 16 Sep 2003 08:01:05 GMT
Hello Mark and once again thanks for your help,

now that you've posted the link to your code I think I have a complete 
solution to my problem, I'll get coding and let you know if something 
goes wrong.

Once again, thanks.

Mark.Priest@ngc.com wrote:

>Stefan,
>
>The only logger created in that file is org.eupki.ca.  I think you will need <categoryFactory
class="yourcategoryfactoryclass"/> in your XML config file.  If you use a RepositorySelector
that returns a LoggerRepository impl that always uses your factory then you should avoid the
classloading problems since everything would be loaded by the JBoss classloader.  However,
I think you also need to use <category name="org.eupki.ca" class="yourcategoryfactoryclass">
because there is a bug in the DOMConfigurator that causes the factory you specify to not actually
get used to create the loggers in that file.   I forgot that I actually posted some code in
http://marc.theaimsgroup.com/?l=log4j-user&m=106340752929541&w=2.
>
>Good luck,
>Mark
>
>-----Original Message-----
>From: Stefan Puiu [mailto:stefan.puiu@axetel.com]
>Sent: Monday, September 15, 2003 12:16 PM
>To: Log4J Users List
>Subject: Re: log4j, JBoss, EJBs
>
>
>All static loggers are created in the code, not in the configuration 
>file, as far as I know, I've included a log4j.xml sample configuration 
>file; it's written by someone else from our team. Thanks for your 
>suggestions, I will look into LoggerFactories in the following days.
>
>I'm pretty sure it's logger-related, replacing OurLogger with Logger 
>makes the Exceptions go away. I narrowed it down to class loading 
>because the only problem that can occur with the logging class is the 
>issue I've described (the second call to OurLogger.getLogger returns an 
>object that the JVM can't cast to the new type because it thinks the two 
>types are different). At least that's what I understood from the 
>ClassCastException problem reported in the "troubleshooting log4j" page. 
>I don't know why the confusing "class not found" exception pops up, 
>could be a JUnitEJB issue (I'm using JUnitEJB for running tests in the 
>server JVM).
>
>Mark.Priest@ngc.com wrote:
>
>  
>
>>Stefan,
>>
>>Log4j caches instances of loggers that have already been created (as indicated in
the link you provided).  Are you creating the loggers you are accessing in your configuration
file or are they being created for the first time when you execute OurLogger.getLogger(XXX.class.getName())?
 If you are specifically creating loggers (or categories) in the config file then that is
the same as the problem described in your link.  If you need to do this you can try the work-around
I recommended in  http://marc.theaimsgroup.com/?l=log4j-user&m=106312777504479&w=2.
 There is nothing special about an EJB environment. As long as you set the RepositorySelector
in the static block of the LoggerFactory it will get executed as soon as log4j is initialized.
 Note that you must pass the system property "log4j.categoryFactory" for this to happen (or
set the CategoryFactory tag if you are using the DOMConfigurator).
>>
>>How do you know that the reason the cast fails is due to a classloader issue?  That
seems unlikely.  Why don't you print out logger.getClass().getName() and logger.getClass().getClassLoader()
to be sure.
>>
>>It is fine to put log4j jars in the classpath of JBoss.   In fact you will need to
also put your custom logger class, LoggerFactory class and RepositorySelector impl, in there
if you choose to use the workaround above.
>>
>>Good luck,
>>Mark
>>
>>
>>-----Original Message-----
>>From: Stefan Puiu [mailto:stefan.puiu@axetel.com]
>>Sent: Monday, September 15, 2003 11:21 AM
>>To: Log4J Users List
>>Subject: Re: log4j, JBoss, EJBs
>>
>>
>>Hello and thank you for the quick reply,
>>
>>Sorry, I've forgotten to attach my stack trace, here it is now. The 
>>error message is quite confusing and probably doesn't indicate the 
>>source of the problem (the class which allegedly isn't found exists in 
>>the ear file of the application).  Yes, JBoss uses log4j and the Logger 
>>class is in the classpath, how can that be overriden? One solution would 
>>have been the Repository Selector solution, but I've only found examples 
>>for setting those in servlet container environments, how about EJB 
>>environments?
>>
>>At each redeploy the classes don't change, but as far as I understand 
>>the following occurs: at the first deployment, when doing something like 
>>this:
>>
>>static OurLogger logger =  (OurLogger) 
>>OurLogger.getLogger(XXX.class.getName());
>>
>>Then, when redeploying, the problem described at 
>>http://jakarta.apache.org/log4j/docs/TROUBLESHOOT.html#cce happens, the 
>>new OurLogger class in the redeployed package is considered to be a 
>>different class by the JBoss class loader and casting to it fails. We 
>>don't include the log4j classes in our jars, considering the fact that 
>>the log4j jar is 300 Kb large.
>>
>>Mark.Priest@ngc.com wrote:
>>
>> 
>>
>>    
>>
>>>Stefan,
>>>
>>>I cannot seem to find your stack trace so I am not sure exactly what the nature
of your problem is.  I suspect that you have your version of the Logger class in the system
classpath of the JBoss app server.  That would require you to restart JBoss.  If your log
classes are deployed with your application you should not need to restart JBoss.  Does JBoss
use log4j?  Also, are you changing the implementation of your logging class on these restarts?
>>>
>>>-Mark
>>>
>>>-----Original Message-----
>>>From: Stefan Puiu [mailto:stefan.puiu@axetel.com]
>>>Sent: Monday, September 15, 2003 10:47 AM
>>>To: log4j-user@jakarta.apache.org
>>>Subject: log4j, JBoss, EJBs
>>>
>>>
>>>Hello list,
>>>
>>>our company is working on a project involving JBoss 3.2.1 and using 
>>>log4j for logging. Please don't send me to the JBoss lists, I've asked 
>>>this on JBoss-user and nobody has replied since...
>>>
>>>We have a class that inherits from the log4j Logger class and adds 
>>>functionality useful for our project (other levels of logging besides 
>>>INFO, TRACE, DEBUG, for example), and it causes us some problems. At 
>>>first it was ClassCastExceptions when redeploying the application which, 
>>>as far as I can understand now, after reading some docs, where caused by 
>>>class loader issues (the old Logger wrapper class was undeployed, but 
>>>the static loggers for the classes were still present when redeploying), 
>>>now when I try to redeploy and run tests that use our custom logger 
>>>JUnit reports that it can't find the test file... I've included an 
>>>example stack trace from the JUnit output.
>>>
>>>Anyway, I've seen the documentation available on repository selectors 
>>>and the code to use a JNDI RS in a web application, my question is how 
>>>could something similar be achieved for EJBs? Restarting JBoss every 
>>>time we redeploy our application is tiresome, we only have Mandrake 9.0 
>>>and 9.1 boxes here and starting JBoss 3.2.1 takes about 1 minute.
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>>>
>>>
>>>   
>>>
>>>      
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>> 
>>
>>    
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org


Mime
View raw message