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]
