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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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" <[email protected]> wrote: >>>>> >>>>>> I'll try to look into it tonight. >>>>>> >>>>>> regards, >>>>>> >>>>>> Karl >>>>>> >>>>>> On Tue, Feb 16, 2010 at 12:54 PM, Jackson, Bruce <[email protected]> >>>>>> 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" <[email protected]> wrote: >>>>>>> >>>>>>>> org.mortbay.jetty.servlet.ServletHandler >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Karl Pauls >>>> [email protected] >>>> >>> >>> >> >> > >
