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]
