From jdom at tuis.net Sun Apr 1 20:17:18 2012 From: jdom at tuis.net (Rolf Lear) Date: Sun, 01 Apr 2012 23:17:18 -0400 Subject: [jdom-interest] JDOM 2.x BETA 6 Released - April Fools Message-ID: <4F791A3E.8010307@tuis.net> No, actually, really it has been released. No April Fools in that. There are some significant changes in this release: The Parent interface has been extended to incorporate the addContent(*) methods which are common to both Document and Element. When the Parent interface was designed, it was not possible to do Covariant return types, and it was not possible to have addContent(Content) return Document on a Document instance, and Element on an Element instance. With Java5, this is now possible, and it is thus logical to include these methods on the Parent interface. XPathExpression and its derivative classes have been changed to be more consistent both with each other, and with other 'de-facto' standards in JDOM. This means that: 1. Instead of passing around String uri's, the code now passes around Namespace instances. 2. XPathExpression now supports getting and setting Variables using a 'qname' syntax that matches the syntax used for declaring the variables in the XPathFactory. JDOMConstants has a few values which represent common prefixes for some namespaces. These were named "NS_PFX_...". They have been renamed to "NS_PREFIX_*" to be more specific. SAXBuilder was changed by me a while ago to rename three 'boolean' get* methods to be is* methods. For example, getExpandEntities() became isExpandEntities(). It has become apparent that there is no significant benefit from this change. It does not clarify what the methods do, the names are still ugly, and the additional complexity for both the JDOM code (with deprecated get* methods) and the users (having to change their code calls to avoid deprecation warnings) makes it not-worthwhile. Thus these three changes have been 'reverted'. TextHelper is a 'contrib' class that I recently ported in to 'core'. Unfortunately, I completely missed the fact that the functionality already existed in JDOM's Element class. So, this TextHelper has been completely removed. I introduced the 'Walker' Interface to deal with the complexities of formatting XML Output in the org.jdom2.output.* packages. The names of the 4 concrete implementations of the Walker interface were inconsistent with the types of formatting they do. The concrete implementations have been renamed to match the TextMode they represent. This change will only affect people who have already subclassed JDOM 2.x beta code. A number of documentation issues have been addressed, and the wiki page is being improved and updated. I am hoping that you will all jump on to this beta and run it through it's paces. If you have any questions or suggestions, please speak up. If you notice any JavaDoc issues please shout out as well. The final 2.0.0 release is still targeted for this Easter weekend. Please continue to play with the JDOM 2.x Beta releases. This latest BETA is available from the regular places (with maven to follow soon): Downloads: https://github.com/hunterhacker/jdom/downloads The Release: https://github.com/downloads/hunterhacker/jdom/jdom2-0.0.6-BETA.zip The APIDocs: http://hunterhacker.github.com/jdom/jdom2/apidocs/index.html The Code Coverage: http://hunterhacker.github.com/jdom/jdom2/coverage/index.html The JUnit Report: http://hunterhacker.github.com/jdom/jdom2/junit.report/index.html Thanks Rolf From noel at peralex.com Mon Apr 2 23:24:32 2012 From: noel at peralex.com (Noel Grandin) Date: Tue, 03 Apr 2012 08:24:32 +0200 Subject: [jdom-interest] JDOM 2.x BETA 6 Released - April Fools In-Reply-To: <4F791A3E.8010307@tuis.net> References: <4F791A3E.8010307@tuis.net> Message-ID: <4F7A97A0.20103@peralex.com> Nice! Thanks for all the hard work! Disclaimer: http://www.peralex.com/disclaimer.html From jdom at tuis.net Tue Apr 3 06:07:01 2012 From: jdom at tuis.net (Rolf Lear) Date: Tue, 03 Apr 2012 09:07:01 -0400 Subject: [jdom-interest] JDOM 2.x BETA 6 Released - April Fools In-Reply-To: <4F7A97A0.20103@peralex.com> References: <4F791A3E.8010307@tuis.net> <4F7A97A0.20103@peralex.com> Message-ID: <7aeda2dde5526fca076f5566324b7c79@tuis.net> Thank you , and you're welcome ;-) Rolf On Tue, 03 Apr 2012 08:24:32 +0200, Noel Grandin wrote: > Nice! Thanks for all the hard work! > > > > Disclaimer: http://www.peralex.com/disclaimer.html From jdom at tuis.net Tue Apr 3 06:41:13 2012 From: jdom at tuis.net (Rolf Lear) Date: Tue, 03 Apr 2012 09:41:13 -0400 Subject: [jdom-interest] Still to do - org.jdom2.util Message-ID: Hi all I have the following on the to-do list: 'fix' the org.jdom2.util package this package contains public classes many of which are not really JDOM specific: https://github.com/hunterhacker/jdom/tree/master/core/src/java/org/jdom2/util My plan is: StringBin will become 'package private' and will be moved to org.jdom2. This makes it 'invisible' but still accessible to SlimJDOMFactory XMLBase will have its internal logic moved to Element as a new method public URI getXMLBase(), then XMLBase will be removed entirely NamespaceStack can stay in util and be declared part of the public API IteratorIterable can stay in util and be declared part of the public API This leaves ArrayCopy and ReflectionConstructor. These classes are used from a number of different places in JDOM. ArrayCopy duplicates the Arrays.arrayCopy(*) logic because it is not available in Java5. ReflectionConstructor centralizes the logic and error handling for a number of places too. They cannot be made 'private'. I think I am going to create a new package org.jdom2.support which I will document as 'this is private JDOM code. Do not use any classes in this directly package in your code!' I think this will leave org.jdom2.util with just the NamespaceStack and the IteratorIterable. Which are fair to make part of the public JDOM API. Does anyone have any comments on this? Concerns? I would particularly like feedback on what a good name would be for the new package containing ArrayCopy and other 'public-but-not-public' classes. "org.jdom2.support"? "org.jdom2.internal"? Any ideas? Rolf From jdom at tuis.net Tue Apr 3 06:49:58 2012 From: jdom at tuis.net (Rolf Lear) Date: Tue, 03 Apr 2012 09:49:58 -0400 Subject: [jdom-interest] Still to do - Text 'merger' Message-ID: Hi all. I have been playing with a problem related to multiple-adjacent-text content in Elements. For example: Element root = new Element("Root"); root.addContent(new Text("Hello")); root.addContent(new Text(" ")); root.addContent(new Text("World!")); I think there is a useful concept of 'merging' consecutive Text items in to one. The code is simple enough, and I have written it, and it works. This is similar to the 'normalize' function of DOM's Node. The questions are: 1. Should the code be part of the JDOM API? Is it useful? 2. The way I have it now is as a method on Element, which, for example, you call root.runTheMergeMethod() and it *recursively* scans the Element (and child Elements) for consecutive Text items and merges them. Should the method be recursive, or should it be at the current element only. Perhaps there should be two versions, one is recursive, the other is not. 3. What should the methods be called? 4. Should it be accessible through the JDOM Document too, or just the root element? Ideas? Rolf From noel at peralex.com Tue Apr 3 08:00:07 2012 From: noel at peralex.com (Noel Grandin) Date: Tue, 03 Apr 2012 17:00:07 +0200 Subject: [jdom-interest] Still to do - org.jdom2.util In-Reply-To: References: Message-ID: <4F7B1077.9000609@peralex.com> On 2012-04-03 15:41, Rolf Lear wrote: > I would particularly like feedback on what a good name would be for the > new package containing ArrayCopy and other 'public-but-not-public' classes. > "org.jdom2.support"? "org.jdom2.internal"? Any ideas? .internal matches the Eclipse naming conventions. I haven't seen any other common conventions for this. Disclaimer: http://www.peralex.com/disclaimer.html From noel at peralex.com Tue Apr 3 08:01:27 2012 From: noel at peralex.com (Noel Grandin) Date: Tue, 03 Apr 2012 17:01:27 +0200 Subject: [jdom-interest] Still to do - Text 'merger' In-Reply-To: References: Message-ID: <4F7B10C7.6040702@peralex.com> void normalizeText(boolean recursive) or void normalizeTextNodes(boolean recursive) Disclaimer: http://www.peralex.com/disclaimer.html From mikeb at mitre.org Tue Apr 3 08:06:47 2012 From: mikeb at mitre.org (Brenner, Mike) Date: Tue, 3 Apr 2012 15:06:47 +0000 Subject: [jdom-interest] Still to do - Text 'merger' In-Reply-To: References: Message-ID: <264449A6A521A14593F58479F46B34EB167097@IMCMBX03.MITRE.ORG> 1. Perhaps the nonrecursive version should be part of the API as an example of how to do building blocks for simple transformations. 2. The recursive version could be in CONTRIB, to show how easy recursive transformations are in jdom. 3. JOIN, to be compatible with scripting languages, (along with a separator parameter). 4. Neither the DOCUMENT nor the ROOT, but any element. -----Original Message----- From: jdom-interest-bounces at jdom.org [mailto:jdom-interest-bounces at jdom.org] On Behalf Of Rolf Lear Sent: Tuesday, April 03, 2012 9:50 AM To: Jdom interest Subject: [jdom-interest] Still to do - Text 'merger' Hi all. I have been playing with a problem related to multiple-adjacent-text content in Elements. For example: Element root = new Element("Root"); root.addContent(new Text("Hello")); root.addContent(new Text(" ")); root.addContent(new Text("World!")); I think there is a useful concept of 'merging' consecutive Text items in to one. The code is simple enough, and I have written it, and it works. This is similar to the 'normalize' function of DOM's Node. The questions are: 1. Should the code be part of the JDOM API? Is it useful? 2. The way I have it now is as a method on Element, which, for example, you call root.runTheMergeMethod() and it *recursively* scans the Element (and child Elements) for consecutive Text items and merges them. Should the method be recursive, or should it be at the current element only. Perhaps there should be two versions, one is recursive, the other is not. 3. What should the methods be called? 4. Should it be accessible through the JDOM Document too, or just the root element? Ideas? Rolf _______________________________________________ To control your jdom-interest membership: http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Tue Apr 3 08:15:46 2012 From: jdom at tuis.net (Rolf Lear) Date: Tue, 03 Apr 2012 11:15:46 -0400 Subject: [jdom-interest] Still to do - Text 'merger' In-Reply-To: <4F7B10C7.6040702@peralex.com> References: <4F7B10C7.6040702@peralex.com> Message-ID: I was specifically trying to avoid the normalize word.... it has additional connotations in JDOM, in the sense that it is already part of the Element's API which does a 'different' thing (trims and normalizes internal whitespace): http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/Element.html#getTextNormalize%28%29 I assume though that you think it is a good idea to push it in before 2.0.0? If it helps, the method name I currently have is called 'mergeAdjacentText()' What about putting it at the document level too? That would involve a change to Document, Parent, and Element....? Rolf On Tue, 03 Apr 2012 17:01:27 +0200, Noel Grandin wrote: > void normalizeText(boolean recursive) > > or > > void normalizeTextNodes(boolean recursive) > > > Disclaimer: http://www.peralex.com/disclaimer.html From bshuffman at gmail.com Tue Apr 3 08:38:05 2012 From: bshuffman at gmail.com (Bradley S. Huffman) Date: Tue, 3 Apr 2012 10:38:05 -0500 Subject: [jdom-interest] Still to do - Text 'merger' In-Reply-To: References: <4F7B10C7.6040702@peralex.com> Message-ID: Why not just a Element.addText(String) that either adds a new text node or merges with a adjacent one if one exists? I don't think a recursive merge method would be that useful since SAXHandler already does it in the characters() method. From jdom at tuis.net Tue Apr 3 09:19:56 2012 From: jdom at tuis.net (Rolf Lear) Date: Tue, 03 Apr 2012 12:19:56 -0400 Subject: [jdom-interest] Still to do - Text 'merger' In-Reply-To: References: <4F7B10C7.6040702@peralex.com> Message-ID: <00a2134196402da3cf802bcc6e8cae9a@tuis.net> I realize that the conditions under which you get these 'adjacent' Text items are limited. Essentially, the only way to do it is through the programming API.... oh, and, I guess technically the StAX streams could do it. But, I mostly expect this to be a problem with people having JDOM code adding Text content, and then being surprised when they want to retrieve it and have to figure out which one... or all of them to process. The Outputter variants already all (since JDOM 2.x) merge the adjacent Texts in to a single 'event' or whatever... so output is not a problem either I am really not sure how big the problem is... but the other thing my current code example does is to remove Text items which are empty (new Text("")).... and that is not something that addText() would accommodate... All this process would solve is that one time when someone has somehow got multiple texts, and they want to simplify the processing of the JDOM tree. A non-recursive example would be for (Element emt : doc.getDescendants(Filters.element())) { emt.mergeAdjacentTexts(); } When I look at it like that, it's really simple.... I think my opinion is swaying to either: 1. don't do it at all - but I have the code done already, and even though it is simple, it is *very* useful in a *limited* situation. Hate to waste 10-lines of code ;-) 2. do it as a non-recursive 'cleanup' post-process task.... like the mergeAdjacentTexts() example above. I think while adding an 'append-or-create' Element.addText() would be somewhat useful at reducing the problem, it does not solve it after it happens. Rolf On Tue, 3 Apr 2012 10:38:05 -0500, "Bradley S. Huffman" wrote: > Why not just a Element.addText(String) that either adds a new text > node or merges with a adjacent one if one exists? I don't think a > recursive merge method would be that useful since SAXHandler already > does it in the characters() method. From jdom at tuis.net Tue Apr 3 21:05:28 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 04 Apr 2012 00:05:28 -0400 Subject: [jdom-interest] Still to do - Text 'merger' In-Reply-To: References: Message-ID: <4F7BC888.6080306@tuis.net> Hi all. I have moved this code in as the new method Element.simplifyText(). https://github.com/hunterhacker/jdom/commit/d4b5c67f1df51cacf05e704e238f1d5361828233#diff-0 It is a non-recursive method. I think the name is better than 'merge', 'join', or 'normalize'. I think the recursive means of doing it is easy enough to code (three-liner), so it does not add much value. I think it has enough value to be included. Unless someone can come up with better names, options, I think it will stay. Rolf On 03/04/2012 9:49 AM, Rolf Lear wrote: > > Hi all. > > I have been playing with a problem related to multiple-adjacent-text > content in Elements. For example: > > Element root = new Element("Root"); > root.addContent(new Text("Hello")); > root.addContent(new Text(" ")); > root.addContent(new Text("World!")); > > I think there is a useful concept of 'merging' consecutive Text items in > to one. The code is simple enough, and I have written it, and it works. > This is similar to the 'normalize' function of DOM's Node. > > The questions are: > 1. Should the code be part of the JDOM API? Is it useful? > 2. The way I have it now is as a method on Element, which, for example, > you call root.runTheMergeMethod() and it *recursively* scans the Element > (and child Elements) for consecutive Text items and merges them. Should the > method be recursive, or should it be at the current element only. Perhaps > there should be two versions, one is recursive, the other is not. > 3. What should the methods be called? > 4. Should it be accessible through the JDOM Document too, or just the root > element? > > Ideas? > > Rolf > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From jdom at tuis.net Tue Apr 3 21:06:15 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 04 Apr 2012 00:06:15 -0400 Subject: [jdom-interest] Still to do - org.jdom2.util In-Reply-To: <4F7B1077.9000609@peralex.com> References: <4F7B1077.9000609@peralex.com> Message-ID: <4F7BC8B7.1010602@tuis.net> Thanks. I think 'internal' works well, and the change is done. Rolf On 03/04/2012 11:00 AM, Noel Grandin wrote: > > On 2012-04-03 15:41, Rolf Lear wrote: >> I would particularly like feedback on what a good name would be for the >> new package containing ArrayCopy and other 'public-but-not-public' >> classes. >> "org.jdom2.support"? "org.jdom2.internal"? Any ideas? > .internal matches the Eclipse naming conventions. > > I haven't seen any other common conventions for this. > From curoli at gmail.com Wed Apr 4 03:52:26 2012 From: curoli at gmail.com (Oliver Ruebenacker) Date: Wed, 4 Apr 2012 06:52:26 -0400 Subject: [jdom-interest] Still to do - Text 'merger' In-Reply-To: <4F7BC888.6080306@tuis.net> References: <4F7BC888.6080306@tuis.net> Message-ID: Hello Rolf, All, I think most users would be puzzled what it means to "simplify" text. It sounds as if the text itself is affected, rather than its representation. I would call it Element.defragmentText(). Many people know that if you defragment a file, the content stays the same. Take care Oliver On Wed, Apr 4, 2012 at 12:05 AM, Rolf Lear wrote: > Hi all. > > I have moved this code in as the new method Element.simplifyText(). > > https://github.com/hunterhacker/jdom/commit/d4b5c67f1df51cacf05e704e238f1d5361828233#diff-0 > > It is a non-recursive method. I think the name is better than 'merge', > 'join', or 'normalize'. > > I think the recursive means of doing it is easy enough to code > (three-liner), so it does not add much value. > > I think it has enough value to be included. > > Unless someone can come up with better names, options, I think it will stay. > > Rolf > > > On 03/04/2012 9:49 AM, Rolf Lear wrote: >> >> >> Hi all. >> >> I have been playing with a problem related to multiple-adjacent-text >> content in Elements. For example: >> >> Element root = new Element("Root"); >> root.addContent(new Text("Hello")); >> root.addContent(new Text(" ")); >> root.addContent(new Text("World!")); >> >> I think there is a useful concept of 'merging' consecutive Text items in >> to one. The code is simple enough, and I have written it, and it works. >> This is similar to the 'normalize' function of DOM's Node. >> >> The questions are: >> 1. Should the code be part of the JDOM API? Is it useful? >> 2. The way I have it now is as a method on Element, which, for example, >> you call root.runTheMergeMethod() and it *recursively* scans the Element >> (and child Elements) for consecutive Text items and merges them. Should >> the >> method be recursive, or should it be at the current element only. Perhaps >> there should be two versions, one is recursive, the other is not. >> 3. What should the methods be called? >> 4. Should it be accessible through the JDOM Document too, or just the root >> element? >> >> Ideas? >> >> Rolf >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com -- Oliver Ruebenacker, Computational Cell Biologist Virtual Cell (http://vcell.org) SBPAX: Turning Bio Knowledge into Math Models (http://www.sbpax.org) http://www.oliver.curiousworld.org From jhunter at servlets.com Wed Apr 4 08:34:52 2012 From: jhunter at servlets.com (Jason Hunter) Date: Wed, 4 Apr 2012 08:34:52 -0700 Subject: [jdom-interest] Still to do - Text 'merger' In-Reply-To: References: <4F7BC888.6080306@tuis.net> Message-ID: <0387DACE-5951-4B90-8154-98B9470C0841@servlets.com> I'd probably name it coalesceText(). -jh- On Apr 4, 2012, at 3:52 AM, Oliver Ruebenacker wrote: > Hello Rolf, All, > > I think most users would be puzzled what it means to "simplify" > text. It sounds as if the text itself is affected, rather than its > representation. I would call it Element.defragmentText(). Many people > know that if you defragment a file, the content stays the same. > > Take care > Oliver > > On Wed, Apr 4, 2012 at 12:05 AM, Rolf Lear wrote: >> Hi all. >> >> I have moved this code in as the new method Element.simplifyText(). >> >> https://github.com/hunterhacker/jdom/commit/d4b5c67f1df51cacf05e704e238f1d5361828233#diff-0 >> >> It is a non-recursive method. I think the name is better than 'merge', >> 'join', or 'normalize'. >> >> I think the recursive means of doing it is easy enough to code >> (three-liner), so it does not add much value. >> >> I think it has enough value to be included. >> >> Unless someone can come up with better names, options, I think it will stay. >> >> Rolf >> >> >> On 03/04/2012 9:49 AM, Rolf Lear wrote: >>> >>> >>> Hi all. >>> >>> I have been playing with a problem related to multiple-adjacent-text >>> content in Elements. For example: >>> >>> Element root = new Element("Root"); >>> root.addContent(new Text("Hello")); >>> root.addContent(new Text(" ")); >>> root.addContent(new Text("World!")); >>> >>> I think there is a useful concept of 'merging' consecutive Text items in >>> to one. The code is simple enough, and I have written it, and it works. >>> This is similar to the 'normalize' function of DOM's Node. >>> >>> The questions are: >>> 1. Should the code be part of the JDOM API? Is it useful? >>> 2. The way I have it now is as a method on Element, which, for example, >>> you call root.runTheMergeMethod() and it *recursively* scans the Element >>> (and child Elements) for consecutive Text items and merges them. Should >>> the >>> method be recursive, or should it be at the current element only. Perhaps >>> there should be two versions, one is recursive, the other is not. >>> 3. What should the methods be called? >>> 4. Should it be accessible through the JDOM Document too, or just the root >>> element? >>> >>> Ideas? >>> >>> Rolf >>> >>> _______________________________________________ >>> To control your jdom-interest membership: >>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>> >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > > > > -- > Oliver Ruebenacker, Computational Cell Biologist > Virtual Cell (http://vcell.org) > SBPAX: Turning Bio Knowledge into Math Models (http://www.sbpax.org) > http://www.oliver.curiousworld.org > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Wed Apr 4 20:11:25 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 04 Apr 2012 23:11:25 -0400 Subject: [jdom-interest] Still to do - Text 'merger' In-Reply-To: References: <4F7BC888.6080306@tuis.net> <0387DACE-5951-4B90-8154-98B9470C0841@servlets.com> Message-ID: <4F7D0D5D.6090500@tuis.net> coalesce is a big name (thinking of not-native-English-speakers), but it does encapsulate the intent of the method. People will figure it out. There, decision made. I will need some time to 'package' things up, so no more code changes, only documentation, and wiki.... JDOM 2.0.0 to be released this weekend. Rolf On 04/04/2012 11:49 AM, Grzegorz wrote: > +1 for coalesceText(boolean) ;) > > 2012/4/4 Jason Hunter > > > I'd probably name it coalesceText(). > > -jh- > > On Apr 4, 2012, at 3:52 AM, Oliver Ruebenacker wrote: > > > Hello Rolf, All, > > > > I think most users would be puzzled what it means to "simplify" > > text. It sounds as if the text itself is affected, rather than its > > representation. I would call it Element.defragmentText(). Many people > > know that if you defragment a file, the content stays the same. > > > > Take care > > Oliver > > > > On Wed, Apr 4, 2012 at 12:05 AM, Rolf Lear > wrote: > >> Hi all. > >> > >> I have moved this code in as the new method Element.simplifyText(). > >> > >> > https://github.com/hunterhacker/jdom/commit/d4b5c67f1df51cacf05e704e238f1d5361828233#diff-0 > >> > >> It is a non-recursive method. I think the name is better than > 'merge', > >> 'join', or 'normalize'. > >> > >> I think the recursive means of doing it is easy enough to code > >> (three-liner), so it does not add much value. > >> > >> I think it has enough value to be included. > >> > >> Unless someone can come up with better names, options, I think > it will stay. > >> > >> Rolf > >> > >> > >> On 03/04/2012 9:49 AM, Rolf Lear wrote: > >>> > >>> > >>> Hi all. > >>> > >>> I have been playing with a problem related to > multiple-adjacent-text > >>> content in Elements. For example: > >>> > >>> Element root = new Element("Root"); > >>> root.addContent(new Text("Hello")); > >>> root.addContent(new Text(" ")); > >>> root.addContent(new Text("World!")); > >>> > >>> I think there is a useful concept of 'merging' consecutive Text > items in > >>> to one. The code is simple enough, and I have written it, and > it works. > >>> This is similar to the 'normalize' function of DOM's Node. > >>> > >>> The questions are: > >>> 1. Should the code be part of the JDOM API? Is it useful? > >>> 2. The way I have it now is as a method on Element, which, for > example, > >>> you call root.runTheMergeMethod() and it *recursively* scans > the Element > >>> (and child Elements) for consecutive Text items and merges > them. Should > >>> the > >>> method be recursive, or should it be at the current element > only. Perhaps > >>> there should be two versions, one is recursive, the other is not. > >>> 3. What should the methods be called? > >>> 4. Should it be accessible through the JDOM Document too, or > just the root > >>> element? > >>> > >>> Ideas? > >>> > >>> Rolf > >>> > > From jdom at tuis.net Thu Apr 5 03:57:47 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 05 Apr 2012 06:57:47 -0400 Subject: [jdom-interest] Download/Distribution format Message-ID: <4F7D7AAB.4080604@tuis.net> Hi all. I intend to 'release' 2.0.0 in the same format as all the BETA releases. Oh, I have just checked, and the license is not in there.... Apart from the licenses, is there anything else that needs to go in the final package? This is the 'last moment' for people to inspect that and make sure it is right Thanks Rolf From jdom at tuis.net Fri Apr 6 14:08:50 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 06 Apr 2012 17:08:50 -0400 Subject: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) In-Reply-To: <6A01160BED1CB74CB2F447CB21ED5C110119B039EA32@INT03EXVS3.mcint.local> References: <6A01160BED1CB74CB2F447CB21ED5C110119B039EA32@INT03EXVS3.mcint.local> Message-ID: <4F7F5B62.6020201@tuis.net> Hi Gisella. Is it possible to send us a stack trace, at least the parts including the org.jdom.* code. Thanks Rolf On 06/04/2012 1:43 PM, gisella.saavedra at navis.com wrote: > I just upgraded from jdom 1.0 to jdom 1.1.3 > > and I was setting an attribute where the namespace was NULL. > > The old code was different, it was NOT calling get(?), so it was setting > the namespace to namespace.NO_NAMESPACE when the namespace was NULL, > > before calling this get(?) > > but the new code, when it calls getAttribute(name, ns) (first line of > method described) > > is getting a null pointer on the namespace. > > Probably the namespace needs to be set to NO_NAMESPACE before calling > get(..) when it is NULL. > > *Gisella Saavedra** > *Framework Team > _gsaavedra at navis.com _ > > > > http://www.navis.com/images/spacer.gif > > 1000 Broadway, Suite 150, Oakland, CA 94607 | T+1 510 267 5123 T Main+1 > 510 267 5000 F+1 510 267 5100 | _http://www.navis.com > _ > > > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Fri Apr 6 14:39:43 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 06 Apr 2012 17:39:43 -0400 Subject: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) In-Reply-To: <4F7F5B62.6020201@tuis.net> References: <6A01160BED1CB74CB2F447CB21ED5C110119B039EA32@INT03EXVS3.mcint.local> <4F7F5B62.6020201@tuis.net> Message-ID: <4F7F629F.7080202@tuis.net> Hi Gisella. I have looked through the JDOM 1.0 code. JDOM 1.0 was released in September 2004. Here's the code as it was at the time: Here's the getAttribute method: https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/Element.java#L980 Here's the attributes.get(String,Namespace) method: https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L365 And that calls the indexOf(String,Namespace) method: https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L377 Which calls namespace.getURI(). The way I see it is that JDOM 1.0 would always throw a NullPointerException if you gave it a null Namespace. I don't think it would have ever worked in JDOM 1.0... Did you have your own custom build of JDOM 1.0? Rolf On 06/04/2012 5:08 PM, Rolf Lear wrote: > Hi Gisella. > > Is it possible to send us a stack trace, at least the parts including > the org.jdom.* code. > > Thanks > > Rolf > > > On 06/04/2012 1:43 PM, gisella.saavedra at navis.com wrote: >> I just upgraded from jdom 1.0 to jdom 1.1.3 >> >> and I was setting an attribute where the namespace was NULL. >> >> The old code was different, it was NOT calling get(?), so it was setting >> the namespace to namespace.NO_NAMESPACE when the namespace was NULL, >> >> before calling this get(?) >> >> but the new code, when it calls getAttribute(name, ns) (first line of >> method described) >> >> is getting a null pointer on the namespace. >> >> Probably the namespace needs to be set to NO_NAMESPACE before calling >> get(..) when it is NULL. >> >> *Gisella Saavedra** >> *Framework Team >> _gsaavedra at navis.com _ >> >> >> >> http://www.navis.com/images/spacer.gif >> >> 1000 Broadway, Suite 150, Oakland, CA 94607 | T+1 510 267 5123 T Main+1 >> 510 267 5000 F+1 510 267 5100 | _http://www.navis.com >> _ >> >> >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From gisella.saavedra at navis.com Fri Apr 6 14:48:45 2012 From: gisella.saavedra at navis.com (gisella.saavedra at navis.com) Date: Sat, 7 Apr 2012 00:48:45 +0300 Subject: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) In-Reply-To: <4F7F629F.7080202@tuis.net> References: <6A01160BED1CB74CB2F447CB21ED5C110119B039EA32@INT03EXVS3.mcint.local> <4F7F5B62.6020201@tuis.net> <4F7F629F.7080202@tuis.net> Message-ID: <6A01160BED1CB74CB2F447CB21ED5C110119B039EC01@INT03EXVS3.mcint.local> Rolf, I believe you might be looking at the wrong method: This is JDOM 1.0 (ns is passed as null) public Element setAttribute(String name, String value, Namespace ns) { return setAttribute(new Attribute(name, value, ns)); } Inside this code, the constructor new Attribute(name, value, ns) calls: public Attribute(String name, String value, Namespace namespace) { setName(name); setValue(value); setNamespace(namespace); } Here setNamespace(namespace) calls: public Attribute setNamespace(Namespace namespace) { if (namespace == null) { namespace = Namespace.NO_NAMESPACE; } // Verify the attribute isn't trying to be in a default namespace // Attributes can't be in a default namespace if (namespace != Namespace.NO_NAMESPACE && namespace.getPrefix().equals("")) { throw new IllegalNameException("", "attribute namespace", "An attribute namespace without a prefix can only be the " + "NO_NAMESPACE namespace"); } this.namespace = namespace; return this; } where namespace being null is set to NO_NAMESPACE. Stack trace: java.lang.NullPointerException at org.jdom.AttributeList.indexOf(AttributeList.java:378) at org.jdom.AttributeList.get(AttributeList.java:366) at org.jdom.Element.getAttribute(Element.java:1004) at org.jdom.Element.setAttribute(Element.java:1178) at com.navis.argo.business.snx.AbstractXmlExporter.setAttribute(AbstractXmlExporter.java:40) -------------- -----Original Message----- From: Rolf Lear [mailto:jdom at tuis.net] Sent: Friday, April 06, 2012 2:40 PM To: Saavedra Gisella Cc: jdom-interest at jdom.org Subject: Re: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) Hi Gisella. I have looked through the JDOM 1.0 code. JDOM 1.0 was released in September 2004. Here's the code as it was at the time: Here's the getAttribute method: https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/Element.java#L980 Here's the attributes.get(String,Namespace) method: https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L365 And that calls the indexOf(String,Namespace) method: https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L377 Which calls namespace.getURI(). The way I see it is that JDOM 1.0 would always throw a NullPointerException if you gave it a null Namespace. I don't think it would have ever worked in JDOM 1.0... Did you have your own custom build of JDOM 1.0? Rolf On 06/04/2012 5:08 PM, Rolf Lear wrote: > Hi Gisella. > > Is it possible to send us a stack trace, at least the parts including > the org.jdom.* code. > > Thanks > > Rolf > > > On 06/04/2012 1:43 PM, gisella.saavedra at navis.com wrote: >> I just upgraded from jdom 1.0 to jdom 1.1.3 >> >> and I was setting an attribute where the namespace was NULL. >> >> The old code was different, it was NOT calling get(...), so it was setting >> the namespace to namespace.NO_NAMESPACE when the namespace was NULL, >> >> before calling this get(...) >> >> but the new code, when it calls getAttribute(name, ns) (first line of >> method described) >> >> is getting a null pointer on the namespace. >> >> Probably the namespace needs to be set to NO_NAMESPACE before calling >> get(..) when it is NULL. >> >> *Gisella Saavedra** >> *Framework Team >> _gsaavedra at navis.com _ >> >> >> >> http://www.navis.com/images/spacer.gif >> >> 1000 Broadway, Suite 150, Oakland, CA 94607 | T+1 510 267 5123 T Main+1 >> 510 267 5000 F+1 510 267 5100 | _http://www.navis.com >> _ >> >> >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From gisella.saavedra at navis.com Fri Apr 6 14:53:40 2012 From: gisella.saavedra at navis.com (gisella.saavedra at navis.com) Date: Sat, 7 Apr 2012 00:53:40 +0300 Subject: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) References: <6A01160BED1CB74CB2F447CB21ED5C110119B039EA32@INT03EXVS3.mcint.local> <4F7F5B62.6020201@tuis.net> <4F7F629F.7080202@tuis.net> Message-ID: <6A01160BED1CB74CB2F447CB21ED5C110119B039EC12@INT03EXVS3.mcint.local> the stack trace belongs to JDOM 1.1.3 -----Original Message----- From: Saavedra Gisella Sent: Friday, April 06, 2012 2:49 PM To: 'Rolf Lear' Cc: jdom-interest at jdom.org Subject: RE: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) Rolf, I believe you might be looking at the wrong method: This is JDOM 1.0 (ns is passed as null) public Element setAttribute(String name, String value, Namespace ns) { return setAttribute(new Attribute(name, value, ns)); } Inside this code, the constructor new Attribute(name, value, ns) calls: public Attribute(String name, String value, Namespace namespace) { setName(name); setValue(value); setNamespace(namespace); } Here setNamespace(namespace) calls: public Attribute setNamespace(Namespace namespace) { if (namespace == null) { namespace = Namespace.NO_NAMESPACE; } // Verify the attribute isn't trying to be in a default namespace // Attributes can't be in a default namespace if (namespace != Namespace.NO_NAMESPACE && namespace.getPrefix().equals("")) { throw new IllegalNameException("", "attribute namespace", "An attribute namespace without a prefix can only be the " + "NO_NAMESPACE namespace"); } this.namespace = namespace; return this; } where namespace being null is set to NO_NAMESPACE. Stack trace (JODM 1.1.3): java.lang.NullPointerException at org.jdom.AttributeList.indexOf(AttributeList.java:378) at org.jdom.AttributeList.get(AttributeList.java:366) at org.jdom.Element.getAttribute(Element.java:1004) at org.jdom.Element.setAttribute(Element.java:1178) at com.navis.argo.business.snx.AbstractXmlExporter.setAttribute(AbstractXmlExporter.java:40) -------------- -----Original Message----- From: Rolf Lear [mailto:jdom at tuis.net] Sent: Friday, April 06, 2012 2:40 PM To: Saavedra Gisella Cc: jdom-interest at jdom.org Subject: Re: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) Hi Gisella. I have looked through the JDOM 1.0 code. JDOM 1.0 was released in September 2004. Here's the code as it was at the time: Here's the getAttribute method: https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/Element.java#L980 Here's the attributes.get(String,Namespace) method: https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L365 And that calls the indexOf(String,Namespace) method: https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L377 Which calls namespace.getURI(). The way I see it is that JDOM 1.0 would always throw a NullPointerException if you gave it a null Namespace. I don't think it would have ever worked in JDOM 1.0... Did you have your own custom build of JDOM 1.0? Rolf On 06/04/2012 5:08 PM, Rolf Lear wrote: > Hi Gisella. > > Is it possible to send us a stack trace, at least the parts including > the org.jdom.* code. > > Thanks > > Rolf > > > On 06/04/2012 1:43 PM, gisella.saavedra at navis.com wrote: >> I just upgraded from jdom 1.0 to jdom 1.1.3 >> >> and I was setting an attribute where the namespace was NULL. >> >> The old code was different, it was NOT calling get(...), so it was setting >> the namespace to namespace.NO_NAMESPACE when the namespace was NULL, >> >> before calling this get(...) >> >> but the new code, when it calls getAttribute(name, ns) (first line of >> method described) >> >> is getting a null pointer on the namespace. >> >> Probably the namespace needs to be set to NO_NAMESPACE before calling >> get(..) when it is NULL. >> >> *Gisella Saavedra** >> *Framework Team >> _gsaavedra at navis.com _ >> >> >> >> http://www.navis.com/images/spacer.gif >> >> 1000 Broadway, Suite 150, Oakland, CA 94607 | T+1 510 267 5123 T Main+1 >> 510 267 5000 F+1 510 267 5100 | _http://www.navis.com >> _ >> >> >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From jdom at tuis.net Fri Apr 6 15:37:37 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 06 Apr 2012 18:37:37 -0400 Subject: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) In-Reply-To: <6A01160BED1CB74CB2F447CB21ED5C110119B039EC01@INT03EXVS3.mcint.local> References: <6A01160BED1CB74CB2F447CB21ED5C110119B039EA32@INT03EXVS3.mcint.local> <4F7F5B62.6020201@tuis.net> <4F7F629F.7080202@tuis.net> <6A01160BED1CB74CB2F447CB21ED5C110119B039EC01@INT03EXVS3.mcint.local> Message-ID: <4F7F7031.2030008@tuis.net> Ahh, you are right, in your sibject it does say setAttribute(), but the body of the message had references to getAttribute() only. I will check things again, and the stack trace will make the difference... Rolf On 06/04/2012 5:48 PM, gisella.saavedra at navis.com wrote: > Rolf, > > I believe you might be looking at the wrong method: > > This is JDOM 1.0 (ns is passed as null) > > public Element setAttribute(String name, String value, Namespace ns) { > return setAttribute(new Attribute(name, value, ns)); > } > > Inside this code, the constructor new Attribute(name, value, ns) calls: > > public Attribute(String name, String value, Namespace namespace) { > setName(name); > setValue(value); > setNamespace(namespace); > } > > Here setNamespace(namespace) calls: > public Attribute setNamespace(Namespace namespace) { > if (namespace == null) { > namespace = Namespace.NO_NAMESPACE; > } > > // Verify the attribute isn't trying to be in a default namespace > // Attributes can't be in a default namespace > if (namespace != Namespace.NO_NAMESPACE&& > namespace.getPrefix().equals("")) { > throw new IllegalNameException("", "attribute namespace", > "An attribute namespace without a prefix can only be the " + > "NO_NAMESPACE namespace"); > } > this.namespace = namespace; > return this; > } > > where namespace being null is set to NO_NAMESPACE. > > > > > Stack trace: > > java.lang.NullPointerException > at org.jdom.AttributeList.indexOf(AttributeList.java:378) > at org.jdom.AttributeList.get(AttributeList.java:366) > at org.jdom.Element.getAttribute(Element.java:1004) > at org.jdom.Element.setAttribute(Element.java:1178) > at com.navis.argo.business.snx.AbstractXmlExporter.setAttribute(AbstractXmlExporter.java:40) > > > -------------- > > > -----Original Message----- > From: Rolf Lear [mailto:jdom at tuis.net] > Sent: Friday, April 06, 2012 2:40 PM > To: Saavedra Gisella > Cc: jdom-interest at jdom.org > Subject: Re: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) > > Hi Gisella. > > I have looked through the JDOM 1.0 code. JDOM 1.0 was released in > September 2004. Here's the code as it was at the time: > > Here's the getAttribute method: > https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/Element.java#L980 > > Here's the attributes.get(String,Namespace) method: > https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L365 > > And that calls the indexOf(String,Namespace) method: > https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L377 > > Which calls namespace.getURI(). > > The way I see it is that JDOM 1.0 would always throw a > NullPointerException if you gave it a null Namespace. > > I don't think it would have ever worked in JDOM 1.0... > > Did you have your own custom build of JDOM 1.0? > > Rolf > > On 06/04/2012 5:08 PM, Rolf Lear wrote: >> Hi Gisella. >> >> Is it possible to send us a stack trace, at least the parts including >> the org.jdom.* code. >> >> Thanks >> >> Rolf >> >> >> On 06/04/2012 1:43 PM, gisella.saavedra at navis.com wrote: >>> I just upgraded from jdom 1.0 to jdom 1.1.3 >>> >>> and I was setting an attribute where the namespace was NULL. >>> >>> The old code was different, it was NOT calling get(...), so it was setting >>> the namespace to namespace.NO_NAMESPACE when the namespace was NULL, >>> >>> before calling this get(...) >>> >>> but the new code, when it calls getAttribute(name, ns) (first line of >>> method described) >>> >>> is getting a null pointer on the namespace. >>> >>> Probably the namespace needs to be set to NO_NAMESPACE before calling >>> get(..) when it is NULL. >>> >>> *Gisella Saavedra** >>> *Framework Team >>> _gsaavedra at navis.com_ >>> >>> >>> >>> http://www.navis.com/images/spacer.gif >>> >>> 1000 Broadway, Suite 150, Oakland, CA 94607 | T+1 510 267 5123 T Main+1 >>> 510 267 5000 F+1 510 267 5100 | _http://www.navis.com >>> _ >>> >>> >>> >>> _______________________________________________ >>> To control your jdom-interest membership: >>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > From jdom at tuis.net Fri Apr 6 16:38:35 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 06 Apr 2012 19:38:35 -0400 Subject: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) In-Reply-To: <6A01160BED1CB74CB2F447CB21ED5C110119B039EC12@INT03EXVS3.mcint.local> References: <6A01160BED1CB74CB2F447CB21ED5C110119B039EA32@INT03EXVS3.mcint.local> <4F7F5B62.6020201@tuis.net> <4F7F629F.7080202@tuis.net> <6A01160BED1CB74CB2F447CB21ED5C110119B039EC12@INT03EXVS3.mcint.local> Message-ID: <4F7F7E7B.8080703@tuis.net> Hi Gisella Yes, I can see now where the change is. It happened between JDOM 1.0 and 1.1, back in 2006 ... https://github.com/hunterhacker/jdom/commit/b48373d95cd91986f83ac5345566258d80e88027#L0R1139 In fact, this issue has been reported before: http://markmail.org/message/atybnwqqvlxk7ut4 and there was never any follow-up... So, I can see the problem, and it still exists in JDOM 2.x. But, I can't see an easy fix. I am of the opinion that null input values deserve a NullPointerException unless documented that nulls are allowed... but I also recognize that compatibility is important, and JDOM has some consistency in it when treating null Namespace values as Namespace.NO_NAMESPACE. So, I am going to think about it for a moment.... but, I would not expect a fix in the short term for JDOM 1.x. Even in the best circumstances it would take a month or so to get a 1.1.4 out... For JDOM 2.x, it is also very late in the game.... too late, in fact. In order to fix it properly I would have to decide on a strategy for dealing with null Namespace input. A quick 'poll' of the JDOM 2.x code suggests: Change null to NO_NAMESPACE: ---------------------------- Element Constructor. Element.setNamespace(Namespace) Treats null as 'wildcard': -------------------------- Element.getChild(String,Namespace) Element.getChildren(String,Namespace) Element.getChildText*(String,Namespace) Element.removeChild(String,Namespace) Element.removeChildren(String,Namespace) Just ignores it. ---------------- Element.removeNamespaceDeclaration(Namespace) Throws NPE: ----------- Element.addNamespaceDeclaration(Namespace) Element.getAttribute(String,Namespace) Element.getAttributeValue(String,Namespace); Element.getAttributeValue(String,Namespace, String); Element.removeAttribute(String,Namespace); Element.setAttribute(String,String,Namespace) I think, having looked at the 'poll' results, when it comes to Attributes, the NPE is the 'right' thing. Given that getAttribute(String,Namespace) throws NPE (and removeAttribute), and they have 'always' thrown NPE, I think it is logical that setAttribute(String,String,Namespace) throws NPE too. Bottom line is that I am not convinced that it is a bug in 1.1.3. Perhaps it was a bug in 1.0 to allow the null. So, this all comes around to the 'push-back' option. How difficult is it for you to do the null-check yourself before you call setAttribute()? That is the obvious workaround, and it is the 'right thing'.... Rolf On 06/04/2012 5:53 PM, gisella.saavedra at navis.com wrote: > the stack trace belongs to JDOM 1.1.3 > > -----Original Message----- > From: Saavedra Gisella > Sent: Friday, April 06, 2012 2:49 PM > To: 'Rolf Lear' > Cc: jdom-interest at jdom.org > Subject: RE: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) > > Rolf, > > I believe you might be looking at the wrong method: > > This is JDOM 1.0 (ns is passed as null) > > public Element setAttribute(String name, String value, Namespace ns) { > return setAttribute(new Attribute(name, value, ns)); > } > > Inside this code, the constructor new Attribute(name, value, ns) calls: > > public Attribute(String name, String value, Namespace namespace) { > setName(name); > setValue(value); > setNamespace(namespace); > } > > Here setNamespace(namespace) calls: > public Attribute setNamespace(Namespace namespace) { > if (namespace == null) { > namespace = Namespace.NO_NAMESPACE; > } > > // Verify the attribute isn't trying to be in a default namespace > // Attributes can't be in a default namespace > if (namespace != Namespace.NO_NAMESPACE&& > namespace.getPrefix().equals("")) { > throw new IllegalNameException("", "attribute namespace", > "An attribute namespace without a prefix can only be the " + > "NO_NAMESPACE namespace"); > } > this.namespace = namespace; > return this; > } > > where namespace being null is set to NO_NAMESPACE. > > > > > Stack trace (JODM 1.1.3): > > java.lang.NullPointerException > at org.jdom.AttributeList.indexOf(AttributeList.java:378) > at org.jdom.AttributeList.get(AttributeList.java:366) > at org.jdom.Element.getAttribute(Element.java:1004) > at org.jdom.Element.setAttribute(Element.java:1178) > at com.navis.argo.business.snx.AbstractXmlExporter.setAttribute(AbstractXmlExporter.java:40) > > > -------------- > > > -----Original Message----- > From: Rolf Lear [mailto:jdom at tuis.net] > Sent: Friday, April 06, 2012 2:40 PM > To: Saavedra Gisella > Cc: jdom-interest at jdom.org > Subject: Re: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) > > Hi Gisella. > > I have looked through the JDOM 1.0 code. JDOM 1.0 was released in > September 2004. Here's the code as it was at the time: > > Here's the getAttribute method: > https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/Element.java#L980 > > Here's the attributes.get(String,Namespace) method: > https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L365 > > And that calls the indexOf(String,Namespace) method: > https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L377 > > Which calls namespace.getURI(). > > The way I see it is that JDOM 1.0 would always throw a > NullPointerException if you gave it a null Namespace. > > I don't think it would have ever worked in JDOM 1.0... > > Did you have your own custom build of JDOM 1.0? > > Rolf > > On 06/04/2012 5:08 PM, Rolf Lear wrote: >> Hi Gisella. >> >> Is it possible to send us a stack trace, at least the parts including >> the org.jdom.* code. >> >> Thanks >> >> Rolf >> >> >> On 06/04/2012 1:43 PM, gisella.saavedra at navis.com wrote: >>> I just upgraded from jdom 1.0 to jdom 1.1.3 >>> >>> and I was setting an attribute where the namespace was NULL. >>> >>> The old code was different, it was NOT calling get(...), so it was setting >>> the namespace to namespace.NO_NAMESPACE when the namespace was NULL, >>> >>> before calling this get(...) >>> >>> but the new code, when it calls getAttribute(name, ns) (first line of >>> method described) >>> >>> is getting a null pointer on the namespace. >>> >>> Probably the namespace needs to be set to NO_NAMESPACE before calling >>> get(..) when it is NULL. >>> >>> *Gisella Saavedra** >>> *Framework Team >>> _gsaavedra at navis.com_ >>> >>> >>> >>> http://www.navis.com/images/spacer.gif >>> >>> 1000 Broadway, Suite 150, Oakland, CA 94607 | T+1 510 267 5123 T Main+1 >>> 510 267 5000 F+1 510 267 5100 | _http://www.navis.com >>> _ >>> >>> >>> >>> _______________________________________________ >>> To control your jdom-interest membership: >>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > From gisella.saavedra at navis.com Fri Apr 6 17:28:14 2012 From: gisella.saavedra at navis.com (gisella.saavedra at navis.com) Date: Sat, 7 Apr 2012 03:28:14 +0300 Subject: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) In-Reply-To: <4F7F7E7B.8080703@tuis.net> References: <6A01160BED1CB74CB2F447CB21ED5C110119B039EA32@INT03EXVS3.mcint.local> <4F7F5B62.6020201@tuis.net> <4F7F629F.7080202@tuis.net> <6A01160BED1CB74CB2F447CB21ED5C110119B039EC12@INT03EXVS3.mcint.local> <4F7F7E7B.8080703@tuis.net> Message-ID: <6A01160BED1CB74CB2F447CB21ED5C110119B039ECF7@INT03EXVS3.mcint.local> I see the inconsistencies I would say that when removing the nullpointerexception is OK. But when creating, you can see for example new Element(string name) new Element (String name, null) both set the value of Namespace to NO_NAMESPACE. And Element.setAttribute(final String name, final String value) does not throw a NPE but Element.setAttribute(final String name, final String value, null) does. -----Original Message----- From: Rolf Lear [mailto:jdom at tuis.net] Sent: Friday, April 06, 2012 4:39 PM To: Saavedra Gisella Cc: jdom-interest at jdom.org Subject: Re: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) Hi Gisella Yes, I can see now where the change is. It happened between JDOM 1.0 and 1.1, back in 2006 ... https://github.com/hunterhacker/jdom/commit/b48373d95cd91986f83ac5345566258d80e88027#L0R1139 In fact, this issue has been reported before: http://markmail.org/message/atybnwqqvlxk7ut4 and there was never any follow-up... So, I can see the problem, and it still exists in JDOM 2.x. But, I can't see an easy fix. I am of the opinion that null input values deserve a NullPointerException unless documented that nulls are allowed... but I also recognize that compatibility is important, and JDOM has some consistency in it when treating null Namespace values as Namespace.NO_NAMESPACE. So, I am going to think about it for a moment.... but, I would not expect a fix in the short term for JDOM 1.x. Even in the best circumstances it would take a month or so to get a 1.1.4 out... For JDOM 2.x, it is also very late in the game.... too late, in fact. In order to fix it properly I would have to decide on a strategy for dealing with null Namespace input. A quick 'poll' of the JDOM 2.x code suggests: Change null to NO_NAMESPACE: ---------------------------- Element Constructor. Element.setNamespace(Namespace) Treats null as 'wildcard': -------------------------- Element.getChild(String,Namespace) Element.getChildren(String,Namespace) Element.getChildText*(String,Namespace) Element.removeChild(String,Namespace) Element.removeChildren(String,Namespace) Just ignores it. ---------------- Element.removeNamespaceDeclaration(Namespace) Throws NPE: ----------- Element.addNamespaceDeclaration(Namespace) Element.getAttribute(String,Namespace) Element.getAttributeValue(String,Namespace); Element.getAttributeValue(String,Namespace, String); Element.removeAttribute(String,Namespace); Element.setAttribute(String,String,Namespace) I think, having looked at the 'poll' results, when it comes to Attributes, the NPE is the 'right' thing. Given that getAttribute(String,Namespace) throws NPE (and removeAttribute), and they have 'always' thrown NPE, I think it is logical that setAttribute(String,String,Namespace) throws NPE too. Bottom line is that I am not convinced that it is a bug in 1.1.3. Perhaps it was a bug in 1.0 to allow the null. So, this all comes around to the 'push-back' option. How difficult is it for you to do the null-check yourself before you call setAttribute()? That is the obvious workaround, and it is the 'right thing'.... Rolf On 06/04/2012 5:53 PM, gisella.saavedra at navis.com wrote: > the stack trace belongs to JDOM 1.1.3 > > -----Original Message----- > From: Saavedra Gisella > Sent: Friday, April 06, 2012 2:49 PM > To: 'Rolf Lear' > Cc: jdom-interest at jdom.org > Subject: RE: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) > > Rolf, > > I believe you might be looking at the wrong method: > > This is JDOM 1.0 (ns is passed as null) > > public Element setAttribute(String name, String value, Namespace ns) { > return setAttribute(new Attribute(name, value, ns)); > } > > Inside this code, the constructor new Attribute(name, value, ns) calls: > > public Attribute(String name, String value, Namespace namespace) { > setName(name); > setValue(value); > setNamespace(namespace); > } > > Here setNamespace(namespace) calls: > public Attribute setNamespace(Namespace namespace) { > if (namespace == null) { > namespace = Namespace.NO_NAMESPACE; > } > > // Verify the attribute isn't trying to be in a default namespace > // Attributes can't be in a default namespace > if (namespace != Namespace.NO_NAMESPACE&& > namespace.getPrefix().equals("")) { > throw new IllegalNameException("", "attribute namespace", > "An attribute namespace without a prefix can only be the " + > "NO_NAMESPACE namespace"); > } > this.namespace = namespace; > return this; > } > > where namespace being null is set to NO_NAMESPACE. > > > > > Stack trace (JODM 1.1.3): > > java.lang.NullPointerException > at org.jdom.AttributeList.indexOf(AttributeList.java:378) > at org.jdom.AttributeList.get(AttributeList.java:366) > at org.jdom.Element.getAttribute(Element.java:1004) > at org.jdom.Element.setAttribute(Element.java:1178) > at com.navis.argo.business.snx.AbstractXmlExporter.setAttribute(AbstractXmlExporter.java:40) > > > -------------- > > > -----Original Message----- > From: Rolf Lear [mailto:jdom at tuis.net] > Sent: Friday, April 06, 2012 2:40 PM > To: Saavedra Gisella > Cc: jdom-interest at jdom.org > Subject: Re: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) > > Hi Gisella. > > I have looked through the JDOM 1.0 code. JDOM 1.0 was released in > September 2004. Here's the code as it was at the time: > > Here's the getAttribute method: > https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/Element.java#L980 > > Here's the attributes.get(String,Namespace) method: > https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L365 > > And that calls the indexOf(String,Namespace) method: > https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L377 > > Which calls namespace.getURI(). > > The way I see it is that JDOM 1.0 would always throw a > NullPointerException if you gave it a null Namespace. > > I don't think it would have ever worked in JDOM 1.0... > > Did you have your own custom build of JDOM 1.0? > > Rolf > > On 06/04/2012 5:08 PM, Rolf Lear wrote: >> Hi Gisella. >> >> Is it possible to send us a stack trace, at least the parts including >> the org.jdom.* code. >> >> Thanks >> >> Rolf >> >> >> On 06/04/2012 1:43 PM, gisella.saavedra at navis.com wrote: >>> I just upgraded from jdom 1.0 to jdom 1.1.3 >>> >>> and I was setting an attribute where the namespace was NULL. >>> >>> The old code was different, it was NOT calling get(...), so it was setting >>> the namespace to namespace.NO_NAMESPACE when the namespace was NULL, >>> >>> before calling this get(...) >>> >>> but the new code, when it calls getAttribute(name, ns) (first line of >>> method described) >>> >>> is getting a null pointer on the namespace. >>> >>> Probably the namespace needs to be set to NO_NAMESPACE before calling >>> get(..) when it is NULL. >>> >>> *Gisella Saavedra** >>> *Framework Team >>> _gsaavedra at navis.com_ >>> >>> >>> >>> http://www.navis.com/images/spacer.gif >>> >>> 1000 Broadway, Suite 150, Oakland, CA 94607 | T+1 510 267 5123 T Main+1 >>> 510 267 5000 F+1 510 267 5100 | _http://www.navis.com >>> _ >>> >>> >>> >>> _______________________________________________ >>> To control your jdom-interest membership: >>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > From jdom at tuis.net Fri Apr 6 19:08:52 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 06 Apr 2012 22:08:52 -0400 Subject: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) In-Reply-To: <6A01160BED1CB74CB2F447CB21ED5C110119B039ECF7@INT03EXVS3.mcint.local> References: <6A01160BED1CB74CB2F447CB21ED5C110119B039EA32@INT03EXVS3.mcint.local> <4F7F5B62.6020201@tuis.net> <4F7F629F.7080202@tuis.net> <6A01160BED1CB74CB2F447CB21ED5C110119B039EC12@INT03EXVS3.mcint.local> <4F7F7E7B.8080703@tuis.net> <6A01160BED1CB74CB2F447CB21ED5C110119B039ECF7@INT03EXVS3.mcint.local> Message-ID: <4F7FA1B4.4060309@tuis.net> Hi again Gisella. I think your examples are great, in the sense that they perfectly illustrate the inconsistencies. On the other hand, they do not help solve the problem of which one is right or wrong. It does make me want to make sure that new Element(String, null) throws NPE though! Currently the Attribute handling is 'consistent'... get, remove, set all throw NPE for null Namespace. I can't think of a nice way to put it, but the easiest thing to do would be to change your code to use a conditional: emt.setAttribute(String, String, ns == null ? Namespace.NO_NAMESPACE : ns); That's for 1.1.3 at least. I still think that maybe I could change the logic on JDOM 2.0.0... For all the get/set/remove Attribute I can maybe put the if-logic in. Yes, I have played with it, and it's a reasonable thing to do for 2.0.0. It is also consistent with 'new Attribute(String, String, null). On the whole, I would agree with you, it should not throw NPE, and get and remove should not throw NPE either. I just changed to code to 'work', and, surprisingly, all the tests pass. That's the wonders of wvwn with 100% code coverage you still miss some things. Maybe that will inspire you to try JDOM 2.0.0 ;-) Rolf On 06/04/2012 8:28 PM, gisella.saavedra at navis.com wrote: > I see the inconsistencies > I would say that when removing the nullpointerexception is OK. But when creating, you can see for example > new Element(string name) > new Element (String name, null) > both set the value of Namespace to NO_NAMESPACE. > And Element.setAttribute(final String name, final String value) does not throw a NPE > but Element.setAttribute(final String name, final String value, null) does. > > > -----Original Message----- > From: Rolf Lear [mailto:jdom at tuis.net] > Sent: Friday, April 06, 2012 4:39 PM > To: Saavedra Gisella > Cc: jdom-interest at jdom.org > Subject: Re: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) > > Hi Gisella > > Yes, I can see now where the change is. It happened between JDOM 1.0 and > 1.1, back in 2006 ... > https://github.com/hunterhacker/jdom/commit/b48373d95cd91986f83ac5345566258d80e88027#L0R1139 > > In fact, this issue has been reported before: > http://markmail.org/message/atybnwqqvlxk7ut4 and there was never any > follow-up... > > So, I can see the problem, and it still exists in JDOM 2.x. > > But, I can't see an easy fix. > > I am of the opinion that null input values deserve a > NullPointerException unless documented that nulls are allowed... but I > also recognize that compatibility is important, and JDOM has some > consistency in it when treating null Namespace values > as Namespace.NO_NAMESPACE. > > So, I am going to think about it for a moment.... but, I would not > expect a fix in the short term for JDOM 1.x. Even in the best > circumstances it would take a month or so to get a 1.1.4 out... > > For JDOM 2.x, it is also very late in the game.... too late, in fact. > > In order to fix it properly I would have to decide on a strategy for > dealing with null Namespace input. A quick 'poll' of the JDOM 2.x code > suggests: > > > Change null to NO_NAMESPACE: > ---------------------------- > Element Constructor. > Element.setNamespace(Namespace) > > > Treats null as 'wildcard': > -------------------------- > Element.getChild(String,Namespace) > Element.getChildren(String,Namespace) > Element.getChildText*(String,Namespace) > Element.removeChild(String,Namespace) > Element.removeChildren(String,Namespace) > > > Just ignores it. > ---------------- > Element.removeNamespaceDeclaration(Namespace) > > > Throws NPE: > ----------- > Element.addNamespaceDeclaration(Namespace) > Element.getAttribute(String,Namespace) > Element.getAttributeValue(String,Namespace); > Element.getAttributeValue(String,Namespace, String); > Element.removeAttribute(String,Namespace); > Element.setAttribute(String,String,Namespace) > > > I think, having looked at the 'poll' results, when it comes to > Attributes, the NPE is the 'right' thing. > > Given that getAttribute(String,Namespace) throws NPE (and > removeAttribute), and they have 'always' thrown NPE, I think it is > logical that setAttribute(String,String,Namespace) throws NPE too. > > Bottom line is that I am not convinced that it is a bug in 1.1.3. > Perhaps it was a bug in 1.0 to allow the null. > > So, this all comes around to the 'push-back' option. How difficult is it > for you to do the null-check yourself before you call setAttribute()? > > That is the obvious workaround, and it is the 'right thing'.... > > Rolf > > > > > On 06/04/2012 5:53 PM, gisella.saavedra at navis.com wrote: >> the stack trace belongs to JDOM 1.1.3 >> >> -----Original Message----- >> From: Saavedra Gisella >> Sent: Friday, April 06, 2012 2:49 PM >> To: 'Rolf Lear' >> Cc: jdom-interest at jdom.org >> Subject: RE: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) >> >> Rolf, >> >> I believe you might be looking at the wrong method: >> >> This is JDOM 1.0 (ns is passed as null) >> >> public Element setAttribute(String name, String value, Namespace ns) { >> return setAttribute(new Attribute(name, value, ns)); >> } >> >> Inside this code, the constructor new Attribute(name, value, ns) calls: >> >> public Attribute(String name, String value, Namespace namespace) { >> setName(name); >> setValue(value); >> setNamespace(namespace); >> } >> >> Here setNamespace(namespace) calls: >> public Attribute setNamespace(Namespace namespace) { >> if (namespace == null) { >> namespace = Namespace.NO_NAMESPACE; >> } >> >> // Verify the attribute isn't trying to be in a default namespace >> // Attributes can't be in a default namespace >> if (namespace != Namespace.NO_NAMESPACE&& >> namespace.getPrefix().equals("")) { >> throw new IllegalNameException("", "attribute namespace", >> "An attribute namespace without a prefix can only be the " + >> "NO_NAMESPACE namespace"); >> } >> this.namespace = namespace; >> return this; >> } >> >> where namespace being null is set to NO_NAMESPACE. >> >> >> >> >> Stack trace (JODM 1.1.3): >> >> java.lang.NullPointerException >> at org.jdom.AttributeList.indexOf(AttributeList.java:378) >> at org.jdom.AttributeList.get(AttributeList.java:366) >> at org.jdom.Element.getAttribute(Element.java:1004) >> at org.jdom.Element.setAttribute(Element.java:1178) >> at com.navis.argo.business.snx.AbstractXmlExporter.setAttribute(AbstractXmlExporter.java:40) >> >> >> -------------- >> >> >> -----Original Message----- >> From: Rolf Lear [mailto:jdom at tuis.net] >> Sent: Friday, April 06, 2012 2:40 PM >> To: Saavedra Gisella >> Cc: jdom-interest at jdom.org >> Subject: Re: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) >> >> Hi Gisella. >> >> I have looked through the JDOM 1.0 code. JDOM 1.0 was released in >> September 2004. Here's the code as it was at the time: >> >> Here's the getAttribute method: >> https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/Element.java#L980 >> >> Here's the attributes.get(String,Namespace) method: >> https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L365 >> >> And that calls the indexOf(String,Namespace) method: >> https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L377 >> >> Which calls namespace.getURI(). >> >> The way I see it is that JDOM 1.0 would always throw a >> NullPointerException if you gave it a null Namespace. >> >> I don't think it would have ever worked in JDOM 1.0... >> >> Did you have your own custom build of JDOM 1.0? >> >> Rolf >> >> On 06/04/2012 5:08 PM, Rolf Lear wrote: >>> Hi Gisella. >>> >>> Is it possible to send us a stack trace, at least the parts including >>> the org.jdom.* code. >>> >>> Thanks >>> >>> Rolf >>> >>> >>> On 06/04/2012 1:43 PM, gisella.saavedra at navis.com wrote: >>>> I just upgraded from jdom 1.0 to jdom 1.1.3 >>>> >>>> and I was setting an attribute where the namespace was NULL. >>>> >>>> The old code was different, it was NOT calling get(...), so it was setting >>>> the namespace to namespace.NO_NAMESPACE when the namespace was NULL, >>>> >>>> before calling this get(...) >>>> >>>> but the new code, when it calls getAttribute(name, ns) (first line of >>>> method described) >>>> >>>> is getting a null pointer on the namespace. >>>> >>>> Probably the namespace needs to be set to NO_NAMESPACE before calling >>>> get(..) when it is NULL. >>>> >>>> *Gisella Saavedra** >>>> *Framework Team >>>> _gsaavedra at navis.com_ >>>> >>>> >>>> >>>> http://www.navis.com/images/spacer.gif >>>> >>>> 1000 Broadway, Suite 150, Oakland, CA 94607 | T+1 510 267 5123 T Main+1 >>>> 510 267 5000 F+1 510 267 5100 | _http://www.navis.com >>>> _ >>>> >>>> >>>> >>>> _______________________________________________ >>>> To control your jdom-interest membership: >>>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>> >>> _______________________________________________ >>> To control your jdom-interest membership: >>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>> >> > From bashiro at myway.com Sat Apr 7 17:07:12 2012 From: bashiro at myway.com (Bashiro) Date: Sat, 07 Apr 2012 20:07:12 -0400 Subject: [jdom-interest] Empty File Message-ID: <20120407200712.32185@web007.roc2.bluetie.com> Hello Folks, I wonder if Jdom can check a file is empty before attempting to read ? Bashiro Drammen-Norway From jdom at tuis.net Sat Apr 7 17:33:45 2012 From: jdom at tuis.net (Rolf Lear) Date: Sat, 07 Apr 2012 20:33:45 -0400 Subject: [jdom-interest] Empty File In-Reply-To: <20120407200712.32185@web007.roc2.bluetie.com> References: <20120407200712.32185@web007.roc2.bluetie.com> Message-ID: <4F80DCE9.5080705@tuis.net> Hi Bashiro Interesting question, and I can understand why you would ask, but, technically, no. JDOM itself does not read the file. It passes it directly to the configured XML Parser (Typically the SAX Parser). In many instances, JDOM does not even know it is reading a file... it is often converted to a URL before JDOM is aware of its source. It would not be possible to have a consistent way to check the 'input'. Further, there is no consistent way to produce errors. In your case you would possibly want an empty Document returned from the parse, but most people would want an Exception. So, the logical answer is no. If you know you are parsing a file, it would be easy for you to check the File.length() before parsing. If it is not a file source, there is no way for JDOM to intercept the stream before the SAX parser, so no, it cannot be done. Out of interest, I tried it to see what JDOM does, and, for any file with any amount of plain white-space (newlines, spaces, etc.) it all produces the same Exception: Exception in thread "main" org.jdom2.input.JDOMParseException: Error on line -1: Premature end of file. at org.jdom2.input.sax.SAXBuilderEngine.build(SAXBuilderEngine.java:232) at org.jdom2.input.sax.SAXBuilderEngine.build(SAXBuilderEngine.java:277) at org.jdom2.input.sax.SAXBuilderEngine.build(SAXBuilderEngine.java:264) at org.jdom2.input.SAXBuilder.build(SAXBuilder.java:1116) at net.tuis.debug.EMptyFile.main(EMptyFile.java:15) Caused by: org.xml.sax.SAXParseException: Premature end of file. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) If you consistently use Xerces, you may be able to trap the JDOMException, and check to see whether the SAXException error is on line -1... which appears, at least in my experimenting, to indicate whether the file has white-space-only content. Thus, you may be able to trap the empty-source problem after the fact. Rolf On 07/04/2012 8:07 PM, Bashiro wrote: > Hello Folks, > > I wonder if Jdom can check a file is empty before attempting to read ? > > Bashiro > Drammen-Norway > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From jdom at tuis.net Sun Apr 8 18:06:15 2012 From: jdom at tuis.net (Rolf Lear) Date: Sun, 08 Apr 2012 21:06:15 -0400 Subject: [jdom-interest] JDOM 2.0.0 is released Message-ID: <4F823607.9070509@tuis.net> Hi all! JDOM 2.0.0 is out and available at http://jdom.org/downloads/index.html It is also available on maven-central (or will be soon) as GroupID org.jdom, ArtifactID jdom, and Version 2.0.0. For details on all the new features available in JDOM 2.0.0 please see the wiki page: https://github.com/hunterhacker/jdom/wiki/JDOM2-Features For a 'Primer' on getting started with JDOM, some basic concepts, and examples on how to accomplish the most common tasks in JDOM, see: https://github.com/hunterhacker/jdom/wiki/JDOM2-A-Primer For insights on what issues to expect when changing from JDOM 1.x to 2.x have a look at the 'Migration Guide' here: https://github.com/hunterhacker/jdom/wiki/JDOM2-Migration-Issues The JavaDoc is available in the release, as well as at: http://jdom.org/docs/apidocs/index.html Like previous snapshot releases, the JUnit and Cobertura test-coverage reports are available at: http://hunterhacker.github.com/jdom/jdom2/junit.report/index.html http://hunterhacker.github.com/jdom/jdom2/coverage/index.html As always, if you have any comments, suggestions, concerns, please speak up! Happy Coding Rolf From gisella.saavedra at navis.com Mon Apr 9 08:59:54 2012 From: gisella.saavedra at navis.com (gisella.saavedra at navis.com) Date: Mon, 9 Apr 2012 18:59:54 +0300 Subject: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) In-Reply-To: <4F7FA1B4.4060309@tuis.net> References: <6A01160BED1CB74CB2F447CB21ED5C110119B039EA32@INT03EXVS3.mcint.local> <4F7F5B62.6020201@tuis.net> <4F7F629F.7080202@tuis.net> <6A01160BED1CB74CB2F447CB21ED5C110119B039EC12@INT03EXVS3.mcint.local> <4F7F7E7B.8080703@tuis.net> <6A01160BED1CB74CB2F447CB21ED5C110119B039ECF7@INT03EXVS3.mcint.local> <4F7FA1B4.4060309@tuis.net> Message-ID: <6A01160BED1CB74CB2F447CB21ED5C110119B044210C@INT03EXVS3.mcint.local> thank you, Rolf. I had patched our code using JDOM 1.1.3, to check for null. A solution for the NPE in JDOM 1.1.3/2.x could be: As in Element.java: public Attribute getAttribute(final String name) { return getAttribute(name, Namespace.NO_NAMESPACE); } then: public Attribute getAttribute(final String name, final Namespace ns) { return (Attribute) attributes.get(name, (ns == null)? Namespace.NO_NAMESPACE : ns); } Thanks. -----Original Message----- From: Rolf Lear [mailto:jdom at tuis.net] Sent: Friday, April 06, 2012 7:09 PM To: Saavedra Gisella Cc: jdom-interest at jdom.org; Jason Hunter Subject: Re: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) Hi again Gisella. I think your examples are great, in the sense that they perfectly illustrate the inconsistencies. On the other hand, they do not help solve the problem of which one is right or wrong. It does make me want to make sure that new Element(String, null) throws NPE though! Currently the Attribute handling is 'consistent'... get, remove, set all throw NPE for null Namespace. I can't think of a nice way to put it, but the easiest thing to do would be to change your code to use a conditional: emt.setAttribute(String, String, ns == null ? Namespace.NO_NAMESPACE : ns); That's for 1.1.3 at least. I still think that maybe I could change the logic on JDOM 2.0.0... For all the get/set/remove Attribute I can maybe put the if-logic in. Yes, I have played with it, and it's a reasonable thing to do for 2.0.0. It is also consistent with 'new Attribute(String, String, null). On the whole, I would agree with you, it should not throw NPE, and get and remove should not throw NPE either. I just changed to code to 'work', and, surprisingly, all the tests pass. That's the wonders of wvwn with 100% code coverage you still miss some things. Maybe that will inspire you to try JDOM 2.0.0 ;-) Rolf On 06/04/2012 8:28 PM, gisella.saavedra at navis.com wrote: > I see the inconsistencies > I would say that when removing the nullpointerexception is OK. But when creating, you can see for example > new Element(string name) > new Element (String name, null) > both set the value of Namespace to NO_NAMESPACE. > And Element.setAttribute(final String name, final String value) does not throw a NPE > but Element.setAttribute(final String name, final String value, null) does. > > > -----Original Message----- > From: Rolf Lear [mailto:jdom at tuis.net] > Sent: Friday, April 06, 2012 4:39 PM > To: Saavedra Gisella > Cc: jdom-interest at jdom.org > Subject: Re: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) > > Hi Gisella > > Yes, I can see now where the change is. It happened between JDOM 1.0 and > 1.1, back in 2006 ... > https://github.com/hunterhacker/jdom/commit/b48373d95cd91986f83ac5345566258d80e88027#L0R1139 > > In fact, this issue has been reported before: > http://markmail.org/message/atybnwqqvlxk7ut4 and there was never any > follow-up... > > So, I can see the problem, and it still exists in JDOM 2.x. > > But, I can't see an easy fix. > > I am of the opinion that null input values deserve a > NullPointerException unless documented that nulls are allowed... but I > also recognize that compatibility is important, and JDOM has some > consistency in it when treating null Namespace values > as Namespace.NO_NAMESPACE. > > So, I am going to think about it for a moment.... but, I would not > expect a fix in the short term for JDOM 1.x. Even in the best > circumstances it would take a month or so to get a 1.1.4 out... > > For JDOM 2.x, it is also very late in the game.... too late, in fact. > > In order to fix it properly I would have to decide on a strategy for > dealing with null Namespace input. A quick 'poll' of the JDOM 2.x code > suggests: > > > Change null to NO_NAMESPACE: > ---------------------------- > Element Constructor. > Element.setNamespace(Namespace) > > > Treats null as 'wildcard': > -------------------------- > Element.getChild(String,Namespace) > Element.getChildren(String,Namespace) > Element.getChildText*(String,Namespace) > Element.removeChild(String,Namespace) > Element.removeChildren(String,Namespace) > > > Just ignores it. > ---------------- > Element.removeNamespaceDeclaration(Namespace) > > > Throws NPE: > ----------- > Element.addNamespaceDeclaration(Namespace) > Element.getAttribute(String,Namespace) > Element.getAttributeValue(String,Namespace); > Element.getAttributeValue(String,Namespace, String); > Element.removeAttribute(String,Namespace); > Element.setAttribute(String,String,Namespace) > > > I think, having looked at the 'poll' results, when it comes to > Attributes, the NPE is the 'right' thing. > > Given that getAttribute(String,Namespace) throws NPE (and > removeAttribute), and they have 'always' thrown NPE, I think it is > logical that setAttribute(String,String,Namespace) throws NPE too. > > Bottom line is that I am not convinced that it is a bug in 1.1.3. > Perhaps it was a bug in 1.0 to allow the null. > > So, this all comes around to the 'push-back' option. How difficult is it > for you to do the null-check yourself before you call setAttribute()? > > That is the obvious workaround, and it is the 'right thing'.... > > Rolf > > > > > On 06/04/2012 5:53 PM, gisella.saavedra at navis.com wrote: >> the stack trace belongs to JDOM 1.1.3 >> >> -----Original Message----- >> From: Saavedra Gisella >> Sent: Friday, April 06, 2012 2:49 PM >> To: 'Rolf Lear' >> Cc: jdom-interest at jdom.org >> Subject: RE: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) >> >> Rolf, >> >> I believe you might be looking at the wrong method: >> >> This is JDOM 1.0 (ns is passed as null) >> >> public Element setAttribute(String name, String value, Namespace ns) { >> return setAttribute(new Attribute(name, value, ns)); >> } >> >> Inside this code, the constructor new Attribute(name, value, ns) calls: >> >> public Attribute(String name, String value, Namespace namespace) { >> setName(name); >> setValue(value); >> setNamespace(namespace); >> } >> >> Here setNamespace(namespace) calls: >> public Attribute setNamespace(Namespace namespace) { >> if (namespace == null) { >> namespace = Namespace.NO_NAMESPACE; >> } >> >> // Verify the attribute isn't trying to be in a default namespace >> // Attributes can't be in a default namespace >> if (namespace != Namespace.NO_NAMESPACE&& >> namespace.getPrefix().equals("")) { >> throw new IllegalNameException("", "attribute namespace", >> "An attribute namespace without a prefix can only be the " + >> "NO_NAMESPACE namespace"); >> } >> this.namespace = namespace; >> return this; >> } >> >> where namespace being null is set to NO_NAMESPACE. >> >> >> >> >> Stack trace (JODM 1.1.3): >> >> java.lang.NullPointerException >> at org.jdom.AttributeList.indexOf(AttributeList.java:378) >> at org.jdom.AttributeList.get(AttributeList.java:366) >> at org.jdom.Element.getAttribute(Element.java:1004) >> at org.jdom.Element.setAttribute(Element.java:1178) >> at com.navis.argo.business.snx.AbstractXmlExporter.setAttribute(AbstractXmlExporter.java:40) >> >> >> -------------- >> >> >> -----Original Message----- >> From: Rolf Lear [mailto:jdom at tuis.net] >> Sent: Friday, April 06, 2012 2:40 PM >> To: Saavedra Gisella >> Cc: jdom-interest at jdom.org >> Subject: Re: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) >> >> Hi Gisella. >> >> I have looked through the JDOM 1.0 code. JDOM 1.0 was released in >> September 2004. Here's the code as it was at the time: >> >> Here's the getAttribute method: >> https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/Element.java#L980 >> >> Here's the attributes.get(String,Namespace) method: >> https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L365 >> >> And that calls the indexOf(String,Namespace) method: >> https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L377 >> >> Which calls namespace.getURI(). >> >> The way I see it is that JDOM 1.0 would always throw a >> NullPointerException if you gave it a null Namespace. >> >> I don't think it would have ever worked in JDOM 1.0... >> >> Did you have your own custom build of JDOM 1.0? >> >> Rolf >> >> On 06/04/2012 5:08 PM, Rolf Lear wrote: >>> Hi Gisella. >>> >>> Is it possible to send us a stack trace, at least the parts including >>> the org.jdom.* code. >>> >>> Thanks >>> >>> Rolf >>> >>> >>> On 06/04/2012 1:43 PM, gisella.saavedra at navis.com wrote: >>>> I just upgraded from jdom 1.0 to jdom 1.1.3 >>>> >>>> and I was setting an attribute where the namespace was NULL. >>>> >>>> The old code was different, it was NOT calling get(...), so it was setting >>>> the namespace to namespace.NO_NAMESPACE when the namespace was NULL, >>>> >>>> before calling this get(...) >>>> >>>> but the new code, when it calls getAttribute(name, ns) (first line of >>>> method described) >>>> >>>> is getting a null pointer on the namespace. >>>> >>>> Probably the namespace needs to be set to NO_NAMESPACE before calling >>>> get(..) when it is NULL. >>>> >>>> *Gisella Saavedra** >>>> *Framework Team >>>> _gsaavedra at navis.com_ >>>> >>>> >>>> >>>> http://www.navis.com/images/spacer.gif >>>> >>>> 1000 Broadway, Suite 150, Oakland, CA 94607 | T+1 510 267 5123 T Main+1 >>>> 510 267 5000 F+1 510 267 5100 | _http://www.navis.com >>>> _ >>>> >>>> >>>> >>>> _______________________________________________ >>>> To control your jdom-interest membership: >>>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>> >>> _______________________________________________ >>> To control your jdom-interest membership: >>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>> >> > From jdom at tuis.net Mon Apr 9 09:06:48 2012 From: jdom at tuis.net (Rolf Lear) Date: Mon, 09 Apr 2012 12:06:48 -0400 Subject: [jdom-interest] NullPointerException in Element.setAttribute(final String name, final String value, final Namespace ns) In-Reply-To: <6A01160BED1CB74CB2F447CB21ED5C110119B044210C@INT03EXVS3.mcint.local> References: <6A01160BED1CB74CB2F447CB21ED5C110119B039EA32@INT03EXVS3.mcint.local> <4F7F5B62.6020201@tuis.net> <4F7F629F.7080202@tuis.net> <6A01160BED1CB74CB2F447CB21ED5C110119B039EC12@INT03EXVS3.mcint.local> <4F7F7E7B.8080703@tuis.net> <6A01160BED1CB74CB2F447CB21ED5C110119B039ECF7@INT03EXVS3.mcint.local> <4F7FA1B4.4060309@tuis.net> <6A01160BED1CB74CB2F447CB21ED5C110119B044210C@INT03EXVS3.mcint.local> Message-ID: Hi Gisella. I pushed through a change for 2.0.0.... Issue: https://github.com/hunterhacker/jdom/issues/71 Commit: https://github.com/hunterhacker/jdom/commit/587efe408670d112f6e1af7094373e20f5a8d0aa In JDOM 2 I have more flexibility with changing the API, and this one makes it all somewhat more consistent.... So, the fix is already in for 2.0.0, and released. I don't expect this to be changed in 1.1.4. It is possible it could break existing behaviour for other people.... Rolf On Mon, 9 Apr 2012 18:59:54 +0300, wrote: > thank you, Rolf. > I had patched our code using JDOM 1.1.3, to check for null. > > A solution for the NPE in JDOM 1.1.3/2.x could be: > > As in Element.java: > > public Attribute getAttribute(final String name) { > return getAttribute(name, Namespace.NO_NAMESPACE); > } > > then: > > public Attribute getAttribute(final String name, final Namespace ns) { > return (Attribute) attributes.get(name, (ns == null)? > Namespace.NO_NAMESPACE : ns); > } > > Thanks. > > -----Original Message----- > From: Rolf Lear [mailto:jdom at tuis.net] > Sent: Friday, April 06, 2012 7:09 PM > To: Saavedra Gisella > Cc: jdom-interest at jdom.org; Jason Hunter > Subject: Re: [jdom-interest] NullPointerException in > Element.setAttribute(final String name, final String value, final Namespace > ns) > > Hi again Gisella. > > I think your examples are great, in the sense that they perfectly > illustrate the inconsistencies. On the other hand, they do not help > solve the problem of which one is right or wrong. It does make me want > to make sure that new Element(String, null) throws NPE though! > > Currently the Attribute handling is 'consistent'... get, remove, set all > throw NPE for null Namespace. > > I can't think of a nice way to put it, but the easiest thing to do would > be to change your code to use a conditional: > emt.setAttribute(String, String, > ns == null ? Namespace.NO_NAMESPACE : ns); > > That's for 1.1.3 at least. > > I still think that maybe I could change the logic on JDOM 2.0.0... > > For all the get/set/remove Attribute I can maybe put the if-logic in. > > Yes, I have played with it, and it's a reasonable thing to do for 2.0.0. > It is also consistent with 'new Attribute(String, String, null). > > On the whole, I would agree with you, it should not throw NPE, and get > and remove should not throw NPE either. > > I just changed to code to 'work', and, surprisingly, all the tests pass. > > That's the wonders of wvwn with 100% code coverage you still miss some > things. > > Maybe that will inspire you to try JDOM 2.0.0 ;-) > > Rolf > > > On 06/04/2012 8:28 PM, gisella.saavedra at navis.com wrote: >> I see the inconsistencies >> I would say that when removing the nullpointerexception is OK. But when >> creating, you can see for example >> new Element(string name) >> new Element (String name, null) >> both set the value of Namespace to NO_NAMESPACE. >> And Element.setAttribute(final String name, final String value) does not >> throw a NPE >> but Element.setAttribute(final String name, final String value, null) >> does. >> >> >> -----Original Message----- >> From: Rolf Lear [mailto:jdom at tuis.net] >> Sent: Friday, April 06, 2012 4:39 PM >> To: Saavedra Gisella >> Cc: jdom-interest at jdom.org >> Subject: Re: [jdom-interest] NullPointerException in >> Element.setAttribute(final String name, final String value, final >> Namespace ns) >> >> Hi Gisella >> >> Yes, I can see now where the change is. It happened between JDOM 1.0 and >> 1.1, back in 2006 ... >> https://github.com/hunterhacker/jdom/commit/b48373d95cd91986f83ac5345566258d80e88027#L0R1139 >> >> In fact, this issue has been reported before: >> http://markmail.org/message/atybnwqqvlxk7ut4 and there was never any >> follow-up... >> >> So, I can see the problem, and it still exists in JDOM 2.x. >> >> But, I can't see an easy fix. >> >> I am of the opinion that null input values deserve a >> NullPointerException unless documented that nulls are allowed... but I >> also recognize that compatibility is important, and JDOM has some >> consistency in it when treating null Namespace values >> as Namespace.NO_NAMESPACE. >> >> So, I am going to think about it for a moment.... but, I would not >> expect a fix in the short term for JDOM 1.x. Even in the best >> circumstances it would take a month or so to get a 1.1.4 out... >> >> For JDOM 2.x, it is also very late in the game.... too late, in fact. >> >> In order to fix it properly I would have to decide on a strategy for >> dealing with null Namespace input. A quick 'poll' of the JDOM 2.x code >> suggests: >> >> >> Change null to NO_NAMESPACE: >> ---------------------------- >> Element Constructor. >> Element.setNamespace(Namespace) >> >> >> Treats null as 'wildcard': >> -------------------------- >> Element.getChild(String,Namespace) >> Element.getChildren(String,Namespace) >> Element.getChildText*(String,Namespace) >> Element.removeChild(String,Namespace) >> Element.removeChildren(String,Namespace) >> >> >> Just ignores it. >> ---------------- >> Element.removeNamespaceDeclaration(Namespace) >> >> >> Throws NPE: >> ----------- >> Element.addNamespaceDeclaration(Namespace) >> Element.getAttribute(String,Namespace) >> Element.getAttributeValue(String,Namespace); >> Element.getAttributeValue(String,Namespace, String); >> Element.removeAttribute(String,Namespace); >> Element.setAttribute(String,String,Namespace) >> >> >> I think, having looked at the 'poll' results, when it comes to >> Attributes, the NPE is the 'right' thing. >> >> Given that getAttribute(String,Namespace) throws NPE (and >> removeAttribute), and they have 'always' thrown NPE, I think it is >> logical that setAttribute(String,String,Namespace) throws NPE too. >> >> Bottom line is that I am not convinced that it is a bug in 1.1.3. >> Perhaps it was a bug in 1.0 to allow the null. >> >> So, this all comes around to the 'push-back' option. How difficult is it >> for you to do the null-check yourself before you call setAttribute()? >> >> That is the obvious workaround, and it is the 'right thing'.... >> >> Rolf >> >> >> >> >> On 06/04/2012 5:53 PM, gisella.saavedra at navis.com wrote: >>> the stack trace belongs to JDOM 1.1.3 >>> >>> -----Original Message----- >>> From: Saavedra Gisella >>> Sent: Friday, April 06, 2012 2:49 PM >>> To: 'Rolf Lear' >>> Cc: jdom-interest at jdom.org >>> Subject: RE: [jdom-interest] NullPointerException in >>> Element.setAttribute(final String name, final String value, final >>> Namespace ns) >>> >>> Rolf, >>> >>> I believe you might be looking at the wrong method: >>> >>> This is JDOM 1.0 (ns is passed as null) >>> >>> public Element setAttribute(String name, String value, Namespace >>> ns) { >>> return setAttribute(new Attribute(name, value, ns)); >>> } >>> >>> Inside this code, the constructor new Attribute(name, value, ns) calls: >>> >>> public Attribute(String name, String value, Namespace namespace) { >>> setName(name); >>> setValue(value); >>> setNamespace(namespace); >>> } >>> >>> Here setNamespace(namespace) calls: >>> public Attribute setNamespace(Namespace namespace) { >>> if (namespace == null) { >>> namespace = Namespace.NO_NAMESPACE; >>> } >>> >>> // Verify the attribute isn't trying to be in a default >>> namespace >>> // Attributes can't be in a default namespace >>> if (namespace != Namespace.NO_NAMESPACE&& >>> namespace.getPrefix().equals("")) { >>> throw new IllegalNameException("", "attribute namespace", >>> "An attribute namespace without a prefix can only be >>> the " + >>> "NO_NAMESPACE namespace"); >>> } >>> this.namespace = namespace; >>> return this; >>> } >>> >>> where namespace being null is set to NO_NAMESPACE. >>> >>> >>> >>> >>> Stack trace (JODM 1.1.3): >>> >>> java.lang.NullPointerException >>> at org.jdom.AttributeList.indexOf(AttributeList.java:378) >>> at org.jdom.AttributeList.get(AttributeList.java:366) >>> at org.jdom.Element.getAttribute(Element.java:1004) >>> at org.jdom.Element.setAttribute(Element.java:1178) >>> at >>> com.navis.argo.business.snx.AbstractXmlExporter.setAttribute(AbstractXmlExporter.java:40) >>> >>> >>> -------------- >>> >>> >>> -----Original Message----- >>> From: Rolf Lear [mailto:jdom at tuis.net] >>> Sent: Friday, April 06, 2012 2:40 PM >>> To: Saavedra Gisella >>> Cc: jdom-interest at jdom.org >>> Subject: Re: [jdom-interest] NullPointerException in >>> Element.setAttribute(final String name, final String value, final >>> Namespace ns) >>> >>> Hi Gisella. >>> >>> I have looked through the JDOM 1.0 code. JDOM 1.0 was released in >>> September 2004. Here's the code as it was at the time: >>> >>> Here's the getAttribute method: >>> https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/Element.java#L980 >>> >>> Here's the attributes.get(String,Namespace) method: >>> https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L365 >>> >>> And that calls the indexOf(String,Namespace) method: >>> https://github.com/hunterhacker/jdom/blob/jdom-1.0/core/src/java/org/jdom/AttributeList.java#L377 >>> >>> Which calls namespace.getURI(). >>> >>> The way I see it is that JDOM 1.0 would always throw a >>> NullPointerException if you gave it a null Namespace. >>> >>> I don't think it would have ever worked in JDOM 1.0... >>> >>> Did you have your own custom build of JDOM 1.0? >>> >>> Rolf >>> >>> On 06/04/2012 5:08 PM, Rolf Lear wrote: >>>> Hi Gisella. >>>> >>>> Is it possible to send us a stack trace, at least the parts including >>>> the org.jdom.* code. >>>> >>>> Thanks >>>> >>>> Rolf >>>> >>>> >>>> On 06/04/2012 1:43 PM, gisella.saavedra at navis.com wrote: >>>>> I just upgraded from jdom 1.0 to jdom 1.1.3 >>>>> >>>>> and I was setting an attribute where the namespace was NULL. >>>>> >>>>> The old code was different, it was NOT calling get(...), so it was >>>>> setting >>>>> the namespace to namespace.NO_NAMESPACE when the namespace was NULL, >>>>> >>>>> before calling this get(...) >>>>> >>>>> but the new code, when it calls getAttribute(name, ns) (first line of >>>>> method described) >>>>> >>>>> is getting a null pointer on the namespace. >>>>> >>>>> Probably the namespace needs to be set to NO_NAMESPACE before calling >>>>> get(..) when it is NULL. >>>>> >>>>> *Gisella Saavedra** >>>>> *Framework Team >>>>> _gsaavedra at navis.com_ >>>>> >>>>> >>>>> >>>>> http://www.navis.com/images/spacer.gif >>>>> >>>>> 1000 Broadway, Suite 150, Oakland, CA 94607 | T+1 510 267 5123 T >>>>> Main+1 >>>>> 510 267 5000 F+1 510 267 5100 | _http://www.navis.com >>>>> _ >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> To control your jdom-interest membership: >>>>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>>> >>>> _______________________________________________ >>>> To control your jdom-interest membership: >>>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>>> >>> >> From bashiro at myway.com Mon Apr 9 09:47:56 2012 From: bashiro at myway.com (Bashiro) Date: Mon, 09 Apr 2012 12:47:56 -0400 Subject: [jdom-interest] Removing Elements Message-ID: <20120409124756.17823@web006.roc2.bluetie.com> Hello Folks! First of all thanks to the jDom team for version 2.0! Congrats to us all... My question is; I am trying to remove an element in jDom. It only removes the element if the element is located at [0]. Is there a good code or a good book to help me with that ? Thanks Bashiro Drammen-Norway From jdom at tuis.net Mon Apr 9 10:29:37 2012 From: jdom at tuis.net (Rolf Lear) Date: Mon, 09 Apr 2012 13:29:37 -0400 Subject: [jdom-interest] Removing Elements In-Reply-To: <20120409124756.17823@web006.roc2.bluetie.com> References: <20120409124756.17823@web006.roc2.bluetie.com> Message-ID: <292c09220d6fd60d4b8c6a1715890c23@tuis.net> Hi Brashiro. I think (at least I hope) you are mistaken. You should be able to remove an Element in a number of ways.... Assuming that you have a Element emt which is item 3 in the 'parent' ContentList, you should be able to do any one of: emt.detach(); parent.removeContent(emt); parent.getContent().remove(3); Rolf On Mon, 09 Apr 2012 12:47:56 -0400, "Bashiro" wrote: > Hello Folks! > First of all thanks to the jDom team for version 2.0! > Congrats to us all... > > My question is; I am trying to remove an element in jDom. It only removes > the element if > the element is located at [0]. Is there a good code or a good book to > help me with that ? > > Thanks > > Bashiro > Drammen-Norway > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From bashiro at myway.com Mon Apr 9 12:39:31 2012 From: bashiro at myway.com (Bashiro) Date: Mon, 09 Apr 2012 15:39:31 -0400 Subject: [jdom-interest] Removing Elements Message-ID: <20120409153931.2724@web007.roc2.bluetie.com> Thanks a lot for the reply. And thanks to both Rolf and Chris! I really appreciate this. What I am doing is; I am searching for an "ID" in "contacts" to delete. I have the following code-> List lists; Element next; lists = document.getRootElement().getChildren(); for (int i = 0; i < lists.size(); i++) { next = (Element) lists.get(i); if (next.getAttribute("contacts").getValue().equals(ID)) { next.getAttribute("name").getValue(); next.getAttribute("address").getValue(); next.getAttribute("tel").getValue(); next.getAttribute("mobile").getValue(); next.detach(); This only works when the ID in question is at [0]. I can view the contacts in a table too. If the contact is in a second row or a different row than first row it does not work. I even tried this; if (next.getAttribute("contacts").getValue().equals(ID)&&next.getAttribute("name").getValue().equals(name)) { do..... } Thanks for any help. Have a nice day! bashiro next.detach(); System.out.println("REMOVED LAST " + domainName + "\n"); Bashiro Drammen-Norway -----Original Message----- From: "Rolf Lear" [jdom at tuis.net] Date: 04/09/2012 19:36 To: "Bashiro" CC: jdom-interest at jdom.org Subject: Re: [jdom-interest] Removing Elements Hi Brashiro. I think (at least I hope) you are mistaken. You should be able to remove an Element in a number of ways.... Assuming that you have a Element emt which is item 3 in the 'parent' ContentList, you should be able to do any one of: emt.detach(); parent.removeContent(emt); parent.getContent().remove(3); Rolf On Mon, 09 Apr 2012 12:47:56 -0400, "Bashiro" wrote: > Hello Folks! > First of all thanks to the jDom team for version 2.0! > Congrats to us all... > > My question is; I am trying to remove an element in jDom. It only removes > the element if > the element is located at [0]. Is there a good code or a good book to > help me with that ? > > Thanks > > Bashiro > Drammen-Norway > > _______________________________________________ > To control your jdom-interest membership: > youraddr at yourhost.com">http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Mon Apr 9 14:34:22 2012 From: jdom at tuis.net (Rolf Lear) Date: Mon, 09 Apr 2012 17:34:22 -0400 Subject: [jdom-interest] Removing Elements In-Reply-To: <20120409153931.2724@web007.roc2.bluetie.com> References: <20120409153931.2724@web007.roc2.bluetie.com> Message-ID: <4F8355DE.7020905@tuis.net> Hi Bashiro. Chris is right, doing a remove() changes the size(), so you are skipping items.... Iteration is your friend, but there is no need to go backwards... are you using JDOM 2.0.0? Element root = document.getRootElement(); Iterator it = root.getChildren().iterator(); while (it.hasNext()) { Element emt = it.next(); if (ID.equals(emt.getAttributeValue("contacts"))) { it.remove(); } } Otherwise: Element root = document.getRootElement(); Iterator it = root.getChildren().iterator(); while (it.hasNext()) { Element emt = (Element)it.next(); if (ID.equals(emt.getAttributeValue("contacts"))) { it.remove(); } } Rolf On 09/04/2012 3:39 PM, Bashiro wrote: > Thanks a lot for the reply. And thanks to both Rolf and Chris! > I really appreciate this. > > What I am doing is; I am searching for an "ID" in "contacts" to delete. > I have the following code-> > > List lists; > Element next; > > lists = document.getRootElement().getChildren(); > for (int i = 0; i< lists.size(); i++) { > next = (Element) lists.get(i); > if (next.getAttribute("contacts").getValue().equals(ID)) { > next.getAttribute("name").getValue(); > next.getAttribute("address").getValue(); > next.getAttribute("tel").getValue(); > next.getAttribute("mobile").getValue(); > next.detach(); > > This only works when the ID in question is at [0]. I can view the contacts in a table too. > If the contact is in a second row or a different row than first row it does not work. > > I even tried this; > if (next.getAttribute("contacts").getValue().equals(ID)&&next.getAttribute("name").getValue().equals(name)) { > do..... > } > > Thanks for any help. > > Have a nice day! > > bashiro > next.detach(); > System.out.println("REMOVED LAST " + domainName + "\n"); > > Bashiro > Drammen-Norway > > -----Original Message----- > From: "Rolf Lear" [jdom at tuis.net] > Date: 04/09/2012 19:36 > To: "Bashiro" > CC: jdom-interest at jdom.org > Subject: Re: [jdom-interest] Removing Elements > > > Hi Brashiro. > > I think (at least I hope) you are mistaken. > > You should be able to remove an Element in a number of ways.... > > Assuming that you have a Element emt which is item 3 in the 'parent' > ContentList, you should be able to do any one of: > > emt.detach(); > parent.removeContent(emt); > parent.getContent().remove(3); > > Rolf > > > > > On Mon, 09 Apr 2012 12:47:56 -0400, "Bashiro" wrote: >> Hello Folks! >> First of all thanks to the jDom team for version 2.0! >> Congrats to us all... >> >> My question is; I am trying to remove an element in jDom. It only > removes >> the element if >> the element is located at [0]. Is there a good code or a good book to >> help me with that ? >> >> Thanks >> >> Bashiro >> Drammen-Norway >> >> _______________________________________________ >> To control your jdom-interest membership: >> youraddr at yourhost.com">http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > > From bashiro at myway.com Tue Apr 10 05:06:41 2012 From: bashiro at myway.com (Bashiro) Date: Tue, 10 Apr 2012 08:06:41 -0400 Subject: [jdom-interest] Removing Elements Message-ID: <20120410080641.17822@web008.roc2.bluetie.com> Thanks a lot. Everything works perfectly now. I will start using vers 2.0 today. Have a nice day.... Bashiro Drammen-Norway -----Original Message----- From: "Chris Pratt" [thechrispratt at gmail.com] Date: 04/10/2012 01:24 To: "Bashiro" CC: jdom at tuis.net, jdom-interest at jdom.org Subject: Re: [jdom-interest] Removing Elements You might try iterating backwards through the list. ?I would assume that removing a child might change the indexing of the rest of the children, if your start at lists.size() - 1 and work your way toward 0, then the rest of the indexes wont change.? (*Chris*) On Mon, Apr 9, 2012 at 12:39 PM, Bashiro wrote: Thanks a lot for the reply. And thanks to both Rolf and Chris! I really appreciate this. What I am doing is; I am searching for ?an "ID" in "contacts" to delete. I have the following code-> ?List lists; ?Element ?next; ?lists = document.getRootElement().getChildren(); ? ? ? ?for (int i = 0; i < lists.size(); i++) { ? ? ? ? ? ?next = (Element) lists.get(i); ? ? ? ? ? ?if (next.getAttribute("contacts").getValue().equals(ID)) { ? ? ? ? ? ? ? ? ? ?next.getAttribute("name").getValue(); ? ? ? ? ? ? ? ? ? ?next.getAttribute("address").getValue(); ? ? ? ? ? ? ? ? ? ?next.getAttribute("tel").getValue(); ? ? ? ? ? ? ? ? ? ?next.getAttribute("mobile").getValue(); ? ? ? ? ? ? ? ? ?next.detach(); This only works when the ID ?in question is at [0]. I can view the contacts in a table too. If the contact is in a second row or a different row than first row it does not work. I even tried this; ?if (next.getAttribute("contacts").getValue().equals(ID)&&next.getAttribute("name").getValue().equals(name)) { do..... } Thanks for any help. Have a nice day! bashiro ? ? ? ? ? ? ? ? ? ?next.detach(); ? ? ? ? ? ? ? ?System.out.println("REMOVED ?LAST " + domainName + "\n"); Bashiro Drammen-Norway -----Original Message----- From: "Rolf Lear" [jdom at tuis.net] Date: 04/09/2012 19:36 To: "Bashiro" CC: jdom-interest at jdom.org Subject: Re: [jdom-interest] Removing Elements Hi Brashiro. I think (at least I hope) you are mistaken. You should be able to remove an Element in a number of ways.... Assuming that you have a Element emt which is item 3 in the parent ContentList, you should be able to do any one of: emt.detach(); parent.removeContent(emt); parent.getContent().remove(3); Rolf On Mon, 09 Apr 2012 12:47:56 -0400, "Bashiro" wrote: > Hello Folks! > First of all thanks to the jDom team for version 2.0! > Congrats to us all... > > My question is; I am trying to remove an element in jDom. It only removes > the element if > the element is located at [0]. ?Is there a good code or a good book to > help me with that ? > > Thanks > > Bashiro > Drammen-Norway > > _______________________________________________ > To control your jdom-interest membership: > youraddr at yourhost.com">http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From lighton.phiri at gmail.com Wed Apr 11 02:40:08 2012 From: lighton.phiri at gmail.com (Lighton Phiri) Date: Wed, 11 Apr 2012 11:40:08 +0200 Subject: [jdom-interest] XMLOutputter(Format.getCompactFormat) Message-ID: Hello, I recently started playing around with JDOM (I am working with ) and was trying to test XMLOutputter. For some strange reason, when I attempt to write to an XML file using XMLOutputter(Format.getCompactFormat), the code below only writes the first sub-element of the root node. Substituting getCompactFormat with the other formats (getPrettyFormat and getRawFormat) results in desired output. Could there be something I might be missing? Input File ??? ??? ??? Aaa ??? ??? Bbb ??? ??? 20 ??? ??? ??? ??? Ccc ??? ??? Ddd ??? ??? 30 ??? ??? ??? ??? Eee ??? ??? Fff ??? ??? 40 ??? ??? ??? ??? Ggg ??? ??? Hhh ??? ??? 50 ??? Output Aaa Code import java.io.File; import java.io.FileWriter; import java.io.IOException; // jdom2 imports import org.jdom2.Document; import org.jdom2.JDOMException; import org.jdom2.input.SAXBuilder; import org.jdom2.output.Format; import org.jdom2.output.XMLOutputter; public class FirstRecipeJDOM { ??? public static void main(String[] args) { ??? ??? File XMLFile = new File("file.xml"); ??? ??? FileWriter JDOMRawOutputFile = null; ??? ??? SAXBuilder builder = new SAXBuilder(); ??? ??? try { ??? ??? ??? Document XMLDocument = builder.build(XMLFile); ??? ??? ??? XMLOutputter XMLOutput = new XMLOutputter(Format.getCompactFormat()); ??? ??? ??? XMLOutput.output(XMLDocument, System.out); ??? ??? ??? JDOMRawOutputFile = new FileWriter(new File("jdom_recipes.xml")); ??? ??? ??? XMLOutput.output(XMLDocument, JDOMRawOutputFile); ??? ??? } ??? ??? catch(IOException ioe) { ??? ??? ??? System.out.println(ioe.getMessage()); ??? ??? } ??? ??? catch(JDOMException jdome) { ??? ??? ??? System.out.println(jdome.getMessage()); ??? ??? } ??? } } -- Phiri From jdom at tuis.net Wed Apr 11 03:35:11 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 11 Apr 2012 06:35:11 -0400 Subject: [jdom-interest] XMLOutputter(Format.getCompactFormat) In-Reply-To: References: Message-ID: <4F855E5F.9010106@tuis.net> Hi Lighton. Hmmm.... it's a bug. So many things going through my head right now.... like how can that be? But, I am stepping through the code, and yes, it's a bug. I am (was) certain I had test cases that cover this condition.... but obviously I don't. I am working on it with 'top priority'. Rolf On 11/04/2012 5:40 AM, Lighton Phiri wrote: > import java.io.File; > import java.io.FileWriter; > import java.io.IOException; > > // jdom2 imports > import org.jdom2.Document; > import org.jdom2.JDOMException; > import org.jdom2.input.SAXBuilder; > import org.jdom2.output.Format; > import org.jdom2.output.XMLOutputter; > > public class FirstRecipeJDOM { > > public static void main(String[] args) { > File XMLFile = new File("file.xml"); > FileWriter JDOMRawOutputFile = null; > SAXBuilder builder = new SAXBuilder(); > > try { > Document XMLDocument = builder.build(XMLFile); > XMLOutputter XMLOutput = new > XMLOutputter(Format.getCompactFormat()); > XMLOutput.output(XMLDocument, System.out); > > JDOMRawOutputFile = new FileWriter(new File("jdom_recipes.xml")); > XMLOutput.output(XMLDocument, JDOMRawOutputFile); > } > catch(IOException ioe) { > System.out.println(ioe.getMessage()); > } > catch(JDOMException jdome) { > System.out.println(jdome.getMessage()); > } > } > } From lighton.phiri at gmail.com Wed Apr 11 03:38:52 2012 From: lighton.phiri at gmail.com (Lighton Phiri) Date: Wed, 11 Apr 2012 12:38:52 +0200 Subject: [jdom-interest] XMLOutputter(Format.getCompactFormat) In-Reply-To: <4F855E5F.9010106@tuis.net> References: <4F855E5F.9010106@tuis.net> Message-ID: Hello Rolf, Noted. Thank you very much. --Phiri On 11 April 2012 12:35, Rolf Lear wrote: > Hi Lighton. > > Hmmm.... it's a bug. So many things going through my head right now.... like > how can that be? > > But, I am stepping through the code, and yes, it's a bug. > > I am (was) certain I had test cases that cover this condition.... but > obviously I don't. > > I am working on it with 'top priority'. > > Rolf > > > On 11/04/2012 5:40 AM, Lighton Phiri wrote: >> >> import java.io.File; >> import java.io.FileWriter; >> import java.io.IOException; >> >> // jdom2 imports >> import org.jdom2.Document; >> import org.jdom2.JDOMException; >> import org.jdom2.input.SAXBuilder; >> import org.jdom2.output.Format; >> import org.jdom2.output.XMLOutputter; >> >> public class FirstRecipeJDOM { >> >> ? ? public static void main(String[] args) { >> ? ? ? ? File XMLFile = new File("file.xml"); >> ? ? ? ? FileWriter JDOMRawOutputFile = null; >> ? ? ? ? SAXBuilder builder = new SAXBuilder(); >> >> ? ? ? ? try { >> ? ? ? ? ? ? Document XMLDocument = builder.build(XMLFile); >> ? ? ? ? ? ? XMLOutputter XMLOutput = new >> XMLOutputter(Format.getCompactFormat()); >> ? ? ? ? ? ? XMLOutput.output(XMLDocument, System.out); >> >> ? ? ? ? ? ? JDOMRawOutputFile = new FileWriter(new >> File("jdom_recipes.xml")); >> ? ? ? ? ? ? XMLOutput.output(XMLDocument, JDOMRawOutputFile); >> ? ? ? ? } >> ? ? ? ? catch(IOException ioe) { >> ? ? ? ? ? ? System.out.println(ioe.getMessage()); >> ? ? ? ? } >> ? ? ? ? catch(JDOMException jdome) { >> ? ? ? ? ? ? System.out.println(jdome.getMessage()); >> ? ? ? ? } >> ? ? } >> } > > From jdom at tuis.net Wed Apr 11 04:15:33 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 11 Apr 2012 07:15:33 -0400 Subject: [jdom-interest] XMLOutputter(Format.getCompactFormat) In-Reply-To: References: <4F855E5F.9010106@tuis.net> Message-ID: <4F8567D5.6080908@tuis.net> Hi Phiri. I found (and fixed) the issue. Also added a test case for it. Now the question is how to deal with it.... For the moment I have uploaded a 'hotfix' to github: https://github.com/downloads/hunterhacker/jdom/jdom-2.x-issue72.zip I have to think about this some more though. This happens to be a 'big' bug, but should I wait a few days.... or should I push it out in a rush? Rolf On 11/04/2012 6:38 AM, Lighton Phiri wrote: > Hello Rolf, > > Noted. Thank you very much. > > --Phiri > > > > On 11 April 2012 12:35, Rolf Lear wrote: >> Hi Lighton. >> >> Hmmm.... it's a bug. So many things going through my head right now.... like >> how can that be? >> >> But, I am stepping through the code, and yes, it's a bug. >> >> I am (was) certain I had test cases that cover this condition.... but >> obviously I don't. >> >> I am working on it with 'top priority'. >> >> Rolf >> >> >> On 11/04/2012 5:40 AM, Lighton Phiri wrote: >>> >>> import java.io.File; >>> import java.io.FileWriter; >>> import java.io.IOException; >>> >>> // jdom2 imports >>> import org.jdom2.Document; >>> import org.jdom2.JDOMException; >>> import org.jdom2.input.SAXBuilder; >>> import org.jdom2.output.Format; >>> import org.jdom2.output.XMLOutputter; >>> >>> public class FirstRecipeJDOM { >>> >>> public static void main(String[] args) { >>> File XMLFile = new File("file.xml"); >>> FileWriter JDOMRawOutputFile = null; >>> SAXBuilder builder = new SAXBuilder(); >>> >>> try { >>> Document XMLDocument = builder.build(XMLFile); >>> XMLOutputter XMLOutput = new >>> XMLOutputter(Format.getCompactFormat()); >>> XMLOutput.output(XMLDocument, System.out); >>> >>> JDOMRawOutputFile = new FileWriter(new >>> File("jdom_recipes.xml")); >>> XMLOutput.output(XMLDocument, JDOMRawOutputFile); >>> } >>> catch(IOException ioe) { >>> System.out.println(ioe.getMessage()); >>> } >>> catch(JDOMException jdome) { >>> System.out.println(jdome.getMessage()); >>> } >>> } >>> } >> >> > From lighton.phiri at gmail.com Wed Apr 11 04:25:49 2012 From: lighton.phiri at gmail.com (Lighton Phiri) Date: Wed, 11 Apr 2012 13:25:49 +0200 Subject: [jdom-interest] XMLOutputter(Format.getCompactFormat) In-Reply-To: <4F8567D5.6080908@tuis.net> References: <4F855E5F.9010106@tuis.net> <4F8567D5.6080908@tuis.net> Message-ID: Hello, Thanks a lot for the hotfix. --Phiri On 11 April 2012 13:15, Rolf Lear wrote: > Hi Phiri. > > I found (and fixed) the issue. Also added a test case for it. > > Now the question is how to deal with it.... > > For the moment I have uploaded a 'hotfix' to github: > https://github.com/downloads/hunterhacker/jdom/jdom-2.x-issue72.zip > > I have to think about this some more though. This happens to be a 'big' bug, > but should I wait a few days.... or should I push it out in a rush? > > Rolf > > > On 11/04/2012 6:38 AM, Lighton Phiri wrote: >> >> Hello Rolf, >> >> Noted. Thank you very much. >> >> --Phiri >> >> >> >> On 11 April 2012 12:35, Rolf Lear ?wrote: >>> >>> Hi Lighton. >>> >>> Hmmm.... it's a bug. So many things going through my head right now.... >>> like >>> how can that be? >>> >>> But, I am stepping through the code, and yes, it's a bug. >>> >>> I am (was) certain I had test cases that cover this condition.... but >>> obviously I don't. >>> >>> I am working on it with 'top priority'. >>> >>> Rolf >>> >>> >>> On 11/04/2012 5:40 AM, Lighton Phiri wrote: >>>> >>>> >>>> import java.io.File; >>>> import java.io.FileWriter; >>>> import java.io.IOException; >>>> >>>> // jdom2 imports >>>> import org.jdom2.Document; >>>> import org.jdom2.JDOMException; >>>> import org.jdom2.input.SAXBuilder; >>>> import org.jdom2.output.Format; >>>> import org.jdom2.output.XMLOutputter; >>>> >>>> public class FirstRecipeJDOM { >>>> >>>> ? ? public static void main(String[] args) { >>>> ? ? ? ? File XMLFile = new File("file.xml"); >>>> ? ? ? ? FileWriter JDOMRawOutputFile = null; >>>> ? ? ? ? SAXBuilder builder = new SAXBuilder(); >>>> >>>> ? ? ? ? try { >>>> ? ? ? ? ? ? Document XMLDocument = builder.build(XMLFile); >>>> ? ? ? ? ? ? XMLOutputter XMLOutput = new >>>> XMLOutputter(Format.getCompactFormat()); >>>> ? ? ? ? ? ? XMLOutput.output(XMLDocument, System.out); >>>> >>>> ? ? ? ? ? ? JDOMRawOutputFile = new FileWriter(new >>>> File("jdom_recipes.xml")); >>>> ? ? ? ? ? ? XMLOutput.output(XMLDocument, JDOMRawOutputFile); >>>> ? ? ? ? } >>>> ? ? ? ? catch(IOException ioe) { >>>> ? ? ? ? ? ? System.out.println(ioe.getMessage()); >>>> ? ? ? ? } >>>> ? ? ? ? catch(JDOMException jdome) { >>>> ? ? ? ? ? ? System.out.println(jdome.getMessage()); >>>> ? ? ? ? } >>>> ? ? } >>>> } >>> >>> >>> >> > From jdom at tuis.net Wed Apr 11 04:39:52 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 11 Apr 2012 07:39:52 -0400 Subject: [jdom-interest] XMLOutputter(Format.getCompactFormat) In-Reply-To: References: <4F855E5F.9010106@tuis.net> <4F8567D5.6080908@tuis.net> Message-ID: <4F856D88.50902@tuis.net> You're welcome... and thanks for the comprehensive 'issue' that you put together with the whole test-case. It helps a lot. Rolf On 11/04/2012 7:25 AM, Lighton Phiri wrote: > Hello, > > Thanks a lot for the hotfix. > > --Phiri > > > On 11 April 2012 13:15, Rolf Lear wrote: >> Hi Phiri. >> >> I found (and fixed) the issue. Also added a test case for it. >> >> Now the question is how to deal with it.... >> >> For the moment I have uploaded a 'hotfix' to github: >> https://github.com/downloads/hunterhacker/jdom/jdom-2.x-issue72.zip >> >> I have to think about this some more though. This happens to be a 'big' bug, >> but should I wait a few days.... or should I push it out in a rush? >> >> Rolf >> >> >> On 11/04/2012 6:38 AM, Lighton Phiri wrote: >>> Hello Rolf, >>> >>> Noted. Thank you very much. >>> >>> --Phiri >>> >>> >>> >>> On 11 April 2012 12:35, Rolf Lear wrote: >>>> Hi Lighton. >>>> >>>> Hmmm.... it's a bug. So many things going through my head right now.... >>>> like >>>> how can that be? >>>> >>>> But, I am stepping through the code, and yes, it's a bug. >>>> >>>> I am (was) certain I had test cases that cover this condition.... but >>>> obviously I don't. >>>> >>>> I am working on it with 'top priority'. >>>> >>>> Rolf >>>> >>>> >>>> On 11/04/2012 5:40 AM, Lighton Phiri wrote: >>>>> >>>>> import java.io.File; >>>>> import java.io.FileWriter; >>>>> import java.io.IOException; >>>>> >>>>> // jdom2 imports >>>>> import org.jdom2.Document; >>>>> import org.jdom2.JDOMException; >>>>> import org.jdom2.input.SAXBuilder; >>>>> import org.jdom2.output.Format; >>>>> import org.jdom2.output.XMLOutputter; >>>>> >>>>> public class FirstRecipeJDOM { >>>>> >>>>> public static void main(String[] args) { >>>>> File XMLFile = new File("file.xml"); >>>>> FileWriter JDOMRawOutputFile = null; >>>>> SAXBuilder builder = new SAXBuilder(); >>>>> >>>>> try { >>>>> Document XMLDocument = builder.build(XMLFile); >>>>> XMLOutputter XMLOutput = new >>>>> XMLOutputter(Format.getCompactFormat()); >>>>> XMLOutput.output(XMLDocument, System.out); >>>>> >>>>> JDOMRawOutputFile = new FileWriter(new >>>>> File("jdom_recipes.xml")); >>>>> XMLOutput.output(XMLDocument, JDOMRawOutputFile); >>>>> } >>>>> catch(IOException ioe) { >>>>> System.out.println(ioe.getMessage()); >>>>> } >>>>> catch(JDOMException jdome) { >>>>> System.out.println(jdome.getMessage()); >>>>> } >>>>> } >>>>> } >>>> >>>> From lighton.phiri at gmail.com Thu Apr 12 04:13:38 2012 From: lighton.phiri at gmail.com (Lighton Phiri) Date: Thu, 12 Apr 2012 13:13:38 +0200 Subject: [jdom-interest] Using namespace prefixes for sub-elements Message-ID: Hello, I've been going through the JavaDoc documentation and cannot seem to find anything that will help me create a document with fully qualified namespaces defined in the root element. I do not want to have to explicitly define the fully qualified namespace for each subsequent subelement that I define, but rather just use the namespace prefixes. Code // namespaces Namespace dc = Namespace.getNamespace("dc", "http://purl.org/dc/elements/1.1/"); Namespace dcterms = Namespace.getNamespace("dcterms", "http://purl.org/dc/dcterms/"); // title element Element dcTitle = new Element("title", dc); dcTitle.addContent("Notebooks"); // hasPart element Element dctermsHasPart = new Element("hasPart", dcterms); dctermsHasPart.addContent("BC_151_A1_4_001"); Element dctermsHasPart2 = new Element("hasPart", dcterms); dctermsHasPart2.addContent("BC_151_A1_4_002"); // root element Element rootNodeElement = new Element("resource"); rootNodeElement.addContent(dcTitle); rootNodeElement.addContent(dctermsHasPart); rootNodeElement.addContent(dctermsHasPart2); Output Notebooks A1_4_001 A1_4_002 Desired output Notebooks A1_4_001 A1_4_002 -- Phiri From lighton.phiri at gmail.com Thu Apr 12 04:57:45 2012 From: lighton.phiri at gmail.com (Lighton Phiri) Date: Thu, 12 Apr 2012 13:57:45 +0200 Subject: [jdom-interest] [SOLVED] Re: Using namespace prefixes for sub-elements In-Reply-To: References: Message-ID: Hello, Spoke too soon --using the 'addNamespaceDeclaration(Namespace arg0)' method to the root element does exactly what I want. // root element Element rootNodeElement = new Element("resource"); rootNodeElement.addNamespaceDeclaration(dc); rootNodeElement.addNamespaceDeclaration(dcterms); rootNodeElement.addContent(dcTitle); rootNodeElement.addContent(dctermsHasPart); rootNodeElement.addContent(dctermsHasPart2); -- Phiri On 12 April 2012 13:13, Lighton Phiri wrote: > Hello, > > I've been going through the JavaDoc documentation and cannot seem to > find anything that will help me create a document with fully qualified > namespaces defined in the root element. I do not want to have to > explicitly define the fully qualified namespace for each subsequent > subelement that I define, but rather just use the namespace prefixes. > > Code > > // namespaces > Namespace dc = Namespace.getNamespace("dc", "http://purl.org/dc/elements/1.1/"); > Namespace dcterms = Namespace.getNamespace("dcterms", > "http://purl.org/dc/dcterms/"); > > // title element > Element dcTitle = new Element("title", dc); > dcTitle.addContent("Notebooks"); > > // hasPart element > Element dctermsHasPart = new Element("hasPart", dcterms); > dctermsHasPart.addContent("BC_151_A1_4_001"); > Element dctermsHasPart2 = new Element("hasPart", dcterms); > dctermsHasPart2.addContent("BC_151_A1_4_002"); > > // root element > Element rootNodeElement = new Element("resource"); > rootNodeElement.addContent(dcTitle); > rootNodeElement.addContent(dctermsHasPart); > rootNodeElement.addContent(dctermsHasPart2); > > Output > > > > ?Notebooks > ? xmlns:dcterms="http://purl.org/dc/dcterms/">A1_4_001 > ? xmlns:dcterms="http://purl.org/dc/dcterms/">A1_4_002 > > > Desired output > > > xmlns:dcterms="http://purl.org/dc/dcterms/"> > ?Notebooks > ?A1_4_001 > ?A1_4_002 > > > > -- Phiri From jdom at tuis.net Thu Apr 12 05:10:48 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 12 Apr 2012 08:10:48 -0400 Subject: [jdom-interest] Using namespace prefixes for sub-elements In-Reply-To: References: Message-ID: <6ae0faa2a6b5f9f3c145d0f61c9a74b5@tuis.net> Hi Phiri. 'declare' the namespaces at the root level: http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/Element.html#addNamespaceDeclaration(org.jdom2.Namespace) rootNodeElement.addNamespaceDeclaration(dc); rootNodeElement.addNamespaceDeclaration(dcterms); Rolf On Thu, 12 Apr 2012 13:13:38 +0200, Lighton Phiri wrote: > Hello, > > I've been going through the JavaDoc documentation and cannot seem to > find anything that will help me create a document with fully qualified > namespaces defined in the root element. I do not want to have to > explicitly define the fully qualified namespace for each subsequent > subelement that I define, but rather just use the namespace prefixes. > > Code > > // namespaces > Namespace dc = Namespace.getNamespace("dc", > "http://purl.org/dc/elements/1.1/"); > Namespace dcterms = Namespace.getNamespace("dcterms", > "http://purl.org/dc/dcterms/"); > > // title element > Element dcTitle = new Element("title", dc); > dcTitle.addContent("Notebooks"); > > // hasPart element > Element dctermsHasPart = new Element("hasPart", dcterms); > dctermsHasPart.addContent("BC_151_A1_4_001"); > Element dctermsHasPart2 = new Element("hasPart", dcterms); > dctermsHasPart2.addContent("BC_151_A1_4_002"); > > // root element > Element rootNodeElement = new Element("resource"); > rootNodeElement.addContent(dcTitle); > rootNodeElement.addContent(dctermsHasPart); > rootNodeElement.addContent(dctermsHasPart2); > > Output > > > > xmlns:dc="http://purl.org/dc/elements/1.1/">Notebooks > xmlns:dcterms="http://purl.org/dc/dcterms/">A1_4_001 > xmlns:dcterms="http://purl.org/dc/dcterms/">A1_4_002 > > > Desired output > > > xmlns:dcterms="http://purl.org/dc/dcterms/"> > Notebooks > A1_4_001 > A1_4_002 > > > > -- Phiri > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From lighton.phiri at gmail.com Thu Apr 12 05:29:31 2012 From: lighton.phiri at gmail.com (Lighton Phiri) Date: Thu, 12 Apr 2012 14:29:31 +0200 Subject: [jdom-interest] Using namespace prefixes for sub-elements In-Reply-To: <6ae0faa2a6b5f9f3c145d0f61c9a74b5@tuis.net> References: <6ae0faa2a6b5f9f3c145d0f61c9a74b5@tuis.net> Message-ID: <4F86CAAB.4040400@gmail.com> Hello Rolf, Thank you very much. Lighton Phiri http://lightonphiri.org http://en.gravatar.com/lightonphiri Twitter: @lightonphiri On 12/04/2012 14:10, Rolf Lear wrote: > Hi Phiri. > > 'declare' the namespaces at the root level: > > http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/Element.html#addNamespaceDeclaration(org.jdom2.Namespace) > > rootNodeElement.addNamespaceDeclaration(dc); > rootNodeElement.addNamespaceDeclaration(dcterms); > > > Rolf > > > On Thu, 12 Apr 2012 13:13:38 +0200, Lighton Phiri > > wrote: >> Hello, >> >> I've been going through the JavaDoc documentation and cannot seem to >> find anything that will help me create a document with fully qualified >> namespaces defined in the root element. I do not want to have to >> explicitly define the fully qualified namespace for each subsequent >> subelement that I define, but rather just use the namespace prefixes. >> >> Code >> >> // namespaces >> Namespace dc = Namespace.getNamespace("dc", >> "http://purl.org/dc/elements/1.1/"); >> Namespace dcterms = Namespace.getNamespace("dcterms", >> "http://purl.org/dc/dcterms/"); >> >> // title element >> Element dcTitle = new Element("title", dc); >> dcTitle.addContent("Notebooks"); >> >> // hasPart element >> Element dctermsHasPart = new Element("hasPart", dcterms); >> dctermsHasPart.addContent("BC_151_A1_4_001"); >> Element dctermsHasPart2 = new Element("hasPart", dcterms); >> dctermsHasPart2.addContent("BC_151_A1_4_002"); >> >> // root element >> Element rootNodeElement = new Element("resource"); >> rootNodeElement.addContent(dcTitle); >> rootNodeElement.addContent(dctermsHasPart); >> rootNodeElement.addContent(dctermsHasPart2); >> >> Output >> >> >> >> > xmlns:dc="http://purl.org/dc/elements/1.1/">Notebooks >> > xmlns:dcterms="http://purl.org/dc/dcterms/">A1_4_001 >> > xmlns:dcterms="http://purl.org/dc/dcterms/">A1_4_002 >> >> >> Desired output >> >> >> > xmlns:dcterms="http://purl.org/dc/dcterms/"> >> Notebooks >> A1_4_001 >> A1_4_002 >> >> >> >> -- Phiri >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Thu Apr 12 11:21:00 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 12 Apr 2012 14:21:00 -0400 Subject: [jdom-interest] 2.0.0 usage Message-ID: Hi all. I know it is soon, but I am trying to budget time and resources for 2.0.1. Already there is a bug identified in 2.0.0, and it needs to be resolved.... but, how long should I wait to see if there are other bugs? Thus I would like as much feedback as possible whether you are using JDOM 2.x or not. Think of it as a 'poll', and all I need (for now) are simple things like: - Yes, using it, no problems - Yes, using it, some problems, but will keep going. - Tried it, had problems, gave up. - Going to try it when there's time. - Going to try it when it is more 'stable'. - I would try it if it had feature XYZ. - Not planning on trying it - happy with JDOM 1.x If you feel like creating your own answer, or expanding on your reply, or anything, please do. Thanks Rolf From jdom at tuis.net Thu Apr 12 11:30:10 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 12 Apr 2012 14:30:10 -0400 Subject: [jdom-interest] Volunteers Wanted.... Message-ID: <584fd7b53ff9c5e8c0edc32672d21497@tuis.net> Hi all I have been trying to 'analyze' how issue #72 slipped through, and I have decided it stems from 4 factors: 1. not many people use 'compact' format output 2. When I wrote the JUnit tests I was focussed on the fine details, and the multiple-component circumstances that cause the failure are not tested in a 'compact' form 3. When I do process data at a 'high level' with complext XML content with multi-type child content, I am not using the compact format, but more typically the 'raw' format. 4. Programmers are not good at testing their own code. As a result of the above, I am looking for some volunteers to spend a few hours and really try to get a 'grip' on JDOM2, to plug it in to their existing systems, and to provide as much feedback as they can. Everything down to typo's in the comments! Oh, by the way, paulk-asert, if you're on the list, thanks for reviewing the wiki pages ;-) If I could get a few people to give some objective feedback it would make a big difference for how much confidence we could put on a JDOM 2.0.1 release.... Thanks Rolf From jdom at tuis.net Thu Apr 12 11:46:14 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 12 Apr 2012 14:46:14 -0400 Subject: [jdom-interest] JDOM 2.x additional features Message-ID: <09463111c9de50bfbdd514921bec8f00@tuis.net> Hi again everyone. I am scheduling some additional features to put in the 'roadmap' for JDOM. I am already working on some, but I want to get some feedback and suggestions too. 'On the side' I have started the 'Resolver' project. This is hosted on github: https://github.com/rolfl/Resolver This project comes directly from the JDOM work because I did much of my JDOM work on the train, without an internet connection, and I needed to 'resolve' XSD and other resources from the web. If the Resolver project gets some interest, I am sure it would make some sense to at least consider moving it in to JDOM. I have been playing with a new Android tablet, and messing with the Android dev kit. I think it would be useful to come up with at minimum a 'statement' indicating Android support. If JDOM operates on Android it would be good to indicate what works, what's needed to make it work, what does not work, etc. Something similar to the Java5 page for JDOM: https://github.com/hunterhacker/jdom/wiki/JDOM2-Using-Java5 Other items that I am not yet working on are: XPath 2.0 support Saxon 'native' integration - integrate with Saxon at a lower level and perhaps make it possible (by just including a saxon jar) to use Saxon for both XSLT and XPath. OSGi - investigate it, and find out whether JDOM could be a part of that model. Finally, there are a whole bunch of things I am not aware of that should be happening.... What should JDOM 2.x be doing for you? Rolf From mike at saxonica.com Thu Apr 12 12:24:22 2012 From: mike at saxonica.com (Michael Kay) Date: Thu, 12 Apr 2012 20:24:22 +0100 Subject: [jdom-interest] 2.0.0 usage In-Reply-To: References: Message-ID: <4F872BE6.2080008@saxonica.com> We were going to include JDOM 2.0 support in Saxon 9.4, tested it and it was fine, but then we realised the API wasn't stable enough and pulled it before release. It will no doubt go back in for 9.5. Having said that, we don't actually "use" JDOM, except to run tests. Michael Kay Saxonica On 12/04/2012 19:21, Rolf Lear wrote: > Hi all. > > I know it is soon, but I am trying to budget time and resources for 2.0.1. > > Already there is a bug identified in 2.0.0, and it needs to be > resolved.... but, how long should I wait to see if there are other bugs? > > Thus I would like as much feedback as possible whether you are using JDOM > 2.x or not. Think of it as a 'poll', and all I need (for now) are simple > things like: > - Yes, using it, no problems > - Yes, using it, some problems, but will keep going. > - Tried it, had problems, gave up. > - Going to try it when there's time. > - Going to try it when it is more 'stable'. > - I would try it if it had feature XYZ. > - Not planning on trying it - happy with JDOM 1.x > > If you feel like creating your own answer, or expanding on your reply, or > anything, please do. > > Thanks > > Rolf > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From noel at peralex.com Fri Apr 13 00:24:52 2012 From: noel at peralex.com (Noel Grandin) Date: Fri, 13 Apr 2012 09:24:52 +0200 Subject: [jdom-interest] JDOM 2.x additional features In-Reply-To: <09463111c9de50bfbdd514921bec8f00@tuis.net> References: <09463111c9de50bfbdd514921bec8f00@tuis.net> Message-ID: <4F87D4C4.2090506@peralex.com> OOOh, I'd love a nice resolver solution. I live in sunny South Africa, with lovely beaches, and incredibly high latency internet connections, so reducing resolver calls helps a lot :-) On 2012-04-12 20:46, Rolf Lear wrote: > 'On the side' I have started the 'Resolver' project. This is hosted on > github: https://github.com/rolfl/Resolver This project comes directly from > the JDOM work because I did much of my JDOM work on the train, without an > internet connection, and I needed to 'resolve' XSD and other resources from > the web. If the Resolver project gets some interest, I am sure it would > make some sense to at least consider moving it in to JDOM. > Disclaimer: http://www.peralex.com/disclaimer.html From olivier.jaquemet at jalios.com Fri Apr 13 01:03:10 2012 From: olivier.jaquemet at jalios.com (Olivier Jaquemet) Date: Fri, 13 Apr 2012 10:03:10 +0200 Subject: [jdom-interest] 2.0.0 usage In-Reply-To: References: Message-ID: <4F87DDBE.9010209@jalios.com> Hi Rolf, Regarding usage, 2 custom answers for me : - Tried it when it was in beta, had no apparent problems (which indicates we have a "basic usage" of the library). - Going to try it *more* when there's time. Regarding next release date : I am shared between "release often" and "release when there is a major bug or enough small bug discovered". What we usually do for our software is provide more frequent release in the beginning of a new major version, even if the bug is not really major or critical, and then slow down. It marks our implication in the new release and I think it gives more confidence to the user that we provide rapid fixes (though the opposite could be said as user might perceive this frequent release as a proof of buggy release...) Olivier On 12/04/2012 20:21, Rolf Lear wrote: > Hi all. > > I know it is soon, but I am trying to budget time and resources for 2.0.1. > > Already there is a bug identified in 2.0.0, and it needs to be > resolved.... but, how long should I wait to see if there are other bugs? > > Thus I would like as much feedback as possible whether you are using JDOM > 2.x or not. Think of it as a 'poll', and all I need (for now) are simple > things like: > - Yes, using it, no problems > - Yes, using it, some problems, but will keep going. > - Tried it, had problems, gave up. > - Going to try it when there's time. > - Going to try it when it is more 'stable'. > - I would try it if it had feature XYZ. > - Not planning on trying it - happy with JDOM 1.x > > If you feel like creating your own answer, or expanding on your reply, or > anything, please do. > > Thanks > > Rolf > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > -- Olivier Jaquemet Ing?nieur R&D Jalios S.A. - http://www.jalios.com/ @OlivierJaquemet +33970461480 From lighton.phiri at gmail.com Fri Apr 13 01:22:19 2012 From: lighton.phiri at gmail.com (Lighton Phiri) Date: Fri, 13 Apr 2012 10:22:19 +0200 Subject: [jdom-interest] Element comparison in XML document Message-ID: Is there an easier way of checking if an element exists in an XML file? I tried to use the List function 'contains' to do my comparison, but it seems to fail; checked the Element class for appropriate methods, but nothing there. The closest I came to finding something similar on markmail.org is an old article [1] that isn't quite helpful. The only workaround I can think of at the moment is a recursive walk-through to check the textual content of each element, but something tells me there has to be a built-in mechanism for doing this. Code snippet Element hasPartNode = new Element("hasPart", Namespace.getNamespace("dcterms", "http://purl.org/dc/terms/")); hasPartNode.addContent("A1_4_001"); // This prints false System.out.println(rootNode.getChildren("hasPart", Namespace.getNamespace("dcterms", "http://purl.org/dc/terms/")).contains(hasPartNode)); Input XML document Notebooks A1_4_001 A1_4_002 A1_4_003 [1] http://markmail.org/message/s7le3js7r5vub7oy -- Phiri From grzegorz.kaczor at gmail.com Fri Apr 13 02:02:39 2012 From: grzegorz.kaczor at gmail.com (Grzegorz) Date: Fri, 13 Apr 2012 11:02:39 +0200 Subject: [jdom-interest] 2.0.0 usage In-Reply-To: <4F87DDBE.9010209@jalios.com> References: <4F87DDBE.9010209@jalios.com> Message-ID: Started to use it, no problems yet. I would not be very hasty in releasing the first bug fix to a brand-new major version. It would suggest that it is already well tested. Staying at 2.0.0 suggests correctly - it is new, try it, but be sure something will not work optimal. Regards, GK 2012/4/13, Olivier Jaquemet : > Hi Rolf, > > Regarding usage, 2 custom answers for me : > - Tried it when it was in beta, had no apparent problems (which > indicates we have a "basic usage" of the library). > - Going to try it *more* when there's time. > > Regarding next release date : > I am shared between "release often" and "release when there is a major > bug or enough small bug discovered". > What we usually do for our software is provide more frequent release in > the beginning of a new major version, even if the bug is not really > major or critical, and then slow down. It marks our implication in the > new release and I think it gives more confidence to the user that we > provide rapid fixes (though the opposite could be said as user might > perceive this frequent release as a proof of buggy release...) > > Olivier > > On 12/04/2012 20:21, Rolf Lear wrote: >> Hi all. >> >> I know it is soon, but I am trying to budget time and resources for 2.0.1. >> >> Already there is a bug identified in 2.0.0, and it needs to be >> resolved.... but, how long should I wait to see if there are other bugs? >> >> Thus I would like as much feedback as possible whether you are using JDOM >> 2.x or not. Think of it as a 'poll', and all I need (for now) are simple >> things like: >> - Yes, using it, no problems >> - Yes, using it, some problems, but will keep going. >> - Tried it, had problems, gave up. >> - Going to try it when there's time. >> - Going to try it when it is more 'stable'. >> - I would try it if it had feature XYZ. >> - Not planning on trying it - happy with JDOM 1.x >> >> If you feel like creating your own answer, or expanding on your reply, or >> anything, please do. >> >> Thanks >> >> Rolf >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > > -- > Olivier Jaquemet > Ing?nieur R&D Jalios S.A. - http://www.jalios.com/ > @OlivierJaquemet +33970461480 > > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From jdom at tuis.net Fri Apr 13 03:52:31 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 13 Apr 2012 06:52:31 -0400 Subject: [jdom-interest] 2.0.0 usage In-Reply-To: <4F872BE6.2080008@saxonica.com> References: <4F872BE6.2080008@saxonica.com> Message-ID: <4F88056F.3040305@tuis.net> Hi Michael I understand the concerns you had with the API stability. Out of interest though, when I was working with Jaxen, it became apparent that the 'model' of putting JDOM support directly in to Jaxen is 'broken', it should be (and now is) the other way around. JDOM 2.x now 'owns' the interface to Jaxen, it 'Owns' the implementation of the Jaxen 'Navigator'. This solves a number of problems, not the least of which is that the compile-time dependencies are circular otherwise... Is there not some way you can help build the 'glue' logic in to JDOM rather than in to Saxon? I started trying to do that a few months ago, but got my head all messed up in the API, and NodeInfo classes, etc. From a JDOM perspective it does not make much sense to be embedded inside Saxon, but it makes sense to have Saxon available as an XPath 'engine' using the JDOM XPath API. I know that from a Saxon perspective there are different objectives.... Anyway, I am going to (at some point soon-ish) work on putting together a Soxon-based implementation of JDOM XPath API, and it would be great if I could work from some existing base, rather than reinvent it all... Rolf On 12/04/2012 3:24 PM, Michael Kay wrote: > We were going to include JDOM 2.0 support in Saxon 9.4, tested it and it > was fine, but then we realised the API wasn't stable enough and pulled > it before release. It will no doubt go back in for 9.5. > > Having said that, we don't actually "use" JDOM, except to run tests. > > Michael Kay > Saxonica > From jdom at tuis.net Fri Apr 13 07:47:20 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 13 Apr 2012 10:47:20 -0400 Subject: [jdom-interest] JDOM 2.x additional features In-Reply-To: References: <09463111c9de50bfbdd514921bec8f00@tuis.net> <4F87D4C4.2090506@peralex.com> Message-ID: <4F883C78.9080903@tuis.net> Currently the resolver is just a 'simple' file system cache, with some 'smart' logic in Java to allow that cache to be accessed concurrently by multiple threads, and multiple JVM's. It uses File-locking to accomplish this. The 'specification' for the cache file structure is 'easy'. There is no reason why you can't zip up the cache, move it, add to it, etc. Note that the Resolver project I have proposed fills a gap between two different existing concepts: the current 'get it when I need it' Resolver we normally use; and the existing concept of a web catalog, which is a static pre-loaded, unmodifiable. If all you want to do is pre-cache existing, known DTD's and Schemas you may want to just use existing web-catalog concepts. Have a look at the 'motivation' page for 'my' ideas of why a different Resolver is needed: https://github.com/rolfl/Resolver/wiki/Motivation-and-Requirements Currently the resolver technically works. I have tested it 'extensively' in a multi-threaded and multi-JVM test suite. Now that JDOM 2.0.0 is out, I can put some more thought in to how best to 'package' the Resolver. It technically does not even need to be a part of JDOM... But, I do think JDOM would be better if it provided an easy way to integrate multiple resolvers for XML Parsing... giving it the ability to 'use a web catalog for *this*', 'use a direct web access for *that*', and 'use the cache for *that*'. In the long run I think it would be really nice if you could do something like: JDOMResolver myres = new JDOMResolver(); myres.addChainedResolver(new WebCatalog("path/to/catalog")); myres.addChainedResolver(new WebCatalog("path/to/some/other/catalog")); myres.addChainedResolver(new FilteredResolver("my.local.host.com")); myres.addChainedResolver(new CachingResolver()); SAXBuilder sb = new SaxBuilder(); sb.setEntityResolver(myres); But, that is a change for a later version of JDOM... It will need some more input (maybe from people like you ... ;-) Rolf On 13/04/2012 10:30 AM, Chris Pratt wrote: > Does the resolver have the ability to preload DTDs/Schemas? I know there > have been several times it would have been nice to be able to pre-cache > documents I know I'm going to need, rather than waiting until the first > request. > (*Chris*) > > On Apr 13, 2012 12:40 AM, "Noel Grandin" > wrote: > > OOOh, I'd love a nice resolver solution. > I live in sunny South Africa, with lovely beaches, and incredibly > high latency internet connections, so reducing resolver calls helps > a lot :-) > > On 2012-04-12 20:46, Rolf Lear wrote: > > 'On the side' I have started the 'Resolver' project. This is > hosted on > github: https://github.com/rolfl/__Resolver > This project comes directly from > the JDOM work because I did much of my JDOM work on the train, > without an > internet connection, and I needed to 'resolve' XSD and other > resources from > the web. If the Resolver project gets some interest, I am sure > it would > make some sense to at least consider moving it in to JDOM. > > > Disclaimer: http://www.peralex.com/__disclaimer.html > > > > _________________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/__options/jdom-interest/__youraddr at yourhost.com > > From mike at saxonica.com Fri Apr 13 08:04:54 2012 From: mike at saxonica.com (Michael Kay) Date: Fri, 13 Apr 2012 16:04:54 +0100 Subject: [jdom-interest] 2.0.0 usage In-Reply-To: <4F88056F.3040305@tuis.net> References: <4F872BE6.2080008@saxonica.com> <4F88056F.3040305@tuis.net> Message-ID: <4F884096.5000506@saxonica.com> On 13/04/2012 11:52, Rolf Lear wrote: > Hi Michael > > I understand the concerns you had with the API stability. > > Out of interest though, when I was working with Jaxen, it became > apparent that the 'model' of putting JDOM support directly in to Jaxen > is 'broken', it should be (and now is) the other way around. JDOM 2.x > now 'owns' the interface to Jaxen, it 'Owns' the implementation of the > Jaxen 'Navigator'. > > This solves a number of problems, not the least of which is that the > compile-time dependencies are circular otherwise... > > Is there not some way you can help build the 'glue' logic in to JDOM > rather than in to Saxon? I started trying to do that a few months ago, > but got my head all messed up in the API, and NodeInfo classes, etc. Basically there needs to be an adapter module that bridges the Saxon NodeInfo interface to the JDOM Node implementation. There are a number of such modules issued with Saxon, but they use a plug-in architecture - Saxon has no intrinsic knowledge of these modules, and anyone can write a new one. The module itself needs to know about both Saxon and JDOM interfaces, but neither Saxon nor JDOM needs to have static knowledge of the module. So there are no circular dependencies. Which product the module is then distributed with becomes a purely tactical matter, with obvious implications in terms of who gets the bug reports, and so on. One factor here is that historically the NodeInfo interface has not been 100% stable; we will sometimes add a method, or add an argument to an existing method, which means that existing implementations of the interface need to be tweaked. Michael Kay Saxonica From paul at hoplahup.net Fri Apr 13 08:41:22 2012 From: paul at hoplahup.net (Paul Libbrecht) Date: Fri, 13 Apr 2012 17:41:22 +0200 Subject: [jdom-interest] 2.0.0 usage In-Reply-To: References: Message-ID: <0D8026D5-9B60-4E11-BF05-B489E650E32E@hoplahup.net> Le 12 avr. 2012 ? 20:21, Rolf Lear a ?crit : > - Going to try it when there's time. (and major development involving the JDOM usage) Projects: - http://sail-m.de/smala/ - http://www.curriki.org/ - http://www.activemath.org/ paul From bcox at virtualschool.edu Sat Apr 14 10:20:20 2012 From: bcox at virtualschool.edu (Brad Cox) Date: Sat, 14 Apr 2012 13:20:20 -0400 Subject: [jdom-interest] 2.0.0 usage In-Reply-To: <0D8026D5-9B60-4E11-BF05-B489E650E32E@hoplahup.net> References: <0D8026D5-9B60-4E11-BF05-B489E650E32E@hoplahup.net> Message-ID: Will try it when I do another XML project. Everything's JSON right now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdom at tuis.net Mon Apr 16 20:08:50 2012 From: jdom at tuis.net (Rolf Lear) Date: Mon, 16 Apr 2012 23:08:50 -0400 Subject: [jdom-interest] JDOM and Android Message-ID: <4F8CDEC2.5040901@tuis.net> 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 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 From jdom at tuis.net Mon Apr 16 21:51:59 2012 From: jdom at tuis.net (Rolf Lear) Date: Tue, 17 Apr 2012 00:51:59 -0400 Subject: [jdom-interest] JDOM and Android In-Reply-To: References: <4F8CDEC2.5040901@tuis.net> Message-ID: <4F8CF6EF.4090802@tuis.net> 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.(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.(XMLReaderXSDFactory.java:272) at org.jdom2.test.cases.input.sax.TestXMLReaderXSDFactory.testXMLReaderXSDFactoryFileArray(TestXMLReaderXSDFactory.java:80) at org.jdom2.test.cases.input.sax.TestXMLReaderXSDFactoryTT.testXMLReaderXSDFactoryFileArray(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.(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/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 > > > --Joe > > > On Mon, Apr 16, 2012 at 8:08 PM, Rolf Lear > 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 > > > 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 > From jdom at tuis.net Tue Apr 17 20:58:14 2012 From: jdom at tuis.net (Rolf Lear) Date: Tue, 17 Apr 2012 23:58:14 -0400 Subject: [jdom-interest] JDOM and Android In-Reply-To: References: <4F8CDEC2.5040901@tuis.net> <4F8CF6EF.4090802@tuis.net> Message-ID: <4F8E3BD6.30803@tuis.net> 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//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.__(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.(__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.__(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/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 > > > > --Joe > > > On Mon, Apr 16, 2012 at 8:08 PM, Rolf Lear > >> 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 > > > __> > > 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 > > > From jdom at tuis.net Wed Apr 18 18:32:05 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 18 Apr 2012 21:32:05 -0400 Subject: [jdom-interest] JDOM and Android In-Reply-To: <4F8E3BD6.30803@tuis.net> References: <4F8CDEC2.5040901@tuis.net> <4F8CF6EF.4090802@tuis.net> <4F8E3BD6.30803@tuis.net> Message-ID: <4F8F6B15.3020604@tuis.net> 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//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.__(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.(__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.__(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/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 >> >> >> >> >> >> --Joe >> >> >> On Mon, Apr 16, 2012 at 8:08 PM, Rolf Lear > >> >> 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 >> >> >> > __> >> >> 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 at yourhost.com > From mike at saxonica.com Thu Apr 19 02:00:23 2012 From: mike at saxonica.com (Michael Kay) Date: Thu, 19 Apr 2012 10:00:23 +0100 Subject: [jdom-interest] JDOM and Android In-Reply-To: <4F8F6B15.3020604@tuis.net> References: <4F8CDEC2.5040901@tuis.net> <4F8CF6EF.4090802@tuis.net> <4F8E3BD6.30803@tuis.net> <4F8F6B15.3020604@tuis.net> Message-ID: <4F8FD427.7020303@saxonica.com> Many thanks for sharing this information. I've done some experiments with compiling Saxon for Android, and it's nice that someone has cleared a trail through the jungle. I've so far got as far as compiling the code, by: * removing a number of packages and classes, essentially those that provide interfaces to other libraries such as .NET code, DOM4J, XOM, and JDOM, StAX, XQJ * commenting out a few methods where there's a dependency on one of the above. This isn't an impossible loss of functionality, though it would be nice to put some of this back in, e.g. it's a shame to lose some of Saxon's diagnostic tracing output just because there's no XMLStreamWriter. Of course a key aim will be to maintain single source. I suspect that will be easier if the build is all done using scripts / Ant, rather than in the IDE, which will make it much easier to manage things like conditional exclusion of selected methods. If only Java had a decent conditional compilation framework. Perhaps something can be done with annotations, I don't know. Actually running the code will no doubt reveal a few more problems, but the next challenge is to tackle the test environment, which as with JDOM, will probably be a bigger challenge than the code itself. I was already thinking in the direction of two projects, one for production code and one for test code, before I read this blog post. Since no one has been clamouring for Saxon on Android it's not my highest priority, but there does seem to be a lot of development activity on Android and the XML support on the platform seems to be very impoverished, so one feels there is an opportunity here. Michael Kay Saxonica On 19/04/2012 02:32, Rolf Lear wrote: > 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//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.__(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.(__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.__(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/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 >>> >>> >>> >>> >>> >>> >>> >>> --Joe >>> >>> >>> On Mon, Apr 16, 2012 at 8:08 PM, Rolf Lear >> >>> >> 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 >>> >>> >>> >> __> >>> >>> 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 at yourhost.com >> > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From mikeb at mitre.org Thu Apr 19 04:22:47 2012 From: mikeb at mitre.org (Brenner, Mike) Date: Thu, 19 Apr 2012 11:22:47 +0000 Subject: [jdom-interest] JDOM and Android In-Reply-To: <4F8F6B15.3020604@tuis.net> References: <4F8CDEC2.5040901@tuis.net> <4F8CF6EF.4090802@tuis.net> <4F8E3BD6.30803@tuis.net> <4F8F6B15.3020604@tuis.net> Message-ID: <264449A6A521A14593F58479F46B34EB182EAA@IMCMBX03.MITRE.ORG> 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//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.__(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.(__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.__(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/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 >> >> >> >> >> >> --Joe >> >> >> On Mon, Apr 16, 2012 at 8:08 PM, Rolf Lear > >> >> 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 >> >> >> > __> >> >> 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 at yourhost.com > _______________________________________________ To control your jdom-interest membership: http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Thu Apr 19 06:40:12 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 19 Apr 2012 09:40:12 -0400 Subject: [jdom-interest] JDOM and Android In-Reply-To: <264449A6A521A14593F58479F46B34EB182EAA@IMCMBX03.MITRE.ORG> References: <4F8CDEC2.5040901@tuis.net> <4F8CF6EF.4090802@tuis.net> <4F8E3BD6.30803@tuis.net> <4F8F6B15.3020604@tuis.net> <264449A6A521A14593F58479F46B34EB182EAA@IMCMBX03.MITRE.ORG> Message-ID: <79482d4c9a74980b00d939e9a58b1051@tuis.net> 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" 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//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.__(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.(__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.__(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/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 >>> >>> >>> >>> >>> >>> --Joe >>> >>> >>> On Mon, Apr 16, 2012 at 8:08 PM, Rolf Lear >> >>> >> 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 >>> >>> >>> >> __> >>> >>> 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 at yourhost.com >> > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Sun Apr 22 21:06:15 2012 From: jdom at tuis.net (Rolf Lear) Date: Mon, 23 Apr 2012 00:06:15 -0400 Subject: [jdom-interest] JDOM and Android In-Reply-To: <79482d4c9a74980b00d939e9a58b1051@tuis.net> References: <4F8CDEC2.5040901@tuis.net> <4F8CF6EF.4090802@tuis.net> <4F8E3BD6.30803@tuis.net> <4F8F6B15.3020604@tuis.net> <264449A6A521A14593F58479F46B34EB182EAA@IMCMBX03.MITRE.ORG> <79482d4c9a74980b00d939e9a58b1051@tuis.net> Message-ID: <4F94D537.40509@tuis.net> 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" > 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//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.__(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.(__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.__(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/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 >>>> >>>> > >>>> >>>> >>>> >>>> --Joe >>>> >>>> >>>> On Mon, Apr 16, 2012 at 8:08 PM, Rolf Lear>>> >>>> >> 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 >>>> >>>> >>>> >>> __> >>>> >>>> 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 at yourhost.com >>> >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From jdom at tuis.net Mon Apr 23 16:28:23 2012 From: jdom at tuis.net (Rolf Lear) Date: Mon, 23 Apr 2012 19:28:23 -0400 Subject: [jdom-interest] JDOM and Android In-Reply-To: <4F94D537.40509@tuis.net> References: <4F8CDEC2.5040901@tuis.net> <4F8CF6EF.4090802@tuis.net> <4F8E3BD6.30803@tuis.net> <4F8F6B15.3020604@tuis.net> <264449A6A521A14593F58479F46B34EB182EAA@IMCMBX03.MITRE.ORG> <79482d4c9a74980b00d939e9a58b1051@tuis.net> <4F94D537.40509@tuis.net> Message-ID: <4F95E597.3010006@tuis.net> Hi all. I think I am ready to produce a statement on the 'Status of JDOM on Android'... The full wiki page is here: https://github.com/hunterhacker/jdom/wiki/JDOM2-and-Android Here is a summary... JDOM is fully functional on Android with the following 2 exceptions: 1. Android has neither a StAX API nor an implementation. As a result, all JDOM input and output classes that source/sink StAX streams will fail. This includes all classes with the word 'StAX' in the classname. Using these JDOM classes will cause a 'FATAL' application error and your JDOM app will 'crash'. 2. JDOM requires third-party support to implement XML Parsing and the default parser on Android has limited features, and thus JDOM functionality is limited too. As a result, using the default XML parser you will not be able to do: - DTD validation (even though the DocType is parsed and used to add default attributes, entity references, etc.) - XMLSchema validation (even though the XSD Schema is parsed and used to add default attributes, etc.) - suppress the expansion of Entity References - &entity; type references are always expanded. - receive 'internal subset' values from the DocType if there are any. It should be noted that it is possible to install Xerces parser with your Android app, but this does not add significant value because neither the DocType nor Schema validation is possible with Xerces because of various interdependencies within Xerces that make validation impossible. Additionally, the JAXP process in Android is somewhat broken, and as far as I can tell it is not possible to install Xerces as the 'default' parser, but only as a create-each-instance-by-name SAX2 parser. Thus, in conclusion, a number of internal issues have been resolved in JDOM to make it compatible with Android. JDOM has dependencies though on third part functionality (SAX/DOM/StAX) and these dependencies have limitations on Android. As a result JDOM has similar limitations. Of significance, the 'core' functionality of parsing, manipulating, and outputting XML though JDOM is all fully functional. Rolf From jdom at tuis.net Mon Apr 23 16:47:53 2012 From: jdom at tuis.net (Rolf Lear) Date: Mon, 23 Apr 2012 19:47:53 -0400 Subject: [jdom-interest] Scheduled release of 2.0.1 April 28 Message-ID: <4F95EA29.5090108@tuis.net> Hi all. Based on the responses to the '2.0.0 usage' mail, I get the impression that: - 2.0.0 is being used 'seriously', and any other major bugs would have been noticed. - there is no rush/panic to get a 2.0.1 version - it would be useful to have expectations.... As a consequence, I think it is fair to use a release schedule for 2.0.1 that is similar to what I did with 1.1.3... that is: - if there is a bug I release an immediate 'hotfix', and schedule a future 'point-release' - the 'point-release' will contain the bug fix, as well as any other issues that may crop up in the interim. - the point-release date will be scheduled for somewhere between 2 and 4 weeks of the bug discovery. Thus, I am going to schedule a release date for 2.0.1, and it will contain the fix for #72 as well as any other issues that may come up before then.... Since #72 was found a couple of weeks ago, it makes sense to release 2.0.1 this weekend - the 28th/29th April... Currently scheduled for that release: - Fix #72 - Statement of support for Android. If anyone runs in to any more issues, they will be assessed, and that may impact the release schedule, but that is unlikely. Rolf From jdom at tuis.net Sun Apr 29 15:57:14 2012 From: jdom at tuis.net (Rolf Lear) Date: Sun, 29 Apr 2012 18:57:14 -0400 Subject: [jdom-interest] JDOM 2.0.1 released ! Message-ID: <4F9DC74A.6090804@tuis.net> Hi all. JDOM 2.0.1 is now available from www.jdom.org as well as (imminently) on maven-central. New in JDOM 2.0.1 is 'support' for Android. There are some limitations to the JDOM functionality on Android as a result of reduced XML processing support on the Android platform. If you know of any Android-compatible XML parser (SAX) that can successfully perform XSD/DTD validation please let me know! See the full statement of support here: https://github.com/hunterhacker/jdom/wiki/JDOM2-and-Android Additionally, JDOM 2.0.1 fixes issue #72 related to 'Compact' XML Output. If you are new to JDOM or new to JDOM 2.x, here are some useful starting points.... For details on all the new features available in JDOM 2.0.0 please see the wiki page: https://github.com/hunterhacker/jdom/wiki/JDOM2-Features For a 'Primer' on getting started with JDOM, some basic concepts, and examples on how to accomplish the most common tasks in JDOM, see: https://github.com/hunterhacker/jdom/wiki/JDOM2-A-Primer For insights on what issues to expect when changing from JDOM 1.x to 2.x have a look at the 'Migration Guide' here: https://github.com/hunterhacker/jdom/wiki/JDOM2-Migration-Issues The JavaDoc is available in the release, as well as at: http://jdom.org/docs/apidocs/index.html Like previous snapshot releases, the JUnit and Cobertura test-coverage reports are available at: http://hunterhacker.github.com/jdom/jdom2/junit.report/index.html http://hunterhacker.github.com/jdom/jdom2/coverage/index.html As always, if you have any comments, suggestions, concerns, please speak up! Happy Coding Rolf