From paul at hoplahup.net Wed Feb 1 07:00:51 2012 From: paul at hoplahup.net (Paul Libbrecht) Date: Wed, 1 Feb 2012 16:00:51 +0100 Subject: [jdom-interest] Mark Wutka's DTDparser Message-ID: Hello JDOM Friends, I am pretty sure several around here have been using the DTDparser of Mark Wutka, I have since quite long. Mark's website is not up-to-date anymore but he sent me the source. I have put this in my temp: http://www.hoplahup.net/tmp/dtdparser-1.21.zip paul From jdom at tuis.net Thu Feb 2 20:00:49 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 02 Feb 2012 23:00:49 -0500 Subject: [jdom-interest] JDOM ALPHA - Groundhog Day - 3rd and Final Alpha Message-ID: <4F2B5BF1.6030308@tuis.net> Hi All. I have just pushed through the 'Groundhog Day' final ALPHA release. In theory, according to the schedule, the API should be finalized by now. There are no outstanding 'known' issues (but two issues are indefinitely 'deferred' - probably to be closed unless more information about them can be garnered). Please take the code for a spin. If you are new to JDOM2 please see the features and migration guides: https://github.com/hunterhacker/jdom/wiki/JDOM2-Features https://github.com/hunterhacker/jdom/wiki/JDOM2--Migration-Issues Highlights of this release over Alpha2: - Smaller memory footprint (and faster) - option of making it even smaller again using the SlimJDOMFactory (but at the expense of being slower) - all known issues fixed - tidied up some JavaDoc documentation An update of the schedule is: - 1 Jan *DONE* 'New Year' - First ALPHA - 2 Feb *DONE* 'GroundHog Day' - today - Last ALPHA all current issues resolved - submit any issues to the mailing list if you encounter any (*none identified*). Deadline for new feature requests/enhancements - mail the list if you have any (*none requested*). - 14 Feb 'Valentine' *BETA* Release on 14th February - may shift depending on any large enhancements/requests. - 29 Feb 'Leap Day' Second *BETA* - All class/method signatures 'locked' Bug Fixing only - 9 Apr 'Easter' JDOM2 Release It would seem that we are still on track with the schedule, with the Valentine BETA around the corner in 2 weeks. Between now and then I anticipate to be working on documentation only... unless something comes up. As always, this alpha has been posted on the project downloads page: https://github.com/hunterhacker/jdom/downloads specifically here: https://github.com/downloads/hunterhacker/jdom/jdom-2.x-2012.02.02.22.29.zip The JDOM2 web-pages have been updated with the matching JavaDoc pages, and the JUnit and Cobertura Reports: https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 http://hunterhacker.github.com/jdom/jdom2/apidocs/index.html http://hunterhacker.github.com/jdom/jdom2/junit.report/index.html http://hunterhacker.github.com/jdom/jdom2/coverage/index.html Thanks all, and happy coding Rolf From palmercliff at gmail.com Thu Feb 9 12:54:17 2012 From: palmercliff at gmail.com (cliff palmer) Date: Thu, 9 Feb 2012 15:54:17 -0500 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL Message-ID: I'm reading through several hundred thousand existing XML documents building counts of XML tags and have encountered a Java.net.MalformedURL Exception raised by saxBuilder.build because the xmlns points to a URL that can not be reached. I am using JDOM 1.1.2. Is there a call or parameter setting that will cause saxBuilder to ignore namespaces when parsing? Thanks! Cliff From paul at hoplahup.net Thu Feb 9 13:18:41 2012 From: paul at hoplahup.net (Paul Libbrecht) Date: Thu, 9 Feb 2012 22:18:41 +0100 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: References: Message-ID: Cliff, this doesn't sound reasonable to me. I have never seen code doing such and would not expect it (I also run jdom offline quite often). Could it be the DTD is hitting you? Can you copy a full stacktrace? thanks in advance Paul Le 9 f?vr. 2012 ? 21:54, cliff palmer a ?crit : > I'm reading through several hundred thousand existing XML documents > building counts of XML tags and have encountered a > Java.net.MalformedURL Exception raised by saxBuilder.build because the > xmlns points to a URL that can not be reached. > I am using JDOM 1.1.2. > Is there a call or parameter setting that will cause saxBuilder to > ignore namespaces when parsing? > Thanks! > Cliff > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From palmercliff at gmail.com Thu Feb 9 13:31:16 2012 From: palmercliff at gmail.com (cliff palmer) Date: Thu, 9 Feb 2012 16:31:16 -0500 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: References: Message-ID: I don't believe this is a DTD problem - no DTD is referenced. This is the stack trace: at java.net.URL.(URL.java:567) at java.net.URL.(URL.java:464) at java.net.URL.(URL.java:413) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:650) at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:186) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:772) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at org.jdom.input.SAXBuilder.build(SAXBuilder.java:518) at org.jdom.input.SAXBuilder.build(SAXBuilder.java:986) at com.dt.XMLUtility.ProfileXMLAttributes.process(ProfileXMLAttributes.java:162) at com.dt.XMLUtility.main.main(main.java:22) java.io.FileNotFoundException: /home/cpalmer/workspace/ProfileXMLAttributes/< (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:120) at java.io.FileInputStream.(FileInputStream.java:79) at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70) at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:653) at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:186) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:772) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at org.jdom.input.SAXBuilder.build(SAXBuilder.java:518) at org.jdom.input.SAXBuilder.build(SAXBuilder.java:986) at com.dt.XMLUtility.ProfileXMLAttributes.process(ProfileXMLAttributes.java:162) at com.dt.XMLUtility.main.main(main.java:22) java.net.MalformedURLException: no protocol: Thanks Cliff On 2/9/12, Paul Libbrecht wrote: > Cliff, > > this doesn't sound reasonable to me. I have never seen code doing such and > would not expect it (I also run jdom offline quite often). > > Could it be the DTD is hitting you? > Can you copy a full stacktrace? > > thanks in advance > > Paul > > > Le 9 f?vr. 2012 ? 21:54, cliff palmer a ?crit : > >> I'm reading through several hundred thousand existing XML documents >> building counts of XML tags and have encountered a >> Java.net.MalformedURL Exception raised by saxBuilder.build because the >> xmlns points to a URL that can not be reached. >> I am using JDOM 1.1.2. >> Is there a call or parameter setting that will cause saxBuilder to >> ignore namespaces when parsing? >> Thanks! >> Cliff >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > > From curoli at gmail.com Thu Feb 9 14:08:24 2012 From: curoli at gmail.com (Oliver Ruebenacker) Date: Thu, 9 Feb 2012 17:08:24 -0500 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: References: Message-ID: Hello, I don't know anything about SAX, but the error says the problem is not an unreachable URL, but a malformed one. Somehow, it seems to try to use "" as an URL. Apparently, the content of an XML file (or the first line of it) is used where a URL should be used. Take care Oliver On Thu, Feb 9, 2012 at 4:31 PM, cliff palmer wrote: > I don't believe this is a DTD problem - no DTD is referenced. > This is the stack trace: > at java.net.URL.(URL.java:567) > ? ? ? ?at java.net.URL.(URL.java:464) > ? ? ? ?at java.net.URL.(URL.java:413) > ? ? ? ?at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:650) > ? ? ? ?at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:186) > ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:772) > ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) > ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) > ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) > ? ? ? ?at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) > ? ? ? ?at org.jdom.input.SAXBuilder.build(SAXBuilder.java:518) > ? ? ? ?at org.jdom.input.SAXBuilder.build(SAXBuilder.java:986) > ? ? ? ?at com.dt.XMLUtility.ProfileXMLAttributes.process(ProfileXMLAttributes.java:162) > ? ? ? ?at com.dt.XMLUtility.main.main(main.java:22) > java.io.FileNotFoundException: > /home/cpalmer/workspace/ProfileXMLAttributes/< (No such file or > directory) > ? ? ? ?at java.io.FileInputStream.open(Native Method) > ? ? ? ?at java.io.FileInputStream.(FileInputStream.java:120) > ? ? ? ?at java.io.FileInputStream.(FileInputStream.java:79) > ? ? ? ?at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70) > ? ? ? ?at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161) > ? ? ? ?at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:653) > ? ? ? ?at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:186) > ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:772) > ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) > ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) > ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) > ? ? ? ?at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) > ? ? ? ?at org.jdom.input.SAXBuilder.build(SAXBuilder.java:518) > ? ? ? ?at org.jdom.input.SAXBuilder.build(SAXBuilder.java:986) > ? ? ? ?at com.dt.XMLUtility.ProfileXMLAttributes.process(ProfileXMLAttributes.java:162) > ? ? ? ?at com.dt.XMLUtility.main.main(main.java:22) > java.net.MalformedURLException: no protocol: > > Thanks > Cliff > > On 2/9/12, Paul Libbrecht wrote: >> Cliff, >> >> this doesn't sound reasonable to me. I have never seen code doing such and >> would not expect it (I also run jdom offline quite often). >> >> Could it be the DTD is hitting you? >> Can you copy a full stacktrace? >> >> thanks in advance >> >> Paul >> >> >> Le 9 f?vr. 2012 ? 21:54, cliff palmer a ?crit : >> >>> I'm reading through several hundred thousand existing XML documents >>> building counts of XML tags and have encountered a >>> Java.net.MalformedURL Exception raised by saxBuilder.build because the >>> xmlns points to a URL that can not be reached. >>> I am using JDOM 1.1.2. >>> Is there a call or parameter setting that will cause saxBuilder to >>> ignore namespaces when parsing? >>> Thanks! >>> Cliff >>> _______________________________________________ >>> 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 palmercliff at gmail.com Thu Feb 9 14:19:16 2012 From: palmercliff at gmail.com (cliff palmer) Date: Thu, 9 Feb 2012 17:19:16 -0500 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: References: Message-ID: Thanks Oliver - I don't need access to the unreachable/malformed URL, I just need to instantiate the XML that is there so I can step through it and determine what tags are there. Is there a way to tell JDOM to ignore external references and not be concerned about URLs ? Thanks Cliff On Thu, Feb 9, 2012 at 5:08 PM, Oliver Ruebenacker wrote: > ? ? Hello, > > ?I don't know anything about SAX, but the error says the problem is > not an unreachable URL, but a malformed one. Somehow, it seems to try > to use "" as an URL. Apparently, the content of > an XML file (or the first line of it) is used where a URL should be > used. > > ? ? Take care > ? ? Oliver > > On Thu, Feb 9, 2012 at 4:31 PM, cliff palmer wrote: >> I don't believe this is a DTD problem - no DTD is referenced. >> This is the stack trace: >> at java.net.URL.(URL.java:567) >> ? ? ? ?at java.net.URL.(URL.java:464) >> ? ? ? ?at java.net.URL.(URL.java:413) >> ? ? ? ?at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:650) >> ? ? ? ?at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:186) >> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:772) >> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) >> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) >> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) >> ? ? ? ?at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) >> ? ? ? ?at org.jdom.input.SAXBuilder.build(SAXBuilder.java:518) >> ? ? ? ?at org.jdom.input.SAXBuilder.build(SAXBuilder.java:986) >> ? ? ? ?at com.dt.XMLUtility.ProfileXMLAttributes.process(ProfileXMLAttributes.java:162) >> ? ? ? ?at com.dt.XMLUtility.main.main(main.java:22) >> java.io.FileNotFoundException: >> /home/cpalmer/workspace/ProfileXMLAttributes/< (No such file or >> directory) >> ? ? ? ?at java.io.FileInputStream.open(Native Method) >> ? ? ? ?at java.io.FileInputStream.(FileInputStream.java:120) >> ? ? ? ?at java.io.FileInputStream.(FileInputStream.java:79) >> ? ? ? ?at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70) >> ? ? ? ?at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161) >> ? ? ? ?at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:653) >> ? ? ? ?at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:186) >> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:772) >> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) >> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) >> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) >> ? ? ? ?at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) >> ? ? ? ?at org.jdom.input.SAXBuilder.build(SAXBuilder.java:518) >> ? ? ? ?at org.jdom.input.SAXBuilder.build(SAXBuilder.java:986) >> ? ? ? ?at com.dt.XMLUtility.ProfileXMLAttributes.process(ProfileXMLAttributes.java:162) >> ? ? ? ?at com.dt.XMLUtility.main.main(main.java:22) >> java.net.MalformedURLException: no protocol: >> >> Thanks >> Cliff >> >> On 2/9/12, Paul Libbrecht wrote: >>> Cliff, >>> >>> this doesn't sound reasonable to me. I have never seen code doing such and >>> would not expect it (I also run jdom offline quite often). >>> >>> Could it be the DTD is hitting you? >>> Can you copy a full stacktrace? >>> >>> thanks in advance >>> >>> Paul >>> >>> >>> Le 9 f?vr. 2012 ? 21:54, cliff palmer a ?crit : >>> >>>> I'm reading through several hundred thousand existing XML documents >>>> building counts of XML tags and have encountered a >>>> Java.net.MalformedURL Exception raised by saxBuilder.build because the >>>> xmlns points to a URL that can not be reached. >>>> I am using JDOM 1.1.2. >>>> Is there a call or parameter setting that will cause saxBuilder to >>>> ignore namespaces when parsing? >>>> Thanks! >>>> Cliff >>>> _______________________________________________ >>>> 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 paul at hoplahup.net Thu Feb 9 14:25:22 2012 From: paul at hoplahup.net (Paul Libbrecht) Date: Thu, 9 Feb 2012 23:25:22 +0100 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: References: Message-ID: Click, are you parsing a document that' s in a string? Mustn't be... one thing tickles me: the trailing < in java.io.FileNotFoundException: /home/cpalmer/workspace/ProfileXMLAttributes/< (No such file or Crawling this stacktrace with my intelliJ idea makes me conclude that the file above is passed to SAXBuilder in ProfileXMLAttributes.java:162. hope it helps. paul Le 9 f?vr. 2012 ? 23:08, Oliver Ruebenacker a ?crit : > Hello, > > I don't know anything about SAX, but the error says the problem is > not an unreachable URL, but a malformed one. Somehow, it seems to try > to use "" as an URL. Apparently, the content of > an XML file (or the first line of it) is used where a URL should be > used. > > Take care > Oliver > > On Thu, Feb 9, 2012 at 4:31 PM, cliff palmer wrote: >> I don't believe this is a DTD problem - no DTD is referenced. >> This is the stack trace: >> at java.net.URL.(URL.java:567) >> at java.net.URL.(URL.java:464) >> at java.net.URL.(URL.java:413) >> at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:650) >> at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:186) >> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:772) >> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) >> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) >> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) >> at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) >> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:518) >> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:986) >> at com.dt.XMLUtility.ProfileXMLAttributes.process(ProfileXMLAttributes.java:162) >> at com.dt.XMLUtility.main.main(main.java:22) >> java.io.FileNotFoundException: >> /home/cpalmer/workspace/ProfileXMLAttributes/< (No such file or >> directory) >> at java.io.FileInputStream.open(Native Method) >> at java.io.FileInputStream.(FileInputStream.java:120) >> at java.io.FileInputStream.(FileInputStream.java:79) >> at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70) >> at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161) >> at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:653) >> at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:186) >> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:772) >> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) >> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) >> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) >> at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) >> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:518) >> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:986) >> at com.dt.XMLUtility.ProfileXMLAttributes.process(ProfileXMLAttributes.java:162) >> at com.dt.XMLUtility.main.main(main.java:22) >> java.net.MalformedURLException: no protocol: >> >> Thanks >> Cliff >> >> On 2/9/12, Paul Libbrecht wrote: >>> Cliff, >>> >>> this doesn't sound reasonable to me. I have never seen code doing such and >>> would not expect it (I also run jdom offline quite often). >>> >>> Could it be the DTD is hitting you? >>> Can you copy a full stacktrace? >>> >>> thanks in advance >>> >>> Paul >>> >>> >>> Le 9 f?vr. 2012 ? 21:54, cliff palmer a ?crit : >>> >>>> I'm reading through several hundred thousand existing XML documents >>>> building counts of XML tags and have encountered a >>>> Java.net.MalformedURL Exception raised by saxBuilder.build because the >>>> xmlns points to a URL that can not be reached. >>>> I am using JDOM 1.1.2. >>>> Is there a call or parameter setting that will cause saxBuilder to >>>> ignore namespaces when parsing? >>>> Thanks! >>>> Cliff >>>> _______________________________________________ >>>> 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 curoli at gmail.com Thu Feb 9 14:32:52 2012 From: curoli at gmail.com (Oliver Ruebenacker) Date: Thu, 9 Feb 2012 17:32:52 -0500 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: References: Message-ID: Hello, I would guess the fact that a piece of XML content appears where a URL is expected points to some kind of coding error. Can you post a few lines of your code? Take care Oliver On Thu, Feb 9, 2012 at 5:19 PM, cliff palmer wrote: > Thanks Oliver - I don't need access to the unreachable/malformed URL, > I just need to instantiate the XML that is there so I can step through > it and determine what tags are there. > Is there a way to tell JDOM to ignore external references and not be > concerned about URLs ? > Thanks > Cliff > > On Thu, Feb 9, 2012 at 5:08 PM, Oliver Ruebenacker wrote: >> ? ? Hello, >> >> ?I don't know anything about SAX, but the error says the problem is >> not an unreachable URL, but a malformed one. Somehow, it seems to try >> to use "" as an URL. Apparently, the content of >> an XML file (or the first line of it) is used where a URL should be >> used. >> >> ? ? Take care >> ? ? Oliver >> >> On Thu, Feb 9, 2012 at 4:31 PM, cliff palmer wrote: >>> I don't believe this is a DTD problem - no DTD is referenced. >>> This is the stack trace: >>> at java.net.URL.(URL.java:567) >>> ? ? ? ?at java.net.URL.(URL.java:464) >>> ? ? ? ?at java.net.URL.(URL.java:413) >>> ? ? ? ?at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:650) >>> ? ? ? ?at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:186) >>> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:772) >>> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) >>> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) >>> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) >>> ? ? ? ?at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) >>> ? ? ? ?at org.jdom.input.SAXBuilder.build(SAXBuilder.java:518) >>> ? ? ? ?at org.jdom.input.SAXBuilder.build(SAXBuilder.java:986) >>> ? ? ? ?at com.dt.XMLUtility.ProfileXMLAttributes.process(ProfileXMLAttributes.java:162) >>> ? ? ? ?at com.dt.XMLUtility.main.main(main.java:22) >>> java.io.FileNotFoundException: >>> /home/cpalmer/workspace/ProfileXMLAttributes/< (No such file or >>> directory) >>> ? ? ? ?at java.io.FileInputStream.open(Native Method) >>> ? ? ? ?at java.io.FileInputStream.(FileInputStream.java:120) >>> ? ? ? ?at java.io.FileInputStream.(FileInputStream.java:79) >>> ? ? ? ?at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70) >>> ? ? ? ?at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161) >>> ? ? ? ?at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:653) >>> ? ? ? ?at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:186) >>> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:772) >>> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) >>> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) >>> ? ? ? ?at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) >>> ? ? ? ?at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) >>> ? ? ? ?at org.jdom.input.SAXBuilder.build(SAXBuilder.java:518) >>> ? ? ? ?at org.jdom.input.SAXBuilder.build(SAXBuilder.java:986) >>> ? ? ? ?at com.dt.XMLUtility.ProfileXMLAttributes.process(ProfileXMLAttributes.java:162) >>> ? ? ? ?at com.dt.XMLUtility.main.main(main.java:22) >>> java.net.MalformedURLException: no protocol: >>> >>> Thanks >>> Cliff >>> >>> On 2/9/12, Paul Libbrecht wrote: >>>> Cliff, >>>> >>>> this doesn't sound reasonable to me. I have never seen code doing such and >>>> would not expect it (I also run jdom offline quite often). >>>> >>>> Could it be the DTD is hitting you? >>>> Can you copy a full stacktrace? >>>> >>>> thanks in advance >>>> >>>> Paul >>>> >>>> >>>> Le 9 f?vr. 2012 ? 21:54, cliff palmer a ?crit : >>>> >>>>> I'm reading through several hundred thousand existing XML documents >>>>> building counts of XML tags and have encountered a >>>>> Java.net.MalformedURL Exception raised by saxBuilder.build because the >>>>> xmlns points to a URL that can not be reached. >>>>> I am using JDOM 1.1.2. >>>>> Is there a call or parameter setting that will cause saxBuilder to >>>>> ignore namespaces when parsing? >>>>> Thanks! >>>>> Cliff >>>>> _______________________________________________ >>>>> 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 -- 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 jdom at tuis.net Thu Feb 9 14:40:57 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 09 Feb 2012 17:40:57 -0500 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: References: Message-ID: <4F344B79.1050709@tuis.net> Hi Cliff. I think there's been some good pointers already, but just to make things crystal clear... can you perhaps post the relevant code snippet you are using to parse the document, and perhaps the first few lines of the actual XML too. Also, does this problem happen with *all* xml documents (the first one), or with just some of them? My guess is that Oliver has the right idea with parsing the wrong string.... remember that the SaxBuilder.build(String) method expects the String to be a URL, not the actual XML content..... YTour stack trace indicates you are calling this method... See the code here: https://github.com/hunterhacker/jdom/blob/jdom-1.x/core/src/java/org/jdom/input/SAXBuilder.java#L986 Anyway, seeing your code would help.... Rolf On 09/02/2012 3:54 PM, cliff palmer wrote: > I'm reading through several hundred thousand existing XML documents > building counts of XML tags and have encountered a > Java.net.MalformedURL Exception raised by saxBuilder.build because the > xmlns points to a URL that can not be reached. > I am using JDOM 1.1.2. > Is there a call or parameter setting that will cause saxBuilder to > ignore namespaces when parsing? > Thanks! > Cliff > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From palmercliff at gmail.com Thu Feb 9 14:58:23 2012 From: palmercliff at gmail.com (cliff palmer) Date: Thu, 9 Feb 2012 17:58:23 -0500 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: <4F344B79.1050709@tuis.net> References: <4F344B79.1050709@tuis.net> Message-ID: Hi Rolf I will post the code later, (sorry late for a meeting) but to answer your questions: - this error occurs when there is an "xmlns" declaration. Since this is the first instance of an "xmlns" declaration I've encountered with JDOM and all of the URLs in the "xmlns" declaration that I have found point to the same bad address, I don't know if the problem is related to lookup of the URL or just the presence of an "xmlns" declaration. - the problem is predictable and occurs for each xml document that uses this bad URL in an "xmlns" declaration. - I've used the code (I will post it, I promise) to parse over 3 million xml documents, passing a string containing the xml document (not a URL). The value I pass to saxbuilder.build is the returned string from the JDBC call ResultSet.getString using a column number parameter. I haven't been altering or converting the string returned from JDBC. Thanks Rolf and I will post the code as soon as the suits are done with me. Cliff On Thu, Feb 9, 2012 at 5:40 PM, Rolf Lear wrote: > Hi Cliff. > > I think there's been some good pointers already, but just to make things > crystal clear... can you perhaps post the relevant code snippet you are > using to parse the document, and perhaps the first few lines of the actual > XML too. > > Also, does this problem happen with *all* xml documents (the first one), or > with just some of them? > > My guess is that Oliver has the right idea with parsing the wrong string.... > remember that the SaxBuilder.build(String) method expects the String to be a > URL, not the actual XML content..... YTour stack trace indicates you are > calling this method... > > See the code here: > https://github.com/hunterhacker/jdom/blob/jdom-1.x/core/src/java/org/jdom/input/SAXBuilder.java#L986 > > Anyway, seeing your code would help.... > > Rolf > > > On 09/02/2012 3:54 PM, cliff palmer wrote: >> >> I'm reading through several hundred thousand existing XML documents >> building counts of XML tags and have encountered a >> Java.net.MalformedURL Exception raised by saxBuilder.build because the >> xmlns points to a URL that can not be reached. >> I am using JDOM 1.1.2. >> Is there a call or parameter setting that will cause saxBuilder to >> ignore namespaces when parsing? >> Thanks! >> Cliff >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > From palmercliff at gmail.com Thu Feb 9 15:26:22 2012 From: palmercliff at gmail.com (cliff palmer) Date: Thu, 9 Feb 2012 18:26:22 -0500 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: References: <4F344B79.1050709@tuis.net> Message-ID: code below: import java.io.IOException; import java.io.Reader; import java.io.StringReader; import java.sql.Clob; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.ResultSetMetaData; import java.sql.SQLException; import java.sql.Statement; import java.util.ArrayList; import java.util.HashMap; import java.util.Iterator; import java.util.List; import java.util.Collections; import java.util.Map; import javax.sql.DataSource; import oracle.sql.CLOB; import org.apache.log4j.Appender; import org.apache.log4j.EnhancedPatternLayout; import org.apache.log4j.Logger; import org.jdom.Document; import org.jdom.Element; import org.jdom.Attribute; import org.jdom.JDOMException; import org.jdom.input.SAXBuilder; import org.jdom.output.Format; import org.jdom.output.XMLOutputter; public class ProfileXMLAttributes implements AppDriver { public String driverClassName; static Logger logLogger; Appender logAppender; EnhancedPatternLayout logLayout; DataSource dataSource; JdbcTemplate jdbcTemplate; Connection conn; Statement stmt; ResultSet rs; ResultSetMetaData rsmd; SQLClob sqlClob; SAXBuilder saxBuilder; Document xmlDoc; Format xmlFmt; XMLOutputter xmlOutputter; Element xmlElement; Element xPathElement; Element rootElement; String pathString; static SQLClob theSQLClob; Map tagMap; String tagKey; Integer tagValue; int badXML = 0; int rowsRead = 0; boolean goodXML; String msgID; /* ========================================================= init is called once by the driver program to set up the run environment for logging, JDBC, JDOM, etc ========================================================= */ @Override public void init() { logLogger = Logger.getLogger(ProfileXMLAttributes.class.getName()); dataSource = (DataSource) main.context.getBean("datasource"); jdbcTemplate = new JdbcTemplate(dataSource); try{ conn = DriverManager.getConnection("jdbc:oracle:thin:@10.1.6.78:1521:kbfcubs", "kbfcubs", "kbfcubs"); } catch (SQLException e) { logLogger.debug("Exception initializing connection"); e.printStackTrace(); } stmt = null; try{ stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY); stmt.setFetchSize(10000); } catch (SQLException e) { logLogger.debug("Exception initializing statement"); e.printStackTrace(); } rs = null; try { String xmlQuery = "select xml_id, xml_contents from xml_table"; rs = stmt.executeQuery(xmlQuery); } catch (SQLException e) { logLogger.debug("Exception executing query"); e.printStackTrace(); } saxBuilder = new SAXBuilder(); xmlFmt = Format.getPrettyFormat().setEncoding("UTF-8"); xmlOutputter = new XMLOutputter(xmlFmt); structureString = new ArrayList(); tagMap = new HashMap(); } /* ========================================================= process is called once by the driver program to do all the work. For each row returned by the JDBC query it instantiates the xml document in JDOM and then calls doProcess passing the rootElement to step through the xml tags. ========================================================= */ @Override public void process() throws SQLException { while(rs.next()) { xmlDoc = null; rowsRead ++; msgID = rs.getString(1); try { xmlDoc = saxBuilder.build(rs.getString(2)); } catch (JDOMException e) { e.printStackTrace(); } catch (IOException e) { goodXML = false; e.printStackTrace(); } try { rootElement = xmlDoc.getRootElement(); doProcess(rootElement); } catch (Exception e) { e.printStackTrace(); } } } /* ========================================================= doProcess is called once by process for each row in the JDBC result set. It is also called recursively as the xml tags are discovered. Each xml tag is added to a hash map and counts of the occurances of each tag are accumulated. ========================================================= */ private void doProcess (Element currentElement) { tagKey = new String(currentElement.getName()); tagValue = tagMap.get(tagKey); if(tagValue == null) { tagValue = 1; } else { tagValue += 1; } tagMap.put(tagKey, tagValue); Iterator itr = currentElement.getChildren().iterator(); boolean hasChildren = false; while (itr.hasNext()) { hasChildren = true; Object childElement = itr.next(); } if (hasChildren == true) { itr = currentElement.getChildren().iterator(); hasChildren = false; } while (itr.hasNext()) { Object childElement = itr.next(); doProcess((Element) childElement); } } } On 2/9/12, cliff palmer wrote: > Hi Rolf > I will post the code later, (sorry late for a meeting) but to answer > your questions: > - this error occurs when there is an "xmlns" declaration. Since this > is the first instance of an "xmlns" declaration I've encountered with > JDOM and all of the URLs in the "xmlns" declaration that I have found > point to the same bad address, I don't know if the problem is related > to lookup of the URL or just the presence of an "xmlns" declaration. > - the problem is predictable and occurs for each xml document that > uses this bad URL in an "xmlns" declaration. > - I've used the code (I will post it, I promise) to parse over 3 > million xml documents, passing a string containing the xml document > (not a URL). The value I pass to saxbuilder.build is the returned > string from the JDBC call ResultSet.getString using a column number > parameter. I haven't been altering or converting the string returned > from JDBC. > > Thanks Rolf and I will post the code as soon as the suits are done with me. > > Cliff > > On Thu, Feb 9, 2012 at 5:40 PM, Rolf Lear wrote: >> Hi Cliff. >> >> I think there's been some good pointers already, but just to make things >> crystal clear... can you perhaps post the relevant code snippet you are >> using to parse the document, and perhaps the first few lines of the >> actual >> XML too. >> >> Also, does this problem happen with *all* xml documents (the first one), >> or >> with just some of them? >> >> My guess is that Oliver has the right idea with parsing the wrong >> string.... >> remember that the SaxBuilder.build(String) method expects the String to be >> a >> URL, not the actual XML content..... YTour stack trace indicates you are >> calling this method... >> >> See the code here: >> https://github.com/hunterhacker/jdom/blob/jdom-1.x/core/src/java/org/jdom/input/SAXBuilder.java#L986 >> >> Anyway, seeing your code would help.... >> >> Rolf >> >> >> On 09/02/2012 3:54 PM, cliff palmer wrote: >>> >>> I'm reading through several hundred thousand existing XML documents >>> building counts of XML tags and have encountered a >>> Java.net.MalformedURL Exception raised by saxBuilder.build because the >>> xmlns points to a URL that can not be reached. >>> I am using JDOM 1.1.2. >>> Is there a call or parameter setting that will cause saxBuilder to >>> ignore namespaces when parsing? >>> Thanks! >>> Cliff >>> _______________________________________________ >>> To control your jdom-interest membership: >>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>> >> > From jdom at tuis.net Thu Feb 9 15:44:10 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 09 Feb 2012 18:44:10 -0500 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: References: <4F344B79.1050709@tuis.net> Message-ID: <4F345A4A.3040200@tuis.net> Hi Cliff. I think the problem is that the content of the column 'xml_contents' of the table 'xml_table' is actual XML data.... not a file name/URI. I think what you want to do is: String xmlcontent = rs.getString(2); StringReader reader = new StringReader(xmlcontent); xmlDoc = saxBuilder.build(reader); See http://jdom.org/docs/faq.html#a0210 Rolf On 09/02/2012 6:26 PM, cliff palmer wrote: > code below: ..... > rs = null; > try { > String xmlQuery = "select xml_id, xml_contents from xml_table"; > rs = stmt.executeQuery(xmlQuery); > } catch (SQLException e) { > logLogger.debug("Exception executing query"); > e.printStackTrace(); > } > saxBuilder = new SAXBuilder(); > xmlFmt = Format.getPrettyFormat().setEncoding("UTF-8"); > xmlOutputter = new XMLOutputter(xmlFmt); > structureString = new ArrayList(); > tagMap = new HashMap(); ... > while(rs.next()) { > xmlDoc = null; > rowsRead ++; > msgID = rs.getString(1); > try { > xmlDoc = saxBuilder.build(rs.getString(2)); > } catch (JDOMException e) { > e.printStackTrace(); > } catch (IOException e) { > goodXML = false; > e.printStackTrace(); > } > try { > rootElement = xmlDoc.getRootElement(); > doProcess(rootElement); > } catch (Exception e) { > e.printStackTrace(); > } > } > > On 2/9/12, cliff palmer wrote: >> Hi Rolf >> I will post the code later, (sorry late for a meeting) but to answer >> your questions: >> - this error occurs when there is an "xmlns" declaration. Since this >> is the first instance of an "xmlns" declaration I've encountered with >> JDOM and all of the URLs in the "xmlns" declaration that I have found >> point to the same bad address, I don't know if the problem is related >> to lookup of the URL or just the presence of an "xmlns" declaration. >> - the problem is predictable and occurs for each xml document that >> uses this bad URL in an "xmlns" declaration. >> - I've used the code (I will post it, I promise) to parse over 3 >> million xml documents, passing a string containing the xml document >> (not a URL). The value I pass to saxbuilder.build is the returned >> string from the JDBC call ResultSet.getString using a column number >> parameter. I haven't been altering or converting the string returned >> from JDBC. >> >> Thanks Rolf and I will post the code as soon as the suits are done with me. >> >> Cliff >> >> On Thu, Feb 9, 2012 at 5:40 PM, Rolf Lear wrote: >>> Hi Cliff. >>> >>> I think there's been some good pointers already, but just to make things >>> crystal clear... can you perhaps post the relevant code snippet you are >>> using to parse the document, and perhaps the first few lines of the >>> actual >>> XML too. >>> >>> Also, does this problem happen with *all* xml documents (the first one), >>> or >>> with just some of them? >>> >>> My guess is that Oliver has the right idea with parsing the wrong >>> string.... >>> remember that the SaxBuilder.build(String) method expects the String to be >>> a >>> URL, not the actual XML content..... YTour stack trace indicates you are >>> calling this method... >>> >>> See the code here: >>> https://github.com/hunterhacker/jdom/blob/jdom-1.x/core/src/java/org/jdom/input/SAXBuilder.java#L986 >>> >>> Anyway, seeing your code would help.... >>> >>> Rolf >>> >>> >>> On 09/02/2012 3:54 PM, cliff palmer wrote: >>>> I'm reading through several hundred thousand existing XML documents >>>> building counts of XML tags and have encountered a >>>> Java.net.MalformedURL Exception raised by saxBuilder.build because the >>>> xmlns points to a URL that can not be reached. >>>> I am using JDOM 1.1.2. >>>> Is there a call or parameter setting that will cause saxBuilder to >>>> ignore namespaces when parsing? >>>> Thanks! >>>> Cliff >>>> _______________________________________________ >>>> To control your jdom-interest membership: >>>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>>> From jdom at tuis.net Thu Feb 9 15:59:20 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 09 Feb 2012 18:59:20 -0500 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: <4F345A4A.3040200@tuis.net> References: <4F344B79.1050709@tuis.net> <4F345A4A.3040200@tuis.net> Message-ID: <4F345DD8.1010504@tuis.net> Hi Cliff. I just ran a quick test ... : public class TestParse { public static void main(String[] args) throws Exception { String xml = "\n"; SAXBuilder sb = new SAXBuilder(); sb.build(xml); } } and got: Exception in thread "main" java.net.MalformedURLException: no protocol: at java.net.URL.(URL.java:567) at java.net.URL.(URL.java:464) at java.net.URL.(URL.java:413) at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source) at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.jdom2.input.sax.SAXBuilderEngine.build(SAXBuilderEngine.java:217) at org.jdom2.input.sax.SAXBuilderEngine.build(SAXBuilderEngine.java:327) at org.jdom2.input.SAXBuilder.build(SAXBuilder.java:1286) at net.tuis.debug.TestParse.main(TestParse.java:12) On 09/02/2012 6:44 PM, Rolf Lear wrote: > Hi Cliff. > > I think the problem is that the content of the column 'xml_contents' of > the table 'xml_table' is actual XML data.... not a file name/URI. > > > I think what you want to do is: > > String xmlcontent = rs.getString(2); > StringReader reader = new StringReader(xmlcontent); > xmlDoc = saxBuilder.build(reader); > > See http://jdom.org/docs/faq.html#a0210 > > Rolf > > On 09/02/2012 6:26 PM, cliff palmer wrote: >> code below: > ..... >> rs = null; >> try { >> String xmlQuery = "select xml_id, xml_contents from xml_table"; >> rs = stmt.executeQuery(xmlQuery); >> } catch (SQLException e) { >> logLogger.debug("Exception executing query"); >> e.printStackTrace(); >> } >> saxBuilder = new SAXBuilder(); >> xmlFmt = Format.getPrettyFormat().setEncoding("UTF-8"); >> xmlOutputter = new XMLOutputter(xmlFmt); >> structureString = new ArrayList(); >> tagMap = new HashMap(); > ... >> while(rs.next()) { >> xmlDoc = null; >> rowsRead ++; >> msgID = rs.getString(1); >> try { >> xmlDoc = saxBuilder.build(rs.getString(2)); >> } catch (JDOMException e) { >> e.printStackTrace(); >> } catch (IOException e) { >> goodXML = false; >> e.printStackTrace(); >> } >> try { >> rootElement = xmlDoc.getRootElement(); >> doProcess(rootElement); >> } catch (Exception e) { >> e.printStackTrace(); >> } >> } > > > > >> >> On 2/9/12, cliff palmer wrote: >>> Hi Rolf >>> I will post the code later, (sorry late for a meeting) but to answer >>> your questions: >>> - this error occurs when there is an "xmlns" declaration. Since this >>> is the first instance of an "xmlns" declaration I've encountered with >>> JDOM and all of the URLs in the "xmlns" declaration that I have found >>> point to the same bad address, I don't know if the problem is related >>> to lookup of the URL or just the presence of an "xmlns" declaration. >>> - the problem is predictable and occurs for each xml document that >>> uses this bad URL in an "xmlns" declaration. >>> - I've used the code (I will post it, I promise) to parse over 3 >>> million xml documents, passing a string containing the xml document >>> (not a URL). The value I pass to saxbuilder.build is the returned >>> string from the JDBC call ResultSet.getString using a column number >>> parameter. I haven't been altering or converting the string returned >>> from JDBC. >>> >>> Thanks Rolf and I will post the code as soon as the suits are done >>> with me. >>> >>> Cliff >>> >>> On Thu, Feb 9, 2012 at 5:40 PM, Rolf Lear wrote: >>>> Hi Cliff. >>>> >>>> I think there's been some good pointers already, but just to make >>>> things >>>> crystal clear... can you perhaps post the relevant code snippet you are >>>> using to parse the document, and perhaps the first few lines of the >>>> actual >>>> XML too. >>>> >>>> Also, does this problem happen with *all* xml documents (the first >>>> one), >>>> or >>>> with just some of them? >>>> >>>> My guess is that Oliver has the right idea with parsing the wrong >>>> string.... >>>> remember that the SaxBuilder.build(String) method expects the String >>>> to be >>>> a >>>> URL, not the actual XML content..... YTour stack trace indicates you >>>> are >>>> calling this method... >>>> >>>> See the code here: >>>> https://github.com/hunterhacker/jdom/blob/jdom-1.x/core/src/java/org/jdom/input/SAXBuilder.java#L986 >>>> >>>> >>>> Anyway, seeing your code would help.... >>>> >>>> Rolf >>>> >>>> >>>> On 09/02/2012 3:54 PM, cliff palmer wrote: >>>>> I'm reading through several hundred thousand existing XML documents >>>>> building counts of XML tags and have encountered a >>>>> Java.net.MalformedURL Exception raised by saxBuilder.build because the >>>>> xmlns points to a URL that can not be reached. >>>>> I am using JDOM 1.1.2. >>>>> Is there a call or parameter setting that will cause saxBuilder to >>>>> ignore namespaces when parsing? >>>>> Thanks! >>>>> Cliff >>>>> _______________________________________________ >>>>> 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 palmercliff at gmail.com Fri Feb 10 04:35:43 2012 From: palmercliff at gmail.com (cliff palmer) Date: Fri, 10 Feb 2012 07:35:43 -0500 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: <4F345A4A.3040200@tuis.net> References: <4F344B79.1050709@tuis.net> <4F345A4A.3040200@tuis.net> Message-ID: Rolf, that worked - it's mysterious that the version in my code (passing the string) worked until there was a URL, but I can live with mysteries in light of working code :). Thanks! Cliff On Thu, Feb 9, 2012 at 6:44 PM, Rolf Lear wrote: > Hi Cliff. > > I think the problem is that the content of the column 'xml_contents' of the > table 'xml_table' is actual XML data.... not a file name/URI. > > > I think what you want to do is: > > ? ?String xmlcontent = rs.getString(2); > ? ?StringReader reader = new StringReader(xmlcontent); > ? ?xmlDoc = saxBuilder.build(reader); > > See http://jdom.org/docs/faq.html#a0210 > > Rolf > > On 09/02/2012 6:26 PM, cliff palmer wrote: >> >> code below: > > ..... > >> ? ? ? ? ? ? ? ?rs = null; >> ? ? ? ? ? ? ? ?try { >> ? ? ? ? ? ? ? ? ? ? ? ?String xmlQuery = "select xml_id, xml_contents from >> xml_table"; >> ? ? ? ? ? ? ? ? ? ? ? ?rs = stmt.executeQuery(xmlQuery); >> ? ? ? ? ? ? ? ?} catch (SQLException e) { >> ? ? ? ? ? ? ? ? ? ? ? ?logLogger.debug("Exception executing query"); >> ? ? ? ? ? ? ? ? ? ? ? ?e.printStackTrace(); >> ? ? ? ? ? ? ? ?} >> ? ? ? ? ? ? ? ?saxBuilder = new SAXBuilder(); >> ? ? ? ? ? ? ? ?xmlFmt = ?Format.getPrettyFormat().setEncoding("UTF-8"); >> ? ? ? ? ? ? ? ?xmlOutputter = new XMLOutputter(xmlFmt); >> ? ? ? ? ? ? ? ?structureString = new ArrayList(); >> ? ? ? ? ? ? ? ?tagMap = new HashMap(); > > ... > >> ? ? ? ? ? ? ? ?while(rs.next()) { >> ? ? ? ? ? ? ? ? ? ? ? ?xmlDoc = null; >> ? ? ? ? ? ? ? ? ? ? ? ?rowsRead ++; >> ? ? ? ? ? ? ? ? ? ? ? ?msgID = rs.getString(1); >> ? ? ? ? ? ? ? ? ? ? ? ?try { >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?xmlDoc = saxBuilder.build(rs.getString(2)); >> ? ? ? ? ? ? ? ? ? ? ? ?} catch (JDOMException e) { >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?e.printStackTrace(); >> ? ? ? ? ? ? ? ? ? ? ? ?} catch (IOException e) { >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?goodXML = false; >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?e.printStackTrace(); >> ? ? ? ? ? ? ? ? ? ? ? ?} >> ? ? ? ? ? ? ? ? ? ? ? ?try { >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?rootElement = xmlDoc.getRootElement(); >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?doProcess(rootElement); >> ? ? ? ? ? ? ? ? ? ? ? ?} catch (Exception e) { >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?e.printStackTrace(); >> ? ? ? ? ? ? ? ? ? ? ? ?} >> ? ? ? ? ? ? ? ?} > > > > > >> >> On 2/9/12, cliff palmer ?wrote: >>> >>> Hi Rolf >>> I will post the code later, (sorry late for a meeting) but to answer >>> your questions: >>> - this error occurs when there is an "xmlns" declaration. ?Since this >>> is the first instance of an "xmlns" declaration I've encountered with >>> JDOM and all of the URLs in the "xmlns" declaration that I have found >>> point to the same bad address, I don't know if the problem is related >>> to lookup of the URL or just the presence of an "xmlns" declaration. >>> - the problem is predictable and occurs for each xml document that >>> uses this bad URL in an "xmlns" declaration. >>> - I've used the code (I will post it, I promise) to parse over 3 >>> million xml documents, passing a string containing the xml document >>> (not a URL). ?The value I pass to saxbuilder.build is the returned >>> string from the JDBC call ResultSet.getString using a column number >>> parameter. ?I haven't been altering or converting the string returned >>> from JDBC. >>> >>> Thanks Rolf and I will post the code as soon as the suits are done with >>> me. >>> >>> Cliff >>> >>> On Thu, Feb 9, 2012 at 5:40 PM, Rolf Lear ?wrote: >>>> >>>> Hi Cliff. >>>> >>>> I think there's been some good pointers already, but just to make things >>>> crystal clear... can you perhaps post the relevant code snippet you are >>>> using to parse the document, and perhaps the first few lines of the >>>> actual >>>> XML too. >>>> >>>> Also, does this problem happen with *all* xml documents (the first one), >>>> or >>>> with just some of them? >>>> >>>> My guess is that Oliver has the right idea with parsing the wrong >>>> string.... >>>> remember that the SaxBuilder.build(String) method expects the String to >>>> be >>>> a >>>> URL, not the actual XML content..... YTour stack trace indicates you are >>>> calling this method... >>>> >>>> See the code here: >>>> >>>> https://github.com/hunterhacker/jdom/blob/jdom-1.x/core/src/java/org/jdom/input/SAXBuilder.java#L986 >>>> >>>> Anyway, seeing your code would help.... >>>> >>>> Rolf >>>> >>>> >>>> On 09/02/2012 3:54 PM, cliff palmer wrote: >>>>> >>>>> I'm reading through several hundred thousand existing XML documents >>>>> building counts of XML tags and have encountered a >>>>> Java.net.MalformedURL Exception raised by saxBuilder.build because the >>>>> xmlns points to a URL that can not be reached. >>>>> I am using JDOM 1.1.2. >>>>> Is there a call or parameter setting that will cause saxBuilder to >>>>> ignore namespaces when parsing? >>>>> Thanks! >>>>> Cliff >>>>> _______________________________________________ >>>>> To control your jdom-interest membership: >>>>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>>>> > From jdom at tuis.net Fri Feb 10 05:22:30 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 10 Feb 2012 08:22:30 -0500 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: References: <4F344B79.1050709@tuis.net> <4F345A4A.3040200@tuis.net> Message-ID: Hi Cliff. That would be a mystery, but my suspicion is that it has not worked at all... if it *did* work then there are other problems ... ;-) I suspect that everything has been failing - maybe the first record from the database had an xmlns, and it has been a red-herring for you. I did run some test code through, and it causes similar errors regardless of the actual XML content. I wonder if it would help if we put a validation process in the SAXBuilder.build(String) method that inspected the string, and if the first non-white character is '<' it throws an exception.... that should catch all instances where XML content is supplied to the method, since '<' is never valid in a URI..... and it is always the first character in any valid XML document..... getting an exception: MalformedURLException: "SAXBuilder.build(String) expects a String URI not XML Content" would be a whole lot easier to manage than the exception you have.... Rolf On Fri, 10 Feb 2012 07:35:43 -0500, cliff palmer wrote: > Rolf, that worked - it's mysterious that the version in my code > (passing the string) worked until there was a URL, but I can live with > mysteries in light of working code :). > Thanks! > Cliff > > On Thu, Feb 9, 2012 at 6:44 PM, Rolf Lear wrote: >> Hi Cliff. >> >> I think the problem is that the content of the column 'xml_contents' of >> the >> table 'xml_table' is actual XML data.... not a file name/URI. >> >> >> I think what you want to do is: >> >> ? ?String xmlcontent = rs.getString(2); >> ? ?StringReader reader = new StringReader(xmlcontent); >> ? ?xmlDoc = saxBuilder.build(reader); >> >> See http://jdom.org/docs/faq.html#a0210 >> >> Rolf >> From palmercliff at gmail.com Fri Feb 10 10:32:16 2012 From: palmercliff at gmail.com (cliff palmer) Date: Fri, 10 Feb 2012 13:32:16 -0500 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: References: <4F344B79.1050709@tuis.net> <4F345A4A.3040200@tuis.net> Message-ID: Rolf, that sounds like a great idea. Another validation process that would help when doing XML exploration (i.e you don't know what is in the data and are trying to find out) would be to throw an exception of the string is null and not use the "null pointer" exception. Thanks again for your help. Cliff On Fri, Feb 10, 2012 at 8:22 AM, Rolf Lear wrote: > > Hi Cliff. > > That would be a mystery, but my suspicion is that it has not worked at > all... if it *did* work then there are other problems ... ;-) > > I suspect that everything has been failing - maybe the first record from > the database had an xmlns, and it has been a red-herring for you. > > I did run some test code through, and it causes similar errors regardless > of the actual XML content. > > I wonder if it would help if we put a validation process in the > SAXBuilder.build(String) method that inspected the string, and if the first > non-white character is '<' it throws an exception.... that should catch all > instances where XML content is supplied to the method, since '<' is never > valid in a URI..... and it is always the first character in any valid XML > document..... > > getting an exception: ?MalformedURLException: "SAXBuilder.build(String) > expects a String URI not XML Content" would be a whole lot easier to manage > than the exception you have.... > > Rolf > > On Fri, 10 Feb 2012 07:35:43 -0500, cliff palmer > wrote: >> Rolf, that worked - it's mysterious that the version in my code >> (passing the string) worked until there was a URL, but I can live with >> mysteries in light of working code :). >> Thanks! >> Cliff >> >> On Thu, Feb 9, 2012 at 6:44 PM, Rolf Lear wrote: >>> Hi Cliff. >>> >>> I think the problem is that the content of the column 'xml_contents' of >>> the >>> table 'xml_table' is actual XML data.... not a file name/URI. >>> >>> >>> I think what you want to do is: >>> >>> ? ?String xmlcontent = rs.getString(2); >>> ? ?StringReader reader = new StringReader(xmlcontent); >>> ? ?xmlDoc = saxBuilder.build(reader); >>> >>> See http://jdom.org/docs/faq.html#a0210 >>> >>> Rolf >>> > From jdom at tuis.net Sat Feb 11 14:29:47 2012 From: jdom at tuis.net (Rolf Lear) Date: Sat, 11 Feb 2012 17:29:47 -0500 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: <71452065-7498-4D47-98CC-E1579BB8BDF8@hoplahup.net> References: <4F344B79.1050709@tuis.net> <4F345A4A.3040200@tuis.net> <71452065-7498-4D47-98CC-E1579BB8BDF8@hoplahup.net> Message-ID: <4F36EBDB.70007@tuis.net> I prefer NullPointer for null values too. In some limited places it makes sense to throw IllegalArgumentException. My 'habit' in the past (and it is recently changing...) has been to: - if I actually check for null I throw IllegalArgumentException. - do not check, and then let Java throw the NPE on de-reference. Having read some things recently in Effective Java, and also more carefully implementing core API's like the Collections API, I am now more inclined to do an explicit null check, and throw NullPointerException. I think in cases like JDOM where the code is open-source, it is less critical to validate-for-null in methods because the stack trace on NPE is easy to follow through on.... If JDOM was closed source, and people got a NPE, they would be (justifiably) peeved, especially because the stack trace would be no help for identifying the null reference. Still the question is whether every parameter should be validated before use.... in this case, since the actual null de-reference happens deep in the URI code it sort of makes sense to check... especially if we are adding a check for an invalid URI... So, in this case, I think I will do an explicit check-for-null, and throw NullPointerException... but in a general case the issue is more 'grey'. I also think, in this case, that the issue of having XML content instead of a SystemID in build(String) is common enough to do the pre-validation.... with a better error message. In general though, I think that people misusing the documented API should not expect 'hand-holding' error messages. GIGO Rolf On 11/02/2012 4:44 PM, Paul Libbrecht wrote: > I would vote for a NullPointerException with a message that says "Null URI". > But I note that I generally interpret any NullPointerException as a > place where a "." is. > And in the case discussed in this thread, this is far far deep inside. > > paul > > > Le 11 f?vr. 2012 ? 22:15, Grzegorz a ?crit : > >> Another validation process that would help when doing XML exploration >> (i.e you don't know what is in the data and are trying to find out) >> would be to throw an exception of the string is null and not use the >> "null pointer" exception. >> >> >> Why not? NullPointerException is designed to handle just that. >> >> Regards, >> Grzegorz >> _______________________________________________ >> 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 mike at saxonica.com Sat Feb 11 15:33:14 2012 From: mike at saxonica.com (Michael Kay) Date: Sat, 11 Feb 2012 23:33:14 +0000 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: <4F36EBDB.70007@tuis.net> References: <4F344B79.1050709@tuis.net> <4F345A4A.3040200@tuis.net> <71452065-7498-4D47-98CC-E1579BB8BDF8@hoplahup.net> <4F36EBDB.70007@tuis.net> Message-ID: <4F36FABA.1050805@saxonica.com> > Having read some things recently in Effective Java, and also more > carefully implementing core API's like the Collections API, I am now > more inclined to do an explicit null check, and throw > NullPointerException. I started putting @Nullable and @NotNull assertions into my code, and this got very confusing. I don't know about other tools, but IntelliJ gives you warnings if you say @NotNull and then have an "if null" test, while if you say @Nullable then the wrong information is conveyed to the user of the API. Michael Kay Saxonica From paul at hoplahup.net Sun Feb 12 05:00:02 2012 From: paul at hoplahup.net (Paul Libbrecht) Date: Sun, 12 Feb 2012 14:00:02 +0100 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: <4F36FABA.1050805@saxonica.com> References: <4F344B79.1050709@tuis.net> <4F345A4A.3040200@tuis.net> <71452065-7498-4D47-98CC-E1579BB8BDF8@hoplahup.net> <4F36EBDB.70007@tuis.net> <4F36FABA.1050805@saxonica.com> Message-ID: <565E1DD5-94C4-4175-9D1D-BD3F30D03ACC@hoplahup.net> Michael, can you display a javadoc that displays this use of @Nullable or @NotNull? A screenshot with IntelliJ would also be useful but well... I would think IntelliJ is uselessly zealous to complain about the "if null"; they're rather easy to speak to about such... I am sure it's a matter of maturity for such annotations. thanks paul Le 12 f?vr. 2012 ? 00:33, Michael Kay a ?crit : > >> Having read some things recently in Effective Java, and also more carefully implementing core API's like the Collections API, I am now more inclined to do an explicit null check, and throw NullPointerException. > I started putting @Nullable and @NotNull assertions into my code, and this got very confusing. I don't know about other tools, but IntelliJ gives you warnings if you say @NotNull and then have an "if null" test, while if you say @Nullable then the wrong information is conveyed to the user of the API. > > Michael Kay > Saxonica > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From mike at saxonica.com Sun Feb 12 07:53:54 2012 From: mike at saxonica.com (Michael Kay) Date: Sun, 12 Feb 2012 15:53:54 +0000 Subject: [jdom-interest] malformed URL exception exception in saxbuilder.build due to unreachable URL In-Reply-To: <565E1DD5-94C4-4175-9D1D-BD3F30D03ACC@hoplahup.net> References: <4F344B79.1050709@tuis.net> <4F345A4A.3040200@tuis.net> <71452065-7498-4D47-98CC-E1579BB8BDF8@hoplahup.net> <4F36EBDB.70007@tuis.net> <4F36FABA.1050805@saxonica.com> <565E1DD5-94C4-4175-9D1D-BD3F30D03ACC@hoplahup.net> Message-ID: <4F37E092.9070300@saxonica.com> On 12/02/2012 13:00, Paul Libbrecht wrote: > Michael, > > can you display a javadoc that displays this use of @Nullable or @NotNull? > Not readily because I commented out all the annotations when I realised they stopped the code being compiled under JDK 1.5, and I would have to reconfigure things quite a bit to get back to where I was. Michael Kay Saxonica From jdom at tuis.net Sun Feb 12 15:13:22 2012 From: jdom at tuis.net (Rolf Lear) Date: Sun, 12 Feb 2012 18:13:22 -0500 Subject: [jdom-interest] Serialization Message-ID: <4F384792.9010605@tuis.net> Hi all. I have only limited experience with Java serialization. My experiences in the past have always been ugly, but I have never been expert enough in it to be opinionated... I have been trying to remedy that now, though, and I have come to the conclusion that JDOM still has broken serialization. The problems I see are: 1. we rely on a hodge-podge of serialization mechanisms to implement it. 2. we mark 'Filter' and all the Filter subclasses as being serializable, why? 3. We have no control of how any sublcasses of our classes implement serialization. Fundamentally, XML is specifically designed to make serialization of information easy.... The whole purpose of JDOM is to make it easy to serialize and deserialize (and inspect and change) XML. Why are we also implementing native Java serialization? So, it is my (currently) uninformed opinion that we should strip the Serialization from JDOM entirely. If people can find convincing reasons to make JDOM serializable, it is my opinion that it should be implemented as a simple call to XMLOutputter.output(....) to convert the JDOM to a stream (and a reverse ability to parse the results....). This will satisfy any subclassing mechanisms.... Finally, if there is a convincing reason why that would be inappropriate too, then I think the right answer would be to replace the current serialization process with a redesigned and more robust one. So, I am looking for feedback.... does anyone use Java Serialization on JDOM objects? Why? Examples? Thanks Rolf From noel at peralex.com Mon Feb 13 01:05:58 2012 From: noel at peralex.com (Noel Grandin) Date: Mon, 13 Feb 2012 11:05:58 +0200 Subject: [jdom-interest] Serialization In-Reply-To: <4F384792.9010605@tuis.net> References: <4F384792.9010605@tuis.net> Message-ID: <4F38D276.60204@peralex.com> I can see serialisation of JDOM objects being useful for RPC protocols like RMI and EJB. I often find it extremely convenient being able to simply return a complex object from an application server to a client program. On 2012-02-13 01:13, Rolf Lear wrote: > Hi all. > > I have only limited experience with Java serialization. My experiences > in the past have always been ugly, but I have never been expert enough > in it to be opinionated... > > I have been trying to remedy that now, though, and I have come to the > conclusion that JDOM still has broken serialization. The problems I > see are: > > 1. we rely on a hodge-podge of serialization mechanisms to implement it. > 2. we mark 'Filter' and all the Filter subclasses as being > serializable, why? > 3. We have no control of how any sublcasses of our classes implement > serialization. > > Fundamentally, XML is specifically designed to make serialization of > information easy.... > > The whole purpose of JDOM is to make it easy to serialize and > deserialize (and inspect and change) XML. Why are we also implementing > native Java serialization? > > So, it is my (currently) uninformed opinion that we should strip the > Serialization from JDOM entirely. > > If people can find convincing reasons to make JDOM serializable, it is > my opinion that it should be implemented as a simple call to > XMLOutputter.output(....) to convert the JDOM to a stream (and a > reverse ability to parse the results....). This will satisfy any > subclassing mechanisms.... > > Finally, if there is a convincing reason why that would be > inappropriate too, then I think the right answer would be to replace > the current serialization process with a redesigned and more robust one. > > So, I am looking for feedback.... > > does anyone use Java Serialization on JDOM objects? > > Why? > > Examples? > > > > Thanks > > Rolf > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > Disclaimer: http://www.peralex.com/disclaimer.html From jdom at tuis.net Tue Feb 14 02:49:17 2012 From: jdom at tuis.net (Rolf Lear) Date: Tue, 14 Feb 2012 05:49:17 -0500 Subject: [jdom-interest] Happy Valentine's day! - JDOM2 BETA Release day too. Message-ID: <4F3A3C2D.9090500@tuis.net> HI all. Big release later... Have a great day Rolf From jdom at tuis.net Tue Feb 14 17:19:05 2012 From: jdom at tuis.net (Rolf Lear) Date: Tue, 14 Feb 2012 20:19:05 -0500 Subject: [jdom-interest] JDOM2 BETA available. Message-ID: <4F3B0809.7080604@tuis.net> Happy Valentine's (OK, it's still Valentine's day for Westerners...) JDOM2's first Beta release is available. Like the Alpha releases, this is available for download from github. https://github.com/hunterhacker/jdom/downloads Specifically, the first beta release is: https://github.com/downloads/hunterhacker/jdom/jdom-2.x-2012.02.14.19.57.zip The Github Javadoc, JUnit, and Coverage pages have all been updated to match this new BETA release: https://github.com/hunterhacker/jdom/wiki/JDOM-2.0#wiki-links Serialization is the only significant thing that has changed between this and the previous Alpha (3). Serialization changes are: 1. Namespace is now serializable 2. Numerous bugs fixed. 3. changed the 'line protocol' for serializing pretty much everything. 4. Serialized content is 'detached' when deserialized (it was not before), which makes serialization behave like clone(). I have added some new code to 'Contrib' but not 'Core'. The added 'Contrib' code is: 1. A read-only DOM 'wrapper' for JDOM allowing JDOM content to be 'exposed' as DOM. 2. An implementation to use Xalan as an XPath library by leveraging the DOM wrapper. This 'validates' the new JDOM XPath API in the sense that it is able to do either Xalan or Jaxen implementations. I don't expect the new contrib stuff to be used much, but it is available now, and it is useful for numerous things where DOM input is required. Please take this Beta for a spin, and share your experiences... good and bad. I anticipate doing a 'clean-up' beta release again on the 29th Feb (Leap Day) to fix any JavaDoc and other presentation issues (I expect the 29th release to be in maven-central too). After that I hope to be releasing the final JDOM2 at Easter. Have fun! Rolf From jdom at tuis.net Thu Feb 16 20:43:20 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 16 Feb 2012 23:43:20 -0500 Subject: [jdom-interest] Contrib Message-ID: <4F3DDAE8.6090806@tuis.net> Hi all. I want some input on the way that JDOM has previously shipped as both the 'core' and 'contrib' jars. It is my feeling that 'contrib' is a second-class citizen in the JDOM process... this is reinforced by the fact that I have paid it very little attention in the past 6 months and there are still functional elements in it which are new to me. I do not feel that I am in a position to 'support' the contrib code... if there are bugs, I am not familiar enough with the code to fix them, etc. If anyone has any ideas of how to deal with contrib I would appreciate hearing them. The options I see are: 1. keep the code as 'sample' code, but do not create a contrib jar (my preference, I think). 2. keep the code, build it, but document that the 'contrib' jar contains unsupported code. 3. move the 'valuable' contrib code in to core, 'support' that code, and 'kill' the code that is not valuable. I am interested in hearing people's ideas on this, and I am also interested in hearing from people who use the contrib jar, and what they use from that jar. Thanks Rolf From jhunter at servlets.com Thu Feb 16 21:28:12 2012 From: jhunter at servlets.com (Jason Hunter) Date: Thu, 16 Feb 2012 21:28:12 -0800 Subject: [jdom-interest] Contrib In-Reply-To: <4F3DDAE8.6090806@tuis.net> References: <4F3DDAE8.6090806@tuis.net> Message-ID: <6BE6805F-8F36-4ABC-94CC-05E7BA1B9B5A@servlets.com> The original purpose of contrib was to share the interesting work people were doing "around" JDOM in such a way that people could find it. It did not have a very high bar for entry. I lean toward #1 as well. Course, if something is genuinely valuable and fits the core JDOM model then it should move into core. -jh- On Feb 16, 2012, at 8:43 PM, Rolf Lear wrote: > Hi all. > > I want some input on the way that JDOM has previously shipped as both the 'core' and 'contrib' jars. It is my feeling that 'contrib' is a second-class citizen in the JDOM process... this is reinforced by the fact that I have paid it very little attention in the past 6 months and there are still functional elements in it which are new to me. > > I do not feel that I am in a position to 'support' the contrib code... if there are bugs, I am not familiar enough with the code to fix them, etc. > > If anyone has any ideas of how to deal with contrib I would appreciate hearing them. > > The options I see are: > 1. keep the code as 'sample' code, but do not create a contrib jar (my preference, I think). > 2. keep the code, build it, but document that the 'contrib' jar contains unsupported code. > 3. move the 'valuable' contrib code in to core, 'support' that code, and 'kill' the code that is not valuable. > > I am interested in hearing people's ideas on this, and I am also interested in hearing from people who use the contrib jar, and what they use from that jar. > > Thanks > > Rolf > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From olivier.jaquemet at jalios.com Fri Feb 17 05:30:56 2012 From: olivier.jaquemet at jalios.com (Olivier Jaquemet) Date: Fri, 17 Feb 2012 14:30:56 +0100 Subject: [jdom-interest] Contrib In-Reply-To: <6BE6805F-8F36-4ABC-94CC-05E7BA1B9B5A@servlets.com> References: <4F3DDAE8.6090806@tuis.net> <6BE6805F-8F36-4ABC-94CC-05E7BA1B9B5A@servlets.com> Message-ID: <4F3E5690.8080009@jalios.com> I am for #1 too : Building a jar of contrib incorrectly let people think it can be used as is for production, and maybe sometimes it can, but it is probably not the most common case. Just to provide a counter example if you want to explorer other approach, since the solr/lucene merge, the contribs are provided in the main distribution, as several jar, one for each individual "contrib". Due to the size of this project, it leads to a 55Mb zip distribution.... Olivier On 17/02/2012 06:28, Jason Hunter wrote: > The original purpose of contrib was to share the interesting work people were doing "around" JDOM in such a way that people could find it. It did not have a very high bar for entry. > > I lean toward #1 as well. Course, if something is genuinely valuable and fits the core JDOM model then it should move into core. > > -jh- > > On Feb 16, 2012, at 8:43 PM, Rolf Lear wrote: > >> Hi all. >> >> I want some input on the way that JDOM has previously shipped as both the 'core' and 'contrib' jars. It is my feeling that 'contrib' is a second-class citizen in the JDOM process... this is reinforced by the fact that I have paid it very little attention in the past 6 months and there are still functional elements in it which are new to me. >> >> I do not feel that I am in a position to 'support' the contrib code... if there are bugs, I am not familiar enough with the code to fix them, etc. >> >> If anyone has any ideas of how to deal with contrib I would appreciate hearing them. >> >> The options I see are: >> 1. keep the code as 'sample' code, but do not create a contrib jar (my preference, I think). >> 2. keep the code, build it, but document that the 'contrib' jar contains unsupported code. >> 3. move the 'valuable' contrib code in to core, 'support' that code, and 'kill' the code that is not valuable. >> >> I am interested in hearing people's ideas on this, and I am also interested in hearing from people who use the contrib jar, and what they use from that jar. >> >> Thanks >> >> 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 > -- Olivier Jaquemet Ing?nieur R&D Jalios S.A. - http://www.jalios.com/ @OlivierJaquemet +33970461480 From jdom at tuis.net Fri Feb 17 17:06:58 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 17 Feb 2012 20:06:58 -0500 Subject: [jdom-interest] Maven build In-Reply-To: <95d7ddad8eb3087da3ba87cb56c5a785@tuis.net> References: <95d7ddad8eb3087da3ba87cb56c5a785@tuis.net> Message-ID: <4F3EF9B2.4020503@tuis.net> Hi all. As an update, I have been 'messing around', and, I have just been getting frustrated by Maven. To my knowledge, I am unable to deploy 'snapshot' type builds to oss/sonatype nexus.... or, rather, I am unable to upload snapshot 'bundles' to their web-based interface. This means that the only way I understand it is possible to create SNAPSHOT builds is through the 'mvn deploy' command, and JDOM does not do that. As a result, I am frustrated, and I am wasting time on it. I have a 'procedure' in place that allows me to upload maven bundles to oss.sonatype.org. The procedure is partially manual, and described here: https://github.com/hunterhacker/jdom/wiki/JDOM1.1.2-and-Maven This procedure is good enough to load up 'release' builds only (it seems). This means that I cannot find a good way to test the maven part of the processes.... and I cannot trust myself to be doing 'the right thing' because I simply cannot fathom what 'the right thing' from a maven perspective is. For me the maven aspect JDOM has become 'not fun', and since I do not use maven myself, I now have low motivation for making it work. Further, any previous 'good will' I have had in considering a more 'maven like' build process is evaporating... right now (and I am somewhat peeved) I think maven sucks, and is more trouble than it is worth. So, if maven is to redeem itself to me, I think someone with a more friendly attitude toward it is going to have to smooth out the process, put together a 'just do this, this, and this...', and if it works I will keep doing it. So, if there are maven-experienced people out there... people who have deployed open-source projects to maven-central (not just used maven central as a resource), further, people who have experience with using a non-maven-like source repository like JDOM is, then please consider helping out here. Just to be clear, what I can do is: - 'release' a maven bundle what I cannot do is: - put out 'test' maven releases that are not linked to 'official' JDOM releases. - put out a new JDOM release if I somehow mess up a maven release.... so, I need to ensure that all maven releases are 100% correct. If JDOM 2.x.y is released, and the maven artifact for 2.x.y is somehow broken (bad dependency or something) then I do not want to have to release a JDOM 2.x.z to fix a maven problem. So, if someone wants to take a stab at it, please speak up. Rolf On 03/01/2012 8:22 AM, Rolf Lear wrote: > > Hi all. > > I am going to start playing with the concept of loading the 'snapshot' > builds up on to maven central as 'SNAPSHOT' type builds. This is to ensure > I get some 'practice' before the final JDOM2.0 release. > > If you are currently using maven to load your JDOM 1.x jars you should > ensure that you set your maven version dependencies correctly so that you > do not start pulling any JDOM 2.x jars. My understanding is that if I label > the versions as SNAPSHOT then they should be ignored by you, but, for > everyone's peace of mind, in your 'real' development environments you > should restrict your dependencies to version 1.1.2 only > > I expect to start 'playing' with this in the next week or so. > > Rolf > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From jdom at tuis.net Sat Feb 18 19:08:54 2012 From: jdom at tuis.net (Rolf Lear) Date: Sat, 18 Feb 2012 22:08:54 -0500 Subject: [jdom-interest] Contrib In-Reply-To: <4F3DDAE8.6090806@tuis.net> References: <4F3DDAE8.6090806@tuis.net> Message-ID: <4F4067C6.3050809@tuis.net> I have done a scan of the contrib code, and grouped things in to 4 chunks: 1. code I think should be 'supported' - moved to 'core' 2. code I think should be 'considered'. 'Considered' code I think will need a 'subject specialist' (not me) to do the 'official' migration. 3. code I think should be kept as 'sample' code only. 4. code which no longer has significant value... and should be abandoned. The way I see it happening is that the contrib jar (and org.jdom2.contrib) is going to disappear, with the code either moving to org.jdom2, moving to 'sample', or being deleted entirely. For the 'considered' code, there are things (like JavaBean mapping systems) which are subject-specialized. If there is someone using that code, or an 'expert' in the subject area, who is able to work on bringing the code to adequate 'production-ready' status (generalized, test code, etc.) then it can (likely) be moved in to core. Code to 'move' to core ====================== - Sort content in a ContentList - Issue #65 - I think this should be re-structured as Element.sortContent(Comparator). (avoid problems with existing Collections.sort() where detach() is not called). - AttAwareXMLOutputProcessor - Issue #66 - this code allows you to *not* output Attributes if they match certain rules (like they are 'fixed' or 'defaulted' values from a DTD. - TextHelper - Issue #67 - This has some 'convenience methods' for getting Text content. Some of the methods already exist in some core places (like Format.compact(), Format.trim(), etc.). - XPathHelper - Issue #68 - provides ways to create XPath query strings for existing content (think "the xpath to this Element is "/x/y/z/this") - In-memory verifier - issue #11 - contrib version uses RelaxNG, but this could be made more general. Code to Consider (subject-specialized) ================ - org.jdom2.contrib.beans - JavaBean mapping code. This code has a number of structures which are not 'general XML' type items, and this code is not likely to be considered unless it is 'motivated' somehow. - org.jdom2.contrib.dom - A 'lightweight read-only DOM wrapper for JDOM content'. I added this code recently because I used it to 'interface' with javax.xml.xpath and Xalan XPath libraries. It makes it possible to use DOM-only libraries to access JDOM content. Being that this code is new, currently has little 'testing', etc., it should be 'motivated' too. If it is considered valuable enough, then I volunteer to get it production-ready - org.jdom2.contrib.xpath Java/Xalan - test code used to validate XPath API. May be worth building in to core. Already got test cases, etc. The native Java version does not support String/Boolean/Double return values.... yet. - org.jdom2.contrib.ids - tracking 'ID' values for Elements. Allows fast lookup by ID. - has to be 'maintained' as the JDOM document is built. Sample Code =========== - ResultSetBuilder - converts an SQL ResultSet to a JDOM/XML implementation. I don't know if this is 'generalized' enough... there are standard ways of doing this thing now... not sure if it is in JDOM's Domain. - Input Scanner - filter Input SAX Events... this is mostly replaced by functionality in the StAX API. - JTreeOutputter - output of Element content to a Swing JTree. This appears incomplete... - Perf code - used as the benchmark for JDOM performance. Dead Code ========= - nothing, it seems. Rolf On 16/02/2012 11:43 PM, Rolf Lear wrote: > Hi all. > > I want some input on the way that JDOM has previously shipped as both > the 'core' and 'contrib' jars. It is my feeling that 'contrib' is a > second-class citizen in the JDOM process... this is reinforced by the > fact that I have paid it very little attention in the past 6 months and > there are still functional elements in it which are new to me. > > I do not feel that I am in a position to 'support' the contrib code... > if there are bugs, I am not familiar enough with the code to fix them, etc. > > If anyone has any ideas of how to deal with contrib I would appreciate > hearing them. > > The options I see are: > 1. keep the code as 'sample' code, but do not create a contrib jar (my > preference, I think). > 2. keep the code, build it, but document that the 'contrib' jar contains > unsupported code. > 3. move the 'valuable' contrib code in to core, 'support' that code, and > 'kill' the code that is not valuable. > > I am interested in hearing people's ideas on this, and I am also > interested in hearing from people who use the contrib jar, and what they > use from that jar. > > Thanks > > Rolf > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From jdom at tuis.net Fri Feb 24 05:57:31 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 24 Feb 2012 08:57:31 -0500 Subject: [jdom-interest] JDOM2 BETA available. In-Reply-To: <4F3B0809.7080604@tuis.net> References: <4F3B0809.7080604@tuis.net> Message-ID: Hi all. It has been somewhat quiet this past week ;-) I know that some people have downloaded the JDOM2 Beta... but, no-one has provided any feedback.... ... perhaps everything is perfect? Nothing to complain about? ... perhaps everything is so broken that there's no point in complaining? If you have played with JDOM2 it would be great if you could provide some feedback... even a simple 'works for me' would be great. Even a 'It sucks!' would be useful.... If you have not played with JDOM2 it would be great if you did ... ;-) This is the last weekend I have before I 'push' out the 'final' BETA release on the 29th. I have a few outstanding issues that I will tackle, but, in essence, JDOM2 is, in theory, mostly done. All the remaining items are around the periphery, they are 'extensions' to the core JDOM2, and they will not change what JDOM2 feels like. So, I am really hoping that if there are any concerns that I can deal with them this weekend.... and stay on schedule for the 29th. Additionally, there has been no additional feedback on JDOM 1.1.2, so, the pending fix for the SAXOutputter bug appears to be the only fix needed before pushing out JDOM 1.1.3 on the 1st of March. Since it has been requested, and since it is easy to do, I will push 1.1.3 out to maven-central together with the jdom-contrib jar. I will do it in a way that I believe will do 'the right thing', but I cannot easily test it. If someone can offer suggestions as to how to test releases on maven central I am all ears.... If you are aware of any other issues in 1.1.3, then speak up. I do not intend to release a 'contrib' jar for JDOM2. Happy JDOMing. Rolf On Tue, 14 Feb 2012 20:19:05 -0500, Rolf Lear wrote: > Happy Valentine's (OK, it's still Valentine's day for Westerners...) > > JDOM2's first Beta release is available. > .... > > Please take this Beta for a spin, and share your experiences... good and > bad. > > I anticipate doing a 'clean-up' beta release again on the 29th Feb (Leap > Day) to fix any JavaDoc and other presentation issues (I expect the 29th > release to be in maven-central too). > > After that I hope to be releasing the final JDOM2 at Easter. > > Have fun! > > Rolf From jdom at vitoni.de Sat Feb 25 16:35:37 2012 From: jdom at vitoni.de (Victor Toni) Date: Sun, 26 Feb 2012 01:35:37 +0100 Subject: [jdom-interest] JDOM2 and Runtime Exceptions In-Reply-To: <4F163CFE.4030209@tuis.net> References: <4F163CFE.4030209@tuis.net> Message-ID: 2012/1/18 Rolf Lear > Hi all. > > Recent discussions have highlighted the area of how JDOM handles some > exceptions. In particular the context was XPath expressions. JDOM specifies > (and 'always' has specified) that XPath throws JDOMException in the event > of a failure on XPath. This has been 'questioned' from the perspective that > this would not be the fault of JDOM if the XPath expression failed to > compile, or evaluate. > > Exceptions that are outside the control of the programmer, like > IOException, should be thrown and caught, but an illegal XPath is more of a > bug/programming error than an Exception, and hence should be treated more > like a NullPointerException, IllegalArgumentException, > IndexOutOfBoundsException, etc. > > Certainly it is 'ugly' to have to try/catch even the simplest XPath > expressions: > > List nodes = null; > try { > nodes = XPath.selectNodes(document, "//tag"); > } catch (JDOMException e) { > // handle it somehow > ... > } > // do something with nodes. > > This would all be much simpler if the code throws a RuntimeException > instead: > > List nodes = XPath.selectNodes(document, "//tag"); > > > > So, having used XPath as one example, I can then extrapolate the issue in > to other general areas (sticking with concepts that are 'old' - in JDOM as > well as JDOM2 - JDOM2 has additional areas of concern): > 1. SAXOutputter throws JDOMExcepion on all it's calls because it traps > SAXException from the output target: > http://jdom.org/docs/apidocs/org/jdom/output/SAXOutputter.html#output%28org.jdom.Document%29 > 2. DOMOutputter throws JDOMException to wrap ParserConfigurationException > from Java's DocumentBuilder. > 3. XSLTransform throws a subclass of JDOMException. > > Interestingly, XMLOutputter throws IOException, but not JDOMException. > > > Taking the issue to an abstract level, there are a number of places where > JDOM throws the checked exception JDOMException, and that exception > requires cumbersome handling in situations where unchecked exceptions would > (potentially) be a better choice. > > > There are a number issues at stake here though: > > 1. In JDOM the JDOMException is specified ( > http://jdom.org/docs/apidocs/org/jdom/JDOMException.html ) as being the > 'top level Exception JDOM classes can throw'. But that's already *not* > true. We have had all sorts of runtime exceptions thrown from various > classes like 'Element' which throws IlleglNameException from it's > constructor... So, should JDOMException be redefined to be JDOM-specific > problems only? > > 2. Where is the 'line'? Should SAXOutputter throw SAXException instead of > JDOMException (like XMLOutputter throws IOException not JDOMException)? > Should SAXOutputter throw some new RuntimeException instead? How could the > 'system' be described so that this inconsistency of exceptions is better > controlled? > > 3. It creates a major backward-compatibility issue to remove the 'throws > JDOMException' from methods. Existing code that does: > > try { > nodes = XPath.selectNodes(document, "//tag"); > } catch (JDOMException jde) { > // handle it somehow > ... > } > > Fails to compile with: > > [javac] > ....\src\java\org\jdom2\test\cases\xpath\AbstractTestXPath.java:595: > exception org.jdom2.JDOMException is never thrown in body of corresponding > try statement > [javac] } catch (JDOMException jde) { > [javac] ^ > [javac] 1 error > > > > > I have been playing with the code anyway, and I like the looks of the > results of replacing 'strategic' JDOMExceptions with a runtime Exception. > For example, I created a new unchecked JDOMRuntimeException class. From > this class I created two subclasses: XPathCompileException and > XPathEvaluationException. I made all the code 'work' nicely with these > exceptions and the code looks very clean. > > Backward compatibility is 'screwed' though, but somewhat mitigated by the > fact that 'old' code can be modified from: > > ... > } catch (JDOMException jde) { > ... > > > to > > ... > } catch (JDOMRuntimeException jde) { > ... > > Alternatively, depending on the actual exception handling, the try/catch > can be completely removed and handling can be cascaded up to a higher > point.... > > > Apart from renaming all the packages to org.jdom2, this would be the most > significant migration problem for any users of JDOM/JDOM2. Documenting it > as a migration issue should be relatively easy, but the fix would not be a > pure search/replace, but the exceptions would have to be identified and > fixed individually. > > Admittedly in a tool like eclipse, it is quite easy to put 'Runtime' in > your copy/paste buffer, and go from one compile problem to the next simply > looking for the 'unreachable code' problem and adding the 'Runtime' to the > middle of 'JDOMException'. > > > > Sorry for the long mail, but this is a 'feature' which could make JDOM2 > much easier to work with, but would certainly make a migration from JDOM > more complicated. > > > Would love some thoughts on this.... > > Rolf What about a JDOMXPathException as a subclass of JDOMException? The code above would still work. You could still subclass JODMException from RuntimeException fi really wanted. Personally I rather like unchecked exceptions but would love a hint from the compiler/IDE. Runtime exceptions can be quite nice but it depends very much on the use case. I had once a dependency injection framework which worked great with them, but all the checks needed to be done only once at startup and if failed to program schould startuo at all, so this was a special case... What I personally prefer is that an API, offers a special exception to deal with, in this case JDOMException. This way you can embed all the JDOM related code in one try{...}catch(JDOMException) {} block JDOMException could still use some more subclasses though. Victor -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdom at vitoni.de Sat Feb 25 16:51:43 2012 From: jdom at vitoni.de (Victor Toni) Date: Sun, 26 Feb 2012 01:51:43 +0100 Subject: [jdom-interest] JDOM2 and Runtime Exceptions In-Reply-To: <4F1893D9.5050206@xerox.com> References: <4F163CFE.4030209@tuis.net> <4F168CF7.2000706@saxonica.com> <4F18709E.3020502@xerox.com> <69c4dc0f0b038d49a45074da43984dd1@tuis.net> <4F1893D9.5050206@xerox.com> Message-ID: 2012/1/19 Leigh L Klotz Jr > Given what I decided about our usage of org.jdom.xpath packages being > isolated, the issue of exception checking isn't a big one for me, but sadly > that's because we can't much use it anyway. > > If you're interested in doing refactoring, making it easier to use a > different XPath implementation would be my suggested goal. > > > Leigh. > I would second that especially since Jaxen does not support XPath2 currently and it doesn't look like it would in the near future. Victor -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdom at tuis.net Sun Feb 26 11:06:18 2012 From: jdom at tuis.net (Rolf Lear) Date: Sun, 26 Feb 2012 14:06:18 -0500 Subject: [jdom-interest] JDOM2 and Runtime Exceptions - and XPath In-Reply-To: References: <4F163CFE.4030209@tuis.net> <4F168CF7.2000706@saxonica.com> <4F18709E.3020502@xerox.com> <69c4dc0f0b038d49a45074da43984dd1@tuis.net> <4F1893D9.5050206@xerox.com> Message-ID: <4F4A82AA.3050106@tuis.net> On 25/02/2012 7:51 PM, Victor Toni wrote: > 2012/1/19 Leigh L Klotz Jr > > > Given what I decided about our usage of org.jdom.xpath packages > being isolated, the issue of exception checking isn't a big one for > me, but sadly that's because we can't much use it anyway. > > If you're interested in doing refactoring, making it easier to use a > different XPath implementation would be my suggested goal. > > > Leigh. > > > I would second that especially since Jaxen does not support XPath2 > currently and it doesn't look like it would in the near future. > > Victor Hi all. Great to see some discussion on this. The XPath API has been completely reworked, and it is an area where I think some close 'objective' verification would be useful. In regard to the exceptions, I have currently implemented it using IllegalArgumentException, IllegalStateException, and NullPointerException. This is the same sort of handling that similar API's use (namely javax.xml.xpath.* and java.util.regex.*) On the actual XPath side of things.... The new API is described here: https://github.com/hunterhacker/jdom/wiki/JDOM2-Feature:-XPath-Upgrade In essence, the new API is now more similar to javax.xml.xpath.* than it is to the JDOM 1 XPath class. I have tried to validate the API myself, and I have done it y implementing a direct Xalan backend, as well as a more general JAXB-backend. You can see the implementations (xalan) https://github.com/hunterhacker/jdom/tree/master/contrib/src/java/org/jdom2/contrib/xpath/xalan and (java) https://github.com/hunterhacker/jdom/tree/master/contrib/src/java/org/jdom2/contrib/xpath/java With the 'java' implementation I have a broken situation where the implementation cannot determine the return-type of the XPath, and the only available returns types are String, Boolean, Double, and NodeList... and you have to know the required return typebefore running the expression. This will be very broken in XPath2.0 Most actual XPath implementations (Xalan, Jaxen, Saxon - all the ones I have inspected) have a way to handle unknown-at-run-time return types. The new JDOM2 XPath API handles that situation well.... and it is what is most useful for XPath2.0 So, what I have done is I have plugged in two additional implementations for XPath in the the JDOM2 API already (as well as the base Jaxen inplementation). The way I did that was to create a thin DOM wrapper for JDOM, and then to just convince the implementation that it is inspecting DOM (not JDOM). It would be better to use the more native mechanisms for the implementation instead of creating a DOM wrapper. For example, in Jaxen we have a Navigator. For Xalan, I started writing an Xalan 'DTM' for JDOM, but I got bogged down in some details, and I backed off because it was taking too much time. The DTM is not exactly intuitive... ;-) Also, I found it hard to tell Xalan what DTM version to use... while it appears to support any arbirary DTM, it has fixed ways to load the DTM, and I could not get around that.... I missed something, I think. For Saxon it would be nice to build a JDOM 'ObjectModel' implementation. Again, I started playing with one, but only took it as far as 'I think this will work... but the details are time-consuming' (also, I know it works because the commercial versions of Saxon already do it....). So, while the new JDOM2 API fails to fully 'wrap' the native Java XPath API, it will easily accommodate the actual implementations that are common (if the right glue is used) - Jaxen, Saxon, and Xalan. If there's anyone who's got the time to investigate how to get the 'native' model of JDOM built for any of the available XPath libraries then I will happily integrate it in to core.... right now I don't think the DOM-wrapper versions I did are suitable for core though. Rolf From jdom at tuis.net Sun Feb 26 21:40:24 2012 From: jdom at tuis.net (Rolf Lear) Date: Mon, 27 Feb 2012 00:40:24 -0500 Subject: [jdom-interest] JDOM 1.1.3 released! Message-ID: <4F4B1748.6030601@tuis.net> JDOM 1.1.3 has just been published to http://www.jdom.org/ JDOM 1.1.3 has also been pushed to maven-central, but that typically takes a few hours to process. The official download is in the standard JDOM format here: http://jdom.org/dist/binary/jdom-1.1.3.zip or: http://jdom.org/dist/binary/jdom-1.1.3.tar.gz You can get the contrib and test downloads from: http://jdom.org/dist/binary/ The code can be pulled from github using the "jdom-1.1.3" tag here: https://github.com/hunterhacker/jdom/zipball/jdom-1.1.3 This release fixes one issue - issue #60 - https://github.com/hunterhacker/jdom/issues/60 which affects people using the SAXOutputter (which is also used when doing XSL Transformations). Additionally, as requested, this release publishes the jdom-contrib jar to maven-central. This is new for JDOM, and while jdom-contrib contains useful code, it is not considered to be 'production-ready'. Please take appropriate care when using the contrib jar. This 1.1.3 release is a drop-in replacement for either JDOM 1.1.1 or 1.1.2, and all users are encouraged to use 1.1.3. JDOM 1.x is in 'maintenance mode'. Only bug-fixes will be considered for future a future 1.1.4 release. There are no known bugs in 1.1.3. If you encounter anything please notify the jdom-interest mailing list. The expectation is that 1.1.3 will be the final 1-series release, with the next release scheduled to be JDOM 2.0.0 in April. Happy coding. Rolf From jdom at tuis.net Mon Feb 27 04:29:50 2012 From: jdom at tuis.net (Rolf Lear) Date: Mon, 27 Feb 2012 07:29:50 -0500 Subject: [jdom-interest] JDOM 1.1.3 released! In-Reply-To: <4F4B1748.6030601@tuis.net> References: <4F4B1748.6030601@tuis.net> Message-ID: <6f066b653f5e5a742c9c51110a531463@tuis.net> And the maven central repository is now updated. And there are reports that it is working fine. http://search.maven.org/#artifactdetails|org.jdom|jdom|1.1.3|jar http://search.maven.org/#artifactdetails|org.jdom|jdom-contrib|1.1.3|jar Thanks all Rolf On Mon, 27 Feb 2012 00:40:24 -0500, Rolf Lear wrote: > JDOM 1.1.3 has just been published to http://www.jdom.org/ > JDOM 1.1.3 has also been pushed to maven-central, but that typically > takes a few hours to process. > From jdom at tuis.net Mon Feb 27 18:54:24 2012 From: jdom at tuis.net (Rolf Lear) Date: Mon, 27 Feb 2012 21:54:24 -0500 Subject: [jdom-interest] jdom-contrib on maven central? In-Reply-To: References: <4F3C47AC.8060305@tuis.net> Message-ID: <4F4C41E0.2020508@tuis.net> Hi again Richard, everyone. I am looking at moving the Location-aware SAX-parsing code to 'core', and I was wondering whether you (or anyone) use both the 'start' and 'end' locations, or just the 'start' location. I ask because if it is just the start location, I may consider adding support for all content, not just Element. I have tried to imagine a situation where the end-of-element location is significant, and your validation code seems like the most likely type of scenario. Is the 'end-of-element' information useful? Thanks Rolf On 16/02/2012 5:03 PM, Richard Adams wrote: > Hello Rolf, > Thanks for your prompt and full reply: > > > why are you using JDOM 1.1 and contrib 1.1.1 when you could be using > 1.1.2? 1.1 is *old* (November 2007) > > > We've found 1.1.1 rock solid so didn't see the need to update, but we > can certainly do so, there's no reason in principle. > > can you wait for 2 weeks for the scheduled release of 1.1.3 (fixes a > bug in SAXOutputter)? > > > Absolutely, this isn't urgent. > > what functionality in contrib are you using in your application... > contrib is not treated as 'carefully' as the core JDOM, and it > certainly is not as well tested. Perhaps this functionality should > be in core JDOM? > > > Just the org.jdom.contrib.input package , which we use to report line > numbers when validating documents. > > > So, as for putting the code in to maven, in theory I should now know > what I am doing.... The build script for JDOM contains a target to > do most of the work, and I can 'duplicate' it for the jdom-contrib > jar. On the flip side, I am not a regular maven user, and I did make > mistakes with the existing 1.1.2 'pom' file (it lists 'jaxen' as a > dependency, but there is no jaxen 1.1.3 artifact in maven central - > it should be an optional dependency). Unfortunately there is no way > to 'fix' maven issues unless you release a newer version. > > So, in answer to your questions: > No, we do not have plans to release contrib on maven central, but we > can if there is a good reason.... > It is an active decision because: > 1. maven central is 'new' to me, and 1.1.2 JDOM was the first > release I have done > 2. I do not believe contrib is 'production ready' code. > Certainly I do not pay it very much attention. > 3. contrib is not 'tidy' enough to package with a sources and > javadoc jar to mate with the contrib jar for the OSS requirements > > > I can volunteer to tidy up ( document? unit test? ) the contrib.input > package, if that's any help. > > > We (I) welcome any assistance you can provide, but, in this > particular case, the process of pushing things to maven is fairly > well automated, *but*, the actual maven experience we have is > somewhat limited... if you have manpower to spare I would appreciate > it if you could inspect and criticize/improve the process used to > 'push' 1.1.2 to maven... it could be flawed.... and it will be the > base for pushing all future versions to maven.... > > I'll have a look and get back to you - but I'm certainly no expert, > having gone through the process once last week! > We also use an Ant build as our 'main' build, with the maven build > being added solely to run the 'deploy' goals to put the project on their > repository as a courtesy to consumers of our library who might use a > maven build. But as our library is pretty much just used in academic > research just now, we don't have the same requirement for absolute > compatibility as you with your large user-base, so can re-release easily > if we screw things up. > > I tried to use the mvn:release plugin but ran into all sorts of > problems with tagging our code in subversion, so I ended up generating a > big jar bundle and uploading it manually, then staging and releasing > through their Nexus web-app. > > Best wishes > Richard > > I put together some notes as I went through the 1.1.2 process here: > https://github.com/hunterhacker/jdom/wiki/JDOM1.1.2-and-Maven > > It would be great if you could inspect the 1.1.2 release to see if > there are other issues, also the pom file > https://github.com/hunterhacker/jdom/blob/jdom-1.x/maven.pom and the > build.xml https://github.com/hunterhacker/jdom/blob/jdom-1.x/build.xml > > Thanks > > Ro >> >> >> _______________________________________________ >> 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 Tue Feb 28 20:56:12 2012 From: jdom at tuis.net (Rolf Lear) Date: Tue, 28 Feb 2012 23:56:12 -0500 Subject: [jdom-interest] Location-based parsing Message-ID: <4F4DAFEC.70307@tuis.net> Hi all. I have moved the 'Line-Number' based SAXParser code to core. It is not a straight move, but rather, a rewrite to be more general, and to fit in to the JDOM2 way of doing things in the SAX parsing area. A big side-effect of this move is that I have Extended the JDOMFactory interface. The changes are all 'extending' the interface, and the changes are fully compatible with JDOM 1.x ... unless you have created your own custom JDOMFactory. If you have your own factory then you will need to implement a number of new methods. If you extend the DefaultJDOMFactory (like most people will have, I imagine) then you will find that you are overriding final methods (which fails to compile), but the fix is easy... for example if you overrode the 'text(String)' method (which returns a Text instance), you will have (for example): public Text text(String text) { return new Text(text); } You will need to change this to: public Text text(int line, int col, String text) { return new Text(text); } and you will again have your full functionality. Rolf From jdom at tuis.net Wed Feb 29 05:26:30 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 29 Feb 2012 08:26:30 -0500 Subject: [jdom-interest] Location-based parsing In-Reply-To: <74917C74-A1C7-4A12-81F0-2D574495D7C7@hoplahup.net> References: <4F4DAFEC.70307@tuis.net> <74917C74-A1C7-4A12-81F0-2D574495D7C7@hoplahup.net> Message-ID: <4F4E2786.70909@tuis.net> (most) SAX parsers set a 'Location' instance for each parse. The Location instance is updated just prior to calling any SAX event on the SAX handler. The protocol is that, if the SAX Handler supports the Location system, it calls setDocumentLocator(Locator) on the handler *before* calling the startDocument() method. JDOM has 'always' listened for the Locator call because it also supplies the publicID and SystemID values. The Change I committed yesterday 'just' extends the current usage of the locator so that in each SAX event it passes on the Locator co-ordinates to the new 'location aware' methods on the JDOMFactory. There are no 'call-backs' to do this. The location information is tracked for every SAX event (every startElement, processingInstruction, etc.), including nested content. Thus, in essence, every call to the JDOMFactory contains the coordinates for the item. In addition to changing the SAXHandler and JDOMFactory to track and recieve the lcoation information, I have also included a new JDOMFactory (the LocatedJDOMFactory) which actually uses the location data when it creates special 'Located' JDOMContent (like LocatedText, LocatedCDATA, LocatedElement, etc.). Thus, if you give the SAXBuilder a 'LocatedJDOMFactory' instance, you will get a document back which consists of 'Located' Content, and you can say: Element emt = doc.getRootElement(); Located lemt = (Located)emt; System.out.printlf("Root document has a SAX location of line %d column %d\n", lemt.getLine(), lemt.getColumn); The thing to remember (and what confused me for a bit), is that the SAX specification has an odd idea of what the event 'location' is. It is defined as: "Return the column number where the current document event ends" So, if you have the root document: text then the location of the 'text' Text JDOM content will be: line 1, column 11 (the char after 'text'), and not the more 'obvious' line 1, column 7. Additionally, the location of the 'root' element is line 1, column 7. I decided that it was better for me to keep the behaviour of the 'source' system (in this case, SAX), and have a 'general' LocatedJDOMFactory, than to try to calculate actual start positions of content (which would be very challenging). What it means is that the details of 'Located' JDOM content is dependant on the system that parses the document. Additionally, the SAX specification is 'loose' about the location too, with the documentation: "The return value is an approximation of the line number in the document entity or external parsed entity where the markup triggering the event appears" Rolf On 29/02/2012 2:19 AM, Paul Libbrecht wrote: > Interesting Rolf, > > I had to use call-backs to produce the same functionality long ago. > Does it include locations inside the elements (optional I suppose)? > > paul > > > Le 29 f?vr. 2012 ? 05:56, Rolf Lear a ?crit : > >> Hi all. >> >> I have moved the 'Line-Number' based SAXParser code to core. It is not a straight move, but rather, a rewrite to be more general, and to fit in to the JDOM2 way of doing things in the SAX parsing area. >> >> A big side-effect of this move is that I have Extended the JDOMFactory interface. The changes are all 'extending' the interface, and the changes are fully compatible with JDOM 1.x ... unless you have created your own custom JDOMFactory. >> >> If you have your own factory then you will need to implement a number of new methods. If you extend the DefaultJDOMFactory (like most people will have, I imagine) then you will find that you are overriding final methods (which fails to compile), but the fix is easy... for example if you overrode the 'text(String)' method (which returns a Text instance), you will have (for example): >> >> public Text text(String text) { >> return new Text(text); >> } >> >> You will need to change this to: >> >> public Text text(int line, int col, String text) { >> return new Text(text); >> } >> >> and you will again have your full functionality. >> >> Rolf >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Wed Feb 29 20:21:01 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 29 Feb 2012 23:21:01 -0500 Subject: [jdom-interest] JDOM2 BETA 2 Released - 0.0.2 - Leap Day Message-ID: <4F4EF92D.3050205@tuis.net> Happy "Leap Day" JDOM2's second Beta release is available. Like previous releases, this is available for download from github. https://github.com/hunterhacker/jdom/downloads Specifically, the second beta release is: https://github.com/downloads/hunterhacker/jdom/jdom2-0.0.2-BETA.zip The Github Javadoc, JUnit, and Coverage pages have all been updated to match this new BETA release: https://github.com/hunterhacker/jdom/wiki/JDOM-2.0#wiki-links A few things are different this time: - I have changed the 'naming' convention - now jdom2-0.0.2-BETA. This is to satisfy maven-central. - speaking of which, I am releasing this to the 'jdom2' artifact on maven-central. Expect the jdom2 artifact to arrive in a few hours - includes 'Location-aware' SAX Parsing (concept pulled from contrib). - includes Element.sort* for sorting element Content (concept pulled from contrib). - includes XPathHelper for creating XPath queries for selecting JDOM content (concept pulled from contrib). Please take this Beta for a spin, and share your experiences... good and bad. On the original schedule this was going to be the last BETA release with final JDOM2 release at Easter. I am going to stick with the Easter release, but I expect to push out additional BETA releases between now and then. Have fun! Rolf