[mule-dev] the problem of the encoding attribute on outbound-endpoint

40 views

Skip to first unread message

Kazuya Uno

unread,

Jun 30, 2010, 12:11:25 AM6/30/10

to d...@mule.codehaus.org

I'm trying to fix the problem of encoding attribute on outbound-endpoint
element. and I wrote a tiny patch for mule-3.x, and it works for me　
(core-encoding.patch).
I'm not so sure if I'm on the right way, so any comments or suggestions
are welcome.

Best regards.

*******************
*** Backgrounds ***
*******************

The transports like FTP has not a encoding meta data in messages.
We need to specify the encoding on the endpoint

I wrote a test code for ftp:outbound-endpoint. Its message flow is
as follows. but it doesn't work.(ftpTransport.patch)

input message(with String payload)
-> vm.inbound -> ftp.outbound(encoding="ISO-2022-JP")
==FTP==> ftp.inbound -> component

************************************************************
*** changes in AbstractTransformer and DefaultMuleEvent ***
************************************************************

<<summary>>

I changed to use
MuleMessage#getStringProperty(MuleProperties.MULE_ENCODING_PROPERTY, null)
instead of MuleMessage#getEncoding(). The new encoding priority is:

1. MuleMessage#getStringProperty(MuleProperties.MULE_ENCODING_PROPERTY,
null)
2. if the property value is null, call ImmutableEndpoint#getEncoding().
3. if the endpoint encoding is null, use
System.getProperty(MuleProperties.MULE_ENCODING_SYSTEM_PROPERTY)
(only in AbstractTransformer)

<<change discription>>

There are three methods to get the encoding that are used in original
AbstractTransformer and DefaultMuleEvent.

a message.getEncoding()
b endpoint.getEncoding()
c System.getProperty(MuleProperties.MULE_ENCODING_SYSTEM_PROPERTY)
(only in AbstractTransformer)

The methods never return null.
That the reason the endpoint encoding is never used with the original code.

**************************************
*** changes in DefaultMuleMessage ***
**************************************

<<summary>>

I changed DefaultMuleMessage's copy constructor to copy
a MULE_ENCODING property only if the previous message has it.
If the message has not it, do nothing and the property of
the new message is null.

<<change discription>>

The message generated by the original copy constructor has always
MULE_ENCODING property, even if previous message had no MULE_ENCODING
property.

As a result, the downstream component of the flow has no knowledge
if MESSAGE_ENCODING was set by the upstream transport or the
system wide default encoding was set by the copy constructor.

I changed a copy constructor to distinguish whether MULE_ENCODING was
specified explicitly or not.

Because, if the downstream component of the flow (for example,
AbstractTransformer) cannot distinguish it,
AbstractTransformer cannot judge whether to use the endpoint encoding
to decide encoding.

**********************************
*** impact to the current code ***
**********************************

I ran test codes between before and after my modification,
and the result seems same between before and after.

best regards.

=======================
test results BEFORE
=======================

rev.17714 Runs Fail Errs Skip
============== ===== ==== ==== ====
buildtools - - - -
core 927 1 0 0
distributions - - - -
examples 0 0 0 0
modules(*) 54 0 14 0
tests 224 0 3 0
tools - - - -
transports 117 0 1 0

=======================
test results AFTER
=======================

* NOTE : following files removed due to compile errors.
org.mule.module.client.config.ClientNamespaceHandler.java
org.mule.module.client.config.RemoteDispatcherAgentDefinitionParser.java
org.mule.module.management.config.ManagementNamespaceHandler.java

core-encoding.patch

ftpTransport.patch

Kazuya Uno

unread,

Aug 13, 2010, 12:37:39 AM8/13/10

to d...@mule.codehaus.org

I posted a issue about this to
JIRA.(http://www.mulesoft.org/jira/browse/MULE-5009)

the patch I wrote on mule-3.x(rev 17714), and I'm wondering
wheter it works on current revision.

but if adopted, I'll fix it for current revision.

----- Original Message -----
From: "Kazuya Uno" <Uno_K...@ogis-ri.co.jp>
To: <d...@mule.codehaus.org>
Sent: Wednesday, June 30, 2010 1:11 PM
Subject: [mule-dev] the problem of the encoding attribute on
outbound-endpoint

> I'm trying to fix the problem of encoding attribute on outbound-endpoint
> element. and I wrote a tiny patch for mule-3.x, and it works for me　
> (core-encoding.patch).
> I'm not so sure if I'm on the right way, so any comments or suggestions
> are welcome.
>
> Best regards.

---------------------------------------------------------------------
To unsubscribe from this list, please visit: