jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Limit of 65535 bytes per String value?
Date Thu, 17 Feb 2005 10:36:23 GMT
hi timur,

thanks for reporting this issue.

On Wed, 16 Feb 2005 21:04:03 +0100, Timur Evdokimov <timur@jacum.com> wrote:
> Hello everyone,
> I just have been hit by a strange limitation of Jackrabbit
> ObjectPersistenceManager.
> I've got a custom property with String type and multiple="true" (which is
> mapped to String[] Java type)
> The problem is that Jackrabbit writes these Strings internally using
> DataOutputStream.writeUTF method, which throws UTFDataFormatException when
> the number of bytes required to save that string is effectively more than
> 2^16, thus 65535
> That leaves me to worry, because I thought I could have used these String[]
> fields for multi-page articles and online books on my site. The only option
> I've left to is use of multiple Binary field which could store fields any
> length. However APIs for Binary fields works with InputStream!
> Because of this, my neat and nice
> setProperty("text", new String[] {xxx, yyy, ...});
> would suddenly explode into full-blown method or even class of its own!
> Were there any REAL reasons to limit Strings length by 65535?
> JCR spec, at a first quick sweep through, says nothing about it.

no, it's an implementation issue, as you assumed correctly.

the culprit is the following line in 
DataOutputStream.writeUTF(String str, DataOutput out) :

	if (utflen > 65535)
	    throw new UTFDataFormatException();

i am speechless..., there seemed to be real pro's at work :(

nevertheless, please post a jira bug and i'll fix it asap.

you can attach your patch to the jira issue, if you wish.


> So I've made some quick changes to ObjectPersistenceManager, replacing
> read/writeUTF with byte-wise String persistence, and it works for me.
> Attached comes the copy.
> Regards,
> Timur

View raw message