[ https://issues.apache.org/jira/browse/ARIES-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Miles updated ARIES-2087: ------------------------------- 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 {color:#000000}YAMLFactory {color}{color:#871094}yamlFactory{color}; {{{color:#0033b3}try {color}({color:#000000}YAMLParser yp {color}= {color:#871094}yamlFactory{color}.createParser(input); )}} { {{}}} {{{color:#0033b3}catch {color}({color:#000000}JsonProcessingException {color}jpEx)}} { {{}}} It seems to need processing to check that the two classes YAMLParser and JsonProcessingException have a common super class using {color:#000000}org.apache.aries.spifly.dynamic.{color}OSGiFriendlyClassWriter - getCommonSuperClass. But the check doesn't not find such a class. {color:#172b4d}The catch I think is whilst the package of the base class{color}{color:#172b4d} (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.{color} 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. was: 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 {color:#000000}YAMLFactory {color}{color:#871094}yamlFactory{color}; {{{color:#0033b3}try {color}({color:#000000}YAMLParser yp {color}= {color:#871094}yamlFactory{color}.createParser(input) ;}} { {{}}} {{{color:#0033b3}catch {color}({color:#000000}JsonProcessingException {color}jpEx)}} { {{}}} It seems to need processing to check that the two classes YAMLParser and JsonProcessingException have a common super class using {color:#000000}org.apache.aries.spifly.dynamic.{color}OSGiFriendlyClassWriter - getCommonSuperClass. But the check doesn't not find such a class. {color:#172b4d}The catch I think is whilst the package of the base class{color}{color:#172b4d} (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.{color} 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. > SPI-FLY Handling try-with-resource if a super class is not imported by Felix > bundle > ----------------------------------------------------------------------------------- > > Key: ARIES-2087 > URL: https://issues.apache.org/jira/browse/ARIES-2087 > Project: Aries > Issue Type: Bug > Components: SPI Fly > Reporter: Simon Miles > Priority: Major > > 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 > {color:#000000}YAMLFactory {color}{color:#871094}yamlFactory{color}; > {{{color:#0033b3}try {color}({color:#000000}YAMLParser yp {color}= > {color:#871094}yamlFactory{color}.createParser(input); )}} > { > {{}}} > {{{color:#0033b3}catch {color}({color:#000000}JsonProcessingException > {color}jpEx)}} > { > {{}}} > It seems to need processing to check that the two classes YAMLParser and > JsonProcessingException have a common super class using > {color:#000000}org.apache.aries.spifly.dynamic.{color}OSGiFriendlyClassWriter > - getCommonSuperClass. But the check doesn't not find such a class. > {color:#172b4d}The catch I think is whilst the package of the base > class{color}{color:#172b4d} > (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.{color} > 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. > -- This message was sent by Atlassian Jira (v8.20.10#820010)