[
https://issues.apache.org/jira/browse/DERBY-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609417#comment-14609417
]
Bryan Pendleton commented on DERBY-6801:
----------------------------------------
I see what you mean; this is a little bit tricky.
I think we have to deal with these one by one.
Some of them I think we can simply remove. For example, I don't think you need:
import org.apache.derby.iapi.reference.Limits;
import org.apache.derby.iapi.reference.DRDAConstants;
import org.apache.derby.impl.jdbc.Util;
since those don't seem to be referenced at all elsewhere in Messageutils.
Some of them indicate places where we still need to do more refactoring. For
example, I think that SystemProcedures.SQLERRMC_MESSAGE_DELIMITER
should be moved to MessageUtils, and then we don't have to import
SystemProcedures anymore.
This part of this project may be pretty tricky. For this whole design to work,
it is crucial that MessageUtils be self-contained and minimal, because it
has to be a class that can be packaged either with the client jar, or with the
server jar, and so it can't have a lot of external dependencies.
Maybe you can keep studying the various dependencies and class-not-found errors,
and we can see which ones are straightforward to deal with and which are hard?
> Implement MessageUtils class so client and server can share message argument
> encoding/decoding
> ----------------------------------------------------------------------------------------------
>
> Key: DERBY-6801
> URL: https://issues.apache.org/jira/browse/DERBY-6801
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client, Network Server
> Reporter: Bryan Pendleton
> Assignee: Abhinav Gupta
> Priority: Minor
> Attachments: messageUtils.diff, subPart2.diff
>
>
> Currently, the Network Server contains code which encodes message arguments
> to be passed over DRDA to the client, and other code which
> decodes the encoded message arguments when the client passes
> them back in a call to SQLCAMESSAGE (see DERBY-1178 for additional
> discussion of this behavior).
> We would like to extract that logic and place it into a new MessageUtils
> class in the common shared library so that both the client and server
> can manipulate the message arguments without duplicating the code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
