On 8/7/01 9:09 PM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> 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?
Strictly logging via log4j doesn't get me anything because I can only log
via one category and many appenders which doesn't give me any of log4j's. At
best I can send the same message to multiple targets which isn't what I
want.
We can also embed log4j properties in the velocity configuration for ease of
use, or have a separate log4j properties file so people can use their
existing setup.
>
> 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.
It's trivial to make an appender in log4j, plus you get all the benefits of
log4j. I too am using existing logging systems, but have made a simple log4j
appender that adapts the existing logging system. That is not an issue with
log4j and I imagine it's not an issue with the Sun logging API.
>>
>>> 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.
Well, you're not going to get much smaller than what Ceki made and decent
functionality. The current interface gives me no control, it's not just the
interface but the way we log throughout our classes.
>> 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?
No. Like I said one category which provides no granularity. At best it's the
same messages going to a bunch of targets which isn't very useful.
>> 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?
I am well aware that they are not exactly the same, but they both work in
the same way that you get an instance of a category or logger and use that
for logging. The common pattern is to get an instance of the category/logger
in each class to provide any level of granularity. This is what would allow
you to place all reference exceptions in one file or have them mailed to
someone and allow all messages generated by resource loaders go to another
location. And we shouldn't start adding code each time something like this
is requested.
Even as a simple example, no one can place all reference exceptions in a
separate file. But log4j allows you to arbitrarily do whatever you please by
changing the properties.
>
>> 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
--
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
