[
https://issues.apache.org/jira/browse/SM-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nate updated SM-4314:
---------------------
Description:
XMLRPC-server and Xmlrpc-client bundles both have the xmlrpc-common packages
included in their respective bundles. This means they can't be used in the same
OSGi environment, because doing so causes OSGi to fail on starting up because a
bundle defining imports on any of the shared packages can be resolved through 2
dependency chains.
I have this problem right now: I have 2 Karaf containers that need to be able
to send XMLRPC communications to each other. For this reason, both containers
need to be able to do both the client and server side of communication and as
such need the client and server bundles installed. However, any bundle that
depends on shared code from these (like the wrapper bundle I have written
around the client and server components of XMLRPC to make it easier to update
things) will trigger uses constraint violations related to possible resolution
of packages via 2 dependency chains. The specific problem and error messages
can be found in
[https://stackoverflow.com/questions/60073549/having-xmlrpc-client-and-xmlrpc-server-bundles-in-an-osgi-environment-triggers-u],
where a commenter recommended me to open an issue here.
I think the best solution would be to reorganize the client and server bundles
into the same jar setup as the non-bundle versions. When I tried the
non-bundled versions in Karaf, they appeared to work fine, even though they
were autowrapped by OSGi because they weren't bundles.
Just so we're clear: I'm talking about the
[https://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.xmlrpc-server]
bundle and the related client bundle.
was:
XMLRPC-server and Xmlrpc-client bundles both have the xmlrpc-common packages
included in their respective bundles. This means they can't be used in the same
OSGi environment, because doing so causes OSGi to fail on starting up because a
bundle defining imports on any of the shared packages can be resolved through 2
dependency chains.
I have this problem right now: I have 2 Karaf containers that need to be able
to send XMLRPC communications to each other. For this reason, both containers
need to be able to do both the client and server side of communication and as
such need the client and server bundles installed. However, any bundle that
depends on shared code from these (like the wrapper bundle I have written
around the client and server components of XMLRPC to make it easier to update
things) will trigger uses constraint violations related to possible resolution
of packages via 2 dependency chains. The specific problem and error messages
can be found in
[https://stackoverflow.com/questions/60073549/having-xmlrpc-client-and-xmlrpc-server-bundles-in-an-osgi-environment-triggers-u],
where a commenter recommended me to open an issue here.
I think the best solution would be to reorganize the client and server bundles
into the same jar setup as the non-bundle versions. When I tried the
non-bundled versions in Karaf, they appeared to work fine, even though they
were autowrapped by OSGi because they weren't bundles.
> XMLRPC-server and XMLRPC-client bundles cannot be used in the same karaf
> environment because of split packages
> --------------------------------------------------------------------------------------------------------------
>
> Key: SM-4314
> URL: https://issues.apache.org/jira/browse/SM-4314
> Project: ServiceMix
> Issue Type: Bug
> Reporter: Nate
> Priority: Major
> Labels: xml-rpc
>
> XMLRPC-server and Xmlrpc-client bundles both have the xmlrpc-common packages
> included in their respective bundles. This means they can't be used in the
> same OSGi environment, because doing so causes OSGi to fail on starting up
> because a bundle defining imports on any of the shared packages can be
> resolved through 2 dependency chains.
>
> I have this problem right now: I have 2 Karaf containers that need to be able
> to send XMLRPC communications to each other. For this reason, both containers
> need to be able to do both the client and server side of communication and as
> such need the client and server bundles installed. However, any bundle that
> depends on shared code from these (like the wrapper bundle I have written
> around the client and server components of XMLRPC to make it easier to update
> things) will trigger uses constraint violations related to possible
> resolution of packages via 2 dependency chains. The specific problem and
> error messages can be found in
> [https://stackoverflow.com/questions/60073549/having-xmlrpc-client-and-xmlrpc-server-bundles-in-an-osgi-environment-triggers-u],
> where a commenter recommended me to open an issue here.
>
> I think the best solution would be to reorganize the client and server
> bundles into the same jar setup as the non-bundle versions. When I tried the
> non-bundled versions in Karaf, they appeared to work fine, even though they
> were autowrapped by OSGi because they weren't bundles.
> Just so we're clear: I'm talking about the
> [https://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.xmlrpc-server]
> bundle and the related client bundle.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
