Use OGNL more pervasively throughout Mallet

[RoganDawes]

It is looking like OGNL actually provides a lot of capability that could be useful throughout Mallet. From defining Object -> byte[] -> Object pipelines for persistence purposes, as well as Object.toString() implementations, as well as Handler initialiser strings instead of the existing InstanceFactory implementation.

For example, to provide two lists of ChannelHandler instances to convert String -> byte[] -> String, and an expression to convert the Object to a String evaluate

java.lang.String.encode = "{ new io.netty.codec.handler.string.StringEncoder(@io.netty.util.CharSetUtil@UTF_8)} "
java.lang.String.decode = "{ new io.netty.codec.handler.string.StringDecoder(@io.netty.util.CharSetUtil@UTF_8)} "
java.lang.String.toString = "toString()"

Encoders/Decoders/toString() expressions for ByteBuf and byte[] should probably be hard coded given how fundamental they are, but it should be possible to do something like:

toString = @io.netty.buffer.ByteBufUtil@isText(#root,@io.netty.util.CharsetUtil@UTF_8) ? #root.retainedDuplicate().toString(@io.netty.util.CharsetUtil@UTF_8) : @io.netty.buffer.ByteBufUtil@prettyHexDump(#root, #root.readerIndex,@java.lang.Math@min(16, #root.readableBytes)).split("\n")[3]

Turns out that ByteBufUtil.isText() is not particularly useful, when it comes to detecting special characters. May need to provide a more useful ByteProcessor.

OGNL expressions could also be used to implement searching and filtering on connections, with some supporting infrastructure. e.g. show only connections that have instances of a particular class/interface being read or written through them.

[RoganDawes]

Inspiration: for the configuration util we could have a dialog with a JList on the left, and 3 JTextArea's on the right. JList holds a list of class names, the 3 text areas have the various OGNL phrases for encode, decode, and toString. Could also have a test area for some OGNL to create a sample instance to test the various OGNL phrases against.

Persistence of the expressions can be using Java Preferences.

[RoganDawes]

Persistence turns into a bit of a grey area, of course. Ideally, you should be able to share the OGNL expressions along with the graph, so that other people can also use them. Perhaps with a jar of relevant classes and codecs, of course.
But then, do you lose all your carefully constructed OGNL expressions if you load a new graph? That doesn't sound useful either!

[RoganDawes]

Perhaps some sort of middle ground would be useful, where OGNL expressions are saved locally as Preferences, but also saved into the graph, so that they can be shared. It's a bit of a grey area, as it could lead to Remote Code Execution if you open a graph from an untrusted location, though!

Perhaps prompting the user that there are new OGNL expressions in the graph, do you want to merge with your own saved Preferences? Then allowing them to review the expressions one by one.

Also, when saving the graph, allow to filter which expressions get saved in the graph, so as not to leak details of other protocols being worked on.