Thank you, Karl. That is very promising.
Thank you...
Regards,
Rajini
On 1/16/08, Karl Pauls <[EMAIL PROTECTED]> 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 <[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]
>
