On 12/14/06, Claude Brisson <[EMAIL PROTECTED]> wrote:
(moving to dev list)
Nathan, there is something that is quite unclear in my mind about the
toolbox manager logger : from what I understand, it is still using
commons-logging and failing to log to the servlet logger (in some
containers and with some configurations stdout is redirected to the
webapp but we cannot rely on this). It happened several times to me to
have a broken toolbox.xml file but no output at all due to this problem.
Isn't this logging issue a problem in the current codebase?
Yeah, ever since Tomcat 5.5 made the obnoxious decision to use
commons-logging (which i could have sworn was supposed to be just a
log wrapper/adapter) as a full-on logging solution responsible for
generating servlet log files and printing to them, our former method
of handling things (pointing all commons-logging messages to
Velocity's LogSystem and pointing Velocity's LogSystem at the provided
servlet log) fails with an infinite loop.
It's been a while since i was fully familiar with the nuances of this
issue, but i believe things are currently as follows:
Velocity's LogSystem is being pointed at the servlet log, and all
VelocityTools messages are being sent to commons-logging. If you are
using Tomcat 5.5.x, then this works fine as the VelocityTools and
Velocity methods both end up in the servlet log. If you are using an
older Tomcat or a different servlet container, then you will not get
VelocityTools messages in your servlet log without actively
configuring commons-logging to print to Velocity's LogSystem (see the
LogSystemCommonsLog class for details).
Once Velocity 1.5 is released, it is my intent to push forward with
work on VelocityTools 2.x and leave the VelocityTools 1.x series
behind. VelocityTools 2.x will require Velocity 1.5+ as a dependency
(among other major changes). Among the benefits of this will be the
ability to drop commons-logging from VelocityTools and use the new and
improved LogChute support in Velocity 1.5+. This will once more
allow us to funnel all Velocity and VelocityTools messages to the same
place, regardless of which servlet container you are using.
In short, the Tomcat people did what Geir could not and successfully
convinced me that it is a very bad idea to use commons-logging in a
webapp framework.
Claude
Le jeudi 14 décembre 2006 à 12:30 -0800, Nathan Bubna a écrit :
> On 12/14/06, Tod Thomas <[EMAIL PROTECTED]> wrote:
> > Nathan Bubna wrote:
> > > and what does your web.xml have?
> >
> > Sorry, plain vanilla:
> >
> > <!-- Define Velocity template compiler -->
> > <servlet>
> > <servlet-name>velocity</servlet-name>
> > <servlet-class>
> > org.apache.velocity.tools.view.servlet.VelocityViewServlet
> > </servlet-class>
> >
> > <init-param>
> > <param-name>org.apache.velocity.toolbox</param-name>
> > <param-value>/WEB-INF/toolbox.xml</param-value>
> > </init-param>
> >
> > <init-param>
> > <param-name>org.apache.velocity.properties</param-name>
> > <param-value>/WEB-INF/velocity.properties</param-value>
> > </init-param>
> >
> > <load-on-startup>10</load-on-startup>
> > </servlet>
> >
> > <!-- Map *.vm files to Velocity -->
> > <servlet-mapping>
> > <servlet-name>velocity</servlet-name>
> > <url-pattern>*.vm</url-pattern>
> > </servlet-mapping>
> >
> > <!-- Define Velocity template compiler -->
>
> Looks fine.
>
> > I've gotten a little further along. A number of apache.commons jar
> > files were missing. Once I copied them over I could see the "Toolbox
> > setup complete" message in the catalina.log.
>
> yeah, having all the dependencies is rather important. if you aren't
> sure what dependencies you need, unpack the simple.war found in the
> velocity distribution and make sure you've got all the ones in the
> WEB-INF/lib folder in that war.
>
> some lines before the "Toolbox setup complete" message, there should
> have been a message saying "Using config file '<some file path>'"
> What is the file used?
>
> > Still not getting anything to render using "$import.class.name" or
> > $import.read("url") though.
>
> This still makes me doubt that the intended toolbox file is the one
> being loaded. Try introducing some bad xml into you toolbox.xml and
> see if the application chokes and complains on startup.
>
> >
> > Thanks for all of your help.
> >
> > ---------------------------------------------------------------------
> > 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]
