[
https://issues.jboss.org/browse/ISPN-7580?page=com.atlassian.jira.plugin....
]
Ramesh Reddy commented on ISPN-7580:
------------------------------------
[~anistor] to be honest there isn't much magic in my code, I just extended the
serialization context then injected the a marshaller in place. I would liked if all the
logic would have just depend on Marshallar interface based on the "descriptor
name" not class name, and {{BaseMarshaller}} interface contain the
marshall/unmarshall methods rather than delegating to the {{MarshallDelegate}} interface.
For me to do that, means lot more changes in your code, thus I resisted.
Anyway my git repo is at [1], note this is work very much in progress. The extended
marshaller and serialization context seen here [2], the most important to you may be seen
in my test case here [3] which shows few scenarios, marshalling simple and complex objects
how interchangeably used the stock marshellers or my custom marshaller to test the
validity.
Thanks for taking a look, let me know of any suggestions.
[1]
https://github.com/rareddy/infinispan
[2]
https://github.com/rareddy/infinispan/tree/master/infinispan-api/src/main...
[3]
https://github.com/rareddy/infinispan/blob/master/translator-infinispan-h...
Use of marsheller is not consistent in all places
-------------------------------------------------
Key: ISPN-7580
URL:
https://issues.jboss.org/browse/ISPN-7580
Project: Infinispan
Issue Type: Bug
Components: Marshalling, Remote Querying
Reporter: Ramesh Reddy
Assignee: Adrian Nistor
Usage of extended ProtoStreamMarshaller is not consistent across all the code paths. For
the purposes of Teiid translator, I have extended ProtoStreamMarshaller which knows to
read/write byte streams in portable fashion for given message type, which are
representions of a relational table in Teiid. This works fine, if I just use cache's
get/put calls.
However, the same fails when used with RemoteQuery or Continuous query. The reason is,
these classes circumvent extended Marsheller and go directly to serialization context
registered to do the wrapping/unwrapping. Not only that there are few places code will
type cast the SerializationContext to SerializationContextImpl object. Thus I can not even
provide my own Serializer nor I can extend this as SerializationContextImpl is declared as
final. These need to be corrected such that extended marsheller is used rather than hard
coding them.
I am guessing this is first time anyone has even done this without using dedicated java
classes as marshellers.
This is extremely critical for me to be fixed to move forward, I can provide the pull
request for it?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)