You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Nathan Bubna <nb...@gmail.com> on 2007/04/02 21:02:58 UTC
moving LogChutes from Tools to Engine
Hey folks,
So, the only reason CommonsLogLogSystem ever went into VelocityTools
was that that was the path of least resistance for me at the time. I
wanted it to be released soon, and Velocity releases didn't happen
soon.
Now that we are up to speed, more or less, the reality is that
CommonsLogLogChute (LogSystem is deprecated) doesn't really fit in
Tools as well as it fits in Engine. That's where the other LogChutes
for major logging systems are, and that's where it should be. This is
just a heads up that it is coming in shortly.
The real question i have here is ServletLogChute (formerly known as
ServletLogSystem). Again, we have adaptors for LogKit, Log4j, JDK
Logging, Commons Logging (soon), and System.err/out. Does it make
sense for Engine to provide a wrapper for servletContext.log() too?
Our LogManager essentially chooses the appropriate LogChute from those
configured to be allowed based on the environment of Velocity and the
order of the configured LogChutes. It seems to me that it would make
sense to have sending log output to the servlet's log as a higher
priority than sending it to System.err/out, assuming that a
ServletContext instance is available in the application attributes.
On the flip side, we're trying to remove Servlet API dependencies from Engine...
I could go either way. I'm just curious to hear other people's
thoughts here. If no one cares, chances are that i will leave
ServletLogChute in Tools for now.
p.s. if anyone is wondering about LogChuteCommonsLog (aka
LogSystemCommonsLog), i increasingly feel that it is anathema and will
never escape Tools, even if it manages to survive there. :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: moving LogChutes from Tools to Engine
Posted by Will Glass-Husain <wg...@gmail.com>.
Well, there's two places, which should probably be merged. I like the way
the first gives specific details.
http://velocity.apache.org/engine/devel/build.html
http://velocity.apache.org/engine/devel/jar-dependencies.html
WILL
On 4/19/07, Nathan Bubna <nb...@gmail.com> wrote:
>
> On 4/2/07, Will Glass-Husain <wg...@gmail.com> wrote:
> > I'm +1 on the CommonsLogLogChute in Engine.
> >
> > It probably also makes sense for ServetLogChute to be in Engine. I'm
> > not too worried about compile time dependencies as our build scripts
> > handles these automatically.
>
> Ok, i've been thinking about this more and talked myself into moving
> ServletLogChute into Engine for the sake of ultimately keeping useful
> LogChutes all in one place. Also, since the user must put the
> ServletContext into the runtime's application attributes for the
> ServletLogChute to function (and not merely have
> javax.servlet.ServletContext in the classpath), i'm thinking that this
> should probably precede JdkLogChute in the order for the default
> runtime.log.logsystem.class property.
>
> I'm going to go ahead and check this in. I just wanted to follow up
> on this thread to provide context and a good place for feedback (the
> critical kind is quite welcome :).
>
> > We should try to keep the list of dependencies up to date as that will
> > help people choose which jars to include/exclude when deploying.
>
> Agreed. Do we have a place where we do this? Can this be reflected in
> the POM?
>
> > WILL
> >
> > On 4/2/07, Nathan Bubna <nb...@gmail.com> wrote:
> > > Hey folks,
> > >
> > > So, the only reason CommonsLogLogSystem ever went into VelocityTools
> > > was that that was the path of least resistance for me at the time. I
> > > wanted it to be released soon, and Velocity releases didn't happen
> > > soon.
> > >
> > > Now that we are up to speed, more or less, the reality is that
> > > CommonsLogLogChute (LogSystem is deprecated) doesn't really fit in
> > > Tools as well as it fits in Engine. That's where the other LogChutes
> > > for major logging systems are, and that's where it should be. This is
> > > just a heads up that it is coming in shortly.
> > >
> > > The real question i have here is ServletLogChute (formerly known as
> > > ServletLogSystem). Again, we have adaptors for LogKit, Log4j, JDK
> > > Logging, Commons Logging (soon), and System.err/out. Does it make
> > > sense for Engine to provide a wrapper for servletContext.log() too?
> > > Our LogManager essentially chooses the appropriate LogChute from those
> > > configured to be allowed based on the environment of Velocity and the
> > > order of the configured LogChutes. It seems to me that it would make
> > > sense to have sending log output to the servlet's log as a higher
> > > priority than sending it to System.err/out, assuming that a
> > > ServletContext instance is available in the application attributes.
> > >
> > > On the flip side, we're trying to remove Servlet API dependencies from
> Engine...
> > >
> > > I could go either way. I'm just curious to hear other people's
> > > thoughts here. If no one cares, chances are that i will leave
> > > ServletLogChute in Tools for now.
> > >
> > > p.s. if anyone is wondering about LogChuteCommonsLog (aka
> > > LogSystemCommonsLog), i increasingly feel that it is anathema and will
> > > never escape Tools, even if it manages to survive there. :)
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> > > For additional commands, e-mail: dev-help@velocity.apache.org
> > >
> > >
> >
> >
> > --
> > Forio Business Simulations
> >
> > Will Glass-Husain
> > wglass@forio.com
> > www.forio.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> > For additional commands, e-mail: dev-help@velocity.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
Re: moving LogChutes from Tools to Engine
Posted by Nathan Bubna <nb...@gmail.com>.
On 4/2/07, Will Glass-Husain <wg...@gmail.com> wrote:
> I'm +1 on the CommonsLogLogChute in Engine.
>
> It probably also makes sense for ServetLogChute to be in Engine. I'm
> not too worried about compile time dependencies as our build scripts
> handles these automatically.
Ok, i've been thinking about this more and talked myself into moving
ServletLogChute into Engine for the sake of ultimately keeping useful
LogChutes all in one place. Also, since the user must put the
ServletContext into the runtime's application attributes for the
ServletLogChute to function (and not merely have
javax.servlet.ServletContext in the classpath), i'm thinking that this
should probably precede JdkLogChute in the order for the default
runtime.log.logsystem.class property.
I'm going to go ahead and check this in. I just wanted to follow up
on this thread to provide context and a good place for feedback (the
critical kind is quite welcome :).
> We should try to keep the list of dependencies up to date as that will
> help people choose which jars to include/exclude when deploying.
Agreed. Do we have a place where we do this? Can this be reflected in the POM?
> WILL
>
> On 4/2/07, Nathan Bubna <nb...@gmail.com> wrote:
> > Hey folks,
> >
> > So, the only reason CommonsLogLogSystem ever went into VelocityTools
> > was that that was the path of least resistance for me at the time. I
> > wanted it to be released soon, and Velocity releases didn't happen
> > soon.
> >
> > Now that we are up to speed, more or less, the reality is that
> > CommonsLogLogChute (LogSystem is deprecated) doesn't really fit in
> > Tools as well as it fits in Engine. That's where the other LogChutes
> > for major logging systems are, and that's where it should be. This is
> > just a heads up that it is coming in shortly.
> >
> > The real question i have here is ServletLogChute (formerly known as
> > ServletLogSystem). Again, we have adaptors for LogKit, Log4j, JDK
> > Logging, Commons Logging (soon), and System.err/out. Does it make
> > sense for Engine to provide a wrapper for servletContext.log() too?
> > Our LogManager essentially chooses the appropriate LogChute from those
> > configured to be allowed based on the environment of Velocity and the
> > order of the configured LogChutes. It seems to me that it would make
> > sense to have sending log output to the servlet's log as a higher
> > priority than sending it to System.err/out, assuming that a
> > ServletContext instance is available in the application attributes.
> >
> > On the flip side, we're trying to remove Servlet API dependencies from Engine...
> >
> > I could go either way. I'm just curious to hear other people's
> > thoughts here. If no one cares, chances are that i will leave
> > ServletLogChute in Tools for now.
> >
> > p.s. if anyone is wondering about LogChuteCommonsLog (aka
> > LogSystemCommonsLog), i increasingly feel that it is anathema and will
> > never escape Tools, even if it manages to survive there. :)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> > For additional commands, e-mail: dev-help@velocity.apache.org
> >
> >
>
>
> --
> Forio Business Simulations
>
> Will Glass-Husain
> wglass@forio.com
> www.forio.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: moving LogChutes from Tools to Engine
Posted by Will Glass-Husain <wg...@gmail.com>.
I'm +1 on the CommonsLogLogChute in Engine.
It probably also makes sense for ServetLogChute to be in Engine. I'm
not too worried about compile time dependencies as our build scripts
handles these automatically.
We should try to keep the list of dependencies up to date as that will
help people choose which jars to include/exclude when deploying.
WILL
On 4/2/07, Nathan Bubna <nb...@gmail.com> wrote:
> Hey folks,
>
> So, the only reason CommonsLogLogSystem ever went into VelocityTools
> was that that was the path of least resistance for me at the time. I
> wanted it to be released soon, and Velocity releases didn't happen
> soon.
>
> Now that we are up to speed, more or less, the reality is that
> CommonsLogLogChute (LogSystem is deprecated) doesn't really fit in
> Tools as well as it fits in Engine. That's where the other LogChutes
> for major logging systems are, and that's where it should be. This is
> just a heads up that it is coming in shortly.
>
> The real question i have here is ServletLogChute (formerly known as
> ServletLogSystem). Again, we have adaptors for LogKit, Log4j, JDK
> Logging, Commons Logging (soon), and System.err/out. Does it make
> sense for Engine to provide a wrapper for servletContext.log() too?
> Our LogManager essentially chooses the appropriate LogChute from those
> configured to be allowed based on the environment of Velocity and the
> order of the configured LogChutes. It seems to me that it would make
> sense to have sending log output to the servlet's log as a higher
> priority than sending it to System.err/out, assuming that a
> ServletContext instance is available in the application attributes.
>
> On the flip side, we're trying to remove Servlet API dependencies from Engine...
>
> I could go either way. I'm just curious to hear other people's
> thoughts here. If no one cares, chances are that i will leave
> ServletLogChute in Tools for now.
>
> p.s. if anyone is wondering about LogChuteCommonsLog (aka
> LogSystemCommonsLog), i increasingly feel that it is anathema and will
> never escape Tools, even if it manages to survive there. :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org