User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
Hi Ramchandran,
On 9/14/2016 7:44 AM, Ramachandran K. Narayanan wrote:
Hello Scott,
Thanks a lot for the detailed reply which had a lot of
valuable information. I will go through the tutorials that you
had outlined.
Ok.
Actually, the changes I am making are on a fork of Eclipse
ICE, which is a large GitHub project. So I am not modifying
the ECF examples as such, just carrying over the RS code
changes to Eclipse ICE.
I will go through the tutorials first and see if I can
resolve my issues.
Ok. My theory is that some of the ICE services...that perhaps you
are trying to remote...could have some more complicated
dependencies. Note that for remote services the service interface
and any dependent classes (i.e. classes that are referenced by the
service interface) have to be present on both the service host and
service consumer processes. This is why, for example, it's
considered a good practice to separate the service interface
package/classes from the actual implementation at the bundle
level...because then the consumer doesn't need the implementation
classes.
Do let me know if I can help further. There was some talk on the
ICE project (science working group) about using ECF's remote
services so perhaps that is already happening to some degree.
at
ch.ethz.iks.r_osgi.impl.CodeAnalyzer.visit(CodeAnalyzer.java:297)
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 list.
I am now stuck at org.slf4j.impl (as
the ClassNotFoundException),
but I was simply wondering if this is the right way
to resolve this?
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 consumer.
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.
