I think I've lost the point of this discussion somewhere. The subject
says something about submitting events remotely yet this discussion
seems to be totally about serialization. If it is really about
something like a "service" to submit events than I would suggest
looking at Spring remoting and some of the protocols it supports -
such as Hessian or Burlap. I would argue that a discussion about how
best to serialize an object is pointless without having first decided
on what the service API is. For example, are you presuming that one
system will log to an Appender that will forward to a server that will
turn around and log the event again? Or perhaps an Appender would just
forward the event to an Appender on the remote system? Or, using
Spring Remoting one could imagine that the local Appender is just a
client stub generated by Spring forwarding to the "real" Appender
somewhere else.
Ralph
On Mar 1, 2009, at 4:23 PM, Thorbjoern Ravn Andersen wrote:
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!"
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
