Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of jim@certifydatasystems.com
 designates 64.26.60.137 as permitted sender)
Message-ID: <50E74FC3.1070400@certifydatasystems.com>
Date: Fri, 04 Jan 2013 13:55:15 -0800
From: James Gough <jim@certifydatasystems.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: users@camel.apache.org
Subject: Re: Issue with use of SSLFilter with a custom codec
References: <50E4CCAF.6020101@certifydatasystems.com>
 <CAGB5yNn-OSgarmcq5GGxnpxGrmeBmznOyDPZbQ6yxXXbffxVJg@mail.gmail.com>
 <50E5C356.20304@certifydatasystems.com>
 <50E71C35.2070304@certifydatasystems.com>
In-Reply-To: <50E71C35.2070304@certifydatasystems.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Solution found (or stumbled upon):

I added the following filter to my resources.groovy file:

myCodecFilter(org.apache.mina.filter.codec.ProtocolCodecFilter, mycodec)

And I changed the URL so that:

1. I removed the codec entry
2. I added "&allowDefaultCodec=false" to disable the adding of the 
default codec
3. I added the "myCodecFilter" entry to the filters list

These changes resulted in the following URL:

mina:tcp://{hostname}:{port}?sync=false&minaLogger=true&allowDefaultCodec=false&filters=#sslClientFilter,#myCodecFilter

It all seems to be working correctly now.

Cheers,

Jim

On 1/4/13 10:15 AM, James Gough wrote:
> More data points:
>
> -It doesn't matter whether I set the client field to true, it behaves 
> the same way no matter what the field is set to
>
> -When I called the "sendMessage" method with the grails routing 
> plugin, it was fine with me passing it a string until I added the 
> SSLFilter, then it threw a ClassCast exception unless I would pass it 
> a Mina ByteBuffer
>
> Jim
>
> On 1/3/13 9:43 AM, James Gough wrote:
>> I'm using Camel 2.9.0 with the Mina 1.x component with the 
>> mina-filter-ssl component imported.  I am using the Grails routing 
>> plugin's sendMessage method to the following URL:
>>
>>  "mina:tcp://${hostname}:${port}?sync=false&minaLogger=true&codec=#mycodec&filters=#sslClientFilter" 
>>
>>
>> The SSLFilter is set up using Spring DSL, the only settings I set for 
>> the filter is to pass a valid SSLContext to it's constructor and 
>> setting the clientMode to true:
>>
>>   "sslContextGenerator(com.mypackage.mina.SSLContextGenerator) {
>>     keyStorePassword = '${keyStorePassword}'
>>     trustStorePassword = '${trustStorePassword}'
>>     keyStorePath = '${keyStorePath}'
>>     trustStorePath = '${trustStorePath}'
>>   }
>>
>>   sslContext(sslContextGenerator: "getSSLContext")
>>
>>   sslClientFilter(org.apache.mina.filter.SSLFilter, sslContext) {
>>     useClientMode = true
>>   }"
>>
>> I have verified that the SSLFilter instance does have the "client" 
>> parameter set to true.
>>
>> I'm stumped.  It just seems like when the SSLFilter is engaged it's 
>> behavior is entirely different.
>>
>> Jim
>>
>>
>> On 1/3/13 12:01 AM, Claus Ibsen wrote:
>>> Hi
>>>
>>> What Camel version are you using?
>>> And which Camel component are you referring to? Could it be camel-mina
>>> ? eg the Mina 1.x based component?
>>> And how have you configured the Camel component/route?
>>>
>>>
>>>
>>> On Thu, Jan 3, 2013 at 1:11 AM, James Gough 
>>> <jim@certifydatasystems.com> wrote:
>>>> I am trying to use SSLFilter with a custom codec, but it appears 
>>>> that my
>>>> client (for which I have called SSLFilter's "setUseClientMode" 
>>>> method with a
>>>> setting of true), is calling SSLFilter prior to calling the codec, 
>>>> and it
>>>> calls the decoder's decode method rather than the encoder's encode 
>>>> method,
>>>> which is called when sslFilter is not used.
>>>>
>>>> It goes something like this:
>>>>
>>>> SSLFilter used:
>>>> caller -> SSLFilter -> codec's decoder.decode() method -> service
>>>>
>>>> SSLFilter not used:
>>>> caller -> codec's encoder.encode() method -> service
>>>>
>>>> The codec also is handed an encrypted message, which is useless 
>>>> since I have
>>>> to do some stuff to it prior to sending it.
>>>>
>>>> Any hints?
>>>
>>>
>>
>>
>
>