[ 
https://issues.apache.org/jira/browse/DIRMINA-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721312#action_12721312
 ] 

boB Gage commented on DIRMINA-719:
----------------------------------

It appears the fix is just a matter of a one line change -- I currently 
lack the facilities to test that theory.

We'll see who's priority pile moves quicker.  :-)    This one only affects 
my debug logging, so it's fairly low priority.

The problem is NOT the 0-byte IoBuffer calls at all.   Those are Mina 
internals and I don't need to mess with them; I won't depend on them for 
the same reason.

The problem is the data-bearing (ie non-0-byte) IoBuffer calls that 
*happen* on a socket connection *DO NOT HAPPEN* on a serial connection.

Yes, I could hack around this problem but I would prefer not to.

Especially since that's how it works for socket connections.    My hack 
would have to take transport mechanism into account, and one of the 
strengths of Mina is abstracting that.





> Serial Filter Chain Broken For Outbound Data
> --------------------------------------------
>
>                 Key: DIRMINA-719
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-719
>             Project: MINA
>          Issue Type: Bug
>          Components: Transport
>    Affects Versions: 2.0.0-M4, 2.0.0-M6
>         Environment: Linux & Windows, serial-transport only
>            Reporter: boB Gage
>
> IoFilterAdapter-descended filter's messageSent() hook called only with 0-byte 
> (Mina internal indicator, I'm told) IoBuffer data, not with IoBuffer 
> containing data actually sent out the serial port.
> Filter object looks like:
> {code}
> public class CaptureLogFilter extends IoFilterAdapter {
> ...
>    @Override
>    public void messageReceived(NextFilter nextFilter, IoSession
> session, Object message) throws Exception {
>        log("RECEIVED: ", message);
>        if (nextFilter != null ) nextFilter.messageReceived(session,
> message);
>    }
>    @Override
>    public void messageSent(NextFilter nextFilter, IoSession session,
> WriteRequest writeRequest) throws Exception {
>        log("SENT: ", writeRequest.getMessage());
>        if (nextFilter != null ) nextFilter.messageSent(session,
> writeRequest);
>    }
> ...
>    private void log(String event, Object arg) {
>        if (arg != null && arg instanceof IoBuffer) {
>            byte b[] = IoBufferUtils.asBytes((IoBuffer) arg);
>            log(event + b.length + " bytes: " + ByteUtils.toHex(b));
> //            IoBuffer i = (IoBuffer)arg;
> //            log("DBG: " + event + "pos: " + i.position() + ", lim:
> "+i.limit());
> // Previous debug was added to confirm IoBufferUtils operation, the IoBuffer 
> 'arg' is confirmed empty (both position & limit are 0)
>        }
>        else log(event);
>    }
> ...
> }
> {code}
> And is hooked in the IoConnector set up:
> {code}
>    private final IoConnector buildIoConnector() {
> ...
>        if ( codecFilter == null )
>            codecFilter = new ProtocolCodecFilter(createCodecFactory());
> ...
>        DefaultIoFilterChainBuilder fc = connector.getFilterChain();
>        if ( fc.contains("logging") ) fc.remove("logging");
>        if ( fc.contains("codec") ) fc.remove("codec");
>        fc.addLast("logging", new
> CaptureLogFilter(getClass().getSimpleName()));
>        fc.addLast("codec", codecFilter);
> ...
> }
> {code}

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

Reply via email to