Karl,
Yes, I think it is possible that the class was loaded from the bundle on
another thread, because there is a bundle listener which does some
processing when the bundle moves to resolved state. Should I avoid
classloading in other threads, or is it something that can be fixed in
Felix?
Thank you...
Regards,
Rajini
On 1/15/08, Karl Pauls <[EMAIL PROTECTED]> wrote:
>
> 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 <[EMAIL PROTECTED]>
> 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 <[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
> > > >
> > > >
> > >
> >
>
>
>
> --
> Karl Pauls
> [EMAIL PROTECTED]
>
