http://bugzilla.slf4j.org/show_bug.cgi?id=148
--- Comment #3 from Joern Huxhorn <jo...@huxhorn.de> 2009-11-10 21:50:47 ---
Concerning 1.):
Ah, I think I understand.
I guess that "Hello ${Name}" would reference "Name" in the StructuredData,
right, and the actually logged message would be "Hello Ralph", enabling
translations containing the same placeholders. Neat!
Concerning 2.):
I was referring to the javadoc of getData() in StructuredData:
/**
* Returns the data items and their values. Although the Map can contain
Objects, the
* toString() method of the objects will be called when the objects are
formatted for
* inclusion in log records. If the object is not serializable then the value
of toString
* will be used when serialization is required.
*
* @return The data item names (32 characters maximum) and their values.
*/
That's what confused me quite a bit.
It's unfortunate that this has to be included in slf4j-api instead of slf4j-ext
or whatever new jdk15 artifact might be created.
How about encapsulating the Map, mimicking the Map<String,String> API in
StructuredData, i.e. put, get, remove, each with Strings? This would also be
able to ensure the 32 chars maximum constraint for keys.
getData() whould then return an unmodifiable Map.
Concerning 3.):
I have no problem with StructuredData containing a Map<String, String>,
especially if it's contained in slf4j-api.
Concerning 4.):
If my encapsulation suggestion in 2.) would be implemented then no special
handling beside serialVersionUID would be necessary, I think.
--
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dev mailing list
dev@slf4j.org
http://www.slf4j.org/mailman/listinfo/dev
