glassfish_at_javadesktop.org schrieb:
[...]
> The current project (originally developed on JBoss) I'm working on has
> the necessity to stick with Log4J (Political decision). To become a
> little bit more independent Apache Commons Logging shall be introduced
> within the new code and subsequently replace the plain Log4J code within
> the older modules.
If you still can choose this, I'd heavily plead for using slf4j rather than
commons-logging. I have seen a lot of, well, "interesting" issues after
doing right the same in my apps (introducing c-l to be capable of using
either log4j or JDK logging), and subsequently switched to slf4j which
drastically has eased this pain.
[...]
> Using this method it is necessary to restart the whole Glassfish server
> to detect changes within the Log4J configuration file (I assume Glassfish
> loads some Log4J classes on first usage and they simply remain in memory)
> even after the application is redeployed. Is there any way to reload the
> configuration at run time?
Hmmmm, I am not sure but the last time I dumped an application including
log4j to the glassfish, it seemed fine to me (undeploying the application
and deploying it again made log4j merrily load its new configuration
settings and start all over again). Used to introcude a JMX bean, these days
(we're using Spring in some of our web apps which eases exponing those) to
do log4j reconfiguration at runtime through JMX which worked rather well at
the very least for what I do there (mainly setting log levels for different
classes or packages on demand).
> The other thing is that using the "org.apache.log4j.ConsoleAppender"
> named STDOUT stops working after another application is deployed on the
> server (I deployed the "roller" web log app for testing purposes). After
> deploying the second app one can see the message "log4j:ERROR Attempted
> to append to closed appender named [STDOUT]." Does any one have a tip for
> that?
Well... can't say anything on that, honestly, as I so far never used the
STDOUT appender, we so far always used to dump logging to app specific log
files.
[...]
> Does someone here can explain that to me in more detail or point me to
> some documentation about it?
Well... being an enthusiastic glassfish user (actually, as a company we're
also glassfish technology partner, and I am then and now convinced that gfv2
and even more gfv3 are the very foundation to build a reliable server side
Java application upon), I also have seen (and, to some degreel suffered
from) the lack of options in terms of logging initially: Though log4j worked
pretty well in all of my use cases, I never managed to get log4j logging set
up right in a way to be able to read the log4j application specific log
files using the glassfish web administration console. Even more than that,
using log4j I never managed to be capable of setting application specific
log levels, as well, using the web administration logging configuration
panel which is (no surprise, I guess) tailored towards JDK logging it seems.
Never, though, wanted to manipulate glassfish to "only" use log4j, and it
seems about this very specific issue (just using log4j and _still_ being
capable of having it fully integrated with the glassfish environment) either
so far no one managed to do so or just no one bothered trying. So, overally:
I can't provide you with a real help. In my case, I got out of this rather
straightforward - after moving to slf4j to do the logging, we use log4j just
in case our apps are running in tomcat, and make use of slf4j-jdk adapter to
log through JDK in glassfish. Not what you want, possibly, but at least for
us the most straightforward and working solution. If switching to
commons-logging instead of slf4j, you should be capable of doing the same,
and maybe this would be so far the best option - not questioning the
"political" reasons to use log4j, but if you're switching to an abstraction
layer anyhow, why bother introducing this if you want to use a specific
logger implementation after all...? :)
Sorry if that wasn't helpful that much, just a few thoughts on the issue.
Cheers & good luck,
Kristian
--
Kristian Rink
cell : +49 176 2447 2771
business: http://www.planconnect.de
personal: http://pictorial.zimmer428.net
"we command the system. calling all recievers.
we are noisy people for a better living".
(covenant - "monochrome")