[jdom-interest] JDOM and Android
Brenner, Mike
mikeb at mitre.org
Thu Apr 19 04:22:47 PDT 2012
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