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]
