You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Daniel Pocock <da...@pocock.pro> on 2014/02/25 18:08:05 UTC
Re: [patch?] camel-smpp UCS-2 issues
Hi all,
I'm just following up on this - is anybody actively working on the SMPP
code or should I just submit a patch?
I've also registered some of these issues in the bug tracker.
Regards,
Daniel
On 18/02/14 14:37, Daniel Pocock wrote:
>
> I've observed some oddities sending messages to SMPP that require UCS-2
> (16 bit / Unicode) encoding
>
> To make it work, I have to explicitly set:
> alphabet=-1 in the endpoint config
> CamelSmppDataCoding=8 in the exchange headers
>
> and leave other headers and config settings empty/default
>
> Automatic detection of encoding doesn't seem to work, so I have to scan
> each message myself and then make those settings when necessary on a
> per-message basis.
>
> Given alphabet=-1 in the endpoint config, I also have to explicitly set
> CamelSmppAlphabet= ALPHA_DEFAULT for those messages that don't require
> UCS-2 treatment
>
> I made a quick review of the code and various things caught my eye:
>
> - the header Exchange.CHARSET_NAME is never checked, it could be more
> useful than the "encoding" param in the endpoint config perhaps?
>
> - in SmppSmCommand:
>
> why does determineCharset() only return UCS2_ENCODING for
> UNKNOWN_ALPHABET and not for ALPHA_UCS2?
>
> why does determineAlphabet() only use the charset configured in the
> endpoint? This seems like a good place to use Exchange.CHARSET_NAME
>
>
Re: [patch?] camel-smpp UCS-2 issues
Posted by Daniel Pocock <da...@pocock.pro>.
Hi Christian,
Thanks for your feedback, I just saw your Jira comments to
Could you add some comments to Jira just to confirm if my observations
are correct and if you agree with what I propose before I look at making
any patch?
Regards,
Daniel
On 26/02/14 08:33, Christian Müller wrote:
> Hello Daniel!
>
> Thanks for following up with this.
> I contributed the SMPP component years ago. Afterwards, a few people made
> good contributions to that.
> Unfortunately, I don't have the time to work on this issue at present. We
> would appreciate, if you could contribute a patch (unit test included). We
> love contributions!
>
> You can find more about how to contribute to Apache Camel at [1].
>
> [1] https://camel.apache.org/contributing.html
>
> Thanks in advance,
>
> Christian
> -----------------
>
> Software Integration Specialist
>
> Apache Member
> V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer
> Apache Incubator PMC Member
>
> https://www.linkedin.com/pub/christian-mueller/11/551/642
>
>
> On Tue, Feb 25, 2014 at 6:08 PM, Daniel Pocock <da...@pocock.pro> wrote:
>
>>
>>
>>
>> Hi all,
>>
>> I'm just following up on this - is anybody actively working on the SMPP
>> code or should I just submit a patch?
>>
>> I've also registered some of these issues in the bug tracker.
>>
>> Regards,
>>
>> Daniel
>>
>>
>> On 18/02/14 14:37, Daniel Pocock wrote:
>>>
>>> I've observed some oddities sending messages to SMPP that require UCS-2
>>> (16 bit / Unicode) encoding
>>>
>>> To make it work, I have to explicitly set:
>>> alphabet=-1 in the endpoint config
>>> CamelSmppDataCoding=8 in the exchange headers
>>>
>>> and leave other headers and config settings empty/default
>>>
>>> Automatic detection of encoding doesn't seem to work, so I have to scan
>>> each message myself and then make those settings when necessary on a
>>> per-message basis.
>>>
>>> Given alphabet=-1 in the endpoint config, I also have to explicitly set
>>> CamelSmppAlphabet= ALPHA_DEFAULT for those messages that don't require
>>> UCS-2 treatment
>>>
>>> I made a quick review of the code and various things caught my eye:
>>>
>>> - the header Exchange.CHARSET_NAME is never checked, it could be more
>>> useful than the "encoding" param in the endpoint config perhaps?
>>>
>>> - in SmppSmCommand:
>>>
>>> why does determineCharset() only return UCS2_ENCODING for
>>> UNKNOWN_ALPHABET and not for ALPHA_UCS2?
>>>
>>> why does determineAlphabet() only use the charset configured in the
>>> endpoint? This seems like a good place to use Exchange.CHARSET_NAME
>>>
>>>
>>
>
Re: [patch?] camel-smpp UCS-2 issues
Posted by Christian Müller <ch...@gmail.com>.
Hello Daniel!
Thanks for following up with this.
I contributed the SMPP component years ago. Afterwards, a few people made
good contributions to that.
Unfortunately, I don't have the time to work on this issue at present. We
would appreciate, if you could contribute a patch (unit test included). We
love contributions!
You can find more about how to contribute to Apache Camel at [1].
[1] https://camel.apache.org/contributing.html
Thanks in advance,
Christian
-----------------
Software Integration Specialist
Apache Member
V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer
Apache Incubator PMC Member
https://www.linkedin.com/pub/christian-mueller/11/551/642
On Tue, Feb 25, 2014 at 6:08 PM, Daniel Pocock <da...@pocock.pro> wrote:
>
>
>
> Hi all,
>
> I'm just following up on this - is anybody actively working on the SMPP
> code or should I just submit a patch?
>
> I've also registered some of these issues in the bug tracker.
>
> Regards,
>
> Daniel
>
>
> On 18/02/14 14:37, Daniel Pocock wrote:
> >
> > I've observed some oddities sending messages to SMPP that require UCS-2
> > (16 bit / Unicode) encoding
> >
> > To make it work, I have to explicitly set:
> > alphabet=-1 in the endpoint config
> > CamelSmppDataCoding=8 in the exchange headers
> >
> > and leave other headers and config settings empty/default
> >
> > Automatic detection of encoding doesn't seem to work, so I have to scan
> > each message myself and then make those settings when necessary on a
> > per-message basis.
> >
> > Given alphabet=-1 in the endpoint config, I also have to explicitly set
> > CamelSmppAlphabet= ALPHA_DEFAULT for those messages that don't require
> > UCS-2 treatment
> >
> > I made a quick review of the code and various things caught my eye:
> >
> > - the header Exchange.CHARSET_NAME is never checked, it could be more
> > useful than the "encoding" param in the endpoint config perhaps?
> >
> > - in SmppSmCommand:
> >
> > why does determineCharset() only return UCS2_ENCODING for
> > UNKNOWN_ALPHABET and not for ALPHA_UCS2?
> >
> > why does determineAlphabet() only use the charset configured in the
> > endpoint? This seems like a good place to use Exchange.CHARSET_NAME
> >
> >
>