Hi,
In my current setup I let spring do my logging initialization by adding
the following to my web.xml:
<context-param>
<param-name>log4jConfigLocation</param-name>
<param-value>/WEB-INF/log4j_debug.xml</param-value>
</context-param>
<context-param>
<param-name>log4jRefreshInterval</param-name>
<param-value>2000</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
</listener>
This way you can setup logging per web application and just use your
normal logging procedure where you do Logger.getLogger(Myclass.class).
Furthermore you can edit your log4j config on the fly (without
restarting your application) though due to log4j internals it might not
a good idea to do this on producation machines (the watchdog thread is
not terminated when the application is unloaded). This allows you to do
fine grained logging per application (with per application appenders)
and is minimally intrusive in your code. (The next step would be AOP
which would remove the logging code from your code altogether; however
this is in my opinion a bit unpractical since just entering and leaving
methods is not the only thing I want to log).
Greetings,
Sebastiaan
Adam Zimowski wrote:
I must agree with Sebastian, unless I'm missing something as well.
With little work up front, I can setup:
LoggablePage, LoggableComponent, LoggableObject, etc
and derive a class from that with all my log stuff setup and ready to
go. I still get the fine grained control of Log4j, can have many
loggers (main, session, thread, etc).
Can IOC give me all that, with equal ease of use?
On 3/6/06, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
Hi,
Actually I'm only using tapestry + hivemind as the frontend, and my
services etc are contained in a Spring container (I use
@InjectObject("spring:service") in my pages).
I agree that you should move your business logic into services, but it
seems to me that logic that is relevant only to the page should just go
in you page class. And often it's useful to do some logging in the
processing of this logic as well.
It seems to me though that using logging via the service point you are
negating one of the strong points of Log4j (which is really fine grained
logging) and making it a lot less fine grained (namely one logger for
everything involved in a single service point)? Or am I missing something?
Greetings,
Sebastiaan
James Carman wrote:
Do you need to do your logging in your page classes? The Tapestry 4 way of
doing things is to move most of your processing logic into services.
HiveMind will inject a Log object into your service implementation object
using the fully-qualified name of the service point
(moduleid.servicepointid).
-----Original Message-----
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
Sent: Monday, March 06, 2006 2:49 AM
To: Tapestry users
Subject: Re: Tapestry 4 logging [solved]
Hi,
Why don't you just use the compile time class instead of the runtime
class to get the logger for your page? Seems to me this gives you the
behavior you want in most cases (if a class is subclassed, you want to
be able to tell which log messages come from which superclass, and using
the runtime class will make it seem like all log messages are coming
from the last subclass).
In other words, in your tapestry pages:
publc abstract class Home extends BasePage {
Logger logger = Logger.getLogger(Home.class);
...
}
Greetings,
Sebastiaan
Matt Larson wrote:
Just wanted to post my solution to my Log4J problem, which I posted as a
response to someone else's similar problem a few weeks ago. Apologies
if this is a widely known issue, but in casually reading this list and
checking Tap 4 documentation, I haven't seen this mentioned specifically.
After some research, I saw that the cause of the problem was that
Tapestry 4 instantiates its concrete page objects differently than Tap 3
did, which causes problems if you have created your logger using
Logger.getLogger(this.getClass()) ;
In Tap 4, if you try to check the package using a call like
this.getClass().getPackage().getName();
you'll actually get a NullPointerException, because getPackage() doesn't
return a package. Now I am not really familiar with Log4J's internals,
but it apparently uses this call or one like it to try to determine
whether or not to log a message. In Tap3, the package of the
instantiated class was something (I didn't go back and check this),
probably the package in the abstract page class, that allowed Log4J to
determine that it did need to log messages created using that class's
logger.
The solution, if you have created your Logger using Logger.getLogger(),
is just to call
Logger logger = Logger.getLogger(this.getClass().getSuperclass());
which will instantiate your logger with your abstract class, not
Tapestry's concrete class, and allow Log4J to work correctly.
Matt
Matthew Larson wrote:
I am having the exact same problem. I upgraded from a Tap 3
environment under Tomcat where I used log4j, and all of a sudden some
of my logging messages fail to appear--but only if the logging takes
place within a Tapestry page or component .java file. My DAOs and
such, if they contain logging messages, work fine. I have checked and
rechecked my log4j.properties, which I did not change from my previous
Tap 3 project. The settings are correct. Obviously there's something
I don't understand about Tapestry's instantiation of my abstract page
and component classes, something that is throwing log4j off. I was
planning to investigate the problem more thoroughly, but if others are
having it and someone knows the answer already, that would save me and
Lennart some time...
Thanks in advance for any help.
Matt
Lennart Benoot wrote:
Hi all,
Yesterday I deployed my first tapestry 4 application. I noticed that
there there is hardly any logging in the log file. The only logging I
see is :
Feb 21, 2006 8:00:57 PM org.apache.tapestry.ApplicationServlet init
INFO: Initialized application servlet
'org.apache.catalina.INVOKER.hadron.vocawb.ApplicationServlet': 2,413
millis to create HiveMind Registry, 5,490 millis overall.
How can I have more logging?
Thanks,
Lennart
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
