You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Rajini Sivaram <ra...@googlemail.com> on 2008/01/15 15:20:12 UTC
Intermittent failure with bundle classloading
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
Re: Intermittent failure with bundle classloading
Posted by Rajini Sivaram <ra...@googlemail.com>.
Thank you, Karl. That is very promising.
Thank you...
Regards,
Rajini
On 1/16/08, Karl Pauls <ka...@gmail.com> wrote:
>
> > Karl,
> >
> > Thank you for the fix. Yes, it (the maven snapshot) does seem to have
> > worked.
>
> Great :-)
>
> > When is the next release of Felix? If it is soon, it might be better for
> > Tuscany to wait for the release rather than switch to using the snapshot
> > builds.
>
> Felix 1.0.2 will be out end of next week. I'm waiting for one
> dependency to be released (vote starting the end of this week) to cut
> a release.
>
> regards,
>
> Karl
>
> >
> > Thank you...
> >
> > Regards,
> >
> > Rajini
> >
> > On 1/15/08, Karl Pauls <ka...@gmail.com> wrote:
> > >
> > > Rajini,
> > >
> > > I just commited a patch that should fix the visibility issue (if that
> > > was the cause of your problems). Could you re-run your tests on the
> > > current trunk and see whether that fixes the issue for you?
> > > Alternatively, you can just use the deployed snapshot of the current
> > > trunk from maven (in case you don't want to rebuild trunk yourself).
> > > Let us know whether this makes your problems go away.
> > >
> > > regards,
> > >
> > > Karl
> > >
> > > On Jan 15, 2008 10:04 PM, Rajini Sivaram <rajinisivaram@googlemail.com
> >
> > > wrote:
> > > > 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 <ka...@gmail.com> 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 <
> 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 <he...@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
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Karl Pauls
> > > karlpauls@gmail.com
> > >
> >
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
Re: Intermittent failure with bundle classloading
Posted by Karl Pauls <ka...@gmail.com>.
> Karl,
>
> Thank you for the fix. Yes, it (the maven snapshot) does seem to have
> worked.
Great :-)
> When is the next release of Felix? If it is soon, it might be better for
> Tuscany to wait for the release rather than switch to using the snapshot
> builds.
Felix 1.0.2 will be out end of next week. I'm waiting for one
dependency to be released (vote starting the end of this week) to cut
a release.
regards,
Karl
>
> Thank you...
>
> Regards,
>
> Rajini
>
> On 1/15/08, Karl Pauls <ka...@gmail.com> wrote:
> >
> > Rajini,
> >
> > I just commited a patch that should fix the visibility issue (if that
> > was the cause of your problems). Could you re-run your tests on the
> > current trunk and see whether that fixes the issue for you?
> > Alternatively, you can just use the deployed snapshot of the current
> > trunk from maven (in case you don't want to rebuild trunk yourself).
> > Let us know whether this makes your problems go away.
> >
> > regards,
> >
> > Karl
> >
> > On Jan 15, 2008 10:04 PM, Rajini Sivaram <ra...@googlemail.com>
> > wrote:
> > > 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 <ka...@gmail.com> 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 <ra...@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 <he...@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
> > > >
> > >
> >
> >
> >
> > --
> > Karl Pauls
> > karlpauls@gmail.com
> >
>
--
Karl Pauls
karlpauls@gmail.com
Re: Intermittent failure with bundle classloading
Posted by Rajini Sivaram <ra...@googlemail.com>.
Karl,
Thank you for the fix. Yes, it (the maven snapshot) does seem to have
worked.
When is the next release of Felix? If it is soon, it might be better for
Tuscany to wait for the release rather than switch to using the snapshot
builds.
Thank you...
Regards,
Rajini
On 1/15/08, Karl Pauls <ka...@gmail.com> wrote:
>
> Rajini,
>
> I just commited a patch that should fix the visibility issue (if that
> was the cause of your problems). Could you re-run your tests on the
> current trunk and see whether that fixes the issue for you?
> Alternatively, you can just use the deployed snapshot of the current
> trunk from maven (in case you don't want to rebuild trunk yourself).
> Let us know whether this makes your problems go away.
>
> regards,
>
> Karl
>
> On Jan 15, 2008 10:04 PM, Rajini Sivaram <ra...@googlemail.com>
> wrote:
> > 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 <ka...@gmail.com> 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 <ra...@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 <he...@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
> > >
> >
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
Re: Intermittent failure with bundle classloading
Posted by Karl Pauls <ka...@gmail.com>.
Rajini,
I just commited a patch that should fix the visibility issue (if that
was the cause of your problems). Could you re-run your tests on the
current trunk and see whether that fixes the issue for you?
Alternatively, you can just use the deployed snapshot of the current
trunk from maven (in case you don't want to rebuild trunk yourself).
Let us know whether this makes your problems go away.
regards,
Karl
On Jan 15, 2008 10:04 PM, Rajini Sivaram <ra...@googlemail.com> wrote:
> 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 <ka...@gmail.com> 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 <ra...@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 <he...@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
> >
>
--
Karl Pauls
karlpauls@gmail.com
Re: Intermittent failure with bundle classloading
Posted by Rajini Sivaram <ra...@googlemail.com>.
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 <ka...@gmail.com> 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 <ra...@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 <he...@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
>
Re: Intermittent failure with bundle classloading
Posted by Karl Pauls <ka...@gmail.com>.
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 <ra...@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 <he...@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
Re: Intermittent failure with bundle classloading
Posted by Rajini Sivaram <ra...@googlemail.com>.
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 <he...@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
> >
> >
>
Re: Intermittent failure with bundle classloading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
>
>