[BUG] document.getAttachmentNames() results in IllegalArgumentException

[PaulThorne]

HCL Product Version Notes 12.0.2 talking to data on a 12.0.2 Domino server JNX-api, JNX-commons and JNX-jna are all version 1.36.0 Java version 17 (using Microsoft compiled OpenJDK)

Describe the bug When calling document.getAttachmentNames() it results in an IllegalArgumentException. The document in question has one attachment, attached into a richtext field, which operates perfectly within Notes. No other calls related to gathering field data have failed (i.e the document object is valid). Note that we are using the autoclosable version of the document.

This is using JNX inside a Karaf OSGi server. The acting thread is initialised for Notes. If OSGi class loading was an issue I would have thought it would have shown itself prior to this.

Error Message java.lang.IllegalArgumentException: com.hcl.domino.richtext.structures.ObjectDescriptor referenced from a method is not visible from class loader at java.base/java.lang.reflect.Proxy$ProxyBuilder.ensureVisible(Proxy.java:883) at java.base/java.lang.reflect.Proxy$ProxyBuilder.validateProxyInterfaces(Proxy.java:721) at java.base/java.lang.reflect.Proxy$ProxyBuilder.(Proxy.java:648) at java.base/java.lang.reflect.Proxy$ProxyBuilder.(Proxy.java:656) at java.base/java.lang.reflect.Proxy.lambda$getProxyConstructor$0(Proxy.java:429) at java.base/jdk.internal.loader.AbstractClassLoaderValue$Memoizer.get(AbstractClassLoaderValue.java:329) at java.base/jdk.internal.loader.AbstractClassLoaderValue.computeIfAbsent(AbstractClassLoaderValue.java:205) at java.base/java.lang.reflect.Proxy.getProxyConstructor(Proxy.java:427) at java.base/java.lang.reflect.Proxy.newProxyInstance(Proxy.java:1037) at com.hcl.domino.commons.structures.MemoryStructureUtil.forStructure(MemoryStructureUtil.java:262) at com.hcl.domino.commons.structures.MemoryStructureUtil.forStructure(MemoryStructureUtil.java:266) at com.hcl.domino.jna.internal.JNAMemoryUtils.readStructure(JNAMemoryUtils.java:90) at com.hcl.domino.jna.data.JNADocument.getItemValue(JNADocument.java:467) at com.hcl.domino.jna.data.JNADocument.getItemValue(JNADocument.java:350) at com.hcl.domino.jna.data.JNAItem.getValue(JNAItem.java:229) at com.hcl.domino.jna.data.JNADocument$4.itemFound(JNADocument.java:1075) at com.hcl.domino.jna.data.JNADocument.getItems(JNADocument.java:991) at com.hcl.domino.jna.data.JNADocument.forEachAttachment(JNADocument.java:1067)

[jesse-gallagher]

Hmm, that's certainly odd. I'll admit that I've never used Karaf, and all of my OSGi experience is confined to Domino's Equinox environment specifically. I wonder if the trouble is to do with the fact that the JNA implementation is a fragment of the API bundle, while MemoryStructureUtil sits in another non-fragment bundle that JNA depends on. On paper (and when I've worked in Domino), I'd think that would work fine, but maybe something breaks down here.

As a workaround, would it be possible to embed the JNX dependency tree inside your app bundle rather than including them as separate bundles on their own? That would remove the intricacies of OSGi as a factor in JNX's internal workings.

[jesse-gallagher]

Huh, well, "good news": working with JNX in a project where I happened to do exactly my suggestion just now, I see the same problem. So... my suggestion won't fix it, but I have a reproduction case.

[jesse-gallagher]

This should be fixed in 1.39.0, which I finalized just now.

[PaulThorne]

Thanks Jesse. I'll report back when I get a chance to test it. Apart from the above it works really well in an external OSGi container. Ultimately, we found the domino http container was missing too much of what we needed and unlike yourself and the amazing work you have done to implement the missing bits, we lacked to skill to make up for it ourselves.