felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <karlpa...@gmail.com>
Subject Re: Felix on Android
Date Wed, 17 Feb 2010 16:49:08 GMT
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 <brucej@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" <karlpauls@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 <brucej@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" <karlpauls@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 <karlpauls@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 <brucej@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" <karlpauls@gmail.com> wrote:
>>>>>>
>>>>>>> I'll try to look into it tonight.
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Karl
>>>>>>>
>>>>>>> On Tue, Feb 16, 2010 at 12:54 PM, Jackson, Bruce <brucej@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" <brucej@qualcomm.com>
wrote:
>>>>>>>>
>>>>>>>>> org.mortbay.jetty.servlet.ServletHandler
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>



-- 
Karl Pauls
karlpauls@gmail.com

Mime
View raw message