Problem converting document from rtf to pdf using jodconverter 3.0

[Naveen]

Hi All,

Yesturday I downloaded the new jod 3.0 from oo 3.0.My oo is running on
a different machine and I had to send an rtf to convert it pdf.Here is
what I'm doing.

First I am establishing connection to remote machine using the below
code

OfficeManager officeManager = new ManagedProcessOfficeManager
(OfficeUtils.getDefaultOfficeHome(), OfficeUtils.getDefaultProfileDir
(), "socket,host=172.18.14.21,port=8100");
officeManager.start();

//It says connected

After that I am getting the output format from documentformatregistry
like this

fficeDocumentConverter converter = new OfficeDocumentConverter
(officeManager);
DocumentFormatRegistry registry = new
DefaultDocumentFormatRegistry();
DocumentFormat outputFormat = registry.getFormatByExtension
("pdf");

Finally converting the file like this

converter.convert(new File(inputFilename), new File
(outputFilename),outputFormat);

officeManager.stop();


when I run the above code I get the following exception:

Jan 19, 2009 1:32:05 PM
net.sf.jodconverter.office.ManagedOfficeProcess recreateProfileDir
WARNING: profile dir 'D:\DOCUME~2\501636~1\LOCALS~1\Temp
\.jodconverter_socket_host-172.18.14.21_port-8100' already exists;
deleting
Jan 19, 2009 1:32:06 PM net.sf.jodconverter.office.OfficeProcess start
INFO: starting process with acceptString
'socket,host=172.18.14.21,port=8100' and profileDir 'D:
\DOCUME~2\501636~1\LOCALS~1\Temp
\.jodconverter_socket_host-172.18.14.21_port-8100'
Jan 19, 2009 1:32:06 PM net.sf.jodconverter.office.OfficeProcess start
INFO: started process; pid -1
Jan 19, 2009 1:32:12 PM net.sf.jodconverter.office.OfficeConnection
connect
INFO: connected: 'socket,host=172.18.14.21,port=8100'
Connection Established --->Mon Jan 19 13:32:12 EST 2009
Exception in thread "main" net.sf.jodconverter.office.OfficeException:
could not complete task
at net.sf.jodconverter.office.ManagedProcessOfficeManager.execute
(ManagedProcessOfficeManager.java:128)
at net.sf.jodconverter.OfficeDocumentConverter.convert
(OfficeDocumentConverter.java:71)
at OOoStreamConverter.main(OOoStreamConverter.java:80)
Caused by: java.util.concurrent.ExecutionException:
java.lang.NullPointerException
at java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source)
at java.util.concurrent.FutureTask.get(Unknown Source)
at net.sf.jodconverter.office.ManagedProcessOfficeManager.execute
(ManagedProcessOfficeManager.java:123)
... 2 more
Caused by: java.lang.NullPointerException
at net.sf.jodconverter.AbstractConversionTask.execute
(AbstractConversionTask.java:71)
at net.sf.jodconverter.office.ManagedProcessOfficeManager$2.run
(ManagedProcessOfficeManager.java:118)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown
Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)



In my application the usage of JODConverter as a webservice is not
possible is there a way I can achieve the document convertion using
remote openoffice using JODConverter ?

Please let me know.

[Mirko Nasato]

Hi Naveen,

Connecting to an OOo process running on a different machine is just
not supported, sorry.

The main new feature in JODConverter 3.0 is that
ManagedProcessOfficeManager starts and manages its own OOo process.
This obviously can't work if OOo is on another machine.

JODConverter 2.x had a StreamOpenOfficeDocumentConverter that could be
used for connecting to a remote OOo instance, but it had several
limitations and problems so I have decided to drop it altogether in
3.0. The web service approach is by far a better choice.

Cheers

Mirko


2009/1/19 Naveen <naveen...@gmail.com>:

[Naveen]

Hi Mirko,

Thanks for the information.I was just curious why the
loadcomponentfromurl method is very slow when we use streams for
specific formats like rtf.I did a search in openoffice wiki pages but
I didn't get any solution.Could you please explain why that method had
performance problems with streams ?

Thanks,

Naveen

On Jan 19, 4:14 pm, Mirko Nasato <mirko.nas...@gmail.com> wrote:
> Hi Naveen,
>
> Connecting to an OOo process running on a different machine is just
> not supported, sorry.
>
> The main new feature in JODConverter 3.0 is that
> ManagedProcessOfficeManager starts and manages its own OOo process.
> This obviously can't work if OOo is on another machine.
>
> JODConverter 2.x had a StreamOpenOfficeDocumentConverter that could be
> used for connecting to a remote OOo instance, but it had several
> limitations and problems so I have decided to drop it altogether in
> 3.0. The web service approach is by far a better choice.
>
> Cheers
>
> Mirko
>

> 2009/1/19 Naveen <naveen.kon...@gmail.com>:

[Mirko Nasato]

Hi Naveen,

2009/1/20 Naveen <naveen...@gmail.com>:

>
> Thanks for the information.I was just curious why the
> loadcomponentfromurl method is very slow when we use streams for
> specific formats like rtf.I did a search in openoffice wiki pages but
> I didn't get any solution.Could you please explain why that method had
> performance problems with streams ?
>

I don't know for sure (not much OOo documentation), but I can give you
my guess. When you pass a stream to OOo for loading, it needs to
implement the XSeekable interface. This is a bit like RandomAccessFile
in Java, in the sense that it can be read at various positions, not
just consumed serially from start to end. I think OOo needs this to do
some sort of binary file type detection. I guess this type detection
may be more complex for some type of documents than others.

Additionally, if you're talking about JODConverter 2.x, to be able to
stream a file implementing XSeekable, the entire file is read into
memory before being sent to OOo. So the bigger the file and the slower
this operations is.

Compare this to the normal way of passing files to OOo, which is to
just pass the file path as a string to OOo and let it actually read
the file, and you should have a better idea of why I have decided to
drop stream-based conversions.

Cheers

Mirko