[jdom-interest] JDOM and Android

Sun Apr 22 21:06:15 PDT 2012

Out of interest, I have been struggling with these items still, and I am 
still looking for assistance (hopefully from some experienced Android 
developers).

I have untangled the mess of the ClassLoader.getResource() issues, but I 
am still struggling with XMLSchema Validation on Android. As far as I 
can tell it is not yet possible (not with existing tools anyway).

I have updated the wiki pages:
https://github.com/hunterhacker/jdom/wiki/JDOM2-and-Android
https://github.com/hunterhacker/jdom/wiki/JDOM2---Android-with-Xerces

I have also asked a StackOverflow question:
http://stackoverflow.com/questions/10274555/xmlschema-validation-on-android

I am hoping to release 2.0.1 very soon, and I would love to have full 
support for Android as part of 2.0.1!

Rolf

On 19/04/2012 9:40 AM, Rolf Lear wrote:
>
> 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
> _______________________________________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com
>