You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by "Gosse, William" <wi...@eads.com> on 2008/10/21 12:20:18 UTC

weird issue when ServiceMix is in INFO log level

Hi all,

 

I have a weird error regarding servicemix-bean and xPath operations in INFO
log level...

 

Here is my simple workflow: http-consumer <--> servicemix-bean

In my servicemix-bean I search for a node <id> in the input message and
change the content of this node.

 

The issue is that my XPath expression correctly return the <id> node when
servicemix is in DEBUG log level, but return null when it is in INFO log
level...

 

In log4j.xml :

<logger name="org.apache.servicemix">

<!-- To enable debug logging, replace the INFO by DEBUG -->

            <level value="INFO"/>

</logger> 

 

Here is my servicemix-bean source code:

public class SmixXmlTest implements MessageExchangeListener {

    @Resource

    private DeliveryChannel channel;

 

    public void onMessageExchange(MessageExchange exchange) {

        try {

            // init

            XPath xPath = XPathFactory.newInstance().newXPath();

            XPathExpression xpathExpressionId = xPath.compile("//id");

            Document document = (Document) new
SourceTransformer().toDOMSource(exchange.getMessage("in").getContent()).getN
ode();

            

            // get element <id> in input message

            Node idNode = (Node) xpathExpressionId.evaluate(document,
XPathConstants.NODE);

            

            // idNode is null when servicemix is in INFO log level. In DEBUG
log level, it works... 

            idNode.setTextContent("new");

 

            // send response

            MessageUtil.transferInToOut(exchange, exchange);

            channel.send(exchange);

        } catch (Exception e) {

            e.printStackTrace();

        }

    }

}

 

Any ideas on this issue?

 

William


Re: weird issue when ServiceMix is in INFO log level

Posted by Freeman Fang <fr...@gmail.com>.
Hi,

For performance reason by default the MessageExchange isn't re-readable, 
so in your case you need make it re-readable first.
add
exchange.toString() in first place of your code should do the trick

Freeman


Gosse, William wrote:
> Hi all,
>
>  
>
> I have a weird error regarding servicemix-bean and xPath operations in INFO
> log level...
>
>  
>
> Here is my simple workflow: http-consumer <--> servicemix-bean
>
> In my servicemix-bean I search for a node <id> in the input message and
> change the content of this node.
>
>  
>
> The issue is that my XPath expression correctly return the <id> node when
> servicemix is in DEBUG log level, but return null when it is in INFO log
> level...
>
>  
>
> In log4j.xml :
>
> <logger name="org.apache.servicemix">
>
> <!-- To enable debug logging, replace the INFO by DEBUG -->
>
>             <level value="INFO"/>
>
> </logger> 
>
>  
>
> Here is my servicemix-bean source code:
>
> public class SmixXmlTest implements MessageExchangeListener {
>
>     @Resource
>
>     private DeliveryChannel channel;
>
>  
>
>     public void onMessageExchange(MessageExchange exchange) {
>
>         try {
>
>             // init
>
>             XPath xPath = XPathFactory.newInstance().newXPath();
>
>             XPathExpression xpathExpressionId = xPath.compile("//id");
>
>             Document document = (Document) new
> SourceTransformer().toDOMSource(exchange.getMessage("in").getContent()).getN
> ode();
>
>             
>
>             // get element <id> in input message
>
>             Node idNode = (Node) xpathExpressionId.evaluate(document,
> XPathConstants.NODE);
>
>             
>
>             // idNode is null when servicemix is in INFO log level. In DEBUG
> log level, it works... 
>
>             idNode.setTextContent("new");
>
>  
>
>             // send response
>
>             MessageUtil.transferInToOut(exchange, exchange);
>
>             channel.send(exchange);
>
>         } catch (Exception e) {
>
>             e.printStackTrace();
>
>         }
>
>     }
>
> }
>
>  
>
> Any ideas on this issue?
>
>  
>
> William
>
>
>