Thanks for the reply. In the mean time i've found a way to overcome this limitation.
We still use ULC 6.1.1. To fix this, i've implemented an own IDataStreamProvider, IDataInputStream and IDataOutputStream. The limit is now on Integer.MAX_VALUE bytes (~2GB) which is quite enough. ;-) The tricky part was the registration of my own IDataStreamProvider implementation, because the init-param for the data-stream-provider was not documented. So i did a 'qualified guess'. Well, my guess must have been right. It's working now. kind regards Maik Scheibler -- Sächsische Aufbaubank - Förderbank - (SAB) Informationstechnologie Pirnaische Str. 9 01069 Dresden Tel.: +49 (351) 4910 - 1352 Fax.: +49 (351) 4910 - 1305 mailto:[EMAIL PROTECTED] > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von > Janak Mulani > Gesendet: Dienstag, 25. November 2008 14:40 > An: [email protected] > Betreff: RE: [ULC-developer] custom Coder for java.lang.String > > > > Hi Maik, > > Which version of ULC are you using? > > The problem https://www.canoo.com/jira/browse/UBA-7064 & > https://www.canoo.com/jira/browse/UBA-6939 has been fixed in > ULC 6.1.2. > > PS: For guaranteed response time kindly consider purchasing > ULC Premium > Support : http://www.canoo.com/ulc/products/support.html#premium > > Thanks and regards, > > Janak > > ----------------------------------------- > Janak Mulani > > email: [EMAIL PROTECTED] > url: http://www.canoo.com > > Beyond AJAX - Java Rich Internet Applications > > http://www.canoo.com/ulc > ----------------------------------------- > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > [EMAIL PROTECTED] > > Sent: Tuesday, November 18, 2008 8:31 PM > > To: [email protected] > > Subject: [ULC-developer] custom Coder for java.lang.String > > > > Hello ULC Experts, > > > > i've got a problem with the transfer of large Strings (>64kB) > > between server and client. Because the UlcDataOutputStream > > relies on the java.io.DataOutputStream it is also bound to > > its limitation in the writeUTF()-method: > > > > if (utflen > 65535) > > throw new UTFDataFormatException( > > "encoded string too long: " + utflen + " bytes"); > > > > This causes an Exception on large Strings. > > > > I've tried to circumvent this problem by writing a custom > > StringCoder, but ULC does not use it. > > Ive created my version of the > > DefaultServerCoderRegistryProvider and > > DefaultClientCoderRegistryProvider to add my coder to the > > registry. And i also instructed ULC to use my > > CoderRegistryProviders. But still no effect. > > > > I've checked whether the CoderRegistryProviders are used > > during application startup and they are. But the > > CoderRegistry.getCoder(String className)-method gets never > > called for String! > > > > Are strings handled differently? How can i replace the faulty > > implementation with my own? > > > > Thanks in advance for any sugesstions. > > > > Kind regards > > Maik Scheibler > > > > -- > > Sächsische Aufbaubank - Förderbank - (SAB) > > Informationstechnologie > > Pirnaische Str. 9 > > 01069 Dresden > > Tel.: +49 (351) 4910 - 1352 > > Fax.: +49 (351) 4910 - 1305 > > mailto:[EMAIL PROTECTED] > > > > > > Sächsische Aufbaubank - Förderbank - Anstalt des > öffentlichen Rechts, > > Sitz Dresden, > > Amtsgericht Dresden HRA 5353, > > Ust-IdNr. DE179593934. > > > > _______________________________________________ > > ULC-developer mailing list > > [email protected] > > http://lists.canoo.com/mailman/listinfo/ulc-developer > > > _______________________________________________ > ULC-developer mailing list > [email protected] > http://lists.canoo.com/mailman/listinfo/ulc-developer > Sächsische Aufbaubank - Förderbank - Anstalt des öffentlichen Rechts, Sitz Dresden, Amtsgericht Dresden HRA 5353, Ust-IdNr. DE179593934. _______________________________________________ ULC-developer mailing list [email protected] http://lists.canoo.com/mailman/listinfo/ulc-developer
