Great, thanks Karl.
On 22/02/2010 12:04, "Karl Pauls" <[email protected]> wrote: > 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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" <[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] >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
