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. Whentrue, 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, KarlSo no solution from that option. I will try to change my embedding using thenew FrameworkFactory way, but as far I can the this only wrapsthe 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'tchange 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 ofLde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView; (20) 09-22 13:08:22.829: WARN/dalvikvm(726): Link of class 'Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView;' failed09-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 methodde .mnsoft .mapprovider.gmapsimpl.MapProviderServiceImpl.__generateMapView 09-22 13:08:24.719: WARN/dalvikvm(726): VFY: unable to resolve check-cast19 (Lcom/google/android/maps/MapActivity;) in Lde/mnsoft/mapprovider/gmapsimpl/MapProviderServiceImpl;09-22 13:08:24.719: WARN/dalvikvm(726): VFY: rejecting opcode 0x1f at0x0008 09-22 13:08:24.719: WARN/dalvikvm(726): VFY: rejectedLde/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): atorg .apache .felix.ipojo.InstanceManager.createObject(InstanceManager.java:583)...I still can't get rid of the feeling that this all has to do with thewarning I get every time09-22 13:19:09.302: WARN/System.err(729): Problem creating boot delegationclass 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? (whilekeeping 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 morecompact 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 situationthe problem does not occur when using ..system.extra to export packagesfrom System 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 Issue2711" , 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 fromasuperclass 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 containsthe 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 inandroid.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 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 the service tracker noticed the bundle in addingService() and wants to getthe service)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 1443that calls in libary maps.jar (integrated in android, available onclasspath 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 dowith "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 sufferhere 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 isalittle odd in this area, so we had to put some workarounds in there toeven get 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]--------------------------------------------------------------------- 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]
