jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hendrik Beck \(camunda\)" <hendrik.b...@camunda.com>
Subject RE: [OCM] Binary values from byte[] field
Date Wed, 12 Sep 2007 14:00:42 GMT
Hi Christope,

Thanks for your answer.

Just to clarify what exactly I am doing: I am retrieving that stored binary
value right after I stored it, both times from a remote client over RMI.
With "opening" it I meant that I just wrote a few lines that are writing the
byte array back into a file which I then try to open with an external
application (e.g. Acrobat Reader for PDFs).

I ended up in this approach after I wondered wether the document is really
stored correctly in JCR. I wanted to open it with my JCR-Explorer web
application, it didn't work. Also, full-text search using the TextExtractors
didn't work while it worked well with binary document stored in another way
(e.g. by adding it manually to the repository using JCR-Explorer). 

So, to answer your question: there is only one save() call involved, then
one after I persisted the data using the ObjectContentManager.

So at that point I am kind of stuck. I was also wondering wether it would be
possible to use the constructor you mentioned but also not sure how to
determine the right charset at that point. By the way, does this play
together with the "encoding" stored in nt:resource nodes? Or is that again
two different kinds of things?

Regards
Hendrik


> -----Original Message-----
> From: Christophe Lombart [mailto:christophe.lombart@gmail.com]
> Sent: Wednesday, September 12, 2007 8:46 PM
> To: users@jackrabbit.apache.org
> Subject: Re: [OCM] Binary values from byte[] field
> 
> Hi Hendrik,
> 
> I'm not 100 % sure that is related to a charset mismatch. This is not easy
> to find the solution right now.
> It seems that happens when you try open it after a second save right ?
> When
> you open it after the first save, is it working ?
> What do you mean by can't open it' ? Did you get an exception ?
> 
> 
> Anyway, we should give the possibility to use  this constructor  : public
> String(byte[] bytes, String charsetName)
> But I'm just wondering how is possible to get the charset from this code
> location (ByteArrayTypeConverterImpl).
> 
> 
> br
> Christophe
> 
> 
> On 9/12/07, Hendrik Beck (camunda) <hendrik.beck@camunda.com> wrote:
> > Hi!
> >
> > I am using JCR-OCM and have to store binaries in Jackrabbit. Therefore I
> > have a class BinaryDocument which has a property "byte[] data". The
> class
> is
> > being mapped to a node with node type "nt:resource" and the data
> property
> is
> > mapped to its field "jcr:property". Furthermore I have properties
> encoding,
> > lastModified and mimeType mapped to their counterparts in nt:resource.
> >
> > Ok, I am accessing Jackrabbit via RMI which is the reason why I used
> byte[]
> > as data type for the actual binary data. What I do in my client is
> reading
> a
> > file (let's say a PDF) into a byte array, put that byte array into my
> > BinaryDocument object, send it over RMI to my stateless session bean,
> which
> > then persists it via Jackrabbit-OCM.
> >
> > Now if I load this data again from my session bean and write it back
> into
> a
> > file I can't open it anymore. I assume there is some encoding / charset
> > mismatch somewhere on the way. As I only read and write byte arrays I
> > thought there's no operation in my client that actually changes the
> binary
> > stream in any way. Looking at the OCM sources I saw that
> > ByteArrayTypeConverterImpl creates the JCR value as follows:
> >
> >   String value = new String(byte[]) propValue);
> >   valueFactory.createValue(value);
> >
> > Is it possible that this operation is being done using the wrong charset
> for
> > my file?
> >
> > Well, that's just a wild guess, I could honestly be totally wrong. I
> would
> > be thankful for any pointers. Are there people doing the same, like
> storing
> > binaries with OCM using byte[] for the jcr:data? Am I missing something?
> >
> >
> > Thanks in advance
> > Hendrik
> >
> >
> >


Mime
View raw message