> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> > 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 <[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]
> > > >
> > >
> >
> >
> >
> > --
> > Karl Pauls
> > [EMAIL PROTECTED]
> >
>
--
Karl Pauls
[EMAIL PROTECTED]
