[
https://issues.apache.org/jira/browse/FELIX-5913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16611348#comment-16611348
]
Tom Rutchik commented on FELIX-5913:
------------------------------------
Karl,
Status Update:
I have a new solution for android support that I've been testing and this
solution works.
What I did previously was to use a delegate class loader to either loadClass or
findClass. That delegate has a PathClassLoader with the bundles path available
to it. I placed that delegation decision in the
findClassOrResourceByDelegation method of the BundleWiringImps class. This was
pretty successful until I discovered that these methods could be call from an
external class such as Bundle.loadClass. The bundle.loadClass got access to
the BundleClassLoader by using the method getClassLoader that the
BundeWiringImpl class made public.
In the new solution, the delegation decision was move to being done inside the
loadClass and findClass method of the BundleClassLoader. To make it work I
needed to add a gatekeeper to these methods. The gatekeeper kind of works like
the cycleChecker in the BundleWiringImpl class, but in reverse; Instead of
detecting loops, the gatekeeper opens the gate so that subsequent calls to the
loadClass and findClass method pass through until the loadClass and findClass
ends and closes the gate. It does this on a thread local basis.
In the process of making that solution work, I gained some additional insight
into why a simpler approach I was initially trying seemed to fail. In the
simpler approach I tried, I made the PathClassLoader the parent of the
BundleClassLoader, and made the parent class of the PathClassLoader be the
original parent that the BundleClassLoader would have had. Intuitively, that
seems like it should work, but when I first tried it, it didn't work. From the
insights I gained in making the delegation approach work, I think I discovered
what was preventing the simpler alternative approach from not working.
So before I release a solution I'm going to revisit this simpler approach and
see if I can get it to work. The simpler approach has some real advantages that
makes it more appealing (i.e. less code changes, no gatekeeper, elimination of
two calls made through reflection) It shouldn't take me too long to retry it.
-Tom Rutchik
> Support Android
> ---------------
>
> Key: FELIX-5913
> URL: https://issues.apache.org/jira/browse/FELIX-5913
> Project: Felix
> Issue Type: Wish
> Components: Framework
> Affects Versions: framework-6.0.0, framework-6.0.1
> Reporter: Tom Rutchik
> Priority: Major
> Attachments: BundleWiringImpl.java,
> FelixAndroidSupportImplementationNotes.pdf
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> The lastest 6.0.0 and 6.0.1 release no longer works on Android.
> The code form the 5.6.10 version necessary to make it work was not ported
> into these versions.
> Some code needs to be added to the class BundleWiringImpl class to allow for
> android support. All of the code necessary to due that can be found in the
> 5.6.10 version.
> I've added the code and have tested it and it's working fine again. I've
> attached an implementation of BundleWiringImpl that works with android. It's
> basically the 6.0.1 implementation with the extra code from 5.6.10. You
> should be able to do a file diff on the 6.0.1 to see where I had to add the
> missing code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
