[ 
https://issues.apache.org/jira/browse/FELIX-5913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632214#comment-16632214
 ] 

Tom Rutchik commented on FELIX-5913:
------------------------------------

Karl,

Here's is the change that I made to get your implementation to work:

This is the loadClass method  of the BundleClassLoaderDalvik:

        protected Class loadClass(String name, boolean resolve)
            throws ClassNotFoundException
        {
            Class clazz = findLoadedClass(name);
            if (clazz == null) {
                try {
                    clazz = findClass(name);
                }catch (ClassNotFoundException e) {
                }
            }
            if (clazz == null)
            {
                try
                {
                    clazz = (Class) 
m_wiring.findClassOrResourceByDelegation(name, true);
                }

=================================
So I added an additional try block protected call to findClass().  The try 
catch is necessary because as the class is being found, the method is recalled 
to resolve internal classes such as java.lang.Object which is not in the 
bundle. Those kinds of classes are resolved further down in the class loading 
process. 

There is an alternative location that the findClass(name) method can be called. 
 And that's in the CNFE exception catch block area.  I tried it out, and it 
works too.  Here's how that would be coded:

                catch (ClassNotFoundException cnfe)
                {
                    try {
                        clazz = findClass(name);
                    }catch (ClassNotFoundException e) {
                    }
                    if (clazz == null) {

                        ClassNotFoundException ex = cnfe;
                        if (m_logger.getLogLevel() >= Logger.LOG_DEBUG) {
                            String msg = 
diagnoseClassLoadError(m_wiring.m_resolver, m_wiring.m_revision, name);
                            ex = (msg != null)
                                    ? new ClassNotFoundException(msg, cnfe)
                                    : ex;
                        }
                        throw ex;
                    }
                }

Both work in my test cases, but there is a weird question that if a bundle 
imports a package let's say "com.mycompany.mypackage" and the bundle itself 
also defines the class "com.mycompany.myPackage.MyClass"  what happens when we 
try to load that class.  Weird, but I don't think there's anything preventing 
someone from doing this; it sounds like a way for a bundle to override a single 
class from a package that it imports. Will it find the class in the bundle, or 
might it find the class from another bundle that exports the package 
"com.mycompany.mypackage" and also contains the MyClass class?  It seems to me, 
that it should find the one in the bundle and not one from another bundle that 
exports that package. If that's intend how it's supposed to work, then 1st 
solution is the right one.  If not, then the 2nd solution in the right one.  I 
don't know what the OSGI specification says about this scenario or even whether 
this is legal or undefined.

===========================
Could you also correct this nuisance lint error problem:
C:\PR\Android\BimTabellaeV6\OsgiFramework\src\main\java\org\apache\felix\framework\URLHandlersStreamHandlerProx
y.java:188: warning: non-varargs call of varargs method with inexact argument 
type for last parameter;
            return ((Integer) GET_DEFAULT_PORT.invoke(svc, null)).intValue();

changed to: 

            return ((Integer) GET_DEFAULT_PORT.invoke(svc)).intValue();



-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)

Reply via email to