[
https://issues.apache.org/jira/browse/FELIX-5913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16630692#comment-16630692
]
Tom Rutchik commented on FELIX-5913:
------------------------------------
Karl,
That helps a lot in explaining things. I'm going to have to have to parse your
email a couple of more times so it really sinks in, but I get the general
drift. I did eventually see in the code where you fake out the
dalivk.system.PathClassLoader. What wasn't clear to me that you were planning
to use it only for compile time. That's a clever trick, I've not done that one
before.
I also follow the argument that a class loaded from the DexBundleClassLoader
becomes the assumed classloader; and you're right that it'll resolve any class
the bundle contains. The gap in my understanding was that there are cases where
we don't want that to happen. That is what was not obvious to me, but I do
understand that there is a technical precision that needs to be adhered too or
else we're not complying with the OSGI standard.
I'm also not sure if the native code needs to be copied out. It depends on the
technique of how the native code is located and loaded. If it is loaded on
behalf of a PathClassLoader, it has to exist in a directory. The
PathClassLoader's searchLibraryPath takes a list of directories as input. It
apparently doesn't allow you to reference a directory inside a jar. I did find
a reference on the internet that collaborates that you need to copy the native
code out of the jar and put it in a directory if you want to find native code
libraries using the LibrarySearchPath of PathClassLoader itself. I think I
recall getting any error if the LibrarySearchPath included a none directory
element. There are clearly other ways that native code libraries can be loaded
that don't use the PathClassLoader. It certainly isn't clear to me what
techniques Felix supports for accessing native code other than that there is a
specification for defining native code usage and specifying where it is stored
in the bundle. I went down this path primarily because on you original
specification for native code support; that seemed to imply that if it wasn't
added to the PathClassLoader's LibrarySearchPath that native code wouldn't
work. Does the BundleClassLoader already have the capability to load native
code without relying on the PathClassLoader? I looked for that, but I didn't
see it; but that could have been an oversight on my behalf.
I'll test your solution, fix any obvious errors or omissions and will get back
in touch with you on the results.
-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)
