On Tue, Sep 22, 2009 at 9:28 PM, Matthias Neubert <[email protected]> wrote:
> Hello,
>
> I tried your advice, but it still doesn't work, but the error changed a bit:
>
> Current Configuration:
>
> no use of boot delegation
You have to keep the bootdelegation as you have it except remove the
com.google.* and then add the packages I told you in the last mail.
That did make it work for me until the NullPointer which didn't look
like it is felix releated.
regards,
Karl
> configProps.put("felix.bootdelegation.implicit", "false");
>
> system.packages.extra contains among other the following maps.jar-Packages:
> "com.google.android.maps; " +
> "com.google.android.xmppService; " +
> "com.google.googlenav.map; " +
> "com.google.common;" +
> "com.google.map;"
>
>
> Error:
>
> It remains the basic error:
>
> java.lang.LinkageError: Classes resolve differently in superclass
>
> but he now adds:
>
> Method mismatch: setup in
> Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView; (cl=0x43891310) and
> super Lcom/google/android/maps/MapView; (cl=0x43760eb0)
>
>
> Error:
>
> 09-22 21:15:26.981: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
> android.graphics.drawable -> 0
> 09-22 21:15:27.031: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
> android.util -> 0
> 09-22 21:15:27.091: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
> android.location -> 0
> 09-22 21:15:27.150: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
> com.google.googlenav.map -> 0
> 09-22 21:15:27.481: WARN/dalvikvm(751): Method mismatch: setup in
> Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView; (cl=0x43891310) and
> super Lcom/google/android/maps/MapView; (cl=0x43760eb0)
> 09-22 21:15:27.481: DEBUG/AndroidRuntime(751): Shutting down VM
> 09-22 21:15:27.481: WARN/dalvikvm(751): threadid=3: thread exiting with
> uncaught exception (group=0x4001aa28)
> 09-22 21:15:27.491: ERROR/AndroidRuntime(751): Uncaught handler: thread main
> exiting due to uncaught exception
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): java.lang.LinkageError:
> Classes resolve differently in superclass
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> de.mnsoft.mapprovider.gmapsimpl.ViewBuilder$1.run(ViewBuilder.java:112)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> android.os.Handler.handleCallback(Handler.java:587)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> android.os.Handler.dispatchMessage(Handler.java:92)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> android.os.Looper.loop(Looper.java:123)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> android.app.ActivityThread.main(ActivityThread.java:4203)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> java.lang.reflect.Method.invokeNative(Native Method)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> java.lang.reflect.Method.invoke(Method.java:521)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:791)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> com.android.internal.os.ZygoteInit.main(ZygoteInit.java:549)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> dalvik.system.NativeStart.main(Native Method)
>
>
>
> I will now add to export list just all Packages maps.jar has (I did so for
> android.jar) but I'm afraid that this will not change
> the situation. I'm still hoping that you will find a workaround for the
> bootdelegation in order to see if this solves the problem.
>
> regards
> Matthias
>
>
>
>
>
> Am 22.09.2009 um 19:06 schrieb Karl Pauls:
>
>> On Tue, Sep 22, 2009 at 6:00 PM, Matthias Neubert <[email protected]>
>> wrote:
>>>
>>> Hello,
>>>
>>> additional info: setting the Imports of the using Bundles to
>>>
>>> DynamicImport-Package: android.*, com.google.*
>>>
>>> does NOT solve the problem.
>>
>> It does for me, but you are missing some exports from the system bundle
>> namely,
>>
>> com.google.android.maps
>> com.google.googlenav.map
>> com.google.common
>> com.google.map
>>
>> if I add those plus implict=false and not bootdelegating com.google.*
>> the app starts for me and if I hit the button I get a NullPointer
>> somewhere but one that doesn't seem to be releated to felix.
>>
>> Regarding the bootdelegation I think I know what is going on and will
>> try to find a workaround soon. Until then, please let me know whether
>> it works with the above for you now.
>>
>> regards,
>>
>> Karl
>>
>>> Changing it has one advantage for me: Now I can
>>> easily switch between
>>> bootdelegation and system.packages.extra without touching the bundles,
>>> only
>>> by changing the felix configuration.
>>>
>>> I'm looking foreward that we can solve this issue. Important for me is
>>> what
>>> do you think: will boot delegation be able to solve the underlying
>>> problem?
>>>
>>> regards
>>> Matthias
>>>
>>>
>>>
>>>
>>> Am 22.09.2009 um 15:26 schrieb Matthias Neubert:
>>>
>>>> Hello,
>>>>
>>>> I've tried this combination without success.(he doesn't find the class)
>>>> Some minutes ago I mailed to you the requested Eclipse Projects for
>>>> testing
>>>> it locally.
>>>>
>>>> I hope there is a way for felix to work around this DalvikVM Bug. The
>>>> people from ProSyst seem to have the same problem.[1] I don't know if
>>>> they also had the idea solving this by boot delegation, but as far as I
>>>> understand the dalvik bug [2], boot delegation instead of system.extra
>>>> export will solve the problem.
>>>>
>>>> If not I will have a bigger problem than I ever thought.(regarding to my
>>>> diploma thesis)
>>>>
>>>> feel free to experiment with my test-projects.
>>>>
>>>> regards
>>>> Matthias
>>>>
>>>> [1]
>>>>
>>>> http://dz.prosyst.com/pdoc/changes/Release-Notes_ProSyst-mBS-OSGi-Android_v1.0.0.pdf
>>>> [2] http://code.google.com/p/android/issues/detail?id=2711
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Am 22.09.2009 um 15:05 schrieb Karl Pauls:
>>>>
>>>>> On Tue, Sep 22, 2009 at 2:54 PM, Matthias Neubert
>>>>> <[email protected]>
>>>>> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I tested
>>>>>> configProps.put("org.osgi.framework.bundle.parent",
>>>>>> Constants.FRAMEWORK_BUNDLE_PARENT_BOOT);
>>>>>> (which is org.osgi.framework.bundle.parent=boot)
>>>>>> when felix.bootdelegation.implicit=false then he do not find the
>>>>>> class.
>>>>>> When
>>>>>> true, he hang for ever.
>>>>>
>>>>> Well, the latter (i.e., hang for ever) seems to be a bug in android
>>>>> which we didn't anticipate but we might be able to detect this
>>>>> situation and workaround it in felix. The former, however, is not yet
>>>>> clear to me what is going on exactly but please make sure that it
>>>>> doesn't work if you set the bundle.parent to app and the
>>>>> bootdelegation.implicit to false.
>>>>>
>>>>> regards,
>>>>>
>>>>> Karl
>>>>>
>>>>>> So no solution from that option. I will try to change my embedding
>>>>>> using
>>>>>> the
>>>>>> new FrameworkFactory way, but as far I can the this only wraps
>>>>>> the normal Felix instancing in a standardized manner and so will not
>>>>>> help.
>>>>>>
>>>>>> regards
>>>>>> Matthias
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 22.09.2009 um 13:30 schrieb Matthias Neubert:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I thank you both for answering so quickly.
>>>>>>>
>>>>>>> setting configProps.put("org.osgi.framework.bundle.parent", "app");
>>>>>>> didn't
>>>>>>> change something, same problem occurs.
>>>>>>>
>>>>>>> setting configProps.put("felix.bootdelegation.implicit", "false");
>>>>>>> neither with nor without setting the ..bundle.parent=app
>>>>>>> causes him to not find the Class MapView.
>>>>>>>
>>>>>>> BUT: he doesn't hang (but crashes later)
>>>>>>>
>>>>>>>
>>>>>>> Error is:
>>>>>>>
>>>>>>> 09-22 13:08:22.829: WARN/dalvikvm(726): Unable to resolve superclass
>>>>>>> of
>>>>>>> Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView; (20)
>>>>>>> 09-22 13:08:22.829: WARN/dalvikvm(726): Link of class
>>>>>>> 'Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView;' failed
>>>>>>> 09-22 13:08:22.829: ERROR/dalvikvm(726): ERROR:
>>>>>>> defineClass(0x43878790,
>>>>>>> de.mnsoft.mapprovider.gmapsimpl.AutoRefreshMapView, 0x43854238, 0,
>>>>>>> 2691,
>>>>>>> 0x43838620)
>>>>>>> 09-22 13:08:22.839: WARN/dalvikvm(726): VFY: unable to find class
>>>>>>> referenced in signature
>>>>>>> (Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView;)
>>>>>>> 09-22 13:08:23.829: WARN/dalvikvm(726): VFY: unable to find class
>>>>>>> referenced in signature (Lcom/google/android/maps/MapActivity;)
>>>>>>> 09-22 13:08:24.709: ERROR/dalvikvm(726): Could not find class
>>>>>>> 'com.google.android.maps.MapActivity', referenced from method
>>>>>>>
>>>>>>>
>>>>>>> de.mnsoft.mapprovider.gmapsimpl.MapProviderServiceImpl.__generateMapView
>>>>>>> 09-22 13:08:24.719: WARN/dalvikvm(726): VFY: unable to resolve
>>>>>>> check-cast
>>>>>>> 19 (Lcom/google/android/maps/MapActivity;) in
>>>>>>> Lde/mnsoft/mapprovider/gmapsimpl/MapProviderServiceImpl;
>>>>>>> 09-22 13:08:24.719: WARN/dalvikvm(726): VFY: rejecting opcode 0x1f
>>>>>>> at
>>>>>>> 0x0008
>>>>>>> 09-22 13:08:24.719: WARN/dalvikvm(726): VFY: rejected
>>>>>>>
>>>>>>>
>>>>>>> Lde/mnsoft/mapprovider/gmapsimpl/MapProviderServiceImpl;.__generateMapView
>>>>>>> ()V
>>>>>>> 09-22 13:08:24.719: WARN/dalvikvm(726): Verifier rejected class
>>>>>>> Lde/mnsoft/mapprovider/gmapsimpl/MapProviderServiceImpl;
>>>>>>> 09-22 13:08:24.799: WARN/System.err(726): [ERROR]
>>>>>>> de.mnsoft.mapprovider.gmapsimpl.MapProviderServiceImpl :
>>>>>>> [de.mnsoft.mapprovider.gmapsimpl.MapProviderServiceImpl-0]
>>>>>>> createInstance ->
>>>>>>> The POJO constructor invocation failed :
>>>>>>> de.mnsoft.mapprovider.gmapsimpl.MapProviderServiceImpl
>>>>>>> 09-22 13:08:24.959: WARN/System.err(726): java.lang.VerifyError:
>>>>>>> de.mnsoft.mapprovider.gmapsimpl.MapProviderServiceImpl
>>>>>>> 09-22 13:08:24.979: WARN/System.err(726): at
>>>>>>> java.lang.Class.getDeclaredConstructors(Native Method)
>>>>>>> 09-22 13:08:24.989: WARN/System.err(726): at
>>>>>>> java.lang.Class.getDeclaredConstructor(Class.java:602)
>>>>>>> 09-22 13:08:24.989: WARN/System.err(726): at
>>>>>>>
>>>>>>>
>>>>>>> org.apache.felix.ipojo.InstanceManager.createObject(InstanceManager.java:583)
>>>>>>> ...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I still can't get rid of the feeling that this all has to do with the
>>>>>>> warning I get every time
>>>>>>>
>>>>>>> 09-22 13:19:09.302: WARN/System.err(729): Problem creating boot
>>>>>>> delegation
>>>>>>> class loader: java.lang.reflect.InvocationTargetException
>>>>>>>
>>>>>>> just because "boot delegation" is mentioned.
>>>>>>>
>>>>>>> May it help to set the Android and Maps Bundles as Dynamic-Import in
>>>>>>> the
>>>>>>> using Bundle instead of forcing the Bundle to not-import the Package?
>>>>>>> (while
>>>>>>> keeping the configuration in Hostapplication as it is)
>>>>>>>
>>>>>>>
>>>>>>> If still nessesary I will send you the 2 projects. I guess the
>>>>>>> current
>>>>>>> situation has to many bundle dependencies, so I should better build
>>>>>>> an
>>>>>>> easier Example-Bundle combined with my hostapplication to make it
>>>>>>> more
>>>>>>> compact and problem oriented.
>>>>>>>
>>>>>>>
>>>>>>> regards
>>>>>>> Matthias
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Am 22.09.2009 um 12:00 schrieb Karl Pauls:
>>>>>>>
>>>>>>>> Wait a sec, can you place try to set the following property:
>>>>>>>>
>>>>>>>> felix.bootdelegation.implicit=false
>>>>>>>>
>>>>>>>> and see whether that makes your problem go away?
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>
>>>>>>>> Karl
>>>>>>>>
>>>>>>>> On Tue, Sep 22, 2009 at 11:52 AM, Richard S. Hall
>>>>>>>> <[email protected]>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On 9/22/09 11:32, Matthias Neubert wrote:
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I guess I found a problem when using Bootdelegation. In the same
>>>>>>>>>> situation
>>>>>>>>>> the problem does not occur when using ..system.extra to export
>>>>>>>>>> packages
>>>>>>>>>> from
>>>>>>>>>> System bundle.
>>>>>>>>>>
>>>>>>>>>> Context: Android 1.6r1 (DalvikVM) Felix 2.0.0 is embedded. iPOJO
>>>>>>>>>> 1.4
>>>>>>>>>> is
>>>>>>>>>> used
>>>>>>>>>>
>>>>>>>>>> After I ran into a Bug of DalvikVM which is known as "Android
>>>>>>>>>> Issue
>>>>>>>>>> 2711"
>>>>>>>>>> , I tried to solve this using Boot delegation.(because 2711 an
>>>>>>>>>> classloader
>>>>>>>>>> problem in Dalvik VM)
>>>>>>>>>>
>>>>>>>>>> (For me 2711 showed up, when trying to extend a Class in a bundle
>>>>>>>>>> from
>>>>>>>>>> a
>>>>>>>>>> superclass which is imported via ..system.extra. The packge which
>>>>>>>>>> is
>>>>>>>>>> exported by hostapplication (embedding felix) is on classpath of
>>>>>>>>>> the
>>>>>>>>>> hostapplication (in this case: android.jar and maps.jar) Maps.jar
>>>>>>>>>> contains
>>>>>>>>>> the class com.google.android.maps.MapView which is extended in a
>>>>>>>>>> bundle
>>>>>>>>>> which is installed in the embedded felix.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So I switched the project using bootdelegation for all the
>>>>>>>>>> packages
>>>>>>>>>> in
>>>>>>>>>> android.jar and maps.jar. Additional some packages of the
>>>>>>>>>> hostapplication
>>>>>>>>>> and some osgi packages are exported using system.extra.
>>>>>>>>>> These are:
>>>>>>>>>> "org.osgi.framework; version=1.5.0," +
>>>>>>>>>> "org.osgi.service.packageadmin; version=1.2.0," +
>>>>>>>>>> "org.osgi.service.startlevel; version=1.0.0," +
>>>>>>>>>> "org.osgi.service.url; version=1.0.0," +
>>>>>>>>>> "org.osgi.util.tracker," +
>>>>>>>>>> // local defined
>>>>>>>>>> "de.mnsoft.felixhostapp.activityservice,"+
>>>>>>>>>> "de.mnsoft.felixhostapp.appstarter,"+
>>>>>>>>>> "de.mnsoft.felixhostapp.global"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The bundle which extends the class now do NOT import android and
>>>>>>>>>> maps
>>>>>>>>>> Packages, to force it to get them over bootdelegation mechanism.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The Problem:
>>>>>>>>>>
>>>>>>>>>> When running this configuration, as soon the Bundle gets installed
>>>>>>>>>> the
>>>>>>>>>> following happens:
>>>>>>>>>>
>>>>>>>>>> Application hangs for ever in one thread (which is started when
>>>>>>>>>> the
>>>>>>>>>> service tracker noticed the bundle in addingService() and wants to
>>>>>>>>>> get
>>>>>>>>>> the
>>>>>>>>>> service)
>>>>>>>>>>
>>>>>>>>>> This is running for ever (so absolutly no error message arrive,
>>>>>>>>>> debug
>>>>>>>>>> level of felix is 4);
>>>>>>>>>>
>>>>>>>>>> in ModuleImpl.findClassOrRessourceByDelegation() line 677 he uses
>>>>>>>>>>
>>>>>>>>>> searchDynamicImports() line 1443
>>>>>>>>>>
>>>>>>>>>> that calls in libary maps.jar (integrated in android, available on
>>>>>>>>>> classpath of hostapplication)
>>>>>>>>>>
>>>>>>>>>> Class.getClassLoader() line 409 which uses
>>>>>>>>>> BootClassLoader.getInstance();
>>>>>>>>>> and System.getSecurityManager() line 505
>>>>>>>>>>
>>>>>>>>>> finally it hang in
>>>>>>>>>> searchDynamicImports() in line 1443 and 1445 and switches between
>>>>>>>>>> them.
>>>>>>>>>>
>>>>>>>>>> This happens while com.google.android.maps.MapView is processed
>>>>>>>>>>
>>>>>>>>>> The array classes is filled with exactly 100 (remarkable
>>>>>>>>>> coincidence?)
>>>>>>>>>> classes from felix and ipojo. but no android.* or com.google.*
>>>>>>>>>>
>>>>>>>>>> it seems that bootdelegation doesn't work with this libaries
>>>>>>>>>>
>>>>>>>>>> what do you think about this issue and does it have something to
>>>>>>>>>> do
>>>>>>>>>> with
>>>>>>>>>>
>>>>>>>>>> "org.osgi.framework.bundle.parent=app"
>>>>>>>>>>
>>>>>>>>>> I found this to be a new config in R4.2, but Felix wiki offers no
>>>>>>>>>> information about this, but I guess its very important because I
>>>>>>>>>> suffer
>>>>>>>>>> here
>>>>>>>>>> from classloader-trouble in my VM.
>>>>>>>>>> But: Using the new key or not doesn't change the situation.
>>>>>>>>>
>>>>>>>>> You can try to change this value and see if it has any impact.
>>>>>>>>> Dalvik
>>>>>>>>> is
>>>>>>>>> a
>>>>>>>>> little odd in this area, so we had to put some workarounds in there
>>>>>>>>> to
>>>>>>>>> even
>>>>>>>>> get it to work.
>>>>>>>>>
>>>>>>>>> -> richard
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> regards
>>>>>>>>>> Matthias
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Karl Pauls
>>>>>>>> [email protected]
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> [email protected]
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> [email protected]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
--
Karl Pauls
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
