Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XWIKI-22481: Add the ability to use a LibreOffice binary from another server #3610

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

gdelhumeau
Copy link
Member

Jira URL

https://jira.xwiki.org/browse/XWIKI-22481

Changes

Description

I have introduced 2 new properties in xwiki.properties:

  • openoffice.host to set the hostname of the openoffice server (in case it not reachable at "localhost")
  • openoffice.workDir to set the folder where the files are exchanged, temporary, between XWiki and the openoffice server (same: useful in a kubernetes environment where we need to mount a common volume between the 2 containers).

Clarifications

I have not made commit on xwiki-platform for a while, so I prefer asking for a quick confirmation before merging. Thank you!

I have not built on the current master branch, but it built successfully against the 16.4.4 tag.

*/
default String getWorkDir()
{
return null;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not ideal, but I did not want to break the stable interface. The failover is implemented by the component that call getWorkDir().

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might want to use Optional<String> as the return value, see https://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/JavaCodeStyle/#HOptional

@surli surli self-assigned this Oct 30, 2024
@@ -350,6 +350,10 @@ rendering.transformations = $xwikiRenderingTransformations
#-# 1 - Externally managed (local) server instance.
# openoffice.serverType = 0

#-# [Since 16.10RC1]
#-# Hostname used for connecting to the openoffice server instance.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing the explanation about what is the default value if not specified.

@@ -371,6 +375,11 @@ rendering.transformations = $xwikiRenderingTransformations
#-# If no path is provided, a default value will be calculated based on the operating environment.
# openoffice.profilePath = /home/user/.openoffice.org/3

#-# [Since 16.10RC1]
#-# Path to a folder where XWiki could exchange temporary files with the openoffice server.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/could/will ?

@@ -137,6 +138,7 @@ public void initialize() throws OfficeServerException
ExternalOfficeManager.Builder externalProcessOfficeManager = ExternalOfficeManager.builder();
externalProcessOfficeManager.portNumbers(this.config.getServerPorts());
externalProcessOfficeManager.connectOnStart(true);
externalProcessOfficeManager.hostName(config.getServerHost());
Copy link
Member

@vmassol vmassol Oct 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we sure that 127.0.0.1 is the default? (vs localhost for example).

Another option is to set the a host only if not empty in the XWiki config.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gdelhumeau
Copy link
Member Author

Thank you for all your comments! It was definitively needed!

… server.

* Use Optional<String> instead of plain String in OfficeServerConfiguration#getWorkDir().
* Improve the comments in xwiki.properties.
@gdelhumeau
Copy link
Member Author

I have pushed my changes, thanks!

@vmassol
Copy link
Member

vmassol commented Oct 30, 2024

@gdelhumeau I don't think I've seen any update to the Admin UI at http://localhost:8080/xwiki/bin/admin/XWiki/XWikiPreferences?editor=globaladmin&section=XWiki.OfficeImporterAdmin

Isn't that required? For example to display the server host used.

Thanks

@vmassol
Copy link
Member

vmassol commented Oct 30, 2024

Also we already have this config:

#-# [Since 1.9M2]
#-# Type of the openoffice server instance used by officeimporter component.
#-# 0 - Internally managed server instance. (Default)
#-# 1 - Externally managed (local) server instance.
# openoffice.serverType = 0

I'm not sure how it interacts with your change. On one hand, a value of 1 is what you're doing since it's externally managed, but OTOH it's not a local server instance.

Does it mean that right now we can use your new config property AND keep openoffice.serverType = 0? Sounds weird, no?

Thx

@gdelhumeau
Copy link
Member Author

These changes only apply when openoffice.serverType = 1. I think I should mention it in the xwiki.properties file (and also mention that 1 doesn't imply it is local).

Actually we have a constant SERVER_TYPE_EXTERNAL_REMOTE (with the value 2). This is actually what I am doing.

… server.

* Handle the SERVER_TYPE_EXTERNAL_REMOTE use-case.
* Update OfficeImporterAdmin.
@gdelhumeau
Copy link
Member Author

I have updated the code and the documentation to handle SERVER_TYPE_EXTERNAL_REMOTE.
I suppose the proper implementation would not need to have a shared work directory, but it's already an improvement.

I have also updated the UI.
Capture d’écran 2024-10-30 à 19 04 12

@gdelhumeau
Copy link
Member Author

gdelhumeau commented Nov 12, 2024

@vmassol @surli Did you have the chance to take a look? Do you want a proper proposal on the forum? Maybe you were expecting a proper "remote" behavior where we wouldn't have to share any drive but I don't have the time to implement this and I think what I'm proposing is already an improvement (at least it fixes the problem I have with my Docker/Kubernetes use-case).

* Default host name of the office server instance.
* Coming from org.jodconverter.local.office.ExternalOfficeManager.DEFAULT_HOSTNAME
* @since 16.10.0RC1
* @since 16.4.5
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be 16.4.6 (as used below).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And that's also Unstable

&lt;dt&gt;&lt;label&gt;$escapetool.html($services.localization.render('xe.officeimporter.openoffice.workdir'))&lt;/label&gt;&lt;/dt&gt;
&lt;dd&gt;$escapetool.html($services.officemanager.config.workDir.get())&lt;/dd&gt;
#end
###
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if it's useful to always display that information. Looks a bit technical and more for debug purposes. Let's leave it like this for now but we may want to only display it for advanced users or when in debug mode (debug = true in the query string for example).

###
#if ($services.officemanager.config.serverType == 2)
&lt;dt&gt;
&lt;label&gt;$escapetool.html($services.localization.render('xe.officeimporter.openoffice.serverhost'))&lt;/label&gt;
Copy link
Member

@vmassol vmassol Nov 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm this is using old translation key format, I think we need to fix this. See https://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTranslationPropertyNaming

### Work directory
###
#if ($services.officemanager.config.workDir.isPresent())
&lt;dt&gt;&lt;label&gt;$escapetool.html($services.localization.render('xe.officeimporter.openoffice.workdir'))&lt;/label&gt;&lt;/dt&gt;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same comment re translation key format

@@ -348,8 +348,15 @@ rendering.transformations = $xwikiRenderingTransformations
#-# Type of the openoffice server instance used by officeimporter component.
#-# 0 - Internally managed server instance. (Default)
#-# 1 - Externally managed (local) server instance.
#-# 2 - Externally managed (remotely) server instance. (Since 16.10.0RC1, 16.4.6)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/remotely/remote

#-# [Since 16.4.6]
#-# Path to a folder where XWiki will exchange temporary files with the openoffice server.
#-# If no path is provided, the temporary folder set for XWiki will be used.
#-# If openoffice.serverType = 2, this folder should be a shared volume between the two servers.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should or must?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If openoffice.serverType = 2, this folder should be a shared volume between the two servers.

Hmmm I missed that @gdelhumeau if your plan is to have a shared volume, then why shouldn't you consider the LO as externally but locally installed (serverType=1)?

@vmassol
Copy link
Member

vmassol commented Nov 13, 2024

@vmassol @surli Did you have the chance to take a look? Do you want a proper proposal on the forum? Maybe you were expecting a proper "remote" behavior where we wouldn't have to share any drive but I don't have the time to implement this and I think what I'm proposing is already an improvement (at least it fixes the problem I have with my Docker/Kubernetes use-case).

Thanks @gdelhumeau . The PR looks good to me, just some small details I've commented about. @surli ok for you?

@vmassol vmassol self-assigned this Nov 13, 2024
@surli
Copy link
Member

surli commented Nov 13, 2024

@surli ok for you?

yes sounds good to me

@gdelhumeau
Copy link
Member Author

I'm holding up my changes until https://jira.xwiki.org/browse/XWIKI-22664 is fixed.

@surli
Copy link
Member

surli commented Nov 19, 2024

I'm holding up my changes until https://jira.xwiki.org/browse/XWIKI-22664 is fixed.

Honestly I'm not sure this one will be fixed soon, I'd rather merge your PR before it is since it's already quite good.

@gdelhumeau
Copy link
Member Author

Thank you (I need to fix the last things you have mentioned), but is it OK to publish in our documentation and in our release notes a new "feature" that we know is buggy?

@vmassol
Copy link
Member

vmassol commented Nov 20, 2024

but is it OK to publish in our documentation and in our release notes a new "feature" that we know is buggy?

@gdelhumeau I agree it's not the best :) And since you're the only one needing the feature (AFAIK), I don't think there's a hurry. BTW are you not hit by https://jira.xwiki.org/browse/XWIKI-22664 ?

Also, will you be able to spend time to fix https://jira.xwiki.org/browse/XWIKI-22664 ?

@surli
Copy link
Member

surli commented Nov 20, 2024

Thank you (I need to fix the last things you have mentioned), but is it OK to publish in our documentation and in our release notes a new "feature" that we know is buggy?

Your PR is about allowing to not use the default setting for the remote server. But the feature to be able to use LO with a remote server already exists with default settings, and the bug in XWIKI-22664 is already something impacting users. So for me the tickets can be handled separately without problem.

@vmassol
Copy link
Member

vmassol commented Nov 20, 2024

Your PR is about allowing to not use the default setting for the remote server. But the feature to be able to use LO with a remote server already exists with default settings, and the bug in XWIKI-22664 is already something impacting users. So for me the tickets can be handled separately without problem.

Ah I agree then, I thought that XWIKI-22664 was caused and happening because of XWIKI-22481 (this PR). Now XWIKI-22664 makes using a remote LO server almost useless (since images are common). I suspect that @gdelhumeau is affected by this too in his use case and that he won't be able to use the result of this PR until it's fixed. Is that the case @gdelhumeau ?

Thanks

@gdelhumeau
Copy link
Member Author

Yes, for my usage, I need this PR and XWIKI-22664. I'll see if I have time to handle the later. When using the debugger to understand the problem, I have noticed we use JODConverter differently depending on the configuration, and I don't think it's necessary (assuming we have a shared volume), so maybe I'll propose a patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants