Richard,
I dont think this is the problem in the filtering test because I can see
from the logs that the class used by the service object is different from
the class used by the bundle when the lookup is done. I have a list of print
statements taken from a segment of code in Tuscany when the class suddenly
changes (and this eventually leads to the test failing). Could you tell me
what could have triggered this? I dont think there is much else going on in
the application at this point.
Class<?> proxyInterface = bundle.loadClass(interfaceClass.getName());
registerProxyService(proxyInterface);
debugPrint(bundle, proxyInterface);
Bundle[] bundles = bundleContext.getBundles();
for (Bundle b : bundles) {
try {
if (b.getSymbolicName().startsWith("org.apache.felix"))
continue;
Class<?> c = b.loadClass(interfaceClass.getName());
debugPrint(b, c);
} catch (Throwable t) {
}
}
The log shows:
1. Class="interface conversation.service.ConversationalService"
class.hashCode=1640915406 classloader="9.0"
classLoader.hashCode=171182644 loaded using bundle="
conversation.ConversationalClient [7]" bundle.hashCode=141559920
2. Class="interface conversation.service.ConversationalService"
class.hashCode=1712285199 classloader="
org.apache.maven.surefire.booter.IsolatedClassLoader"
classLoader.hashCode=93324688 loaded using bundle="System Bundle
[0]" bundle.hashCode=992361254
3. Class="interface conversation.service.ConversationalService"
class.hashCode=966932898 classloader="9.0"
classLoader.hashCode=1593597692 loaded using bundle="
conversation.ConversationalClient [7]" bundle.hashCode=141559920
4. Class="interface conversation.service.ConversationalService"
class.hashCode=966932898 classloader="9.0"
classLoader.hashCode=1593597692 loaded using bundle="
conversation.ConversationalReferenceClient [8]"
bundle.hashCode=349312210
5. Class="interface conversation.service.ConversationalService"
class.hashCode=966932898 classloader="9.0"
classLoader.hashCode=1593597692 loaded using bundle="
conversation.ConversationalService [9]"
bundle.hashCode=398464960
1) is from the first print and 2-5 are from the loop. The hashCode of the
class and its classloader in 1) are different from 3) which were both the
return value from the same bundle.loadClass. 3-5 show the same class, and I
can see this class being used throughout the test from this point onwards.
2. is the system bundle which doesn't export the package, but has the class
in its classpath. The bundle doing the lookup for the service is the one
used in 1) and 3). And it doesn't find the service because the proxy uses
the class from 1) while the class visible to the bundle when the lookup is
done is the one from 3).
I have modified Tuscany to do a refreshPackages on PackageAdmin before
registering any proxy services, and I haven't seen this error since then.
But that could just be because of slowing things down.
I am using Felix framework 1.0.1.
Thank you...
Regards,
Rajini
On 1/15/08, Richard S. Hall <[EMAIL PROTECTED]> wrote:
>
> Strange.
>
> Off the top of my head I can think of two ways for this to happen:
>
> 1. PackageA is actually available from more than one place.
> 2. Felix' service filtering test has a bug in it.
>
> Perhaps you could add some debugging printlns to your code to determine
> which class loaders are being used to load the service class from both
> your consumer and your provider, particularly in the case where it
> fails. If we can see that the class loaders are the same when it fails,
> then we can assume the bug is in the service filtering code.
>
> -> richard
>
> Rajini Sivaram wrote:
> > Hello,
> >
> > I have a test case in Apache Tuscany which fails intermittently when run
> > along with a lot of other OSGi-based tests under Felix.
> >
> > I have three bundles A, B and C with distinct packages contained inside
> > them.
> >
> > BundleA exports PackageA.
> > BundleB imports PackageA.
> >
> > I use the system bundleContext to register a service with interface
> > PackageA.ClassA. The interface class for the service is loaded using
> > BundleB.loadClass("PackageA.ClassA"). BundleB looks up the registry to
> find
> > this service (the actual service object registered is a Java proxy with
> the
> > interface PackageA.ClassA).
> >
> > It works fine most of the time. BundleB finds the proxy service using
> > getServiceReferences since the provider (system bundle) does not have a
> wire
> > to PackageA, and the class of the object being looked up is the same as
> the
> > one visible to BundleB.
> >
> > But once in a while, the test does not find the proxy. Sometimes it
> finds a
> > proxy and then throws ClassCastException when BundleB typecasts the
> object
> > returned to (PackageA.ClassA). But there is only one copy of the class
> > installed into the OSGi runtime.
> >
> > There are other bundles which don't contain PackageA which are installed
> and
> > uninstalled while the test is running, but I am not sure if these should
> > affect BundleA/BundleB given that their import/exports are not satisfied
> by
> > these other bundles.
> >
> > Is there any circumstance under which the class that is visible to
> BundleB
> > would get reloaded when neither BundleB that is importing the package
> and
> > BundleA that is exporting the package have not been restarted? In other
> > words, is BundleB.loadClass("PackageA.ClassA") always guaranteed to
> return
> > the same class if the bundle exporting PackageA is not uninstalled, and
> no
> > new bundles are added which export PackageA?
> >
> >
> >
> > Thank you...
> >
> > Regards,
> >
> > Rajini
> >
> >
>
