Spring OSGI service reference interfaces must be explicitly imported by using the package.

I get acquainted with Spring OSGI and Blueprint, but I have difficulties with the "classpath" (for example, many newbies).

I have two OSGI packages - one that defines different beans (using Blueprint, not what it matters) and exports them as services; and another bundle that references the beans service (using Spring OSGI) and connects them to some Apache Camel routes.

The service-provider blueprint component looks something like this:

<service id="camelTsvDataFormat" interface="org.apache.camel.spi.DataFormat"> <bean class="org.apache.camel.component.flatpack.FlatpackDataFormat"/> </service> 

The Spring context of the consumer service package looks something like this:

 <osgi:reference id="tsvDataFormat" interface="org.apache.camel.spi.DataFormat" /> <camel:camelContext> <route> <from uri="vm:in"> <setBody> <constant>SELECT * FROM myTable</constant> </setBody> <to uri="jdbc:myDataSource" /> <marshal ref="tsvDataFormat" /> <to uri="file:/path/to/my/files/?fileName=out.tsv" /> </route> </camel:camelContext> 

... But after deploying Spring, "Unable to find class [org.apache.camel.spi.DataFormat]". I can add the interface to the Import Package section of my Bnd instructions, but it seems like I’ll have to manually list the class twice in different places once again.

An alternative choice is to extend the interface in my own project, so Bnd will automatically pick it up, but this is about the same amount of problems.

I assume that I expect Spring to look for services by interface name without actually resolving the interface class. Is it na & iuml; ve? Or is there a way for Bnd to automatically import interfaces into my appContext service links? If Bnd can do this (using plugins for example), is there a standard way to use Bnd plugins with the Apache Felix plugin for Maven?

+4
source share
2 answers

As Holly says, bnd will usually find this package referenced by any bytecode inside your package that calls it. It should also parse Spring -DM XML files if they are in the right place. However, I do not know if it supports Blueprint XML files in the same way, because they are not in the same place. Therefore, you may need to upgrade the bnd version or use a plugin that supports Blueprint.

Nevertheless, I am suspicious of all this. If there are no links to the interface for bytecode, then you don’t even use the link to the service? In this case, why not just delete it?

+3
source

As @Neil Bartlett points out, Bnd should introspectively view Spring and Blueprint files in the standard bundled location ( META-INF/spring and OSGI-INF/blueprint ). I manually redefined them as META-INF/spring/*.xml and OSGI-INF/blueprint/*.xml in my POM. I thought this was normal since the Spring and Blueprint extensions on my OSGI platform took the headers and loaded the appropriate containers. Bnd, however, seems to expect a simpler header without globs (see SpringXMLType.java ). I'm not going to blame it because it's a terrific tool, but this one caught me.

In any case, since my Spring and Blueprint bookmarks are already in the standard location, I just removed the redundant Bnd commands from my POM, and all the Spring -DM service help interfaces were automatically compiled and Import-Package Package'd in my package:

 <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <version>2.3.6</version> <extensions>true</extensions> <configuration> <instructions> <Bundle-Version>${project.version}.${buildNumber}</Bundle-Version> <Bundle-Activator>com.example.BundleActivator</Bundle-Activator> <!-- <Spring-Context>META-INF/spring/*.xml</Spring-Context> <Bundle-Blueprint>OSGI-INF/blueprint*.xml</Bundle-Blueprint> --> </instructions> </configuration> </plugin> 
+1
source

Source: https://habr.com/ru/post/1392787/


All Articles