Joern Huxhorn skrev:
Why use StAX - you need a SAX parser or something more
sophisticated? I am unfamiliar with the project.
Well, I just like the API.
See http://www.developer.com/xml/article.php/3397691 for a comparison.
While I don't use the skip-feature right now, I like to have that
option. I dislike everything that's using a DOM because has to read
the complete XML and keep it in memory... all in all, it's just a
matter of personal preference... ;)
FIne with me. DOM's don't scale well, and one of the tricks to speed up
XSLT's is to figure out when stuff can be done (before readign all the
data in) which is a science in itself.
Since the serialization mechanism in java relies on the exact
ordering and type of each field in order to generate and interpret
the byte stream without any additional information in the byte stream
but the raw values, it makes sense to me that it will break if the
class signature change. It would not be hard to use an interface
internally and let multiple versions of the class to serialize
implement it. It is not an evil, it is just a trade off :)
Yes, I understand the reasons for the situation but it doesn't make it
easy to read serialized data of previous versions of the class.
Then you need customized serializer and deserializer code, and a version
tag in the stream.
That way, the whole logic of transforming a given object to an
arbitrary byte array is entirely detached from the class itself.
It would also remove the need that LoggingEvent is aware of persisting
at all. The responsibility is entirely in the Serializer/Deserializer
implementation, i.e. there's no need for getLoggerContextVO or similar
methods.
It is still a painpoint. But the version number in the data stream is
no worse than the serialID in the stream anyway :)
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.
I see a good need for a production strength "xml receiver -> sfl4j
events" added to the slf4j-ext package (or so) - would it
licensewise be possible to adapt your work into this?
My code is licensed under LGPL v3 so this shouldn't be a problem.
Since I'm the only developer I could grant any license, anyway.
I'm not sure what you mean with "slf4j events", though. You mean
"logback" instead of "slf4j", right?
No, in the above I actually mean slf4j events. A receiver which
accepts incoming events and throw them straight into a slf4j
log.debug(....) statement (or whatever level was used) - which to me
would be a generic way to glue two separate platforms together.
But slf4j doesn't really define the events, does it?
You have a point there. It doesn't. It is the logging backend that does :)
Sigh. I just hoped for a low entry solution here. Back to the
brainstorming tank.
--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
