Re: [OpenMap Users] Log4J in OpenMap

From: Piotr Kamiński <Piotr.Kaminski_at_ctm.gdynia.pl>
Date: Tue, 10 Jan 2006 02:05:36 +0100

Hi Don,

Don Dietrick napisał(a):
> Hi Piotr,
>
> Thanks for the insight into your decision. My first instinct is to
> wrap the commons logging classes into the OpenMap package (within
> openmap.jar), so that log4j is used if it's available, and the jdk
> logging used if not. Does that seem like a good idea?
>

Because Jakarta Commons Logging is rather small library you could embed
  it into OpenMap.jar. It is not the way I prefer, but I understand your
objectives. As long as I could use log4j I am happy :-)

It may be useful for users to have simple log4j.properties (and its JDK
Logging API equivalent) attached to OpenMap distribution. Talking about
configuration: it is important to me to have mechanism of specifying
exact location of log4j.properties. I have already configured my
application to use log4j and I would prefer to just add some entries in
existing configuration file than adding the new one. (As I remember I
was able to use the same configuration file for my code and Hibernate
internal logging - so it is doable).

> Are you using Hibernate to store OMGraphics?
>

I depends:
   Not, I haven't used Hibernate to store OMGraphics directly - I stored
my own POJO's business objects.
   Yes, I have stored OMGraphicList serialized into XML in BLOBs using
Hibernate.

This is off-topic but I think that it is important one:

In fact I am not very happy with current XML serialization of OMGraphics
classes. Standard JDK XMLEncoder gives 'strange' looking XML files and
is not very friendly for programmers to use. Someone mentioned
successful using XSTREAM. I think it *is* better than standard
mechanism, although it is another jar file (or even more files).

One of the most unpleasant thing about standard JDK serialization is:
if you move you class to other package (or event change its name) your
stored files are not valid any more - you have to modify class name
inside them. I need more stable file format. Refactoring happens
sometimes and I don't want my customers to modify stored files after
changes in my software.

XSTREAM allow you define 'aliases' for class names so refactoring
problem might be solved easily. Another issue is intrinsic structure of
generated XML. Sometimes you want to read it in text editor and change
something. Sometimes you want to process such file using XSLT or
something. Such tasks are easier when you have:
<OMGraphicList>
    <Point x="1.0" y="2.3"/>
    <Point x="2.0" y="4.1"/>
    <Point x="5.3" y="1.3"/>
</OMGraphicList>

instead of

<void property="graphicList">
    <void property="targets">
     <void method="add">
      <object class="com.bbn.openmap.omGraphics.OMSpline">
       <void property="doShapes">
        <boolean>true</boolean>
       </void>
       <void property="fillColor">
        <null/>
       </void>
     <void method="add">
      <object class="com.obrctm.modules.openmap.editor.OMDecoratedPoly">
       <array class="float" length="18">
        <void index="0">
         <float>0.950803</float>
        </void>
        <void index="1">
         <float>0.32749522</float>
        </void>
        <void index="2">
         <float>0.9492003</float>
        </void>
        <void index="3">
         <float>0.3296515</float>
        </void>
        <void index="4">
         <float>0.9495212</float>
        </void>

       </array>
    ...

To produce nice looking XML files using XSTREAM you have to write some
additional classes but the most important thing is that you *can* do
this. Using standard XMLEncoder you simply can't.

In our last project we have extended and enhanced OMDrawingTool. We have
added new OMGraphic classes and one of the most important requirements
is to store them permanently in files on disk. In my opinion other users
of OpenMap would also gain if standard way of storing OMGraphics is
defined and developed. It is another problem to solve and feature to be
included in 4.7 release.

--
Piotr
> 
> - Don
> 
> 
> On Jan 7, 2006, at 8:56 AM, Piotr Kamiński wrote:
> 
>> Hi,
>>
>> I've used only Log4J. After reading some articles which compared  both 
>> libraries I chose Log4J. In my opinion it gives me more  options, more 
>> appenders, more formatters and is still under active  development. 
>> Logging built into JVM is not developed as intensively  as Log4J. As a 
>> bonus I have Chansaw - the log viewer.
>>
>> My application use many other libraries (e.g. Hibernate), which  also 
>> need logging functionality. In most of cases Log4J is used by  them, 
>> not Logging API. It also influenced my decision.
>>
>> After Java 1.4 had been released with new Logging API there were  thin 
>> wrapper developed (http://jakarta.apache.org/commons/logging).  If 
>> someone wishes to switch between different logging libraries, he  can 
>> now. I don't use it.
>>
>> Log4J was 'on the market' before Logging API, it is more mature, I  
>> think. It is the shame that Sun chose something else, not Log4J,  for 
>> its logging framework. That's my opinion.
>>
>> Now a few words about adding new jar to OpenMap. If you treat  OpenMap 
>> as a self-sufficient application then adding log4j is not  very 
>> appropriate. In my case OpenMap.jar is one 20 other 3rd  parties jars 
>> not including our own libraries. Having non-standard  logging in 
>> OpenMap is more problematic to me than having one jar  file more.
>>
>> So I think that 4 implementations of Debug class would satisfy  everyone:
>>    1 - the old one - for usage in applets
>>    2 - using Java 1.4 Logging API - no additional jars required
>>    3 - using Log4J - for Log4J fans ;-)
>>    4 - using Jakarta Logging wrapper - for persons wishing to  switch 
>> between different logging implementations
>>
>> For me having 1st and 3rd option is enough.
>>
>> -- 
>> Piotr
>>
>>
>> Don Dietrick napisał(a):
>>
>>> Hi Geir,
>>> First, I agree that Debug needs to be replaced, and 4.7 would be  an  
>>> ideal time to do it.  The main reason Debug is still around  is  
>>> because I haven't figured out whether to use log4j or java's  
>>> logging  mechanism, and/or using Piotr's suggestion of making  Debug 
>>> a wrapper  for either.
>>> Is there a reason to use log4j over the logging mechanism built  
>>> into  Java?  I've used both but not enough to choose one over the  
>>> other  based on some capability one has over the other.  I can see  a 
>>> benefit  to not having to deal with yet another jar file,  however, 
>>> which makes  the java logger more attractive to me.
>>> Is one faster than the other, or does one take up fewer  resources?   
>>> I've read several articles written that compares the  two, but I 
>>> still  can find or remember an obvious answer.
>>> - Don
>>> On Jan 6, 2006, at 2:05 AM, Geir Øvsttun (AS/ETO) wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have a point on the OpenMap wishlist (4.7 ?) :
>>>>
>>>> A modernized revamped logging component in OpenMap
>>>>
>>>> My proposal is Log4J (THE open source logging component)
>>>> http://logging.apache.org/log4j/docs/
>>>> (which I guess most of us are using anyway in the rest of our code)
>>>>
>>>> It combines extreme ease of use with extreme logging flexilibility
>>>>
>>>> Comments anyone ?
>>>>
>>>> Geir
>>>
>>> -- 
>>> [To unsubscribe to this list send an email to "majdart_at_bbn.com"
>>> with the following text in the BODY of the message "unsubscribe  
>>> openmap-users"]
--
[To unsubscribe to this list send an email to "majdart_at_bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]

Received on Mon Jan 09 2006 - 20:08:29 EST