[logback-dev] What is the most efficient way - preferrably platform agnostic - to submit events from "the outside"?

[Thorbjoern Ravn Andersen]

Joern Huxhorn skrev:
> Well, a stream could contain both LoggingEvent0916 and 
> LoggingEvent0918 and the Deserializer would produce the correct output 
> using instanceof and some defined conversion. The point is that the 
> old class would not be lost as it is the case if just the 
> serialVersionUID is changed. It could therefore still be deserialized.
After thinking it over I believe that this is the exact reason why 
XMLEncoder/XMLDecoder was introduced in the first place - the ability to 
read in old classes.

I don't think that it is possible to get to work _well_ but I'm always 
happy for a good discussion.

>>
>>>>> Have you had the time to check my xml format? While it's not 
>>>>> exactly terse ;) it's definitely human-readable.
>>>> I think I have understood what the problem with my use of the 
>>>> "humanly readable" term is.  It is not the actual XML with names 
>>>> and tags, but the data carried I am talking about.  Timestamps are 
>>>> fine but is not really readable to a human.
>>>>
>>>> I can easily live with one character tag and attribute names if the 
>>>> data in the fields carry meaning to the human eye :)
>>>
>>> Well, I'm using yyyy-MM-dd'T'HH:mm:ss.SSSZ as the primary time stamp 
>>> format and then apply some magic to change it into a valid xml 
>>> timestamp, i.e. I add a colon between hh and mm of the timezone.
>>> It mad my sigh quite a bit when I realized that SimpleDateFormat did 
>>> not support this...
>>>
>> A valid xml timestamp?  According to what dialect?  SOAP?   Frankly I 
>> think that these date objects are expensive to reconstruct - perhaps 
>> you should look into this if performance is an issue to you?  I 
>> believe the date object just serializes  the long datestamp which is 
>> much cheaper to deserialize than to deconstruct a string into pieces 
>> and build a date/calendar object from it.  Note you also need 
>> timestamp information for this so it most likely goes through a 
>> Calendar.
>>
>
> Point taken, I wasn't really thinking about that when I was 
> implementing it, I primarily wanted to do it *right* ;)
>
> It's an xs:dateTime (http://www.w3.org/TR/xmlschema-2/#dateTime) which 
> seemed reasonable to me.
> xs:dateTime expects a colon between timezone hh and mm while 
> SimpleDateFormat does only support hhmm :p
>
> I implemented your suggestion and it's - unsurprisingly - 
> deserializing quite a bit faster, now.
Hehe,  if I read your tables correctly the 
lilithXmlUncompressedDeserializer went from 1.974544 sec to 0.497055 
sec, which is four times faster so "quite a bit" is quite a bit of an 
understatement :)

Also the value is very close to the 0.493445 value for 
serializationUncompressedDeserializer so it appears that the two 
approaches have about the same runtime performance.
>
> Now I just need to update the schema... and I really need to implement 
> an EventWrapper Serializer that's using my xml so I can use it as the 
> Lilith file format...! Performance and size is absolutely acceptable.
Now I just need to bully you into shortening all tags and attribute 
names into one character and skip any namespace prefixes :)  Then we 
agree O:-)

> I moved the benchmarks to 
> http://apps.sourceforge.net/trac/lilith/wiki/SerializationPerformance so 
> I don't have to change the closed bug all the time :p
You _could_ also just reopen the bug :)

-- 
  Thorbjørn Ravn Andersen  "...plus... Tubular Bells!"