[jira] Commented: (CAMEL-2713) camel-netty: Add a registry based option for a custom ChannelPipelineFactory

["Christian Mueller (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/activemq/browse/CAMEL-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59412#action_59412 ] 

Christian Mueller commented on CAMEL-2713:
------------------------------------------

May be I was a little vague with my description. In [1.7.3.  The Second Solution |http://docs.jboss.org/netty/3.1/guide/html_single/index.html#d0e1062] in the Netty documentation it's a sample, in which the FrameDecoder is used:

{code}
package org.jboss.netty.example.time;

public class TimeDecoder extends FrameDecoder {

  @Override
  protected Object decode(
    ChannelHandlerContext ctx, Channel channel, ChannelBuffer buffer) {
            
    if (buffer.readableBytes() < 4) {
      return null; 
    }
        
    return buffer.readBytes(4);
  }
}
{code}

The FrameDecoder has the annotation @ChannelPipelineCoverage("one")) which means it is state full. This means, you cannot share an instance of the FrameDecoder in multiple channels. The guided solution for this is to use a ChannelPipelineFactory and create a new instance of the FrameDecoder for each channel:

{code}
package org.jboss.netty.example.time;

public class TimeClientPipelineFactory implements ChannelPipelineFactory {

  public ChannelPipeline getPipeline() {
    ChannelPipeline pipeline = Channels.pipeline();
    pipeline.addLast("handler", new TimeClientHandler());
    return pipeline;
  }
}
{code}

I think this is the same for the encoders and decoders...
In Camel Netty the handler, encoder and decoder are all shared which not fits the needs described before.

{code}
        List<ChannelUpstreamHandler> decoders = producer.getConfiguration().getDecoders();
        for (int x = 0; x < decoders.size(); x++) {
            channelPipeline.addLast("decoder-" + x, decoders.get(x));
        }

        List<ChannelDownstreamHandler> encoders = producer.getConfiguration().getEncoders();
        for (int x = 0; x < encoders.size(); x++) {
            channelPipeline.addLast("encoder-" + x, encoders.get(x));
        }

        if (producer.getConfiguration().getHandler() != null) {
            channelPipeline.addLast("handler", producer.getConfiguration().getHandler());
        } else {
            channelPipeline.addLast("handler", new ClientChannelHandler(producer));
        }
{code}

Please let me know, if I'm right or not.

Thanks,
Christian

> camel-netty: Add a registry based option for a custom ChannelPipelineFactory
> ----------------------------------------------------------------------------
>
>                 Key: CAMEL-2713
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-2713
>             Project: Apache Camel
>          Issue Type: Improvement
>    Affects Versions: 2.3.0
>         Environment: All
>            Reporter: Christian Mueller
>             Fix For: 2.4.0
>
>
> We will build an ims-component to communicate with our [IMS|http://en.wikipedia.org/wiki/Information_Management_System] system.
> As described in the Netty documentation in chapter [1.7.2.  The First Solution|http://docs.jboss.org/netty/3.1/guide/html_single/index.html#d0e865], I assume that we need a state full SimpleChannelHandler (class annotated with @ChannelPipelineCoverage("one")). The proposed solution is to use a ChannelPipelineFactory which creates a new ChannelPipeline and a new SimpleChannelHandler for each Channel.
> {code}
> public class TimeClientPipelineFactory implements ChannelPipelineFactory {
>     public ChannelPipeline getPipeline() {
>         ChannelPipeline pipeline = Channels.pipeline();
>         pipeline.addLast("handler", new TimeClientHandler());
>         return pipeline;
>     }
> }
> {code}
> In the current implementation, this is not possible IMO. The custom handler, which is looked up from the registry, is shared between all channels:
> {code}
>     channelPipeline.addLast("handler", consumer.getConfiguration().getHandler());
> {code}
> If I'm right, I would like to provide the patch (but unfortunately not in the next two weeks).
> Thanks,
> Christian
> P.S: Very nice/clean code inside this component... :-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.