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, KarlOn 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 fromSystem bundle.Context: Android 1.6r1 (DalvikVM) Felix 2.0.0 is embedded. iPOJO 1.4 isusedAfter 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 classloaderproblem in Dalvik VM)(For me 2711 showed up, when trying to extend a Class in a bundle from asuperclass which is imported via ..system.extra. The packge which is exported by hostapplication (embedding felix) is on classpath of thehostapplication (in this case: android.jar and maps.jar) Maps.jar contains the class com.google.android.maps.MapView which is extended in a bundlewhich 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 hostapplicationand 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 mapsPackages, to force it to get them over bootdelegation mechanism. The Problem:When running this configuration, as soon the Bundle gets installed thefollowing happens: Application hangs for ever in one thread (which is started when theservice tracker noticed the bundle in addingService() and wants to get theservice)This is running for ever (so absolutly no error message arrive, debuglevel 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 insearchDynamicImports() in line 1443 and 1445 and switches between them.This happens while com.google.android.maps.MapView is processedThe 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 libarieswhat 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 noinformation about this, but I guess its very important because I suffer herefrom 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 evenget it to work. -> richardregards 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]
