You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Timur Evdokimov <ti...@jacum.com> on 2005/02/16 21:04:03 UTC
Limit of 65535 bytes per String value?
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.
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
Re: Limit of 65535 bytes per String value?
Posted by Stefan Guggisberg <st...@gmail.com>.
i committed a workaround for this issue. instead of writeUTF i am
using write(byte[]). it's fixed in r154150.
cheers
stefan
On Thu, 17 Feb 2005 11:36:23 +0100, Stefan Guggisberg
<st...@gmail.com> wrote:
> hi timur,
>
> thanks for reporting this issue.
>
> On Wed, 16 Feb 2005 21:04:03 +0100, Timur Evdokimov <ti...@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.
>
> thanks
> stefan
>
> >
> > 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
> >
> >
>
Re: Limit of 65535 bytes per String value?
Posted by Dominique Pfister <do...@day.com>.
David Nuescheler wrote:
>>DataOutputStream.writeUTF(String str, DataOutput out) :
>> if (utflen > 65535)
>> throw new UTFDataFormatException();
>
>
> LOL ;) that will make for a pretty site
> in sun's bug parade.
>
Well, the javadoc for the interface method DataOutput.writeUTF declares
this limitation that is probably due to the internal limit for constant
string values inside a Java Virtual Machine:
* [...] If this number is larger than
* <code>65535</code>, then a <code>UTFDataFormatException</code>
* is thrown.
Sadly enough, this warning didn't make it into the javadoc of
DataOutputStream's implementation...
Dominique
Re: Limit of 65535 bytes per String value?
Posted by David Nuescheler <da...@gmail.com>.
> DataOutputStream.writeUTF(String str, DataOutput out) :
> if (utflen > 65535)
> throw new UTFDataFormatException();
LOL ;) that will make for a pretty site
in sun's bug parade.
regards,
david
Re: Limit of 65535 bytes per String value?
Posted by Stefan Guggisberg <st...@gmail.com>.
hi timur,
thanks for reporting this issue.
On Wed, 16 Feb 2005 21:04:03 +0100, Timur Evdokimov <ti...@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.
thanks
stefan
>
> 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
>
>
Re: Limit of 65535 bytes per String value?
Posted by David Nuescheler <da...@gmail.com>.
hi timur,
thanks for reporting that. maybe you could put that into
jira, since to me this really looks like a bug.
> 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
oops.
> 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!
should all be working exactly as you expected.
this sounds all very fishy to me, just for my reference which
jdk version are you using?
> Were there any REAL reasons to limit Strings length by 65535?
> JCR spec, at a first quick sweep through, says nothing about it.
no, there is no limitation like that in jcr. i can't think of reason that
would justify something like that ;)
> 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.
unfortunately your attachment didn't make it (at least not to me),
but a lot of people had issues sending attachments to the list.
regards,
david
----------------------------------------------------------------------
standardize your content-repository !
http://www.jcp.org/en/jsr/detail?id=170
---------------------------------------< david.nuescheler@day.com >---
This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.
The sender does not assume any liability for timely, trouble free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.
mailto:david.nuescheler@day.com
http://www.day.com
David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel
Switzerland
T 41 61 226 98 98
F 41 61 226 98 97