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]
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>



-- 
Karl Pauls
[email protected]

Reply via email to