[jdom-interest] JDOM and Android

Rolf Lear jdom at tuis.net
Thu Apr 19 06:40:12 PDT 2012


Hi Mike.

Could be for a few reasons..... but, I think there are three types of
issues that I have encountered:
- Android 'paradigms' and 'nuances' that impact actual core JDOM
Operation, but that I have been able to adapt to / workaround by changing
JDOM code - and the JDOM code now produces the 'correct' results.
- Android 'issues' that have impacted core JDOM functionality, but I have
not yet been able to work around, or I do not expect to be able to work
around.
- Android issues related to *testing* the JDOM core that I have worked
around.

While I have not been consistent in my approach, I only think there is a
'significant' problem if it falls in to the second category - issues that
affect JDOM functionality that are unrelated to the actual testing process.

As such, the issues I have had with URLs/Files/Assets/Resources are not
actually impacting JDOM functionality.... just my ability to test it.

For the record though, Android *does* have a file-system that is
accessible by regular Android apps. The issue is that I have found it very
hard to actually get my test data loaded in to that system. Once it is
there though, it all works as expected.

If you are interested, in regular JDOM testing, these XML and XML support
files are embedded in the JDOM-junit jar, and accessed (typically as a URL)
using ClassLoader.getSystemResource().

In order to access them in Android through, I am:
- harvesting the test data from the jar.
- loading them in to the android 'assets' file.
- when the JUnit tests start in Android the assets are copied from the
assets location to the 'cache' Android FileSystem directory.
- when tests request URL's the URL for the file in the 'cache' android
folder is returned.
- If a test requests just an InputStream, a FileInputStream is returned
instead.

So, bottom line is that, while the FileSystem/ClassLoader problems have
been a real issue, it has been a testing issue only, not a functionality
issue.

So, I should only be reporting/documenting issues of the second type:
Functionality that is normally available in JDOM that does not work the
same way (or at all) when used on Android.

Maybe I should add some comments to the page though about some of the
issues I have resolved, rather than just the issues I have
yet-to-resolve...

Rolf



On Thu, 19 Apr 2012 11:22:47 +0000, "Brenner, Mike" <mikeb at mitre.org>
wrote:
> Hi Rolf,
> 	As always, your notes have value far beyond just the jdom 
> list. I would therefore like to ask the following question. Why does the
> lack of support for an ordinary java file system no longer appear
> on you Android list of issues?
> 
> 	Thanks for answering this partially unrelated question.
> 
> Mike Brenner
> 
> 
> 
> -----Original Message-----
> From: jdom-interest-bounces at jdom.org
> [mailto:jdom-interest-bounces at jdom.org] On Behalf Of Rolf Lear
> Sent: Wednesday, April 18, 2012 9:32 PM
> To: jdom
> Subject: Re: [jdom-interest] JDOM and Android
> 
> Hi all.
> 
> Just reporting some progress on the Android testing.
> 
> I have put together a document here:
> https://github.com/hunterhacker/jdom/wiki/JDOM2-and-Android
> 
> I believe I have narrowed down the testing issues a lot. Here is the 
> test summary:
> 
>       [exec] FAILURES!!!
>       [exec] Tests run: 1629,  Failures: 0,  Errors: 55
> 
> The Regular JDOM stream has 1800 tests (of which 33 are ignored). The 
> difference to 1629 tests is a result of skipping the StAX tests and some

> illegal UniCode tests.
> 
> The remaining 55 failing tests fail for one of the following reasons:
> - Android cannot process XMLSchema validation.
> - Android does not give the SAXHandler the 'internal subset' part of a 
> DocType declaration.
> - Some of the JDOM unit tests use the JUnit4 concept of 'assume'. I have

> not yet coded the JUnit3 wrappers to accommodate these failing
assumptions.
> - Android's implementation of java.util.List has slightly different 
> handling for ConcurrentModificationException.
> 
> Bottom line is:
> with some pending fixes, JDOM 2.x is functional on Android.
> The only issues I expect to be significant are:
> - XMLSchema validation
> 
> I am working on:
>   - testing with the Xerces parser to resolve DTD issues
>   - using Xerces's custom XSDSchema Schema for XSD validation
>   - handling JUnit 'assumptions'
> 
> Onc complete this should resolve the issues to close to zero.
> 
> Rolf
> 
> 
> On 17/04/2012 11:58 PM, Rolf Lear wrote:
>> Hi all.
>>
>> So, using the 'Asset' mechanism works, even though it is a fantastic
>> pain in the posterior.
>>
>> No, here are the major issues:
>>
>> Android does not support XML Schema validation
>> ==============================================
>>
>> This i the most significant issue because it causes XMLReaders
>> enumeration to fail:
>>
>> The documentation for ...
>> SchemaFactory.newInstance(XMLConstants.W2C_XML_SCHEMA_NS_URI)
>> ... is ...
>> To be compliant with the spec, the implementation is only required to
>> support W3C XML Schema 1.0
>>
>> But, Android does not..... thus the Enum fails, thus nothing can be
>> parsed... ;-)
>>
>> I have temporarily 'fixed' it by making only the XSD-based test fail,
>> instead of failing *everything* that is parsed....
>>
>>
>> Android does not supply StAX bundles.
>> =====================================
>>
>> Fixed by removing StAX tests.
>>
>>
>>
>>
>> For the moment though, it would seem a preliminary statement is:
>>
>> with some fixes, JDOM 2.0.1 will have full functionality except:
>> DTD - Internal-subset: SAX Parser does not supply it to JDOM
>> XSD Validation is not possible (there are work-arounds...)
>> StAX support not available.
>>
>>
>>
>> Rolf
>>
>>
>> On 17/04/2012 1:15 AM, Joe Bowbeer wrote:
>>> The other approach is to copy the assets to the file system when the
apk
>>> is first started and then read the resources from the file system at
>>> runtime.
>>>
>>> The file system URLs are of the form /data/data/<package-id>/files/
>>>
>>> See
>>>
http://developer.android.com/reference/android/content/Context.html#getFilesDir()
>>>
>>>
>>>
>>> --Joe
>>>
>>> On Mon, Apr 16, 2012 at 9:51 PM, Rolf Lear wrote:
>>>
>>> I have been down that road, and it does not work....
>>>
>>> Because the file URL's are still not readable.... here's a test
trace...
>>> Note how the failure is buried in a 'caused by' where the important
>>> lines are:
>>>
>>> Caused by: java.io.FileNotFoundException:
>>> /android_asset/xsdcomplex/__multi_main.xsd: open failed: ENOENT (No
>>> such file or directory)
>>> at libcore.io.IoBridge.open(__IoBridge.java:406)
>>> at java.io.FileInputStream.<init>__(FileInputStream.java:78)
>>> at
>>>
libcore.net.url.__FileURLConnection.connect(__FileURLConnection.java:82)
>>> at
>>>
libcore.net.url.__FileURLConnection.__getInputStream(__FileURLConnection.java:181)
>>>
>>> at java.net.URL.openStream(URL.__java:462)
>>> at
>>>
org.jdom2.input.sax.__XMLReaderXSDFactory.__getSchemaFromURL(__XMLReaderXSDFactory.java:195)
>>>
>>> ... 15 more
>>>
>>>
>>>
>>> org.jdom2.JDOMException: Unable to read Schema URL
>>> file:///android_asset/__xsdcomplex/multi_main.xsd
>>> at
>>>
org.jdom2.input.sax.__XMLReaderXSDFactory.__getSchemaFromURL(__XMLReaderXSDFactory.java:197)
>>>
>>> at
>>>
org.jdom2.input.sax.__XMLReaderXSDFactory.<init>(__XMLReaderXSDFactory.java:272)
>>>
>>> at
>>>
org.jdom2.test.cases.input.__sax.TestXMLReaderXSDFactory.__testXMLReaderXSDFactoryFileArr__ay(TestXMLReaderXSDFactory.__java:80)
>>>
>>> at
>>>
org.jdom2.test.cases.input.__sax.TestXMLReaderXSDFactoryTT.__testXMLReaderXSDFactoryFileArr__ay(TestXMLReaderXSDFactoryTT.__java:28)
>>>
>>> at java.lang.reflect.Method.__invokeNative(Native Method)
>>> at
>>> android.test.__AndroidTestRunner.runTest(__AndroidTestRunner.java:169)
>>> at
>>> android.test.__AndroidTestRunner.runTest(__AndroidTestRunner.java:154)
>>> at
>>>
android.test.__InstrumentationTestRunner.__onStart(__InstrumentationTestRunner.__java:545)
>>>
>>> at
>>>
android.app.Instrumentation$__InstrumentationThread.run(__Instrumentation.java:1551)
>>>
>>> Caused by: java.io.FileNotFoundException:
>>> /android_asset/xsdcomplex/__multi_main.xsd: open failed: ENOENT (No
>>> such file or directory)
>>> at libcore.io.IoBridge.open(__IoBridge.java:406)
>>> at java.io.FileInputStream.<init>__(FileInputStream.java:78)
>>> at
>>>
libcore.net.url.__FileURLConnection.connect(__FileURLConnection.java:82)
>>> at
>>>
libcore.net.url.__FileURLConnection.__getInputStream(__FileURLConnection.java:181)
>>>
>>> at java.net.URL.openStream(URL.__java:462)
>>> at
>>>
org.jdom2.input.sax.__XMLReaderXSDFactory.__getSchemaFromURL(__XMLReaderXSDFactory.java:195)
>>>
>>> ... 15 more
>>> Caused by: libcore.io.ErrnoException: open failed: ENOENT (No such
>>> file or directory)
>>> at libcore.io.Posix.open(Native Method)
>>> at libcore.io.BlockGuardOs.open(__BlockGuardOs.java:110)
>>> at libcore.io.IoBridge.open(__IoBridge.java:390)
>>> ... 20 more
>>>
>>>
>>>
>>>
>>>
>>> On 17/04/2012 12:00 AM, Joe Bowbeer wrote:
>>>
>>> You'll need to put the data in assets
>>>
>>>
http://stackoverflow.com/__questions/4820816/how-to-get-__uri-from-an-asset-file
>>>
>>>
<http://stackoverflow.com/questions/4820816/how-to-get-uri-from-an-asset-file>
>>>
>>>
>>>
http://stackoverflow.com/__questions/4789325/android-__path-to-asset-txt-file
>>>
>>>
<http://stackoverflow.com/questions/4789325/android-path-to-asset-txt-file>
>>>
>>>
>>> and use getResources().getAssets().__open()
>>>
>>> Or you could put the data in res/raw and use
>>> getResources().__openRawResource()
>>>
>>> .. but res/raw does not support a nested file structure.
>>>
>>> Or maybe you could do something crazy with a custom class loader:
>>>
>>>
http://android-developers.__blogspot.com/2011/07/custom-__class-loading-in-dalvik.html
>>>
>>>
<http://android-developers.blogspot.com/2011/07/custom-class-loading-in-dalvik.html>
>>>
>>>
>>>
>>> --Joe
>>>
>>>
>>> On Mon, Apr 16, 2012 at 8:08 PM, Rolf Lear <jdom at tuis.net
>>> <mailto:jdom at tuis.net>
>>> <mailto:jdom at tuis.net <mailto:jdom at tuis.net>>> wrote:
>>>
>>> Hi all.
>>>
>>> I am having some limited success with the Android testing. I
>>> have
>>> run in to an issue through which could really use some input
>>> from
>>> experienced Android developers.
>>>
>>> Are there any on JDOM-interest with some time to spare?
>>>
>>> My issue right now is that the JUnit tests are mostly
>>> passing, but a
>>> number of them rely on using
>>> ClassLoader.getSystemResource(____"path/to/file.xml") to load
>>>
>>> resources as a URL.
>>>
>>> It is improtant to keep it as a URL because many of these
>>> tests rely
>>> on internal DTD's and XSD's, which, in turn mean that when
>>> they are
>>> processed the input file's URL will be used as a base for a
>>> relative
>>> location of the DTD/XSD.
>>>
>>> In other words, I need to keep access to these files as a
>>> URL....
>>>
>>> But, ClassLoader.getSystemResource(____...) is returning
>>> null on Android.
>>>
>>>
>>> I think it is related to
>>> http://code.google.com/p/____android/issues/detail?id=10076
>>> <http://code.google.com/p/__android/issues/detail?id=10076>
>>>
>>> <http://code.google.com/p/__android/issues/detail?id=10076
>>> <http://code.google.com/p/android/issues/detail?id=10076>__>
>>>
>>> But, I can't find a good way to work around the issue....
>>>
>>> So, If there's some experienced Android developer who can
>>> shed some
>>> light in to this particular dark place, I would appreciate it.
>>>
>>> For the record, I have a full test-suite available for any
>>> Android
>>> developers who happen to use eclipse. It fully compiled,
>>> loads, and
>>> I am running a 'Test' Project on a 4.0.3 emulator.
>>>
>>> I can, in theory, help you bootstrap the environment in your
>>> eclipse
>>> pretty easily... if needed.
>>>
>>> Rolf
>>>
>>>
>>>
>>
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com
>>
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com


More information about the jdom-interest mailing list