Jason van Zyl wrote:
>
> On 8/7/01 5:36 PM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
>
> > I think log4j is great.
> >
> > I don't give a hoot what we use as long as
> >
> > 1) There is a simple way to stream the velocity error messages into an
> > application supplied object. Currently, we have an interface with 1
> > init method, and 1 log() method. Pretty simple.
>
> Again I would say too simple, doesn't provide enough flexibility for
> logging. The ability to direct logs wherever desired in an enterprise
> environment. What we have is not sufficient IMO.
I won't disagree that the simple interface we have doesn't do magic
things. Log4J does magic things, and that is why we include the log4j
adapter. Velocity doesn't care what it is logging to...
Since we already have a log4j interface, so you can then w/o any work
other than configuration have Velocity log to log4j, then that part is
wholly satisfied - that is what you are looking for right? Easily using
log4j with Velocity?
Also, the simple interface then lets one use an existing log system w/o
any real effort, and I have seen exiting production systems that have
their own logging system, and our current way makes it trivial to drop
Velocity into the system. If you forced a user to adapt an existing
system beyond the simple 2 method interface, I think it would be harder.
>
> > 2) The user doesn't have to fetch another jar to get Velocity to work -
> > right now the logkit stuff is put into the vel jar for convenience.
> > That is why I asked ceki about doing a small version - so we could stick
> > it in w/o excessive bloat.
>
> The only reason users don't have to download another JAR is because I made
> the build unjar logkit and roll it into the velocity JAR. We can do exactly
> the same thing with log4j. The micro edition is 25k which is probably the
> same size, if not smaller, than logkit.
Exactly. That is what I was saying.
> And I don't really care about size.
I do.
> The velocity jar is already 400k, in addition log4j is the de facto standard
> for logging so most people will have the full jar on hand.
>
> We should probably unroll JARs the way we are doing now because it could
> potentially cause conflicts. Right now for people using logkit, but I hope
> we move to log4j.
We will.
> > 3) Basic configuration is simple.
>
> log4j is very easy to configure.
>
> > Like I said - I intend to integrate log4j as the logging engine asap in
> > the same way that logkit is used. No one will know the difference.
> >
> > I personally would prefer that instead of forcing people to use log4j,
> > we keep a simple generic interface (for our simple log output stream)
> > and let people use log4j with our current log4j helper (which I am sure
> > no one uses...) or put that simple interface on whatever logger they
> > choose to use.
> >
> > The simple interface with log4j helper and log4j as our default file
> > logger gives us power, simplicity and choice.
>
> I don't believe it gives any power as the you have no control over where
> anything goes.
Why not? I can use the existing log4j adapter, and then I have complete
control, right?
> I described a possible scenerio in a previous email.
I will go back and read it.
> The
> classes should be made to use the methodology employed by log4j and the Sun
> logging API where a category/logger are obtained in each class. This
> provides the most flexibility and is the way most components will work in
> the near future. I would velocity to conform.
>
> I will to do the work to make the old method work and have log4j work in the
> recommended fashion. Eventually all components will log in a manner
> advocated by log4j/Sun API
Log4j and Sun API aren't the same. Specifically, what do you want it to
do?
> and it's very easy to switch between the two of
> them. I don't think there is any point in having another logging API has any
> value and there are things I would already like to do that are not possible
> with the logging like a log for reference errors to one file and everything
> else to another. Or being able to create logs (appenders) for each of the
> resources loaders or whatever you might possibly want for your enterprise
> application.
>
> > geir
> >
> > Paulo Gaspar wrote:
> >>
> >> Maybe Jon is right on this one.
> >> (That strange situation again: me agreeing with Jon!!! (o;= )
> >>
> >>> From what Jason wrote it looks like log4j could even be used as an
> >> adapter for some other logging system.
> >>
> >> Of course that, not knowing log4j, I do not know how easy that would
> >> be, but...
> >> - since we already miss a bit more control on what is logged
> >> and how;
> >> - if log4j is small enough;
> >> - and flexible enough (to use as a bridge to other log systems)...,
> >> maybe it would make more sense to use log4j as Velocity's new log
> >> interface instead of going on improving our own thing.
> >>
> >> Now... this is all supposing-talk. I have to take a look at log4j to
> >> make my own opinion. But Jason arguments make some sense and that is
> >> why I got quiet about it until I know more.
> >>
> >> Have fun,
> >> Paulo Gaspar
> >>
> >>> -----Original Message-----
> >>> From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> >>> Sent: Tuesday, August 07, 2001 6:20 PM
> >>>
> >>> on 8/7/01 6:05 AM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> Jon Stevens wrote:
> >>>>>
> >>>>> on 7/31/01 5:49 PM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:
> >>>>>
> >>>>>> Those wrappers are minimal.
> >>>>>
> >>>>> What does that have to do with anything? It provides a clean
> >>> abstraction for
> >>>>> pluggable Logging within Velocity. Since no one is using it,
> >>> lets get rid of
> >>>>> it and simplify things.
> >>>>
> >>>> I have a client that uses it - they can take the velocity log flow and
> >>>> mix it into their application engine. Works great.
> >>>>
> >>>> geir
> >>>
> >>> The point Jason made earlier is that you can do the same thing with Log4J.
> >>>
> >>> The benefit is that you code your custom logging stuff to the Log4J API's
> >>> and then that way you can move it around to other code instead of
> >>> having it
> >>> be tied to Velocity's Logging API (which will never be used outside of
> >>> Velocity, I'm sure).
> >>>
> >>> I see a lot of value in maximum code re-usability. I'm sure you and your
> >>> clients do as well. :-)
> >>>
> >>> -jon
> >>>
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb
