That was just the plain android adb logcat output. It works even if you start your own vm.
regards, Karl On Mon, Feb 22, 2010 at 12:09 PM, Jackson, Bruce <bru...@qualcomm.com> wrote: > When I was discussing with Karl the other day, he provided me with the debug > output below showing the classloading behaviour. Does anyone know if this > came from Felix or Dalvik debug tools, and whether I can see the > classloading behavior in Felix? > > > On 17/02/2010 16:49, "Karl Pauls" <karlpa...@gmail.com> wrote: > >> As I said, it will only happen if you have the importing classes and >> the exporting classes dexed into the same classes.dex. In your jdom >> case that should not happen as the embedded jar will have it's own >> classes.dex so that the "root" classes.dex of your bundle is different >> from the embedded one (again, that is the hack you can use to work >> around this issue in general). >> >> regards, >> >> Karl >> >> On Wed, Feb 17, 2010 at 5:32 PM, Jackson, Bruce <bru...@qualcomm.com> wrote: >>> Hi Karl >>> >>> That's great, thanks! I've got it working too now. Obviously the >>> classloading mechanism in Dalvik is different to a regular jvm, as you don't >>> see this problem in Felix on the JVM. >>> >>> Is this likely to cause a similar problem in bundles which have been built >>> with an embedded jar (imagine I place something like jdom into a bundle) and >>> the framework also has a jdom bundle installed? >>> >>> Thanks again >>> >>> Bruce >>> >>> On 16/02/2010 23:40, "Karl Pauls" <karlpa...@gmail.com> wrote: >>> >>>> Wait, i got it working (i.e., i get to the point where your example >>>> fails). The reason is this: >>>> >>>> W/dalvikvm( 326): Class resolved by unexpected DEX: >>>> Lorg/mortbay/jetty/servlet/ServletHandler$Context;(0x400a0288):0x68578 >>>> ref [Ljavax/servlet/ServletContext;] >>>> Ljavax/servlet/ServletContext;(0x4002eec0):0x5ef48 >>>> W/dalvikvm( 326): (Lorg/mortbay/jetty/servlet/ServletHandler$Context; >>>> had used a different Ljavax/servlet/ServletContext; during >>>> pre-verification) >>>> I/dalvikvm( 326): Failed resolving >>>> Lorg/mortbay/jetty/servlet/ServletHandler$Context; interface 195 >>>> 'Ljavax/servlet/ServletContext;' >>>> W/dalvikvm( 326): Link of class >>>> 'Lorg/mortbay/jetty/servlet/ServletHandler$Context;' failed >>>> E/dalvikvm( 326): ERROR: defineClass(0x400a0288, >>>> org.mortbay.jetty.servlet.ServletHandler$Context, 0x401d6268, 0, 6067, >>>> 0x401b4b28) >>>> >>>> The problem is as follows: the http jetty bundle contains its own >>>> version of the javax.servlet packages. When you are dexing that >>>> bundle. You are including this version inside the classes.dex. Now, in >>>> your set-up, you are importing them at runtime from the javax.servlet >>>> bundle. That causes the above problem (as the dex is already bound). >>>> If you uninstall the javax.servlet bundle (and change the import >>>> version constraint inside your test bundle for the javax.servlet* >>>> packages to be 2.3.0 instead of 2.4.0 - in which case it will resolve >>>> to the http bundle). Then it works: >>>> >>>> -> ps >>>> START LEVEL 1 >>>> ID State Level Name >>>> [ 0] [Active ] [ 0] System Bundle (2.0.3) >>>> [ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.2) >>>> [ 2] [Active ] [ 1] Apache Felix Shell TUI (1.0.2) >>>> [ 5] [Active ] [ 1] Apache Felix Log Service (1.0.0) >>>> [ 6] [Active ] [ 1] HTTP Service (0.8.0.SNAPSHOT) >>>> [ 7] [Active ] [ 1] Apache Felix Configuration Admin Service >>>> (1.2.4) >>>> [ 10] [Installed ] [ 1] Httptest (1.0.0.201002151713) >>>> -> start 10 >>>> Feb 16, 2010 11:29:22 PM java.io.BufferedWriter <init> >>>> INFO: Default buffer size used in BufferedWriter constructor. It would >>>> be better to be explicit if an 8k-char buffer is required. >>>> DEBUG: WIRE: 10.0 -> javax.servlet -> 6.0 >>>> DEBUG: WIRE: 10.0 -> org.osgi.service.http -> 6.0 >>>> DEBUG: WIRE: 10.0 -> org.osgi.framework -> 0 >>>> DEBUG: WIRE: 10.0 -> javax.servlet.http -> 6.0 >>>> DEBUG: javax/servlet/http/LocalStrings_en_US.properties >>>> DEBUG: javax/servlet/http/LocalStrings_en.properties >>>> DEBUG: org/mortbay/http/mime_en_US.properties >>>> DEBUG: org/mortbay/http/mime_en.properties >>>> DEBUG: org/mortbay/http/encoding_en_US.properties >>>> DEBUG: org/mortbay/http/encoding_en.properties >>>> 23:29:23.644 EVENT Started ServletHttpContext[/] >>>> >>>> The point is this: if you are dexing a bunch of classes, they will >>>> already know about each other and then can't be imported from some >>>> place else. The workaround in this case would be to remove the >>>> javax.servlet* packages from the http bundle in the first place or (in >>>> case you need the optionality) make them a separate jar, dex it, and >>>> put it on the bundleclasspath of the http bundle (this way, the rest >>>> of the http bundle classes are not dexed together with the imported >>>> javax.servlet classes in the same dex). >>>> >>>> No bug in felix or a problem with the complier level. Its just one of >>>> the points where dalvik is working differently than java... sorry, >>>> nothing i can do about that. You will need to be careful when you are >>>> dexing bundles to not dex classes inside the bundle that can be >>>> substituted by an import together with the other classes of the bundle >>>> (either remove them or create a dexed jar on the bundleclasspath for >>>> these classes). >>>> >>>> regards, >>>> >>>> Karl >>>> >>>> On Tue, Feb 16, 2010 at 4:37 PM, Jackson, Bruce <bru...@qualcomm.com> >>>> wrote: >>>>> Hi Karl >>>>> >>>>> I just tried that, and it makes no difference. >>>>> I'll mail you the bundles as discussed in a couple of minutes. >>>>> >>>>> Thanks >>>>> >>>>> Bruce >>>>> >>>>> >>>>> On 16/02/2010 15:33, "Karl Pauls" <karlpa...@gmail.com> wrote: >>>>> >>>>>> Btw. can you first try to set the following property: >>>>>> >>>>>> org.osgi.framework.bundle.parent=framework >>>>>> >>>>>> and see whether that makes a difference on android? >>>>>> >>>>>> regards, >>>>>> >>>>>> Karl >>>>>> >>>>>> On Tue, Feb 16, 2010 at 2:11 PM, Karl Pauls <karlpa...@gmail.com> wrote: >>>>>>> Yeah, if you could zip your project and send it to me in private mail >>>>>>> (list probably wont accept it) - that would be a good start. >>>>>>> >>>>>>> regards, >>>>>>> >>>>>>> Karl >>>>>>> >>>>>>> On Tue, Feb 16, 2010 at 1:53 PM, Jackson, Bruce <bru...@qualcomm.com> >>>>>>> wrote: >>>>>>>> Thanks Karl. Would it help if I zipped the jetty and test bundle I'm >>>>>>>> using? >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Bruce >>>>>>>> >>>>>>>> >>>>>>>> On 16/02/2010 12:51, "Karl Pauls" <karlpa...@gmail.com> wrote: >>>>>>>> >>>>>>>>> I'll try to look into it tonight. >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> >>>>>>>>> Karl >>>>>>>>> >>>>>>>>> On Tue, Feb 16, 2010 at 12:54 PM, Jackson, Bruce <bru...@qualcomm.com> >>>>>>>>> wrote: >>>>>>>>>> Further to this, I have explored the problem some more. Using the >>>>>>>>>> dedexer >>>>>>>>>> tool (http://dedexer.sourceforge.net/) I can examine the classes that >>>>>>>>>> have >>>>>>>>>> been put into the classes.dex in the Jetty Http service bundle. I can >>>>>>>>>> see >>>>>>>>>> in >>>>>>>>>> the bundle that I do indeed have the required classes in the dex >>>>>>>>>> file: >>>>>>>>>> >>>>>>>>>> Processing org/mortbay/jetty/servlet/ServletHandler >>>>>>>>>> Processing org/mortbay/jetty/servlet/ServletHolder$Config >>>>>>>>>> Processing org/mortbay/jetty/servlet/OsgiServletHttpContext >>>>>>>>>> Processing org/mortbay/jetty/servlet/ServletHandler$Context >>>>>>>>>> >>>>>>>>>> This is a mystery. Any ideas anyone? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 16/02/2010 10:12, "Bruce Jackson" <bru...@qualcomm.com> wrote: >>>>>>>>>> >>>>>>>>>>> org.mortbay.jetty.servlet.ServletHandler >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Karl Pauls >>>>>>> karlpa...@gmail.com >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -- Karl Pauls karlpa...@gmail.com
