Initializing with tables in dedicated directory fails in 4.1.0

[alexander233]

We have been using the 3.0.0 version for a few years and now tried moving to latest version 4.1.0. Our code no longer works because our tables are stored in a dedicated directory (not the jar file) which we simply pass to the Translator together with the table names during Translator instantiation.
But now library initialization fails because a default table resolver is created which tries to read resources from the jar file and then throws an exception ("directory does not exist").
As a temporary fix, we deactivated the creation of a new TableResolver in Louis.getLibrary():250 and uncommented the registration of the table resolver in Louis.getLibrary():312-316 (if (!tableResolverIsRegistered) { ... }
Then everything worked like a charm!

I agree that automatic table extraction from the associated jar file is very useful but it would be good to have some mechanism to avoid the problem for cases where tables are stored in the file system (which is more efficient for normal operation). One alternative might be to add a different table resolver which would be initialized to the directory or one might add a flag such as autoExtractTablesFromJar which is set to true by default but could be set to false in cases where the files are already in the file system.

[bertfrees]

Hi! Thanks for the report.

The reason I didn't face this issue before is probably because the way I use liblouis-java myself is always with a custom table resolver.

However it should work I think. The default table resolver first looks for tables inside the JAR, but if it can't find the table it should then fall back to the file system.

I'll double-check that it works and will then come back to you with an example.

[bertfrees]

Apparently there was a bug. Could you try the latest version from master?

[alexander233]

Thank you for the quick update. I still get an exception. The problem is caused by the initializer of the anonymous table resolver which calls Louis.listResources() in line 256 at a time when we have not yet defined any location of where the tables reside in the file system.
This results in an error "directory does not exist" which is thrown in Louis:469

[alexander233]

Maybe the anonymous TableResolver should not search for resources during initialization (which is expensive and may not be needed for standard translation use cases) but call listresources only when TableResolver receives the first request for a table resolution.

[bertfrees]

Maybe the anonymous TableResolver should not search for resources during initialization

Yes, that makes sense. This code is only needed for the discovery of tables (the Translation.find() method), not the resolving. So it would solve your problem, but that doesn't change the fact that there is something wrong with the code. Strange, because this has been tested on Windows.

[bertfrees]

This code is only needed for the discovery of tables, not the resolving.

Sorry, this is not correct. It is needed for resolving too, which means that as soon as you want to load a table, you would get the "directory does not exist" error.

[alexander233]

With our modifications (which just keeps the TableResolver at null and prevents calling listresources during initialization of the library), Translator works correctly, loads tables correctly from the list of tables which we supply in the constructor (for example Translator trans = new Translator("d:\projects\braille\assets\liblouis\unicode.dis,de-de-comp8.ctb");

de-de-comp8.ctb includes a reference to braille-patterns.cti which probably needs to be resolved but this does not seem to lead to a problem in our case with our TableResolver being null.

[bertfrees]

@alexander233 Would it be possible for you to try to debug this? We are using liblouis-java on Windows too, without a custom table resolver, but don't get your exception. So it's going to be hard for me to find the problem.

[bertfrees]

@alexander233 Does this have to do with #16 maybe?

[alexander233]

@bertfrees Sure, I will take a shot at debugging this issue. I don't think that #16 is the same issue but I will check it out...

[alexander233]

I have just forked the repository and compiled on Eclipse. On my machine the unit tests fail immediately in Louis:448. The code determines in Line 445 that my classes are in the target directory of my Eclipse Workspace ("D...\liblouis-java\bin", not in a jar file, and then appends "org/liblouis/resource-files/tables" to that directory (which is not part of the libloius-java repository and which I have not yet created). Predictably in Louis:448 the exception follows which finds that the hard-coded tables subdirectory does not exist. Of course, I could now create the directory in the specified path, and the code would work, but currently there is no way to tell Louis that the tables directory is somewhere else.

To replicate this behavior on your machine, just rename your tables subdirectory to something other than ../org/liblouis/resource-files/tables

Please let me know if you consider this to be part of the problem or if a specific directory path for the liblouis tables should be enforced.

[bertfrees]

I'm not sure I understand the problem. The tests are not supposed to be run with Eclipse. There is also an integration test to make sure it still works when packaged in a JAR. I would say this is the test that really matters. If you can make that one fail, there is really a problem.

Anyway, I have pushed some commits. I hope they fix your problem. The first commit includes your change from 9bf03aa and some additional changes. In the second commit I split the JAR into two versions, a standalone one, with the tables and binaries embedded, and one without tables and binaries (how it was before 4.0.0). I suggest you try both.