From jdom at tuis.net Mon Dec 5 14:47:26 2011 From: jdom at tuis.net (Rolf) Date: Mon, 05 Dec 2011 17:47:26 -0500 Subject: [jdom-interest] End-of-line sequence. In-Reply-To: <4EC1C05C.7010201@tuis.net> References: <4EC1C05C.7010201@tuis.net> Message-ID: <4EDD49FE.8060706@tuis.net> Based on the limited discussion here, it seems 'disruptive' to change the default end-of-line sequence. Instead I have implemented two mechanisms: one makes it easier to name/designate the end-of-line sequence, and another mechanism which makes it possible to change the default default-end-of-line sequence. See https://github.com/hunterhacker/jdom/wiki/JDOM2-Feature:-End-Of-Line-Termination I think this gives the best of both worlds, plus it reduces the need to supply constant values to the Format class. e.g. Format.setLineSeparator(LineSeparator.UNIX); Rolf On 14/11/2011 8:29 PM, Rolf wrote: > Hi all. > > JDOM has been merrily using "\r\n" as an end-of-line sequence in the > XMLOutputer since 'forever'. The XML Spec indicates that all end-of-line > sequences should be normalized to a single '\n': > http://www.w3.org/TR/REC-xml/#sec-line-ends The wording is such that XML > parsers should clear out any extra '\r' characters if there are any, so > it is not as if the code is completely broken. > > But, I think it makes sense to follow the spec, and avoid having > different XML compared to other systems. > > I propose changing the line separator to follow the spec, but this has a > very large impact on anyone who has expectations on JDOM having a > particular line-terminator, even though they shouldn't... > > I have filed https://github.com/hunterhacker/jdom/issues/53 > > The original decision was made by Elliotte: > http://markmail.org/message/gv7m3xjgrkomrfe7 (it's worth noting that it > was changed from the 'platform default' to the constant '\r\n' to create > some consistency too). > > vvv quote vvv > > The one open question in this version is what to use for a line > separator. Right now I'm using \r\n since that's most cross-platform > compatible and friendliest to various network protocols. However, \n > alone might be slightly friendlier to XML parsers. Another possibility > is to ask for System.getProperty("line.separator"). However, I'm loathe > to make the output platform dependent. What do people think? > > ^^^ quote ^^^ > > Also, the commit introducing this has interesting comments: > https://github.com/hunterhacker/jdom/commit/958fb22a4c7088b82f0d48a933bdf4e5c6806151#L0R173 > > > Two issues I see: > 1. "\r\n" was chosen for 'Network protocol' friendliness... is this > still a valid argument? > > 2. is it OK to change the standard format of all the XML that JDOM > produces? (I have been really careful (so far) for the most part to > ensure all whitespace (including indents and EOL/EOF is not changed) ). > > I see changing the default EOL as being an easy decision, especially > since users can still change it back easily on their Format instance. > > advantages: > 1. Most XML tools do not use "\r" values - better compatibility? > 2. XML output will be slightly smaller - ;-) > 3. XML produced by 'other' outputters (currently the StAX outputters) > can be compared directly with XMLOutputter for testing/compatibility > > disadvantages: > 1. people may have 'baselines' that contain \r\n terminators, which will > then be different from JDOM's default output. > 2. there may be some (obscure) protocols that require \r\n terminators > and users of JDOM2 will have to override the EOL to be '\r\n' for those. > > Anyone have comments/suggestions? > > Rolf > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From jhunter at servlets.com Mon Dec 5 16:18:39 2011 From: jhunter at servlets.com (Jason Hunter) Date: Mon, 5 Dec 2011 16:18:39 -0800 Subject: [jdom-interest] End-of-line sequence. In-Reply-To: <4EDD49FE.8060706@tuis.net> References: <4EC1C05C.7010201@tuis.net> <4EDD49FE.8060706@tuis.net> Message-ID: Looks great. -jh- On Dec 5, 2011, at 2:47 PM, Rolf wrote: > Based on the limited discussion here, it seems 'disruptive' to change the default end-of-line sequence. > > Instead I have implemented two mechanisms: > one makes it easier to name/designate the end-of-line sequence, and another mechanism which makes it possible to change the default default-end-of-line sequence. See https://github.com/hunterhacker/jdom/wiki/JDOM2-Feature:-End-Of-Line-Termination > > I think this gives the best of both worlds, plus it reduces the need to supply constant values to the Format class. > > e.g. > Format.setLineSeparator(LineSeparator.UNIX); > > Rolf > > On 14/11/2011 8:29 PM, Rolf wrote: >> Hi all. >> >> JDOM has been merrily using "\r\n" as an end-of-line sequence in the >> XMLOutputer since 'forever'. The XML Spec indicates that all end-of-line >> sequences should be normalized to a single '\n': >> http://www.w3.org/TR/REC-xml/#sec-line-ends The wording is such that XML >> parsers should clear out any extra '\r' characters if there are any, so >> it is not as if the code is completely broken. >> >> But, I think it makes sense to follow the spec, and avoid having >> different XML compared to other systems. >> >> I propose changing the line separator to follow the spec, but this has a >> very large impact on anyone who has expectations on JDOM having a >> particular line-terminator, even though they shouldn't... >> >> I have filed https://github.com/hunterhacker/jdom/issues/53 >> >> The original decision was made by Elliotte: >> http://markmail.org/message/gv7m3xjgrkomrfe7 (it's worth noting that it >> was changed from the 'platform default' to the constant '\r\n' to create >> some consistency too). >> >> vvv quote vvv >> >> The one open question in this version is what to use for a line >> separator. Right now I'm using \r\n since that's most cross-platform >> compatible and friendliest to various network protocols. However, \n >> alone might be slightly friendlier to XML parsers. Another possibility >> is to ask for System.getProperty("line.separator"). However, I'm loathe >> to make the output platform dependent. What do people think? >> >> ^^^ quote ^^^ >> >> Also, the commit introducing this has interesting comments: >> https://github.com/hunterhacker/jdom/commit/958fb22a4c7088b82f0d48a933bdf4e5c6806151#L0R173 >> >> >> Two issues I see: >> 1. "\r\n" was chosen for 'Network protocol' friendliness... is this >> still a valid argument? >> >> 2. is it OK to change the standard format of all the XML that JDOM >> produces? (I have been really careful (so far) for the most part to >> ensure all whitespace (including indents and EOL/EOF is not changed) ). >> >> I see changing the default EOL as being an easy decision, especially >> since users can still change it back easily on their Format instance. >> >> advantages: >> 1. Most XML tools do not use "\r" values - better compatibility? >> 2. XML output will be slightly smaller - ;-) >> 3. XML produced by 'other' outputters (currently the StAX outputters) >> can be compared directly with XMLOutputter for testing/compatibility >> >> disadvantages: >> 1. people may have 'baselines' that contain \r\n terminators, which will >> then be different from JDOM's default output. >> 2. there may be some (obscure) protocols that require \r\n terminators >> and users of JDOM2 will have to override the EOL to be '\r\n' for those. >> >> Anyone have comments/suggestions? >> >> Rolf >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Wed Dec 7 16:31:50 2011 From: jdom at tuis.net (Rolf) Date: Wed, 07 Dec 2011 19:31:50 -0500 Subject: [jdom-interest] Released Snapshot jdom-2.x-2011.12.07.09.37.zip Message-ID: <4EE00576.1000707@tuis.net> Hi all, I have released. This contains no significant new functionality, but it reduces the download size by splitting the 'development' jars from the 'runtime' jars. Additionally, FindBugs identified a potential circular construction dependency I introduced in the new JDOMConstants class. Please take it for a whirl. https://github.com/downloads/hunterhacker/jdom/jdom-2.x-2011.12.07.09.37.zip Rolf From jdom at tuis.net Wed Dec 7 17:25:47 2011 From: jdom at tuis.net (Rolf) Date: Wed, 07 Dec 2011 20:25:47 -0500 Subject: [jdom-interest] Opinion Poll: - JDOM2 and minimum-required Java - Java5 or Java6 In-Reply-To: <4EC5AC22.1070008@tuis.net> References: <4EAE005C.6020608@tuis.net> <716973aed0ca67fc72c533a66ebaf276@tuis.net> <4EC342D2.6070401@tuis.net> <4EC4AC32.4090006@tuis.net> <4EC5AC22.1070008@tuis.net> Message-ID: <4EE0121B.1080707@tuis.net> Hi all. I have 'finalized' the 'support' of Java5 in JDOM2. Unless someone can come up with a *very* compelling reason: - JDOM2 will support only Java6 and newer. - JDOM2 core functionality will run on Java5 with some limitations, documented issues, and workarounds. - issues in JDOM2 will be addressed if they are reproduced in Java6 or later - issues that affect Java5 only will also be considered, but with closer scrutiny. A fix will not be considered if it impacts functionality in later Java versions. The list of issues and workarounds with JDOM2 on Java5 will be maintained: https://github.com/hunterhacker/jdom/wiki/JDOM2:-Using-Java5 See the https://github.com/hunterhacker/jdom/wiki/JDOM2:-Dependencies-and-Supported-Versions page Rolf From jdom at tuis.net Wed Dec 14 07:08:26 2011 From: jdom at tuis.net (Rolf) Date: Wed, 14 Dec 2011 10:08:26 -0500 Subject: [jdom-interest] Class generator In-Reply-To: References: Message-ID: <4EE8BBEA.5010407@tuis.net> Hi Alexandre You seem to be stating two different requirements: 1. output data in XML according to a schema 2. 'generate Java classes for JDOM' In answer to 'outputting XML according to a schema': JDOM is not designed to (easily) build an XML document that matches an XSD schema. The best you can do is to build up an XML document in JDOM, then 'stream' it through an XSD validating parser to make sure it conforms to the schema validations. JDOM does not provide an 'easy' way to do this. On the second issue, I don't think I understand the request... you mention JAXB and XMLBeans as if you want to serialize/deserialize (any) Java classes as XML... or do you specifically want to know whether you can get JDOM to run on Java 1.2.1 ? JDOM 1.1.2 should run fine on Java 1.2.1 (although I do not actually have a Java 1.2.x environment to test in), but JDOM does not provide any special tools for serializing/deserializing any Java classes. JDOM is not like XMLBeans or JAXB. It cannot do that for you. Hope this helps (though I don't think JDOM will be very useful for either of those issues). Rolf On 14/12/2011 9:06 AM, Alexandre Santos wrote: > Hi! I'm involved in a project were I need to output data in XML > according to a XSD Schema. Is there a tool to generate Java classes for > JDom? The project uses Java 1.2.1 (yes, very old) and I can't use those > newer things like JAXB or XMLBeans... > Alex > > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From paul at hoplahup.net Wed Dec 14 07:18:45 2011 From: paul at hoplahup.net (Paul Libbrecht) Date: Wed, 14 Dec 2011 16:18:45 +0100 Subject: [jdom-interest] Class generator In-Reply-To: References: Message-ID: Are you meaning to do java objects serialization and deserialization? JDOM is not an answer for this. JDOM provides easy to use Java objects that represent XML trees but not custom java objects (though you could subclass the factory). There are 1.2-compatible things I believe such as commons-digester. paul Le 14 d?c. 2011 ? 15:06, Alexandre Santos a ?crit : > Hi! I'm involved in a project were I need to output data in XML according to a XSD Schema. Is there a tool to generate Java classes for JDom? The project uses Java 1.2.1 (yes, very old) and I can't use those newer things like JAXB or XMLBeans... > Alex > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Wed Dec 14 09:43:17 2011 From: jdom at tuis.net (Rolf) Date: Wed, 14 Dec 2011 12:43:17 -0500 Subject: [jdom-interest] Status update and request for comments Message-ID: <4EE8E035.7020606@tuis.net> Hi all. Having just come through a crazy few weeks at 'real' work, and sorting out a few other 'christmasy', and 'life' issues, I now have some significant time to throw at JDOM and to make some real progress. Now is also a good time to summarize and consolidate where things are. I am also looking for feedback and criticism of the new code. I know that there have been some people playing with the code: https://github.com/hunterhacker/jdom/downloads ... how is it working out for you? If you have not yet had a look, please check out the wiki pages: https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 The original objectives of the JDOM2 project are close to complete. To recap: Admin things: - move to github, - package rename to org.jdom2 - regression test harness - documentation Required things: - generics - varargs - co-variant return types - enums Corrective things: - XPath factory API - many bug fixes Nice things: - upgraded XPath - upgraded SAX - upgraded Filter concept - namespaces-in-scope. New things: - StAX - JDOMConstants I have tried to keep the wiki pages up to date, for details on all the major functionality 'drives' in JDOM2 please check out the JDOM2 Features page: https://github.com/hunterhacker/jdom/wiki/JDOM2-Features Because the major objectives are essentially complete I want to bring the code to an 'official' ALPHA type state. I want to 'finalize' the new API's, to start down the road of getting a final release. I want to put out the 'Alpha' release on Jan 1, 2012. Hopefully it will be a new year resolution I can keep..... JDOM 1.x spent years in 'beta', and I don't want the same thing to happen with JDOM2. Really, there's not that much that's different, so it should not be needed, but I think we have a better idea now of what's important in the JDOM API, so it is not as important to let the API 'settle' as it is 'played' with in the JDOM2 cycle. In other words, I fully expect any 'alpha' and 'beta' releases to be short, measured in weeks, not years. It will have to happen at some point, but I don't want to miss anything out in JDOM2 because JDOM3 is decades away and changing the JDOM2 API will not be an easy option after it goes in to a 'beta' cycle! This all requires participation and feedback... I need to know what's working, what needs improvement, what's missing. If you can take the code for a spin... Apply it to your existing projects. Swap out the jdom 1.x jar you are using, do a search/replace for 'org.jdom' and replace with 'org.jdom2' and tell me what breaks.... Read this page: https://github.com/hunterhacker/jdom/wiki/JDOM2--Migration-Issues I am putting together a separate mail detailing the changes I expect to be making in the next week.... and I will want some feedback on that too. Thanks Rolf From jdom at tuis.net Wed Dec 14 09:58:40 2011 From: jdom at tuis.net (Rolf) Date: Wed, 14 Dec 2011 12:58:40 -0500 Subject: [jdom-interest] Features 'in the pipeline'. Message-ID: <4EE8E3D0.5030800@tuis.net> Hi all. The following features are what I expect to be working on before an Alpha release can be made for JDOM2. The goal for the ALPHA release will be to have all API-changing functionality for JDOM2 in place. Some features may be added after the Alpha release if they simply extend rather than modify the API. The Beta release will follow the Alpha release, and the intention for the beta release will be bug-fixes only... no API changes at all. The following functionality is 'targeted' for before the Alpha release: 1. adding Format concept to all Outputters (issue 54 - https://github.com/hunterhacker/jdom/issues/54 ) The following is targeted for before the Beta release: 1. maybe in-memory-validation (issue 11 - https://github.com/hunterhacker/jdom/issues/11 ) 2. maybe HTMLOutputer (issue 10 - https://github.com/hunterhacker/jdom/issues/10 ) 3. maybe EntityResolver cache (issue 26 - https://github.com/hunterhacker/jdom/issues/26 ) These lists are pretty short.... but I know there are other issues/features that people want in JDOM2. Please speak up soon so that we can get your 'wish list' included in JDOM2. Thanks Rolf P.S. Is there anything we can do to make it easier to 'play' with JDOM2... ? From jdom at tuis.net Thu Dec 15 06:37:25 2011 From: jdom at tuis.net (Rolf) Date: Thu, 15 Dec 2011 09:37:25 -0500 Subject: [jdom-interest] Status update and request for comments In-Reply-To: <4EE9E566.8080400@jalios.com> References: <4EE8E035.7020606@tuis.net> <4EE9E566.8080400@jalios.com> Message-ID: <4EEA0625.4040309@tuis.net> Hi Olivier Thanks for the play-time and the feedback. First, the deprecated setValidation(). I think I was perhaps over-zealous to mark it deprecated.... perhaps... but I am not sure. In the new JDOM2 world I don't particularly want people using that method.... nor the 'boolean' constructor (nor for that matter using the sax-parser class-name constructor. In JDOM2 I introduced the XMLReader*Factory classs/enum. For more information on the SAX Parsing changes see the 'package' JavaDoc: http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/input/sax/package-summary.html The motivation is because it is 'naive' to only have a 'boolean' setting for XML validation.... in the 'new XML world' (since 200x) there are all sorts of ways to validate XML, and DTD is only one of them. So, JDOM2 keeps setValidation(boolean) for backward compatibility. The constructor: SAXBuilder mybuilder = new SAXBuilder(true); should be replaced with: SAXBuilder mybuilder = new SAXBuilder(XMLReaderSingletons.DTDVALIDATING); likewise, the following is 'old': mybuilder.setValidation(true); and in new JDOM2 should be: mybuilder.setXMLReaderFactory(XMLReaderSingletons.DTDVALIDATING) So, JDOM2 introduces a new 'more logical' way of setting up SAX parsing/validation. Is there any reason why you are not using the JAXP-based mechanism for loading a SAX Parser... do you really need to specify the class-name? If you do, then, in your particular case, a good 'transitional' mechanism to use would be the new SAX2-based XMLReaderSAXFactory class.... http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/input/sax/XMLReaderSAX2Factory.html XMLReaderJDOMFactory readerfac = new XMLReaderSAX2Factory(true, org.apache.xerces.parsers.SAXParser.class.getName()); SAXBuilder builder = new SAXBuilder(readerfac); or, alternately: XMLReaderJDOMFactory readerfac = new XMLReaderSAX2Factory(true, org.apache.xerces.parsers.SAXParser.class.getName()); SAXBuilder builder = new SAXBuilder(); builder.setXMLReaderFactory(readerfac); Now, the real question is whether the 'old' methods should be marked as 'deprecated', or left as 'active' and 'supported'. The 'deprecation' message in the JavaDoc is relatively comprehensive... http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/input/SAXBuilder.html#setValidation%28boolean%29 Certainly, if we mark them as deprecated then the constructors should be deprecated too.... there is no point in marking just the setValidation() method. I think my preference would be to mark the methods/constructors as deprecated, but that could make for a messy 'transition' as you have found. On the other hand, if I update the documentation, and people 'expect' to have to make the change (or live with the deprecation warning) then that may be OK too. Thoughts? For the moment I am going to leave the deprecation in, and also mark the constructors as deprecated. I think that making people aware of the new mechanisms is important, and it does not technically 'break' old-style code... just messy. Thanks for the note on the javadoc typo... will fix that. As for the note on github and 'pull' requests, etc. That's an interesting one... I also have to learn about git more before I am fully capable of managing multiple 'source' repositories. For now it is just fine to mail the list with concerns, and I can apply and 'push' the changes from my local code drop. I anyone has bigger changes to submit then we can learn that together, when it happens. So, to-do: deprecate 'boolean' SAXBuilder constructors - in favour of XMLReaderSingletons.DTDVALIDATION deprecate SAX-Driver-class-name constructors - in favour of XMLReaderSAX2Factory fix 'me' typo in Javadoc for setValidation() update the 'migration' wiki page for suppress-warnings update migration page for deprecated methods. wait for additional input on over-zealous deprecation ... ;-) Thanks! Rolf On 15/12/2011 7:17 AM, Olivier Jaquemet wrote: > Hi Rolf > > Tested with our code based : > > * all unit-tests passed. > * generics works great : > We had long anticipated the time were JDOM would support it and were > already using generics collections, with code such as : > @SuppressWarnings("unchecked"), > List elmList= elm.getChildren("foo"); > I simply had to remove the suppresswarnings everywhere and it worked > like a charm. Great job ! > > I am a little bit confused with the deprecation of method > SAXBuilder.setValidation() > Method is deprecated, but there is still a non deprecated constructor > receiving boolean validate : > This this code compile without warning: > SAXBuilder builder = new > SAXBuilder(org.apache.xerces.parsers.SAXParser.class.getName(), true); > This code generated warning : > SAXBuilder builder = new > SAXBuilder(org.apache.xerces.parsers.SAXParser.class.getName()); > builder.setValidation(true); > > Also note there is a small typo in javadoc for SAXBuilder.setValidation() : > method provides a means to *me* more specific about validation > I tried to fork the project on github to submit a pull request, but I am > not enough familiar with git yet, and unfortunately do not have time to > dig further for the moment. > > On 14/12/2011 18:43, Rolf wrote: >> Hi all. >> >> Having just come through a crazy few weeks at 'real' work, and sorting >> out a few other 'christmasy', and 'life' issues, I now have some >> significant time to throw at JDOM and to make some real progress. Now >> is also a good time to summarize and consolidate where things are. >> >> I am also looking for feedback and criticism of the new code. I know >> that there have been some people playing with the code: >> https://github.com/hunterhacker/jdom/downloads ... how is it working >> out for you? >> >> If you have not yet had a look, please check out the wiki pages: >> https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 >> >> The original objectives of the JDOM2 project are close to complete. To >> recap: >> >> Admin things: >> - move to github, >> - package rename to org.jdom2 >> - regression test harness >> - documentation >> >> Required things: >> - generics >> - varargs >> - co-variant return types >> - enums >> >> Corrective things: >> - XPath factory API >> - many bug fixes >> >> Nice things: >> - upgraded XPath >> - upgraded SAX >> - upgraded Filter concept >> - namespaces-in-scope. >> >> New things: >> - StAX >> - JDOMConstants >> >> >> I have tried to keep the wiki pages up to date, for details on all the >> major functionality 'drives' in JDOM2 please check out the JDOM2 >> Features page: https://github.com/hunterhacker/jdom/wiki/JDOM2-Features >> >> Because the major objectives are essentially complete I want to bring >> the code to an 'official' ALPHA type state. I want to 'finalize' the >> new API's, to start down the road of getting a final release. I want >> to put out the 'Alpha' release on Jan 1, 2012. Hopefully it will be a >> new year resolution I can keep..... >> >> JDOM 1.x spent years in 'beta', and I don't want the same thing to >> happen with JDOM2. Really, there's not that much that's different, so >> it should not be needed, but I think we have a better idea now of >> what's important in the JDOM API, so it is not as important to let the >> API 'settle' as it is 'played' with in the JDOM2 cycle. >> >> In other words, I fully expect any 'alpha' and 'beta' releases to be >> short, measured in weeks, not years. >> >> It will have to happen at some point, but I don't want to miss >> anything out in JDOM2 because JDOM3 is decades away and changing the >> JDOM2 API will not be an easy option after it goes in to a 'beta' cycle! >> >> This all requires participation and feedback... I need to know what's >> working, what needs improvement, what's missing. >> >> If you can take the code for a spin... Apply it to your existing >> projects. Swap out the jdom 1.x jar you are using, do a search/replace >> for 'org.jdom' and replace with 'org.jdom2' and tell me what breaks.... >> >> Read this page: >> https://github.com/hunterhacker/jdom/wiki/JDOM2--Migration-Issues >> >> I am putting together a separate mail detailing the changes I expect >> to be making in the next week.... and I will want some feedback on >> that too. >> >> Thanks >> >> Rolf >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > > -- > Olivier Jaquemet > Ing?nieur R&D Jalios S.A. -http://www.jalios.com/ > @OlivierJaquemet +33970461480 > > From jdom at tuis.net Thu Dec 15 06:42:44 2011 From: jdom at tuis.net (Rolf) Date: Thu, 15 Dec 2011 09:42:44 -0500 Subject: [jdom-interest] Status update and request for comments In-Reply-To: <4EE9E566.8080400@jalios.com> References: <4EE8E035.7020606@tuis.net> <4EE9E566.8080400@jalios.com> Message-ID: <4EEA0764.40602@tuis.net> Hi Again Olivier. I meant to ask... what Unit tests passed? The JDOM tests, or the unit tests for your application? Thanks Rolf On 15/12/2011 7:17 AM, Olivier Jaquemet wrote: > Hi Rolf > > Tested with our code based : > > * all unit-tests passed. From olivier.jaquemet at jalios.com Thu Dec 15 07:43:53 2011 From: olivier.jaquemet at jalios.com (Olivier Jaquemet) Date: Thu, 15 Dec 2011 16:43:53 +0100 Subject: [jdom-interest] Status update and request for comments In-Reply-To: <4EEA0625.4040309@tuis.net> References: <4EE8E035.7020606@tuis.net> <4EE9E566.8080400@jalios.com> <4EEA0625.4040309@tuis.net> Message-ID: <4EEA15B9.9080803@jalios.com> Thank you for the detailed rational behind validation deprecation, and alternatives. I had seen the setValidation() javadoc, but I did not spotted the package summary, my bad > Is there any reason why you are not using the JAXP-based mechanism for > loading a SAX Parser... do you really need to specify the class-name? {{ Digging in vcs history.... vcs history incomplete... failure to find proper explanation... damn developpers... myself included... }} If i recall correctly, we introduced this behavior 6 years ago to fix an incompatibility of our webapp in some app servers which were bundled with other non working parser (probabley WebSphere and its outaded libraries such as jdom beta7 and other oldies... not certain of that...). So we wanted to make sure we were using the certified xerces version we had bundled in our app and nothing else. This might not have been the best way to do deal with this issue... and a proper configuration of the appserver classloader and other properties might have been much better... but I don't remember :/ But this is the general idea : ensuring that the code runs with the certified parser. > I meant to ask... what Unit tests passed? Ours, including many related to XML manipulation using JDom (though with quite basic usage, some tricky namespace and xpath, but not anything really challenging). > Now, the real question is whether the 'old' methods should be marked > as 'deprecated', or left as 'active' and 'supported'. > [...] > Thoughts? I am definitely for the all deprecated solution, it will make a cleaner and homogenous JDOM API, and we certainly be easier to maintain on the long term. Until those API are removed in JDOM3, we can perfectly live with the deprecation warning, or migrate our code to the new XMLReaderJDOMFactory / XMLReaderSAX2Factory. As long as the documentation explains the alternative (and it does), this is perflectly fine ! Just another though regarding naming of "XMLReaderSingletons", I think I would have better understood its behavior with another name. It is an enum, so it's quite obviously a singleton and its member too. I think "XMLReaders" would be a fine name :) http://stackoverflow.com/questions/3069743/coding-conventions-naming-enums My two cents ;) Regards, And thanks again for the great work ! On 15/12/2011 15:37, Rolf wrote: > Hi Olivier > > Thanks for the play-time and the feedback. > > First, the deprecated setValidation(). I think I was perhaps > over-zealous to mark it deprecated.... perhaps... but I am not sure. > In the new JDOM2 world I don't particularly want people using that > method.... nor the 'boolean' constructor (nor for that matter using > the sax-parser class-name constructor. > > In JDOM2 I introduced the XMLReader*Factory classs/enum. For more > information on the SAX Parsing changes see the 'package' JavaDoc: > http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/input/sax/package-summary.html > > > The motivation is because it is 'naive' to only have a 'boolean' > setting for XML validation.... in the 'new XML world' (since 200x) > there are all sorts of ways to validate XML, and DTD is only one of > them. So, JDOM2 keeps setValidation(boolean) for backward compatibility. > > The constructor: > > SAXBuilder mybuilder = > new SAXBuilder(true); > > should be replaced with: > > SAXBuilder mybuilder = > new SAXBuilder(XMLReaderSingletons.DTDVALIDATING); > > likewise, the following is 'old': > > mybuilder.setValidation(true); > > and in new JDOM2 should be: > > mybuilder.setXMLReaderFactory(XMLReaderSingletons.DTDVALIDATING) > > > So, JDOM2 introduces a new 'more logical' way of setting up SAX > parsing/validation. > > Is there any reason why you are not using the JAXP-based mechanism for > loading a SAX Parser... do you really need to specify the class-name? > > If you do, then, in your particular case, a good 'transitional' > mechanism to use would be the new SAX2-based XMLReaderSAXFactory > class.... > http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/input/sax/XMLReaderSAX2Factory.html > > XMLReaderJDOMFactory readerfac = new XMLReaderSAX2Factory(true, > org.apache.xerces.parsers.SAXParser.class.getName()); > SAXBuilder builder = new SAXBuilder(readerfac); > > or, alternately: > > XMLReaderJDOMFactory readerfac = new XMLReaderSAX2Factory(true, > org.apache.xerces.parsers.SAXParser.class.getName()); > SAXBuilder builder = new SAXBuilder(); > builder.setXMLReaderFactory(readerfac); > > > Now, the real question is whether the 'old' methods should be marked > as 'deprecated', or left as 'active' and 'supported'. > > The 'deprecation' message in the JavaDoc is relatively > comprehensive... > http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/input/SAXBuilder.html#setValidation%28boolean%29 > > Certainly, if we mark them as deprecated then the constructors should > be deprecated too.... there is no point in marking just the > setValidation() method. > > I think my preference would be to mark the methods/constructors as > deprecated, but that could make for a messy 'transition' as you have > found. > > On the other hand, if I update the documentation, and people 'expect' > to have to make the change (or live with the deprecation warning) then > that may be OK too. > > Thoughts? > > For the moment I am going to leave the deprecation in, and also mark > the constructors as deprecated. I think that making people aware of > the new mechanisms is important, and it does not technically 'break' > old-style code... just messy. > > > Thanks for the note on the javadoc typo... will fix that. > > As for the note on github and 'pull' requests, etc. That's an > interesting one... I also have to learn about git more before I am > fully capable of managing multiple 'source' repositories. > > For now it is just fine to mail the list with concerns, and I can > apply and 'push' the changes from my local code drop. > > I anyone has bigger changes to submit then we can learn that together, > when it happens. > > So, to-do: > deprecate 'boolean' SAXBuilder constructors - in favour of > XMLReaderSingletons.DTDVALIDATION > deprecate SAX-Driver-class-name constructors - in favour of > XMLReaderSAX2Factory > fix 'me' typo in Javadoc for setValidation() > update the 'migration' wiki page for suppress-warnings > update migration page for deprecated methods. > wait for additional input on over-zealous deprecation ... ;-) > > Thanks! > > Rolf > > On 15/12/2011 7:17 AM, Olivier Jaquemet wrote: >> Hi Rolf >> >> Tested with our code based : >> >> * all unit-tests passed. >> * generics works great : >> We had long anticipated the time were JDOM would support it and were >> already using generics collections, with code such as : >> @SuppressWarnings("unchecked"), >> List elmList= elm.getChildren("foo"); >> I simply had to remove the suppresswarnings everywhere and it worked >> like a charm. Great job ! >> >> I am a little bit confused with the deprecation of method >> SAXBuilder.setValidation() >> Method is deprecated, but there is still a non deprecated constructor >> receiving boolean validate : >> This this code compile without warning: >> SAXBuilder builder = new >> SAXBuilder(org.apache.xerces.parsers.SAXParser.class.getName(), true); >> This code generated warning : >> SAXBuilder builder = new >> SAXBuilder(org.apache.xerces.parsers.SAXParser.class.getName()); >> builder.setValidation(true); >> >> Also note there is a small typo in javadoc for >> SAXBuilder.setValidation() : >> method provides a means to *me* more specific about validation >> I tried to fork the project on github to submit a pull request, but I am >> not enough familiar with git yet, and unfortunately do not have time to >> dig further for the moment. >> >> On 14/12/2011 18:43, Rolf wrote: >>> Hi all. >>> >>> Having just come through a crazy few weeks at 'real' work, and sorting >>> out a few other 'christmasy', and 'life' issues, I now have some >>> significant time to throw at JDOM and to make some real progress. Now >>> is also a good time to summarize and consolidate where things are. >>> >>> I am also looking for feedback and criticism of the new code. I know >>> that there have been some people playing with the code: >>> https://github.com/hunterhacker/jdom/downloads ... how is it working >>> out for you? >>> >>> If you have not yet had a look, please check out the wiki pages: >>> https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 >>> >>> The original objectives of the JDOM2 project are close to complete. To >>> recap: >>> >>> Admin things: >>> - move to github, >>> - package rename to org.jdom2 >>> - regression test harness >>> - documentation >>> >>> Required things: >>> - generics >>> - varargs >>> - co-variant return types >>> - enums >>> >>> Corrective things: >>> - XPath factory API >>> - many bug fixes >>> >>> Nice things: >>> - upgraded XPath >>> - upgraded SAX >>> - upgraded Filter concept >>> - namespaces-in-scope. >>> >>> New things: >>> - StAX >>> - JDOMConstants >>> >>> >>> I have tried to keep the wiki pages up to date, for details on all the >>> major functionality 'drives' in JDOM2 please check out the JDOM2 >>> Features page: https://github.com/hunterhacker/jdom/wiki/JDOM2-Features >>> >>> Because the major objectives are essentially complete I want to bring >>> the code to an 'official' ALPHA type state. I want to 'finalize' the >>> new API's, to start down the road of getting a final release. I want >>> to put out the 'Alpha' release on Jan 1, 2012. Hopefully it will be a >>> new year resolution I can keep..... >>> >>> JDOM 1.x spent years in 'beta', and I don't want the same thing to >>> happen with JDOM2. Really, there's not that much that's different, so >>> it should not be needed, but I think we have a better idea now of >>> what's important in the JDOM API, so it is not as important to let the >>> API 'settle' as it is 'played' with in the JDOM2 cycle. >>> >>> In other words, I fully expect any 'alpha' and 'beta' releases to be >>> short, measured in weeks, not years. >>> >>> It will have to happen at some point, but I don't want to miss >>> anything out in JDOM2 because JDOM3 is decades away and changing the >>> JDOM2 API will not be an easy option after it goes in to a 'beta' >>> cycle! >>> >>> This all requires participation and feedback... I need to know what's >>> working, what needs improvement, what's missing. >>> >>> If you can take the code for a spin... Apply it to your existing >>> projects. Swap out the jdom 1.x jar you are using, do a search/replace >>> for 'org.jdom' and replace with 'org.jdom2' and tell me what breaks.... >>> >>> Read this page: >>> https://github.com/hunterhacker/jdom/wiki/JDOM2--Migration-Issues >>> >>> I am putting together a separate mail detailing the changes I expect >>> to be making in the next week.... and I will want some feedback on >>> that too. >>> >>> Thanks >>> >>> Rolf >>> _______________________________________________ >>> To control your jdom-interest membership: >>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>> >> >> -- >> Olivier Jaquemet >> Ing?nieur R&D Jalios S.A. -http://www.jalios.com/ >> @OlivierJaquemet +33970461480 >> >> > > -- Olivier Jaquemet Ing?nieur R&D Jalios S.A. - http://www.jalios.com/ @OlivierJaquemet +33970461480 From mj-lists at expertsystems.se Fri Dec 16 04:14:24 2011 From: mj-lists at expertsystems.se (Mattias Jiderhamn) Date: Fri, 16 Dec 2011 13:14:24 +0100 Subject: [jdom-interest] Use ampersand character in setText Message-ID: <4EEB3620.40105@expertsystems.se> If you want to create invalid XML you probably don't want to try to force an XML API to help you out... ----- Original Message ----- Subject: Re: [jdom-interest] Use ampersand character in setText Date: Fri, 16 Dec 2011 12:58:56 +0100 From: Andrea Pacini > > We have necessity to write, in the final XML, the string &test and not the > string &test > How can we do ? > > 2011/12/16 Grzegorz > >> according to Jdom FAQ ( http://www.jdom.org/docs/faq.html#a0290 ) , I >>> tried to write the string >>> >>> &test >>> >>> using this statement: >>> >>> root.setText("\u0026test"); >>> >>> where \u0026 is the Unicode code for ampersand character. >>> >>> The output is: >>> >>> &test >>> >>> Where is the error ? >>> >> >> There is no error. What is wrong? It is a special character in XML and as >> such it must be escaped. >> >> Regards, >> Grzegorz >> > > _______________________________________________ To control your jdom-interest membership: http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From robin.rosenberg.lists at dewire.com Fri Dec 16 08:51:02 2011 From: robin.rosenberg.lists at dewire.com (Robin Rosenberg) Date: Fri, 16 Dec 2011 17:51:02 +0100 Subject: [jdom-interest] Use ampersand character in setText In-Reply-To: References: Message-ID: <4EEB76F6.3070108@dewire.com> Andrea Pacini skrev 2011-12-16 10.43: > Hi, > according to Jdom FAQ ( http://www.jdom.org/docs/faq.html#a0290 ) , I tried to write the string > > &test > > using this statement: > > root.setText("\u0026test"); > > where \u0026 is the Unicode code for ampersand character. > > The output is: > > &test > > Where is the error ? It's in your interpretation/the writing in the FAQ. It should be more like "Why does setText(" ") not output a NO-BREAK SPACE character into the XML document". There is no difference in Java between "&test" and "\u0026test", except that the latter is harder to read. Both translates into the exact same bytecode. The FAQ could be complemented with the corrected call, e.g. setText("\u00a0"); To make things more confusing Java uses hexadecimal code units while XML uses decimal code points. -- robin From pacionet at gmail.com Fri Dec 16 14:13:34 2011 From: pacionet at gmail.com (Andrea Pacini) Date: Fri, 16 Dec 2011 23:13:34 +0100 Subject: [jdom-interest] Use ampersand character in setText References: <4EEB76F6.3070108@dewire.com> Message-ID: I am sorry, what I was looking for is : EntityRef ref = new EntityRef("TrueNorthGuitarsTagline"); ref.setSystemID("tngTagline.xml"); that is the EntityRef. Sorry again and thanks for your help, ----- Original Message ----- From: "Robin Rosenberg" To: Sent: Friday, December 16, 2011 5:51 PM Subject: Re: [jdom-interest] Use ampersand character in setText > Andrea Pacini skrev 2011-12-16 10.43: >> Hi, >> according to Jdom FAQ ( http://www.jdom.org/docs/faq.html#a0290 ) , I >> tried to write the string >> >> &test >> >> using this statement: >> >> root.setText("\u0026test"); >> >> where \u0026 is the Unicode code for ampersand character. >> >> The output is: >> >> &test >> >> Where is the error ? > > It's in your interpretation/the writing in the FAQ. > > It should be more like "Why does setText(" ") not output a NO-BREAK > SPACE > character into the XML document". > > There is no difference in Java between "&test" and "\u0026test", except > that the > latter is harder to read. Both translates into the exact same bytecode. > > The FAQ could be complemented with the corrected call, e.g. > setText("\u00a0"); To make > things more confusing Java uses hexadecimal code units while XML uses > decimal code points. > > -- robin > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Wed Dec 21 18:26:25 2011 From: jdom at tuis.net (Rolf) Date: Wed, 21 Dec 2011 21:26:25 -0500 Subject: [jdom-interest] Class generator In-Reply-To: References: <4EE8BBEA.5010407@tuis.net> Message-ID: <4EF29551.50909@tuis.net> Hi Alexandre. Thank you for your feedback. It's nice when people respond the way you have. I have some observations, and a question.... First the questions, in an earlier mail you indicated that you are using Java 1.2.1. Do you have this running under Java 1.2.1? Are you using JDOM 1.1.2? Then the observations.... Just out of interest (and I know that the 'cars2java' example may be a massive simplification), but have you considered simply extending the JDOM classes to get what you want? You may be able to eliminate a complex 'model'. It may create other issues, but, you may come up with a simpler (and perhaps better) solution. For example, you could declare the class 'Car' to be: public class Car extends org.jdom.Element { public Car(String brandname) { super("Car"); setBrand(brandname); } public void setBrand(String brandname) { Element brand = getChild("Brand"); if (brand == null) { brand = new Element("Brand"); // add brand at the beginning of our content.... addContent(0, brand); } brand.setText(brandname); } public String getBrand() { Element brand = getChild("Brand"); if (brand == null) { return ""; } return brand.getText(); } ...... } Once you have defined 'Car' to extend the JDOM Element, you can create Car instances, and add them directly to a root element: Element cars = new Element("Cars"); Car renault = new Car("renault"); renault.setColorRGB("red", "FF0000"); cars.addContent(renault); xmlout.output(System.out, cars); Just some thoughts. Rolf On 21/12/2011 6:05 PM, Alexandre Santos wrote: > Hello Rolf, > I've been doing some experiments with a software called EditiX that can > creates Java classes from a XML file. I've used JDOM on those classes to > accomplish what I've been trying. > The description of the solution I've figured out is here: > www.alexandre-santos.com/Cars2Java.html > > > Alexandre > > From bcox at virtualschool.edu Thu Dec 22 04:09:00 2011 From: bcox at virtualschool.edu (Brad Cox) Date: Thu, 22 Dec 2011 07:09:00 -0500 Subject: [jdom-interest] Class generator In-Reply-To: References: <4EE8BBEA.5010407@tuis.net> <4EF29551.50909@tuis.net> Message-ID: Regarding "a "tool" that would create those classes automatically from a xsd file" If I understand your question correctly, that's what JAXB does. http://jaxb.java.net/ On Thu, Dec 22, 2011 at 5:21 AM, Alexandre Santos wrote: > Hello Rolf, > > I'll do my best to the JDOM community :-) > > This example was compiled with JDOM 1.1.1 and jdk 1.3.1 on a j2se 1.2 > eclipse environment, because my Ubuntu 11.10 won't execute the java 1.2.1 > binaries (only my virtual CentOS 2...). > > About your observations: my first post was about asking if there was a > "tool" that would create those classes automatically from a xsd file (or a > xml file like EditiX). In my approach, the only "hard" work is to copy the > toXML() method to each class. But in the end, you're right :-) > > Maybe a ToDo tool for JDOM :-) > > Alexandre > > > On Thu, Dec 22, 2011 at 2:26 AM, Rolf wrote: > >> Hi Alexandre. >> >> Thank you for your feedback. It's nice when people respond the way you >> have. >> >> I have some observations, and a question.... >> >> First the questions, in an earlier mail you indicated that you are using >> Java 1.2.1. Do you have this running under Java 1.2.1? Are you using JDOM >> 1.1.2? >> >> Then the observations.... >> >> Just out of interest (and I know that the 'cars2java' example may be a >> massive simplification), but have you considered simply extending the JDOM >> classes to get what you want? You may be able to eliminate a complex >> 'model'. It may create other issues, but, you may come up with a simpler >> (and perhaps better) solution. >> >> For example, you could declare the class 'Car' to be: >> >> public class Car extends org.jdom.Element { >> >> public Car(String brandname) { >> super("Car"); >> setBrand(brandname); >> } >> >> public void setBrand(String brandname) { >> Element brand = getChild("Brand"); >> if (brand == null) { >> brand = new Element("Brand"); >> // add brand at the beginning of our content.... >> addContent(0, brand); >> } >> brand.setText(brandname); >> } >> >> public String getBrand() { >> Element brand = getChild("Brand"); >> if (brand == null) { >> return ""; >> } >> return brand.getText(); >> } >> >> ...... >> >> } >> >> Once you have defined 'Car' to extend the JDOM Element, you can create >> Car instances, and add them directly to a root element: >> >> Element cars = new Element("Cars"); >> Car renault = new Car("renault"); >> renault.setColorRGB("red", "FF0000"); >> cars.addContent(renault); >> >> xmlout.output(System.out, cars); >> >> >> Just some thoughts. >> >> Rolf >> >> >> >> On 21/12/2011 6:05 PM, Alexandre Santos wrote: >> >>> Hello Rolf, >>> I've been doing some experiments with a software called EditiX that can >>> creates Java classes from a XML file. I've used JDOM on those classes to >>> accomplish what I've been trying. >>> The description of the solution I've figured out is here: >>> www.alexandre-santos.com/**Cars2Java.html >>> >>> > >>> >>> Alexandre >>> >>> >>> > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > -- Cell: 703-594-1883 Blog: http://bradjcox.blogspot.com Web: http://virtualschool.edu Manassas VA 20111 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mj-lists at expertsystems.se Thu Dec 22 05:42:55 2011 From: mj-lists at expertsystems.se (Mattias Jiderhamn) Date: Thu, 22 Dec 2011 14:42:55 +0100 Subject: [jdom-interest] Class generator Message-ID: <4EF333DF.9040006@expertsystems.se> Have you tried older (pre 1.0) versions of Castor? http://castor.codehaus.org/ ----- Original Message ----- Subject: Re: [jdom-interest] Class generator Date: Thu, 22 Dec 2011 12:31:38 +0000 From: Alexandre Santos Yes, you're 100% correct. My problem is that I'm developing a program for a 2001 server that still uses Java 1.2.1 (it's a Oracle 9.0.1 Database...) and JAXB needs Java 1.5... Yes, i know, BAD TIMES FOR ME :-) Alex On Thu, Dec 22, 2011 at 12:09 PM, Brad Cox wrote: > Regarding "a "tool" that would create those classes automatically from a > xsd file" > > If I understand your question correctly, that's what JAXB does. > http://jaxb.java.net/ > > > On Thu, Dec 22, 2011 at 5:21 AM, Alexandre Santos wrote: > >> Hello Rolf, >> >> I'll do my best to the JDOM community :-) >> >> This example was compiled with JDOM 1.1.1 and jdk 1.3.1 on a j2se 1.2 >> eclipse environment, because my Ubuntu 11.10 won't execute the java 1.2.1 >> binaries (only my virtual CentOS 2...). >> >> About your observations: my first post was about asking if there was a >> "tool" that would create those classes automatically from a xsd file (or a >> xml file like EditiX). In my approach, the only "hard" work is to copy the >> toXML() method to each class. But in the end, you're right :-) >> >> Maybe a ToDo tool for JDOM :-) >> >> Alexandre >> >> >> On Thu, Dec 22, 2011 at 2:26 AM, Rolf wrote: >> >>> Hi Alexandre. >>> >>> Thank you for your feedback. It's nice when people respond the way you >>> have. >>> >>> I have some observations, and a question.... >>> >>> First the questions, in an earlier mail you indicated that you are using >>> Java 1.2.1. Do you have this running under Java 1.2.1? Are you using JDOM >>> 1.1.2? >>> >>> Then the observations.... >>> >>> Just out of interest (and I know that the 'cars2java' example may be a >>> massive simplification), but have you considered simply extending the JDOM >>> classes to get what you want? You may be able to eliminate a complex >>> 'model'. It may create other issues, but, you may come up with a simpler >>> (and perhaps better) solution. >>> >>> For example, you could declare the class 'Car' to be: >>> >>> public class Car extends org.jdom.Element { >>> >>> public Car(String brandname) { >>> super("Car"); >>> setBrand(brandname); >>> } >>> >>> public void setBrand(String brandname) { >>> Element brand = getChild("Brand"); >>> if (brand == null) { >>> brand = new Element("Brand"); >>> // add brand at the beginning of our content.... >>> addContent(0, brand); >>> } >>> brand.setText(brandname); >>> } >>> >>> public String getBrand() { >>> Element brand = getChild("Brand"); >>> if (brand == null) { >>> return ""; >>> } >>> return brand.getText(); >>> } >>> >>> ...... >>> >>> } >>> >>> Once you have defined 'Car' to extend the JDOM Element, you can create >>> Car instances, and add them directly to a root element: >>> >>> Element cars = new Element("Cars"); >>> Car renault = new Car("renault"); >>> renault.setColorRGB("red", "FF0000"); >>> cars.addContent(renault); >>> >>> xmlout.output(System.out, cars); >>> >>> >>> Just some thoughts. >>> >>> Rolf >>> >>> >>> >>> On 21/12/2011 6:05 PM, Alexandre Santos wrote: >>> >>>> Hello Rolf, >>>> I've been doing some experiments with a software called EditiX that can >>>> creates Java classes from a XML file. I've used JDOM on those classes to >>>> accomplish what I've been trying. >>>> The description of the solution I've figured out is here: >>>> www.alexandre-santos.com/**Cars2Java.html >>>> >>>> > >>>> >>>> Alexandre >>>> >>>> >>>> >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > > > > -- > Cell: 703-594-1883 > Blog: http://bradjcox.blogspot.com > Web: http://virtualschool.edu > Manassas VA 20111 > > _______________________________________________ To control your jdom-interest membership: http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com -- /MJ