Yes, Inderdeep, that is exactly what I did. Had to write my own
appender, that does not serialize the LoggingEvent object , but sends
the object inside it as is.
In fact, now we are thinking to use AsyncAppender instead of
JMSAppender. Write our own Appender and attach it to the AsyncAppender.
That way, we get the same asynchronous logging functionality as JMS and
also have more control on the LoggingEvent object.

Thanks
--Viv

On Mon, 2003-06-09 at 02:22, Inderdeep Dhir wrote:

    Hi Vivek,
    
    The message object inside LoggingEvent is kept as a transient field, so it does 
not survive the serialization whereas the string representation of the message (kept 
as a separate field) does. The getMessage() method will return the message object if 
its available otherwise it returns the rendered message (string). So, once 
LoggingEvent is serialized and sent over the wire, it only returns the rendered 
message as a string.
    
    In order to achieve what you want, you can extend the default JMSAppender to 
publish your custom object instead of LoggingEvent. The custom object could be a 
composition of LoggingEvent and LogMessage (which you can get by calling 
getMessage()). 
    
    On the other end, you can extend the default JMSSink to retrieve this custom 
object from the queue. At this point you have both the LoggingEvent and the LogMessage 
objects so you can do whatever processing you want.
    
    Hope this helps,
      ~ Inder
    
    Inderdeep Dhir
    Associate, Technology | Sapient
    desk :(+91) 124.280.5717
    cell :(+91) 981.129.2822
    email:[EMAIL PROTECTED]
    
    
    -----Original Message-----
    From: Vivek Kapadekar [mailto:[EMAIL PROTECTED] 
    Sent: Saturday, June 07, 2003 3:31 AM
    To: Log4J Users List
    Subject: Re: Log4j and JMS , retrieving object
    
    
    Thats true. Is the LoggingEvent class responsible for  Serializing the message 
objects. ?
    
     This is what I do...
    LogMessage message = new LogMessage(key, value);
    logger.debug(message)
    
    In this case will LoggingEvent instance convert the LogMessage object to String, 
which is retrieved by the
    getRenderedMessage() ?  But what I want is the message object before it gets 
rendered , so can I use the getMessage() method on LoggingEvent to get the Object 
itself ? I tried it, but it returns String too? BTW the LogMessage object I am using 
is Serializable.
    
    Thanks
    --Viv
    
    
    
    On Fri, 2003-06-06 at 14:12, Ceki Gülcü wrote:
    
        At 12:10 PM 6/6/2003 -0700, you wrote:
        >Hi All
        >Can someone please help me with this issue. ?
        >It seems log4J always, logs the message in String format. Either it uses
        >the Renderer to render the Object as String Or calls the toString().
        >But what we want to do is, Send the message encapsulated in a LogMessage
        >Object to a JMSAppender. The JMS  Consumer will read this LogMessage
        >Object and send it over to a remote server using SOAP a call.
        >So Basically, we do no want log4j to convert the LogMessage Object to a
        >String . Is there a way we can do it, or do we need to extend log4j code
        >and write our own code to prevent this conversion of object to message.
        >?
        
        The JMSAppender uses object serialisation to send its payload. The 
        LoggingEvent object (which is the payload of the JMS message) is written in 
        such a that it serializes the string of the message object, LogMessage in 
        your case. It does not serialize the message object because not all message 
        objects are serializable and their serialized form can be very large in size.
        
        HTH,
        
        >Thanks
        >Viv
        
        --
        Ceki  For log4j documentation consider "The complete log4j manual"
               ISBN: 2970036908  http://www.qos.ch/shop/products/clm_t.jsp 
        
        
        ---------------------------------------------------------------------
        To unsubscribe, e-mail: [EMAIL PROTECTED]
        For additional commands, e-mail: [EMAIL PROTECTED]
        
        
        
    
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [EMAIL PROTECTED]
    For additional commands, e-mail: [EMAIL PROTECTED]
    
    
    

Reply via email to