[
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}o{color:#172b4d}rg.apache.aries.spifly.dynamic.{color}{color}{color:#172b4d}OSGiFriendlyClassWriter
- getCommonSuperClass. But the check doesn't not find such a class. {color}
{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)
