Comments below:
On Nov 28, 2007, at 4:16 AM, James Strachan wrote:
On 28/11/2007, James Chamberlain <[EMAIL PROTECTED]> wrote:
I just started doing some testing on the mina work with some real
data
and I ran into a few issues.
I was continuing to have problems with the MINA codec so dug in to
see
what was happening.
First thing I saw looks like just a simple typo. In the
configureDataGramCodecFactory method on the MinaComponent, the last
line adds a new TextLineCodecFactory instead of the codecFactory
created above. This was easily fixed by changing the last line.
Great catch - doh! :)
I've patched the code to fix that.
Cool, thx.
Then I ran into issues with it being able to convert from byte[] to
ByteBuffer, none of the built in converters know how to perform that
conversion.
Hmm - this is a MINA ByteBuffer right? Does the
MinaConverter.toByteArray() not get invoked? (The src/main/resources
must be on the classpath to auto-discover the MINA type conversions)
Actually ByteBuffer -> byte[] works just fine. It's going from byte[] -
> ByteBuffer that is the problem. The DefaultTypeCoverter does not
have a suitable converter for that. So the follow call (in
toByteBuffer) returns null.
ByteBuffer answer = convertTo(ByteBuffer.class, message);
That's where the problem is.
- James
That's probably pretty straight forward to create a
converter to handle it. To continue my testing I just performed the
conversion in the MinaComponent, but that's not the right way to do
it
long term.
I needed to have multicast support so I ended up writing a new
component that mirrors what the mina component does, but does not use
nio. I'm not done with it yet, but if your interested I could
contribute it when it is complete.
That'd be awesome, we love contributions! :)
http://activemq.apache.org/camel/contributing.html
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com