On Wed, Jul 8, 2009 at 2:12 PM, Matthias Neubert<sur...@onlinehome.de> wrote: > Hello, > > I add Fileinstall, because my Android HostApplication with its embedded > Felix shall > watch a directory on the Android Phone where new Bundles are stored to. > I'm following mostly the iPojo+Android Sample on: > http://ipojo-dark-side.blogspot.com/2008/10/ipojo-on-android.html . > > For that I add Fileinstall Dir to Felix' config like this: > > configProps.put(DirectoryWatcher.DIR, absFilePath+"/felix/bundle"); > //"felix.fileinstall.dir" > configProps.put(DirectoryWatcher.DEBUG, "1"); //"felix.fileinstall.debug"
Workaround: just set the property as a string for the key and install the fileinstall bundle into felix. That should make it work. > In the HostApplication it self I use FileInstall the following way: > > Adding FileInstall to AutoStart with System Bundle: > > List<BundleActivator> activatorList = new ArrayList<BundleActivator>(); > activatorList.add(m_hostActivator); > > activatorList.add(new FileInstall()); > > // add list of activators which shall be started with system bundle to > config > m_felixProperties.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, > activatorList); > > > Equipped with fileinstall I guess the ServiceTracker (see iPojo+Android > Sample) notices when a bundle > copied to the watched directory is installed and started (by fileinstall) > > If there is an other way, please tell me! (generally I have some problems > understanding that loose coupling thing in Felix and iPojo. I have to read > more regarding this issue.) > > The thing I wonder about is why this problem occurs in 1.9.0 but not in > 1.8.0. Why I an class defined in fileinstall (with identical name an > package) also defined in felix 1.9.0? I'm not sure (would have to look at it first) but it is pretty common in OSGi land to have bundles that have some shared packages embedded to make them working standalone and when they can get the package from another provider. > As far as I know the dexer stops at the first problem. So it may be that > > Lorg/osgi/service/log/LogEntry; > > is not the only problem. It also may happen at other Jars than > fileinstall.jar > > I don't know about visibility filters in eclipse. I will try to find out. > But I think it's not a real solution to do it that way. Sounds like a bug/problem with android or their eclipse integration to me. regards, Karl > > regards > Matthias > > > > > > Am 08.07.2009 um 13:00 schrieb Karl Pauls: > >> Well, why would you want to add fileinstall in the first place? You >> could just dex it and then install as a bundle no? >> >> Regarding the issue, it looks like the dex compiler can't handle >> multiple definitions of the same class in one compile. Thats not nice >> but not the end of the world either I guess. If you have to have both >> felix and fileinstall on the classpath then maybe try to set-up a >> visibility filter for one of them that filters out the package in >> question. >> >> regards, >> >> Karl >> >> On Wed, Jul 8, 2009 at 12:30 PM, Matthias Neubert<sur...@onlinehome.de> >> wrote: >>> >>> Hello, >>> >>> I've tried your patch and it worked! Thank you! >>> >>> BUT: >>> >>> There is another Problem which only occur in all 1.9.0 snapshots (4. , >>> 7., >>> 8. july), but NOT with 1.8.0 : >>> >>> If I add in my Android Project in Eclipse the fileinstall.jar (1.2.0 or >>> current snapshot) to classpath while >>> having Felix 1.9.0 on classpath (as a referenced lib ) I get folling >>> Error >>> when Eclipse tries to build the project (right after adding) >>> >>> -> this does not happen with Felix 1.8.0 >>> >>> -> I can add fileinstall.jar without problems if no felix.jar is added >>> >>> -> if adding fileinstall.jar first, then adding felix.jar, the same >>> problem >>> occurs >>> >>> -> problem also occurs in a completly fresh android project >>> >>> >>> >>> >>> >>> >>> >>> UNEXPECTED TOP-LEVEL EXCEPTION: >>> java.lang.IllegalArgumentException: already added: >>> Lorg/osgi/service/log/LogEntry; >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:123) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> com.android.dx.dex.file.DexFile.add(DexFile.java:143) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> com.android.dx.command.dexer.Main.processClass(Main.java:299) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> com.android.dx.command.dexer.Main.processFileBytes(Main.java:276) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> com.android.dx.command.dexer.Main.access$100(Main.java:56) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:228) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> >>> com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:245) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> >>> com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:130) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> >>> com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:108) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> com.android.dx.command.dexer.Main.processOne(Main.java:245) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> com.android.dx.command.dexer.Main.processAllFiles(Main.java:183) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> com.android.dx.command.dexer.Main.run(Main.java:139) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> java.lang.reflect.Method.invoke(Method.java:585) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> com.android.ide.eclipse.adt.build.DexWrapper.run(Unknown Source) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> com.android.ide.eclipse.adt.build.ApkBuilder.executeDx(Unknown Source) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> com.android.ide.eclipse.adt.build.ApkBuilder.build(Unknown Source) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> >>> org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:633) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> >>> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> >>> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> >>> org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> >>> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> >>> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:309) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> >>> org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:341) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> >>> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:140) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] at >>> org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] 1 error; aborting >>> [2009-07-08 11:34:48 - FelixEmbedAndroid] Conversion to Dalvik format >>> failed >>> with error 1 >>> >>> >>> >>> regards >>> Matthias >>> >>> >>> >>> >>> >>> Am 07.07.2009 um 22:54 schrieb Richard S. Hall: >>> >>>> Ok, I have committed a potential workaround as described here: >>>> >>>> https://issues.apache.org/jira/browse/FELIX-1193 >>>> >>>> If you could test again on trunk and respond on the issue that would be >>>> great. Thanks! >>>> >>>> -> richard >>>> >>>> On 7/7/09 4:10 PM, Karl Pauls wrote: >>>>> >>>>> Looks like a bug in android. Or at least it is something where sun >>>>> java behaves differently then dalvik/android. Anyways, we should be >>>>> able to workaround this. We will track this using FELIX-1193. Thanks >>>>> for letting us know! >>>>> >>>>> regards, >>>>> >>>>> Karl >>>>> >>>>> On Tue, Jul 7, 2009 at 7:42 PM, Matthias Neubert<sur...@onlinehome.de> >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> since nobody answered on my first mail (subject "Android + Felix 1.80 >>>>>> = >>>>>> Problems") >>>>>> I took the long way and found the solution on my own. It took a bit >>>>>> longer >>>>>> because I'm completely new to OSGi and felix. >>>>>> >>>>>> First the solution on that one thing, then the current bug: >>>>>> >>>>>> Solution: >>>>>> Felix 1.8.0 release doesn't have the patch for Android compatible >>>>>> Classloading ( before I thought it has it already), so in adb shell >>>>>> the >>>>>> command "chmod 777 /data/dalvik-cache" has to be executed (which shows >>>>>> us, >>>>>> that this will not work on a real phone) >>>>>> >>>>>> -> with Felix 1.8.0 and the little "hack" it now runs and its >>>>>> starting >>>>>> Bundles. This is the first step getting the outdated ipojo sample >>>>>> running. >>>>>> May be some more work is left. >>>>>> -> without the hack, systembundle and ipojo.annotations get active, >>>>>> but >>>>>> for >>>>>> example shell, shelltui and iPojo remain resolved and doesn't start. >>>>>> >>>>>> >>>>>> Problem/Bug: >>>>>> occures when I try run Felix 1.9.0 Snapshot as embedded in an Android >>>>>> Application.(same project as mentioned above, just switched classpath >>>>>> to >>>>>> newer jar file) >>>>>> The access-rights-hack doesn't help here, so it must be a bug or >>>>>> something >>>>>> like that. >>>>>> >>>>>> If someone is interested in this bug, I can send my eclipse project, >>>>>> if >>>>>> needed >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Here is the stacktrace: (from DDMS Android Debugger) >>>>>> >>>>>> 07-07 19:02:31.133: WARN/dalvikvm(1187): Exception >>>>>> Ljava/lang/RuntimeException; thrown during >>>>>> Lorg/apache/felix/framework/ModuleImpl;.<clinit> >>>>>> >>>>>> 07-07 19:02:36.108: WARN/ActivityManager(600): Launch timeout has >>>>>> expired, >>>>>> giving up wake lock! >>>>>> 07-07 19:02:36.553: WARN/ActivityManager(600): Activity idle timeout >>>>>> for >>>>>> HistoryRecord{435f61b0 >>>>>> {de.mn.felixembedand/de.mn.felixembedand.FelixEmbedAndStarter}} >>>>>> 07-07 19:02:36.858: DEBUG/AndroidRuntime(1187): Shutting down VM >>>>>> >>>>>> 07-07 19:02:36.858: WARN/dalvikvm(1187): threadid=3: thread exiting >>>>>> with >>>>>> uncaught exception (group=0x4000fe70) >>>>>> 07-07 19:02:36.864: ERROR/AndroidRuntime(1187): Uncaught handler: >>>>>> thread >>>>>> main exiting due to uncaught exception >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): >>>>>> java.lang.ExceptionInInitializerError >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> >>>>>> >>>>>> org.apache.felix.framework.ExtensionManager.<init>(ExtensionManager.java:142) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> org.apache.felix.framework.Felix.<init>(Felix.java:302) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> >>>>>> >>>>>> de.mn.felixembedand.FelixEmbedAndStarter.onCreate(FelixEmbedAndStarter.java:77) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> >>>>>> >>>>>> android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1123) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> >>>>>> >>>>>> android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2231) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> >>>>>> >>>>>> android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2284) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> android.app.ActivityThread.access$1800(ActivityThread.java:112) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> android.app.ActivityThread$H.handleMessage(ActivityThread.java:1692) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> android.os.Handler.dispatchMessage(Handler.java:99) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> android.os.Looper.loop(Looper.java:123) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> android.app.ActivityThread.main(ActivityThread.java:3948) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> java.lang.reflect.Method.invokeNative(Native Method) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> java.lang.reflect.Method.invoke(Method.java:521) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> >>>>>> >>>>>> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:782) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> com.android.internal.os.ZygoteInit.main(ZygoteInit.java:540) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> dalvik.system.NativeStart.main(Native Method) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): Caused by: >>>>>> java.lang.RuntimeException: Problem creating boot delegation class >>>>>> loader. >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> org.apache.felix.framework.ModuleImpl.<clinit>(ModuleImpl.java:114) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): ... 16 more >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): Caused by: >>>>>> java.lang.reflect.InvocationTargetException >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> java.security.SecureClassLoader.<init>(SecureClassLoader.java:76) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> java.lang.reflect.Constructor.constructNative(Native Method) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> java.lang.reflect.Constructor.newInstance(Constructor.java:446) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> >>>>>> >>>>>> org.apache.felix.framework.util.SecureAction.invoke(SecureAction.java:862) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> org.apache.felix.framework.ModuleImpl.<clinit>(ModuleImpl.java:109) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): ... 16 more >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): Caused by: >>>>>> java.lang.NullPointerException: Parent ClassLoader may not be null >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> java.lang.ClassLoader.<init>(ClassLoader.java:239) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): at >>>>>> java.lang.ClassLoader.<init>(ClassLoader.java:226) >>>>>> 07-07 19:02:37.043: ERROR/AndroidRuntime(1187): ... 21 more >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> My Config: >>>>>> Eclipse 3.4 >>>>>> Android SDK 1.5r2 >>>>>> ADT 0.91 (current) >>>>>> Java SDK: JVM 1.5.0 MacOS X >>>>>> >>>>>> >>>>>> regards >>>>>> matthias >>>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >> >> >> >> -- >> Karl Pauls >> karlpa...@gmail.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> > > -- Karl Pauls karlpa...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
