Unreliable with custom ClassLoaders

[jernst]

I apologize that this is not a very actionable issue, but intended more as a placeholder for others who may come across the same thing.

I'm running jnr-fuse with the diet4j module framework, which, more or less, uses a different ClassLoader for each jar file. Other than that, it doesn't do anything that's relevant here, and so I suspect others with special ClassLoaders also may run into this:

jnr-fuse sort of works, but not reliably. For example, I just copy-pasted the MemoryFS example code into my project, and mounted that instead of my file system implementation, and here's the result:

• ls -al on all directories always returns "total 0" (not even . or ..). From the debugger, it appears the code is not even invoked although the FUSE debug console output says that LOOKUP, OPENDIR, READDIR and RELEASEDIR were invoked.
• ls -al on a file works
• echo hi > hi works and cat hi works
• the pre-configured files also can be read and written.

In my own code, the behavior is similar in that some of my overridden methods simply do not get invoked. Others are. What the difference might be methods that do get invoked and those that aren't I have no idea. Also, sometimes code is invoked, and data is returned, but the data never makes it back to the file system client. E.g. cat somefile causes the file content to be sent back from my code, but nothing prints to the console.

P.S. If there is a good way of debugging this, I'd very willing to try, but I very quickly seem to end up in part of the call stack that the debugger gets very confused by.

[SerCeMan]

Hey, @jernst! Do you experience these problems only when jnr-fuse running under diet4j?

[jernst]

Hey, @SerCeMan! Yes!

[SerCeMan]

Is it possible that there is some dependency conflict? I believe that it's unlikely that diet4j uses jnr, but can you try to reproduce the same with the shaded version (classifier all, see https://bintray.com/serce/maven/jnr-fuse#files/com%2Fgithub%2Fserceman%2Fjnr-fuse%2F0.5.1 )

[jernst]

You mean that I have two copies of jnr around? If so, I don't think so.

(Pressed for time now to implement a workaround for my project, may come back to this later. Thanks for the prompt response.)