I did not suggest that we use JMS but the properties as in JMS. Sorry, apparently I was not very clear.
More concretely, we add a new field "properties" which is a hashtable that carries any number of key-value pairs. Hostname becomes just a particular key. Is that any clearer? At 15:50 12.12.2002 -0500, [EMAIL PROTECTED] wrote:
And JMS is a fine solution if you can use JMS. But if you aren't using J2EE, you can't use JMS. Running tomcat/apache as an app server lends itself to not knowing which host the message came from. Surely I'm not the only one with a central repository of logs coming from various hosts who can't use JMS? To me, hostname is simple and obvious. It's up there with thread name and class name as fundamental information to be present in a log. Username, and session id are J2EE-specific concepts. Or more generally, they are concepts that different app writers might interpret differently, and so they shouldn't be in some canonical list of things you can log. But hostname? Hostname is canonical. Everyone knows what it means, and everyone with a remote configuration needs to know it. Thus, I think log4j should support hostname retrieval natively. dan
-- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
