[
https://issues.jboss.org/browse/ISPN-7580?page=com.atlassian.jira.plugin....
]
Ramesh Reddy commented on ISPN-7580:
------------------------------------
[~anistor] I know exposing the the "impl" interface without moving to a
different package without refactoring further is bit hacky, but I did not wanted to do
wider changes without knowing the what is public vs private API and potential for
regression. If you want to discuss/provide the layer at the Serialization context level, I
am willing to bridge the gap with another patch.
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)