-- Piotr David Ward napisał(a): >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 Tue Jan 10 2006 - 07:09:29 EST
This archive was generated by hypermail 2.3.0 : Tue Mar 28 2017 - 23:25:07 EDT