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]
