On Tue, Sep 22, 2009 at 10:22 PM, Karl Pauls <[email protected]> wrote:
> 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.
Correction, I figured out the problem. Bootdelegation does work
correctly. All you have to do is use "framework" instead of "app".
That gets me to the mentioned Nullpointer with bootdelegation (you
still need the implicit=false so).
regards,
Karl
> 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]
>
--
Karl Pauls
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
