Piotr,
I think that Log4J and other logging tools are overkill most of the
time. In our project we started out using a simple debug class for
logging that we created to suit our needs. It was relatively small and
had a convienient frame that you could popup during program execution
so you could turn on an off any registered debug flags. This was very
useful in the early stages of our implementation. As the project
progressed we began to use it les and less and began to remove
references to our debug class. Just this week I removed the last
reference to the old debug class. We have no plans on using any
logger/debug class in the future. We now do all of our debugging in
the IDE.
I made an initial implementation using XStream for serializing to XML.
There were a couple of modifications required for a few of the
OMGraphic classes that we use in our application (I forwarded the
changes to Don).
We had to abandon the use of XStream for serialization due to the
resulting voluminous files. While I prefered the XStream approach for
the serialization, we had a major stumbling block in when it came to
documenting the format (schema) of the XML. We have external programs
(not written in Java) that generate graphics data that our application
(that is Java) consumes. It was far too overwhelming to document the
format so the extermal program could produce valid XML.
Our solution was to create a well documented schema for the OMGraphics
that we use, implement a reader that consumes the XML stream and
produces an OMGraphic list and writer that consumes OMGraphics
producing the XML stream. We chose this approach as it was a better
alternative than to making sweeping changes to the OpenMap code base to
accommodate the XML streaming. At present we stream the following:
OMPoint, OMDistance, OMLine, OMPoly, OMSpline, OMCircle, OMRect, and
OMText. We will be changing the design to permit registering handlers
that encode and decode an OMGraphic.
Cheers,
David
--- Piotr Kami�„ski <Piotr.Kaminski_at_ctm.gdynia.pl> wrote:
> 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"]
>
----
David Ward
ROLANDS & ASSOCIATES Corporation
500 Sloat Avenue
Monterey, CA 93940
USA
Tel: 1.831.373.2025
Fax: 1.831.373.2841
Email: synriga_at_yahoo.com
--
[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 - 21:07:04 EST