It doesn't defeat the purpose. It's the same thing as separating an EJB into a
Remote interface. You may have the Remote interface on your classpath, but that
doesn't mean you have the implementation - that could be coming from somewhere
completely different, even a different JVM.
If you don't have the API with the .class objects on your classpath, you can't
interact with them. OSGi does not delegate in any way to Furnace. As far as OSGi knows,
Furnace doesn't exist, so you still need the types on your classpath.
There are two classpaths that you shoudl care about:
1. What Furnace sees and you don't.
2. What you see and Furnace doesn't.
What joins those two classpaths is the ClassLoaderAdapterCallback proxy, which handles
adapting the types between the two world views. Any (non-built in) type that crosses the
classloader boundary between the two worlds must be proxied. If that proxy extends,
implements, or one of those types references a type (such as Spring's
ApplicationContext.class), then that type must be available on the classpath or proxying
will fail. That is what I believe happened in your scenario, and that is why I believe
including the Spring API jar on the OSGi classpath should resolve the issue.
Posted by forums
Original post:
https://developer.jboss.org/message/913988#913988