felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Pauls" <karlpa...@gmail.com>
Subject Re: Intermittent failure with bundle classloading
Date Tue, 15 Jan 2008 20:43:42 GMT
Is it possible that the class has been loaded from the bundle before
this test by a different thread? It looks like we could have a
visibility issue because the classloader is created lazily outside of
a any synchronized block...

regards,

Karl

On Jan 15, 2008 9:07 PM, Rajini Sivaram <rajinisivaram@googlemail.com> wrote:
> 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 <heavy@ungoverned.org> 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
> > >
> > >
> >
>



-- 
Karl Pauls
karlpauls@gmail.com

Mime
View raw message