Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OSGi duplicate package export: sdk-core vs. sdk-server #59

Closed
JulianSchuette opened this issue Oct 11, 2016 · 10 comments
Closed

OSGi duplicate package export: sdk-core vs. sdk-server #59

JulianSchuette opened this issue Oct 11, 2016 · 10 comments

Comments

@JulianSchuette
Copy link

Hello!

Both bundles sdk-server and sdk-core have
Export-Package: ... org.eclipse.milo.opcua.sdk.core, ...
in their OSGi headers, which leads to the following error when starting sdk-server in Karaf/Felix:

Error executing command: Error executing command on bundles:
    Error starting bundle 253: Uses constraint violation. Unable to resolve resource org.eclipse.milo.sdk-server [org.eclipse.milo.sdk-server [253](R 253.0)] because it exports package 'org.eclipse.milo.opcua.sdk.core' and is also exposed to it from resource org.eclipse.milo.sdk-core [org.eclipse.milo.sdk-core [278](R 278.0)] via the following dependency chain:

  org.eclipse.milo.sdk-server [org.eclipse.milo.sdk-server [253](R 253.0)]
    import: (&(osgi.wiring.package=org.eclipse.milo.opcua.sdk.core.model)(version>=0.1.0)(!(version>=1.0.0)))
     |
    export: osgi.wiring.package: org.eclipse.milo.opcua.sdk.core.model; uses:=org.eclipse.milo.opcua.sdk.core
    export: osgi.wiring.package=org.eclipse.milo.opcua.sdk.core
  org.eclipse.milo.sdk-core [org.eclipse.milo.sdk-core [278](R 278.0)] Unresolved requirements: [[org.eclipse.milo.sdk-server [253](R 253.0)] osgi.wiring.package; (&(osgi.wiring.package=org.eclipse.milo.opcua.sdk.core.model)(version>=0.1.0)(!(version>=1.0.0)))]

Looks like either that package import should be removed from sdk-server or sdk-server should be declared as a fragment bundle of sdk-core?

@kevinherron
Copy link
Contributor

I don't know enough about OSGi to know what the correct fix is. Can you try removing it from the sdk-server project and see if everything still works for you?

@ctron
Copy link
Contributor

ctron commented Oct 11, 2016

I also just looked a bit into it. It seems that milo does also import "sun.misc", although that seems never to be used? Or did I just miss it?

@kevinherron
Copy link
Contributor

I don't see "sun.misc" used anywhere either. I suspect it was once used for something like generating certificates, but I don't see it appearing anywhere now...

@ctron
Copy link
Contributor

ctron commented Oct 11, 2016

Ok ... there also is sun.nio.ch .. which seems to be unused.

But I do spot a reference to sun.security .. maybe have a look.

The other two could be removed?!

@ctron
Copy link
Contributor

ctron commented Oct 11, 2016

I made a PR #60 for the two packages.

kevinherron pushed a commit that referenced this issue Oct 13, 2016
- Remove "sun.misc" and "sun.nio.ch" from the list of imported packages.
- Add a Travis CI file
- Use the maven-bundle-plugin in order to create OSGi metadata. It falls back to the default configuration, only overriding this when really necessary.
- Prevent the maven-bundle-plugin from importing 'javax.annotation' in order to prevent a "uses violation".

Signed-off-by: Jens Reimann <jreimann@redhat.com>
@kevinherron
Copy link
Contributor

@JulianSchuette this should be fixed in master now... if you have a chance give it a try and let us know.

@ctron
Copy link
Contributor

ctron commented Oct 13, 2016

@JulianSchuette I also did update the camel Milo repository. The layout is a bit different now, but you can create a Karat feature and archive now. Just do a local build of Milo first.

@JulianSchuette
Copy link
Author

Thank you guys! I can install and run the camel-milo feature (which pulls in the milo feature) in Karaf. However, when testing the following route, there is a CNF exception.
I guess the reason is that both bundles, sdk-core and sdk-server export the same package org.eclipse.milo.opcua.core. OSGi resolves packages only to exactly one bundle - in this case it's sdk-core, but the missing class NamespaceTable is contained in sdk-server. Exporting a package from several bundles is not a good idea in most cases and should be refactored, but I do not want to mess with your code or might be completey wrong here. There are ways to force OSGi to ignore the problem using Require-Bundle, but that would be a hack.

Would it be possible to move classes in org.eclipse.milo.opcua.sdk.core to bundle sdk-core?

Camel route using milo:

<?xml version="1.0" encoding="UTF-8"?>
<blueprint
    xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
      http://www.osgi.org/xmlns/blueprint/v1.0.0
      http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">

    <camelContext xmlns="http://camel.apache.org/schema/blueprint">
      <route id="testroute">
        <from uri="paho:javaonedemo/eclipse-greenhouse-9home/sensors/temperature?brokerUrl=tcp://iot.eclipse.org:1883"/>
        <log message="Temp ${body}"/>
        <convertBodyTo type="java.lang.String"/>
        <to uri="milo-server:MyItem"/>
      </route>
    </camelContext>
</blueprint>

CNFException:

java.lang.NoClassDefFoundError: org/eclipse/milo/opcua/sdk/core/NamespaceTable
    at org.eclipse.milo.opcua.sdk.server.NamespaceManager.<init>(NamespaceManager.java:45)
    at org.eclipse.milo.opcua.sdk.server.OpcUaServer.<init>(OpcUaServer.java:89)
    at org.apache.camel.component.milo.server.MiloServerComponent.doStart(MiloServerComponent.java:136)
    at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
    at org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3371)
    at org.apache.camel.impl.DefaultCamelContext.initComponent(DefaultCamelContext.java:431)
    at org.apache.camel.impl.DefaultCamelContext.lambda$getComponent$9(DefaultCamelContext.java:411)

Package org.eclipse.milo.opcua.core is exported twice:

karaf@root()> package:exports -d
Package Name                             | Version | Exporting bundles (ID)
---------------------------------------------------------------------------
org.eclipse.milo.opcua.sdk.core          | 0.1.0   | 243 244
karaf@root()> la
START LEVEL 100 , List Threshold: 0
 ID | State     | Lvl | Version                            | Name
[...]
243 | Active    |  80 | 0.1.0.SNAPSHOT                     | sdk-core
244 | Active    |  80 | 0.1.0.SNAPSHOT                     | sdk-server
[...]

@ctron
Copy link
Contributor

ctron commented Oct 14, 2016

@JulianSchuette You are always one step ahead of what I am trying to do 😉

I will look into this. But I fully agree. Different artifacts should not export different bundles.

@ctron
Copy link
Contributor

ctron commented Oct 14, 2016

I am going to track this in a separate issue.

Pro pushed a commit to Pro/milo that referenced this issue Nov 28, 2016
- Remove "sun.misc" and "sun.nio.ch" from the list of imported packages.
- Add a Travis CI file
- Use the maven-bundle-plugin in order to create OSGi metadata. It falls back to the default configuration, only overriding this when really necessary.
- Prevent the maven-bundle-plugin from importing 'javax.annotation' in order to prevent a "uses violation".

Signed-off-by: Jens Reimann <jreimann@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants