I have fixed the JAXPXpathExpression so that the expression is not
compiled anymore in the constructor (but when the expression is first
evaluated, or when afterPropertiesSet is explicitely called). Thanks
for diving in this issue.
For the other problems (non US charachters), could you please raise a
JIRA ? We need to find a way to deal with that ...
Cheers,
Guillaume Nodet
On 4/27/06, Juergen Mayrbaeurl <[EMAIL PROTECTED]> wrote:
>
> Testing is done. I've found the bug and a workaround.
>
> The XPath expression gets compiled in
> JAXPXPathExpression.afterPropertiesSet() as long as
> JAXPXPathExpression.xPathExpression is NULL. Since
> JAXPXPathExpression.afterPropertiesSet() gets called from the constructor
> JAXPXPathExpression(String xpath) any further calls to
> JAXPXPathExpression.set... don't change the compiled XPath expression. This
> is the case, if you call JAXPXPathExpression.setNamespaceContext() and Xalan
> won't know about the namespaces, when it evaluates the XPath expression.
> The workaround is: Don't use the constructor JAXPXPathExpression(String
> xpath). Use the default constructor and call the setter methods. Afterwards
> make sure, that JAXPXPathExpression.afterPropertiesSet() gets called (by
> Spring or by calling it directly). If you want to change any attribute, that
> is used in the XPath expression evaluation, of an instance of
> JAXPXPathExpression after construction, set the attribute
> JAXPXPathExpression.xPathExpression to NULL, set other attributes and
> finally call JAXPXPathExpression.afterPropertiesSet().
>
> With these changes the ContentBasedRouter works correctly, as long as you
> are not using non US-ASCII characters like 'ü' or 'ä'. That's the second
> problem and I'm afraid this is a major problem when you're using ServiceMix
> on non-english systems.
> The problems comes from the class
> org.apache.servicemix.jbi.jaxp.StringSource and its method
> StringSource.getInputStream() that's used very often in ServiceMix (e.g.
> JAXPXPathExpression):
>
> public InputStream getInputStream() {
> return new ByteArrayInputStream(text.getBytes());
> }
>
> According to the JDK documentation, the method String.getBytes() uses the
> default character set of the system to transform/encode the characters of a
> string to a byte array. On my system the default character set is "cp1252".
> Every caller of StringSource.getInputStream(), that has to decode the bytes
> from the input stream back to a string, has to use the default character
> set. I'm quite sure, that there is a lot of code in ServiceMix (see
> SourceTransformer), that doesn't set the character encoding. Unfortunately
> I've no workaround for this problem. Avoid to use
> StringSource.getInputStream(). Use JDK's reader implementations.
>
> Kind regards
> Jürgen
> --
> View this message in context:
> http://www.nabble.com/NamespaceContext-in-XPath-based-content-router-t1512305.html#a4119455
> Sent from the ServiceMix - User forum at Nabble.com.
>
>
