[ARIES-2087] SPI-FLY Handling try-with-resource if a super class is not imported by Felix bundle

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: SPI Fly
• Assignee: Unassigned
• Reporter: Simon Miles
• Created: 20/Oct/22 17:52
• Updated: 29/Feb/24 14:50

Description

I came across this issue in our environment where we are using Spi-Fly dynamic weaving to help with GraalVM Javascript integration.

I am getting a problem during bundle loading which I've narrowed down to the weaving code handling the following statement block

YAMLFactory yamlFactory;

try (YAMLParser yp = yamlFactory.createParser(input); )

{

}
catch (JsonProcessingException jpEx)

{

}

It seems to need processing to check that the two classes YAMLParser and JsonProcessingException have a common super class using org.apache.aries.spifly.dynamic.OSGiFriendlyClassWriter - getCommonSuperClass. But the check doesn't not find such a class.

The catch I think is whilst the package of the base class (com.fasterxml.jackson.dataformat.yaml.YAMLParser) is on the list of packages on the bundle Import-Package statement. The package of super class (com.fasterxml.jackson.core.base.ParserBase) is not and so the Apache Felix bundle classloading isn't finding it when the getCommonSuperClass is trying to get it. If I add a reference to the super class into the code sample then the exception isn't thrown because our build is then automatically adding the import for the super class package.

The other work-around is not to use the try-with-resource but use a try-finally block which doesn't seem to need the super class processing.

Apologies if I haven't managed to describe things clearly or mis-interpreted what's happening. My knowledge in this area isn't that extensive.