[xwiki-devs] [Discussion] Officeimporter remote OpenOffice server
Hi Devs, Currently OfficeImporter requires an OpenOffice server to be present in the same computer as XE. I have been searching about adding support for a remote OpenOffice server but the results are not very promising: http://groups.google.com/group/jodconverter/browse_thread/thread/f4f0e8328d4... Even though this is the case, I think we can settle on a compromise with the following approach: * We develop a stand-alone servlet (probably under xwiki-tools just like the root-web-app) * The purpose of this servlet is to: 1. Accept incoming office documents 2. Convert them into html (results in multiple files) 3. Zip the results together 4. Stream the zipped content back to the client * And the client would be any xwiki instance that is configured to consume this converter-servlet. This way, multiple XWiki instances would be able to share a central OpenOffice server via the converter-servlet. The downside of this approach is that there has to be a servlet container on the remote computer which is hosting the OpenOffice server. Please let me know what you think about this idea. Thanks. - Asiri
Asiri Rathnayake <[email protected]> writes:
Hi Devs,
Currently OfficeImporter requires an OpenOffice server to be present in the same computer as XE. I have been searching about adding support for a remote OpenOffice server but the results are not very promising:
http://groups.google.com/group/jodconverter/browse_thread/thread/f4f0e8328d4...
Even though this is the case, I think we can settle on a compromise with the following approach:
* We develop a stand-alone servlet (probably under xwiki-tools just like the root-web-app) * The purpose of this servlet is to:
1. Accept incoming office documents 2. Convert them into html (results in multiple files) 3. Zip the results together 4. Stream the zipped content back to the client
* And the client would be any xwiki instance that is configured to consume this converter-servlet.
This way, multiple XWiki instances would be able to share a central OpenOffice server via the converter-servlet. The downside of this approach is that there has to be a servlet container on the remote computer which is hosting the OpenOffice server.
Please let me know what you think about this idea.
Thanks.
- Asiri
Hi Asiri, I think the big problem is not to share an OpenOffice server between clients (This will be great, but I don't think it's the most urgent) IMO, the real problem we have is a security problem: By having XWiki starting external applications you can't have your tomcat chrooted nor running on a noexec partition for example. I think the most urgent is to permit to give an IP and port to the plugin rather than a directory to the OOo executables. Having another servlet container is ok for me, but we should anyway permit to give a IP and port in the XWiki conf for an OOo server. Best regards, -- Raffaello Pelagalli
Hi Raff, I think the big problem is not to share an OpenOffice server between
clients (This will be great, but I don't think it's the most urgent)
IMO, the real problem we have is a security problem: By having XWiki starting external applications you can't have your tomcat chrooted nor running on a noexec partition for example.
With XE 1.8.4 you can configure XE to use a separate OOo server process (i.e not allow XE to manage the OOo server). But still, that server process needs to be running on the same host as XE. I think the most urgent is to permit to give an IP and port to the
plugin rather than a directory to the OOo executables.
Having another servlet container is ok for me, but we should anyway permit to give a IP and port in the XWiki conf for an OOo server.
How about simply giving the path to the remote servlet? be it local or remote. This way converter-servlet (and the associated openoffice server) can be launched and managed independantly from the XE instance. Won't this solve the security problem you mentioned? Thanks. - Asiri
participants (2)
-
Asiri Rathnayake -
Raffaello Pelagalli