Hi, Going through the related Jira issue, I found that the changes have been introduced to get proper functionality for UDTs in the network client. The network client was required to behave similar to the embedded client when the columns contain java objects. For this reason, some of the functionality of the engine code was used in the client also.
Initially, the two classes InputStreamUtil and DynamicByteArrayOutputStream were made common. But due to the possibility of failures, they were moved and now there are two copies in the engine code and client. But as already mentioned, in the network client, only a little part of these are being used in Request.writeUDT(). So as Knut mentioned the possible solutions would be making use of EncodedInputStream.PublicBufferOutputStream already existing in client.net package or using java.io.ByteArrayOutputStream. I can't see any advantage of using one over the other except for PublicBufferOutputStream giving a direct reference to the byte array. But going through writeUDT(), it seems that it is not needed. So will it be ok to just use java.io.ByteArrayOutputStream? Regards, Nufail. On Wed, May 23, 2012 at 10:53 AM, Mohamed Nufail <[email protected]> wrote: > Thank you. I will go through those and come up with a solution. > > regards, > Nufail. > > On Wed, May 23, 2012 at 9:22 AM, Bryan Pendleton < > [email protected]> wrote: > >> If only such little functionality is utilized, having those two classes >>> is a waste. The new solution sounds much better. >>> >>> So shall I proceed with the suggested solution? >>> >> >> Yes, I think that would be great! >> >> As Knut Anders observed, these two classes were created >> fairly recently. >> >> You might start by reviewing the original change that >> created these two files, and the JIRA entry that tracked >> the discussion around that change, so that you have all >> the background as to why those classes were created in >> that fashion. >> >> Then you could explore the options that Knut Anders suggested, >> or perhaps after your studies you will have a different >> solution to propose. >> >> I believe that the change/JIRA information to examine is this: >> >> $ svn log InputStreamUtil.java >> ------------------------------**------------------------------** >> ------------ >> r899819 | rhillegas | 2010-01-15 13:32:14 -0800 (Fri, 15 Jan 2010) | 1 >> line >> >> DERBY-4491: Fix sealing violation which kills the AssertFailureTest on >> runs against insane jar files. >> ------------------------------**------------------------------** >> ------------ >> >> We'll be looking forward to hear what you learn as you study this. >> >> thanks, >> >> bryan >> >> > > > -- > > Mohamed Nufail > Undergraduate, > Department of Computer Science & Engineering, > University of Moratuwa. > Blog: http://www.nufailm.blogspot.com/ > > > -- Mohamed Nufail Undergraduate, Department of Computer Science & Engineering, University of Moratuwa. Blog: http://www.nufailm.blogspot.com/
