Re: Apace aries spifly reports "No common superclass" on two unrelated classes

2023-08-14 Thread Steinar Bang 
> Steinar Bang :

> When I pull in Apache Aries spifly on one of my bundles I get a weird
> error in karaf.log:
>  java.lang.RuntimeException: No Common 
> Superclass:no/priv/bang/oldalbum/services/bean/AlbumEntry java/sql/ResultSet

> Here's the error:
>  
> https://gist.github.com/steinarb/4fc4b86c49cbdb151d8b9e626366ff07#file-karaf-log-L790

> There is nothing in my code that tries to unify AlbumEntry or ResultSet.

> But there is a method that unpacks a row in a ResultSet into an albumentry:
>  
> https://github.com/steinarb/oldalbum/blob/master/oldalbum.backend/src/main/java/no/priv/bang/oldalbum/backend/OldAlbumServiceProvider.java#L819

> Is that method the cause of the misunderstanding?

> Is there a way to tell spifly not to look at any classes in my bundle?

> If not, is there a way to make spifly disregard these particular
> classes? 

> What I'm trying to do is to load SPI plugins from other bundles
> (TwelveMonkeys image IO plugins) so that they become available to my
> bundle's code.

>From the stack trace it looks like I'm using dynamic weaving?
 https://aries.apache.org/documentation/modules/spi-fly.html

Is dynamic weaving something I need or want if I want to have SPI
classes work in an OSGi context?

Note that I'm already using Apache Aries SPI Fly to make Liquibase work,
so I'm bound by whatever Liquibase requires.

Re: Apace aries spifly reports "No common superclass" on two unrelated classes

2023-08-14 Thread Steinar Bang 
I opened a Jira on Apache Aries spi fly for this:
 https://issues.apache.org/jira/browse/ARIES-2110

Re: Apace aries spifly reports "No common superclass" on two unrelated classes

2023-08-15 Thread Steinar Bang 
> Steinar Bang :

> I opened a Jira on Apache Aries spi fly for this:
>  https://issues.apache.org/jira/browse/ARIES-2110

Though I myself is probably to blame for the use of the Dynamic Weaving
Bundle.

Before I load anything in karaf, it has the following Aries bundles:
karaf@root()> bundle:list -t 10 | grep -i aries
23 │ Active │  30 │ 1.1.5   │ Apache Aries JMX API
24 │ Active │  30 │ 1.1.8   │ Apache Aries JMX Core
25 │ Active │  30 │ 1.2.0   │ Apache Aries Whiteboard support for JMX 
DynamicMBean services
26 │ Active │  20 │ 1.1.3   │ Apache Aries Util
karaf@root()>

Then I load my application:
karaf@root()> feature:repo-add 
mvn:no.priv.bang.oldalbum/karaf/LATEST/xml/features
Adding feature url mvn:no.priv.bang.oldalbum/karaf/LATEST/xml/features
karaf@root()> feature:install oldalbum-with-derby
karaf@root()>

And after that, the following Aries bundles are loaded

karaf@root()> bundle:list -t 10 | grep -i aries
 23 │ Active   │  30 │ 1.1.5 │ Apache Aries JMX API
 24 │ Active   │  30 │ 1.1.8 │ Apache Aries JMX Core
 25 │ Active   │  30 │ 1.2.0 │ Apache Aries Whiteboard support 
for JMX DynamicMBean services
 26 │ Active   │  20 │ 1.1.3 │ Apache Aries Util
109 │ Active   │  20 │ 1.1.13│ Apache Aries Proxy Service
110 │ Active   │  40 │ 1.3.4 │ Apache Aries SPI Fly Dynamic 
Weaving Bundle
karaf@root()>

And bundle 109 and 110 are caused by my liquibase karaf feature:
 
https://github.com/steinarb/liquibase-karaf-feature/blob/master/liquibase-core-karaf/src/main/feature/feature.xml#L17

Whether the dynamic weaving bundle is necessary for the liquibase
feature, or if it can use the static SPI Fly bundle, I have no idea.

But I can try, I guess...?

(I still don't know what dynamic weaving does, why dynamic weaving is
connected to the service loader, and even less why the dynamic weaving
code insists that my bean AlbumEntry and the JDBC ResultSet should have
a common ancestor...)