So I tried resolving this by adding org.eclipse.core.internal.runtime
as part of the Dependency in the Manifest file. Then I get the
same Exception but for a different class (at the same
location) and I end up adding more packages to the Dependency
I am now stuck at org.slf4j.implÂ(as
but I was simply wondering if this is the right way to resolve
I don't think this is the right way to resolve this.ÂÂÂ Based upon
what you say above, my suspicion is that the changes you are making
to the remote service interface are adding some dependencies that
pull in the PrintStackUtil class along with others.
But before going further with this, I would suggest starting from a
different example than the Getting Started with Remote Services
API.Â This example was introduced quite a few years ago...before
OSGi Remote Services specification actually existed.ÂÂ Now it's much
easier to use the OSGi Remote Services approach (less code for both
the remote service registration and the consumer).Â The Getting
Started you point to above should still work, and we don't want to
remove it, but I would recommend using OSGi Remote Services/Remote
Service Admin because it's both simpler and standardized.
Here, for example, is a getting started with OSGi Remote Services
There are also some examples of registering and consuming a remote
service using Declarative Services annotations, which also
simplifies things even further.ÂÂ I haven't yet had a chance to
complete a tutorial for this but you can look at example api,
provider, and consumer bundles here
That is, by adding more packages to the Dependencies.
Without my changes, I don't get the errors (when I revert to
the older code).
This makes me think that your changes are introducing runtime
dependencies (perhaps in bundles that are pulled in for other
classes you are referencing).Â Can you describe the changes you are
making to the examples?ÂÂ If you don't want them to be public then
you could correspond with me directly at slewis at composent.com.
2) Would applying the code changes from the previous link
be enough to support Remote OSGi? That is, are there typical
areas I need to keep an eye on while doing this? I know that
this is too broad a question, butÂI am working with OSGi for the first
time, so I am just trying to avoid the obvious issues.
Well, I do think that OSGi Remote Services is the way to go.ÂÂ The
model for OSGi RS/RSA is straightforward:Â local OSGi services are
*exported* (provider) so they can then be discovered and *imported*
by some other process.ÂÂ This allows you to avoid calling all the
ECF RS-specific code that's in the Getting Started page.ÂÂ All of
the necessary calls to export the service are made automatically as
part of the service registration.
One of the tricky issues with both local and remote services is
dependencies.ÂÂ For example, if your service interface includes
references to packages and/or classes contained in some other
bundle, then all those dependencies have to be available on both the
provider/host and the consumer.ÂÂ It's very easy to include an
entire tree of unwanted dependencies simply by importing one package
into the bundle that contains your service interface.ÂÂ That's kind
of what I'm suspecting is going on with your attempt to modify the
example, resulting in the ClassNotFoundExceptions occurring in the
code that's responsible for creating the remote service proxy on the
If you can let us know what changes you are looking to make to the
service interface then we can probably help further.ÂÂ But I would
suggest looking a the OSGI Remote Service tutorials and examples
given above as they are simpler, smaller, and standardized.