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

[Thorbjoern Ravn Andersen]

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!"