context-class-loader attribute on osgi reference

On osgi service side ,when setting this attribute to service-provider ,I was able to initialize a class present in bundle providing the service using TCCL from withing service reference .

Code on service side:

Code:

---

<osgi:service id="service" interface="com.pg.ccl.intf.ServiceIntf" context-class-loader="service-provider" ref="serviceBean"></osgi:service>


Thread.currentThread().getContextClassLoader().loadClass("com.pg.serviceCCL.Dummy").newInstance();

---

But after going through the doc it seems we can specify the same attribute on osgi reference and same should work .But instead i am getting CNF Exception.

Have i interpreted it incorrectly.

When using a service-provider on the reference side, one needs to keep in mind that the service might be unavailable or that a different service might be selected.
Additionally, the TCCL is set only during the service invocation request. Relying on the classloader outside the call, will not work since the TCCL is unset once the request finishes.

Note that the main reason for TCCL is to accommodate service providers that rely on the TCCL. If you're the entity providing the service then setting the TCCL on that side, is enough.

These being said, I've raised an issue (will get uploaded shortly as it seems there are some problems with jira.springframework.org) to double check this behaviour.
If you have a certain use case or test case that exhibits the problem let me know.
Some code snippet would be fine as well.

Cheers,

I am also facing the same issue -

It worked when attribute context-class-loader=”service-provider” is added with <osgi:service> (service provider).

It does not work when same attribute is added with <osgi:reference> (service consumer). This should also work as mentioned in Spring DM document.

Below is the code and configurations used -

Service provider:

Code:

---

package com.bundle8;

import com.common.IMyClassLoader;

public class MyClassLoader implements IMyClassLoader {
  public void loadClass() {
      try {
          Object obj = Thread.currentThread().getContextClassLoader().loadClass("com.dummy.Dummy").newInstance();
          System.out.println("Obj " + obj);
    } catch (Exception e) {
        e.printStackTrace();
    }       
}

---

Service consumer:

Code:

---

<osgi:reference id="service" interface="com.common.IMyClassLoader" context-class-loader="service-provider"/>

---

If required I will upload the source code and configuration files.

Regards,
Pranav

See http://jira.springframework.org/browse/OSGI-771
Feel free to upload any relevant code to this issue.

I think I've identified the problem. Spring DM uses as the provider classloader, the bundle that registered the service object. In the sample, the service interface (used during the service registration) comes from a different bundle and my guess is that, its classloader is returned instead of the actual bundle that performed the registration.
By itself, Spring DM uses only the OSGi API so it uses whatever bundle the ServiceRegistration returns.

These being said, I was unable to reproduce your problem on my machine using Spring DM trunk. What OSGI implementation are you using?