[
https://issues.apache.org/jira/browse/OPENMEETINGS-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
JiraUser updated OPENMEETINGS-831:
----------------------------------
Description:
The method for finding the jodconverter path fails on (at least) EXT4
filesystems due to the way ext4 maps and traverses the tree- openmeetings
cannot convert using jodconverter.
The fix is simple, please consider including this update in a binary release.
The code relates to GeneratePDF.java, line XX:
if (jar.startsWith("jodconverter")) {
To accomodate the ext4 filesystem, this should read:
if (jar.startsWith("jodconverter-cli")) {
On every successful openmeetings server (quite a few now, including RMTPS and
OOo conversion :D thanks for all your time and amazing work!), the jodconverter
command run executes the jodconverter-cli-2.2.2.jar file. On one machine, it
attempts to execute the jodconverter-2.2.2.jar file. This seems to be because
the method .list() in the loop:
for (String jar : jodFolder.list(new FilenameFilter() {
...
}
}))
seems to traverse the directory structure the same as ' find . ' or 'ls -U' in
that folder.
This means that the last file in the array which matches the condition is
jodconverter-2.2.2.jar (as the ext4 filesystem hash map/algorithm organises the
file logically in the same place), not the jodconverter-cli-2.2.2.jar which
seems to be needed.
Running the command with the -jar jodconverter-cli-2.2.2.jar instead of the
-jar jodconverter-cli-2.2.2.jar on the machine works perfectly- the file is
converted and the expected output is seen.
To see the effect, consider the following two scenarios:
EXT3:
root@host1:~/stan# touch right
root@host1:~/stan# touch left
root@host1:~/stan# touch ever
root@host1:~/stan# touch tonight
root@host1:~/stan# find .
.
./right
./left
./ever
./tonight
root@host1:~/stan# find --version
find (GNU findutils) 4.4.2
EXT4
root@host2:~/stan# touch right
root@host2:~/stan# touch left
root@host2:~/stan# touch ever
root@host2:~/stan# touch tonight
root@host2:~/stan# find .
.
./left
./tonight
./ever
./right
root@host2:~/stan# find --version
find (GNU findutils) 4.4.2
root@host2:~/stan# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
root@host1:~/stan# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Thanks again for all your time and work- is it possible to download a copy of
OpenMeetings 3
was:
The method for finding the jodconverter path fails on (at least) EXT4
filesystems due to the way ext4 maps and traverses the tree- openmeetings
cannot convert using jodconverter.
The fix is simple, please consider including this update in a binary release.
The code relates to GeneratePDF.java, line XX:
if (jar.startsWith("jodconverter")) {
To accomodate the ext4 filesystem, this should read:
if (jar.startsWith("jodconverter-cli")) {
On every successful openmeetings server (quite a few now, including RMTPS and
OOo conversion :D thanks for all your time and amazing work!), the jodconverter
command run executes the jodconverter-cli-2.2.2.jar file. On one machine, it
attempts to execute the jodconverter-2.2.2.jar file. This seems to be because
the loop,
for (String jar : jodFolder.list(new FilenameFilter() {
public boolean accept(File file1, String name) {
return name.endsWith(".jar");
}
}))
seems to traverse the directory structure the same as ' find . ' or 'ls -U' in
that folder.
This means that the last file in the array which matches the condition is
jodconverter-2.2.2.jar (as the ext4 filesystem hash map/algorithm organises the
file logically in the same place), not the jodconverter-cli-2.2.2.jar which
seems to be needed.
Running the command with the -jar jodconverter-cli-2.2.2.jar instead of the
-jar jodconverter-cli-2.2.2.jar on the machine works perfectly- the file is
converted and the expected output is seen.
To see the effect, consider the following two scenarios:
EXT3:
root@host1:~/stan# touch right
root@host1:~/stan# touch left
root@host1:~/stan# touch ever
root@host1:~/stan# touch tonight
root@host1:~/stan# find .
.
./right
./left
./ever
./tonight
root@host1:~/stan# find --version
find (GNU findutils) 4.4.2
root@host2:~/stan# touch right
root@host2:~/stan# touch left
root@host2:~/stan# touch ever
root@host2:~/stan# touch tonight
root@host2:~/stan# find .
.
./left
./tonight
./ever
./right
root@host2:~/stan# find --version
find (GNU findutils) 4.4.2
root@host2:~/stan# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
root@host1:~/stan# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Thanks again for all your time and work- is it possible to download a copy of
OpenMeetings 3
> GeneratePDF.java - ext4 - fails to locate precise jodconverter path
> --------------------------------------------------------------------
>
> Key: OPENMEETINGS-831
> URL: https://issues.apache.org/jira/browse/OPENMEETINGS-831
> Project: Openmeetings
> Issue Type: Improvement
> Environment: EXT4 Filesystems
> Reporter: JiraUser
> Labels: patch, performance
>
> The method for finding the jodconverter path fails on (at least) EXT4
> filesystems due to the way ext4 maps and traverses the tree- openmeetings
> cannot convert using jodconverter.
> The fix is simple, please consider including this update in a binary release.
> The code relates to GeneratePDF.java, line XX:
> if (jar.startsWith("jodconverter")) {
> To accomodate the ext4 filesystem, this should read:
> if (jar.startsWith("jodconverter-cli")) {
> On every successful openmeetings server (quite a few now, including RMTPS and
> OOo conversion :D thanks for all your time and amazing work!), the
> jodconverter command run executes the jodconverter-cli-2.2.2.jar file. On one
> machine, it attempts to execute the jodconverter-2.2.2.jar file. This seems
> to be because the method .list() in the loop:
> for (String jar : jodFolder.list(new FilenameFilter() {
> ...
> }
> }))
> seems to traverse the directory structure the same as ' find . ' or 'ls -U'
> in that folder.
> This means that the last file in the array which matches the condition is
> jodconverter-2.2.2.jar (as the ext4 filesystem hash map/algorithm organises
> the file logically in the same place), not the jodconverter-cli-2.2.2.jar
> which seems to be needed.
> Running the command with the -jar jodconverter-cli-2.2.2.jar instead of the
> -jar jodconverter-cli-2.2.2.jar on the machine works perfectly- the file is
> converted and the expected output is seen.
> To see the effect, consider the following two scenarios:
> EXT3:
> root@host1:~/stan# touch right
> root@host1:~/stan# touch left
> root@host1:~/stan# touch ever
> root@host1:~/stan# touch tonight
> root@host1:~/stan# find .
> .
> ./right
> ./left
> ./ever
> ./tonight
> root@host1:~/stan# find --version
> find (GNU findutils) 4.4.2
> EXT4
> root@host2:~/stan# touch right
> root@host2:~/stan# touch left
> root@host2:~/stan# touch ever
> root@host2:~/stan# touch tonight
> root@host2:~/stan# find .
> .
> ./left
> ./tonight
> ./ever
> ./right
> root@host2:~/stan# find --version
> find (GNU findutils) 4.4.2
> root@host2:~/stan# lscpu
> Architecture: x86_64
> CPU op-mode(s): 32-bit, 64-bit
> Byte Order: Little Endian
> root@host1:~/stan# lscpu
> Architecture: x86_64
> CPU op-mode(s): 32-bit, 64-bit
> Byte Order: Little Endian
> Thanks again for all your time and work- is it possible to download a copy of
> OpenMeetings 3
--
This message was sent by Atlassian JIRA
(v6.1#6144)
