[jdom-interest] RE: JDOM in production (Corcos Igal)
BOHLE,CELIA (HP-Germany,ex2)
celia_bohle at hp.com
Thu Feb 22 23:28:52 PST 2001
Hi Igal,
I will use JDOM in production very soon. I did actually ask the same
question some months ago and many people said that there is no need to
worry. I can now say that I totally agree with that! The only thing is that
there were some code changes necessary with the different versions.
What I have done to ensure that we will not run into any problems is that I
have subscribed to this discussion group. If anything comes up, I will know
it early enough. Anyway, it is an execellent product and the programmers
take their work very seriously. Moreover, questions are really answered in
time!
Go ahead and use it!
Celia
> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]
> Sent: Friday, February 23, 2001 8:11 AM
> To: jdom-interest at jdom.org
> Subject: jdom-interest digest, Vol 1 #482 - 9 msgs
>
>
> Send jdom-interest mailing list submissions to
> jdom-interest at jdom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.denveronline.net/mailman/listinfo/jdom-interest
> or, via email, send a message with subject or body 'help' to
> jdom-interest-request at jdom.org
>
> You can reach the person managing the list at
> jdom-interest-admin at jdom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of jdom-interest digest..."
>
>
> Today's Topics:
>
> 1. Re: building a large xml file (Joseph Bowbeer)
> 2. Re: TODO.TXT: jdom.jar main method and class (Jason Hunter)
> 3. Re: Hard-Coded Newlines (Joseph Bowbeer)
> 4. Re: TODO.TXT: jdom.jar main method and class (Joseph Bowbeer)
> 5. RE: Re: TODO.TXT: jdom.jar main method and class
> (Matthew MacKenzie)
> 6. Re: Re: TODO.TXT: jdom.jar main method and class (Jason Hunter)
> 7. Re: Re: TODO.TXT: jdom.jar main method and class
> (Joseph Bowbeer)
> 8. Re: SAXBuilder questions (Jason Hunter)
> 9. Re: BUG in SAXBuilder (=?EUC-KR?B?waTDorHi?=)
>
> --__--__--
>
> Message: 1
> From: "Joseph Bowbeer" <jozart at csi.com>
> To: <jdom-interest at jdom.org>
> Cc: <wolf at cbsweb.net>
> Date: Thu, 22 Feb 2001 19:27:20 -0800
> Subject: [jdom-interest] Re: building a large xml file
>
> Another option is to use the SAX-based XMLWriter in jdom/samples
> ( Adapted from David Megginson's DataWriter @ megginson.com )
>
> http://cvs.jdom.org/cgi-bin/viewcvs.cgi/jdom/samples/sax/XMLWr
iter.java
>
>
> XMLWriter xml = new XMLWriter(writer);
> xml.startDocument();
> xml.startElement("", "RootElement", "", rootAtts);
> while (!done) {
> xml.emptyElement("Row", rowAtts);
> }
> xml.endElement("RootElement");
> xml.endDocument();
>
> You may also find the dataElement method in XMLFilterBase useful.
>
> XMLWriter gives you SAX-level control over the output. You
> will however
> also need to construct the attributes using SAX.
>
> AttributesImpl atts = new AttributesImpl();
> atts.addAttribute("", name, "", "CDATA", value);
> ...
>
>
> ---- original message -----
>
> From: "Matthew MacKenzie" <matt at xmlglobal.com>
> To: "Mirko Wolf - CBS" <wolf at cbsweb.net>
> Subject: RE: [jdom-interest] building a large xml file
> Date: Thu, 22 Feb 2001 08:04:34 -0800
>
> Mirko,
>
> Two Options:
>
> 1. Use StringBuffers and build the xml yourself as you
> process the lines,
> or
> 2. Build a org.jdom.Element for each line and output it when
> processing
> that line is complete using org.jdom.outputter.XMLOutputter.
>
>
> -----Original Message-----
> From: Mirko Wolf - CBS
> Sent: February 22, 2001 7:07 AM
> To: jdom-interest at jdom.org
> Subject: [jdom-interest] building a large xml file
>
> I've a flat file containing aprox 30000 lines with 100 fields
> each line.
> Every field refers to a xml-tag. I'm not sure, if my application can
> handle the hole data at once, so i would read a single line from the
> file, convert it and write it as part to my output xml-file. Is this
> possible?
> Are the other solutions to handle such large data?
>
>
> --__--__--
>
> Message: 2
> Date: Thu, 22 Feb 2001 19:50:00 -0800
> From: Jason Hunter <jhunter at collab.net>
> To: Steven Gould <steven.gould at cgiusa.com>
> CC: jdom-interest at jdom.org
> Subject: Re: [jdom-interest] TODO.TXT: jdom.jar main method and class
>
> Steven Gould wrote:
> >
> > After getting busy at work, I've finally got around to
> implementing some of
> > this. Before I submit it I was looking for some feedback
> and/or suggestions.
> > I propose adding a META-INF/jdom-info.xml file to the JDOM JAR,
>
> Wouldn't just "info.xml" be better? We could start a trend. :-) In
> other words, the name of the package can be in the file, not in the
> filename.
>
> > as well as an org.jdom.Main class.
>
> I'd prefer just Main, no package. This shouldn't be a public API of
> JDOM itself.
>
> > My initial jdom-info.xml file is as follows:
> >
> > >>>>>>>>>>> jdom-info.xml <<<<<<<<<<<<
> > <?xml version="1.0"?>
> > <jdom-info>
>
> I'd suggest:
>
> <info> <!-- instead of jdom-info, so this can be generic -->
> <title>JDOM</title> <!-- so we know the name of the software -->
>
> And I'd put the other tags in lower case. Not a big deal,
> but I'm used
> to all lowercase per XHTML, XSLT, etc.
>
> > <Version>1.0 Beta 6</Version>
>
> Great.
>
> > <Description>
> > JDOM is a Java-oriented object model which models
> XML documents.
> > It provides a Java-centric means of generating and
> manipulating
> > XML documents. While JDOM interoperates well with existing
> > standards such as the Simple API for XML (SAX) and
> the Document
> > Object Model (DOM), it is not an abstraction layer or
> > enhancement to those APIs. Rather, it seeks to
> provide a robust,
> > light-weight means of reading and writing XML data
> without the
> > complex and memory-consumptive options that current API
> > offerings provide.
> > </Description>
>
> Wonderful.
>
> > <!--
> > The following list of authors was initially extracted
> from @author
> > comments in the code. Apologies if anyone has been left out.
> > -->
> > <Author>
> > <Name>Brett McLaughlin</Name>
> > <E-mail>brett at jdom.org</E-mail>
> > </Author>
>
> Dandy.
>
> Other things to look at adding:
>
> <copyright>2000-2001, Jason Hunter and Brett McLaughlin</copyright>
> <license>BSD/Apache style, see LICENSE.txt</license>
> <support>See the jdom-interest mailing list at jdom.org</support>
> <web-site>http://jdom.org</web-site>
>
> -jh-
>
> --__--__--
>
> Message: 3
> From: "Joseph Bowbeer" <jozart at csi.com>
> To: <jdom-interest at jdom.org>
> Date: Thu, 22 Feb 2001 19:55:12 -0800
> Subject: [jdom-interest] Re: Hard-Coded Newlines
>
> Adding a property to XMLOutputter for controlling the
> newline(s) after the
> xml declaration should solve this.
>
> As you point out, this configuration needs to be separate
> from any element
> content formatting options, since one affects content and the
> other doesn't.
>
> By the way, I like having a newline or two by default, as in b6.
>
>
> ----- original message -----
>
> From: Jason Hunter jhunter at collab.net
> Date: Thu, 22 Feb 2001 11:07:06 -0800
>
> Lincoln.J.Carlton at WellsFargo.COM wrote:
> >
> > I am creating a string of XML from a Document using the
> > XMLOutputter class. I have set newlines false, yet see two
> > newlines in my output string, one after the declaration and
> > one at the end of the xml-string.
>
> OK, this was added between b5 and b6. [...] We can't know
> exactly how the
> whitespace outside the element structure looks, but we guess
> that you didn't
> put the root element on the first line and thus add a new line. :-)
>
>
>
>
> --__--__--
>
> Message: 4
> From: "Joseph Bowbeer" <jozart at csi.com>
> To: <jdom-interest at jdom.org>
> Date: Thu, 22 Feb 2001 20:41:48 -0800
> Subject: [jdom-interest] Re: TODO.TXT: jdom.jar main method and class
>
> I'm wondering about the idea of making jdom.jar executable.
>
> I wouldn't expect anything in my /lib/ext to be executable,
> and I'm a little
> concerned about adding a Main class to the default package in
> every JDOM
> user's classpath.
>
> Applets have a description method, and beans have BeanInfo.
> Is there not
> some standard way for packages to describe themselves?
> (Could we just add
> some extra information to the manifest?)
>
> The most standard thing I can find is package-level documentation.
>
> http://java.sun.com/j2se/javadoc/writingapispecs/index.html#package
>
> In this scheme, we'd add package.html to src/java/org/jdom
> and subdirs.
>
> Failing that, would it be preferable to put Main in *some*
> package? For
> example: org.jdom.info
>
> --
> Joe Bowbeer
>
>
>
>
> --__--__--
>
> Message: 5
> From: "Matthew MacKenzie" <matt at xmlglobal.com>
> To: <jdom-interest at jdom.org>
> Subject: RE: [jdom-interest] Re: TODO.TXT: jdom.jar main
> method and class
> Date: Thu, 22 Feb 2001 20:56:26 -0800
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_001E_01C09D11.C3488AD0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: 7bit
>
> I think it would be useful to have the Main-Class just parse the file
> referenced in argv[0] and print it back out. That way it would be
> possible to validate a file really quick without writing any code.
> Failing that, maybe there could be a release.xml file
> included in every
> release containing build metadata, and the main class could
> just print the
> contents of that file.
>
> my $0.02 CAD
>
>
> --
> Matthew MacKenzie
> VP Research & Development
> XML Global Technologies, Inc.
>
> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]On Behalf Of Joseph Bowbeer
> Sent: February 22, 2001 8:42 PM
> To: jdom-interest at jdom.org
> Subject: [jdom-interest] Re: TODO.TXT: jdom.jar main method and class
>
>
> I'm wondering about the idea of making jdom.jar executable.
>
> I wouldn't expect anything in my /lib/ext to be executable, and I'm a
> little
> concerned about adding a Main class to the default package in
> every JDOM
> user's classpath.
>
> Applets have a description method, and beans have BeanInfo.
> Is there not
> some standard way for packages to describe themselves?
> (Could we just add
> some extra information to the manifest?)
>
> The most standard thing I can find is package-level documentation.
>
> http://java.sun.com/j2se/javadoc/writingapispecs/index.html#package
>
> In this scheme, we'd add package.html to src/java/org/jdom
> and subdirs.
>
> Failing that, would it be preferable to put Main in *some*
> package? For
> example: org.jdom.info
>
> --
> Joe Bowbeer
>
>
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr at yourh
> ost.com
>
> ------=_NextPart_000_001E_01C09D11.C3488AD0
> Content-Type: application/x-pkcs7-signature;
> name="smime.p7s"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
> filename="smime.p7s"
>
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQ
> AAoIIHyTCCAy4w
> ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCz
> AJBgNVBAYTAlVT
> MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdW
> JsaWMgUHJpbWFy
> eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wOD
> A1MTIyMzU5NTla
> MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ2
> 4gVHJ1c3QgTmV0
> d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQS
> BJbmNvcnAuIEJ5
> IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMS
> BDQSBJbmRpdmlk
> dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSI
> b3DQEBAQUAA4GN
> ADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMU
> FweoFLuUgTVi3H
> COGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A
> +HthzjzMaajn9q
> JJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBA
> MCAQYwRwYDVR0g
> BEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ2
> 4uY29tL3JlcG9z
> aXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSI
> b3DQEBAgUAA4GB
> AIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8R
> d9Z7R/LSzdmkKe
> wz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIA
> D9GCDlX4KmsaiS
> xVhqwY0DPOvDzQWikK5uMIIEkzCCA/ygAwIBAgIQS4d6E5KnukqIvw6YosSoAz
> ANBgkqhkiG9w0B
> AQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcm
> lTaWduIFRydXN0
> IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS
> 9SUEEgSW5jb3Jw
> LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYX
> NzIDEgQ0EgSW5k
> aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMT
> AxMTIwMDAwMDBa
> Fw0wMjAxMTIyMzU5NTlaMIIBFzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHz
> AdBgNVBAsTFlZl
> cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb2
> 0vcmVwb3NpdG9y
> eS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFV
> BlcnNvbmEgTm90
> IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm
> 9zb2Z0IEZ1bGwg
> U2VydmljZTEaMBgGA1UEAxQRQ2hhZCBNLiBNYWNLZW56aWUxITAfBgkqhkiG9w
> 0BCQEWEm1hdHRA
> eG1sZ2xvYmFsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnv79td
> B98H+svSvXSGn0
> cusyl8C5qzEOoVlp7WfFf2TNL67lDJT2sm0mHmsXPt7Ci2w8vx89kkWpw/0yMV
> 7QbkH3RnGA7xpa
> T3jnk0p6/72h/L3H7j/0RRRoor23S+oQKd7PKCj5K/QVeU9z8IsLl6IInQNYvH
> pUJm1mUxXl6ckC
> AwEAAaOCASYwggEiMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQ
> cBCDAqMCgGCCsG
> AQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMBEGCWCGSAGG+E
> IBAQQEAwIHgDCB
> hgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNmMjA0NzAyOTI5ODc2M2M5ZDJmMj
> c1MDY5YzczNTli
> ZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdkYTVjNWUwMTQxYmVhZGIyYmQyOWU4ND
> Y0YmQ2YTgyZDAx
> MTQ5OTZhM2JkNDVmYWYzZWE0NTBjMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly
> 9jcmwudmVyaXNp
> Z24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEACJUKMySfFAumU6
> W7cQ9/QkdSUPMb
> VD99/536zw8knm8b6GKAIVo9vk3tlnCDsMPacdidQzSFETjRtTgnmQe+rvkIDM
> bvtFUBUU9JHNSX
> GJ8y37Ug1ZGccPQAtHV58n06k7qbnZyBhsRvIkHnNSCxxPWWn2J6Kn8Ha5mX0c
> 342TYxggM4MIID
> NAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFl
> ZlcmlTaWduIFRy
> dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG
> 9yeS9SUEEgSW5j
> b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIE
> NsYXNzIDEgQ0Eg
> SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQS4
> d6E5KnukqIvw6Y
> osSoAzAJBgUrDgMCGgUAoIIBrDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMB
> wGCSqGSIb3DQEJ
> BTEPFw0wMTAyMjMwNDU1MThaMCMGCSqGSIb3DQEJBDEWBBRmIk1UVT4h57UHLD
> Do9d/2RGQ28TBY
> BgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBg
> UrDgMCBzANBggq
> hkiG9w0DAgIBKDAKBggqhkiG9w0CBTAHBgUrDgMCGjCB8gYJKwYBBAGCNxAEMY
> HkMIHhMIHMMRcw
> FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3
> QgTmV0d29yazFG
> MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcn
> AuIEJ5IFJlZi4s
> TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbm
> RpdmlkdWFsIFN1
> YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBLh3oTkqe6Soi/DpiixK
> gDMA0GCSqGSIb3
> DQEBAQUABIGAkOlnDL5orcfGwlWva4JLSulsnzs9w7z+9Qn6eurf5FMQ7qHKfb
bO8W217Lp+l9wW
> hTDnZgsjX2gVeFZVWyFDt22UDRzNLyVkhRDw5ovjdA1WT0Iq4KoYbYVxL+5eyQ
Rk61ih1eYSZ2dT
> fLIXGXJd00Knf/pAQWQuURNg6p0+XLAAAAAAAAA=
>
> ------=_NextPart_000_001E_01C09D11.C3488AD0--
>
>
> --__--__--
>
> Message: 6
> Date: Thu, 22 Feb 2001 21:08:18 -0800
> From: Jason Hunter <jhunter at collab.net>
> To: Joseph Bowbeer <jozart at csi.com>
> CC: jdom-interest at jdom.org
> Subject: Re: [jdom-interest] Re: TODO.TXT: jdom.jar main
> method and class
>
> > I'm wondering about the idea of making jdom.jar executable.
> >
> > I wouldn't expect anything in my /lib/ext to be executable,
> and I'm a little
> > concerned about adding a Main class to the default package
> in every JDOM
> > user's classpath.
>
> It's common for JAR files these days to be executable. For
> example, you
> start the Orion app server by executing its JAR. In the manifest you
> can point at a class to execute. For this scheme we'll have a little
> Main class that uses the JDOM classes to read and display its info.xml
> information. Most packages would just leave info.xml static
> for manual
> reading, but we can have our easter egg. :-)
>
> > Failing that, would it be preferable to put Main in *some*
> package? For
> > example: org.jdom.info
>
> That would make it part of JDOM itself. If it's not in org.jdom it's
> ancillary. In other words, when we write the JDOM spec, this won't be
> in there.
>
> -jh-
>
> --__--__--
>
> Message: 7
> From: "Joseph Bowbeer" <jozart at csi.com>
> To: "Jason Hunter" <jhunter at collab.net>
> Cc: <jdom-interest at jdom.org>
> Subject: Re: [jdom-interest] Re: TODO.TXT: jdom.jar main
> method and class
> Date: Thu, 22 Feb 2001 21:20:42 -0800
>
> I'm familiar with executable .jar files, but JDOM is not a
> server, and I
> don't know of any pure libraries that are executable.
>
> I'm concerned about adding anything to the default package. (What if
> everyone did that?)
>
>
> ----- Original Message -----
> From: "Jason Hunter" <jhunter at collab.net>
> To: "Joseph Bowbeer" <jozart at csi.com>
> Cc: <jdom-interest at jdom.org>
> Sent: Thursday, February 22, 2001 9:08 PM
> Subject: Re: [jdom-interest] Re: TODO.TXT: jdom.jar main
> method and class
>
> > I'm wondering about the idea of making jdom.jar executable.
> >
> > I wouldn't expect anything in my /lib/ext to be executable,
> and I'm a
> little
> > concerned about adding a Main class to the default package
> in every JDOM
> > user's classpath.
>
> It's common for JAR files these days to be executable. For
> example, you
> start the Orion app server by executing its JAR. In the manifest you
> can point at a class to execute. For this scheme we'll have a little
> Main class that uses the JDOM classes to read and display its info.xml
> information. Most packages would just leave info.xml static
> for manual
> reading, but we can have our easter egg. :-)
>
> > Failing that, would it be preferable to put Main in *some*
> package? For
> > example: org.jdom.info
>
> That would make it part of JDOM itself. If it's not in org.jdom it's
> ancillary. In other words, when we write the JDOM spec, this won't be
> in there.
>
> -jh-
>
>
>
>
> --__--__--
>
> Message: 8
> Date: Thu, 22 Feb 2001 22:25:09 -0800
> From: Jason Hunter <jhunter at collab.net>
> To: "Rosen, Alex" <arosen at silverstream.com>
> CC: jdom-interest at jdom.org
> Subject: Re: [jdom-interest] SAXBuilder questions
>
> "Rosen, Alex" wrote:
> >
> > (1) Wouldn't it be nice if there were a version of
> SAXBuilder that took an
> > already-created XMLReader? Currently there doesn't seem to
> be a way that I can
> > turn on arbitrary SAX features that aren't supported by the
> SAXBuilder API. I'd
> > like to create an XMLReader myself, set it up however I'd
> like, and give it to
> > SAXBuilder.
>
> The reason we've elected not to do that is that many features of the
> XMLReader need to be set a certain way for SAXBuilder to function. If
> you passed in an XMLReader we'd have to either take on faith that the
> features were set properly (not a good solution, as our feature
> selection may change over time without changing the API) or set the
> features to guarantee proper functioning (not good either, as
> it changes
> the passed-in parameter as a side effect).
>
> > (2) Looking at the new JAXP support in SAXBuilder, I think
> it should use
> > ClassLoader.loadClass() instead of Class.forName(). That
> gives it a better
> > chance of finding the JAXP classes if they're loaded via a
> ClassLoader, rather
> > than via the system classpath.
>
> Great idea. Will do.
>
> -jh-
>
> --__--__--
>
> Message: 9
> Date: Fri, 23 Feb 2001 15:26:04 +0900 (KST)
> From: =?EUC-KR?B?waTDorHi?= <newchang at dreamwiz.com>
> To: jdom-interest at jdom.org
> Organization:
> Subject: [jdom-interest] Re: BUG in SAXBuilder
>
> --0-964404149-982909564=:86780
> Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
>
> I noticed that the 'file' stream as an argument of builder.build(file)
> in the 'FileReader' block was used in the previous 'BufferedReader'
> block.
>
> So I put the some codes into the 'FileReader' block to check that
> the 'file' stream is still opened.
>
> try {
> // build and output with FileReader cast to Reader
> System.out.println("\n\n******************\nbuild and
> output with FileReader cast to Reader. Ready? (hit 'Enter')");
> System.in.read();System.in.read();
>
> // added codes
> int ch;
> while((ch = file.read()) != -1) {
> System.out.print((char)ch);
> }
>
> doc = builder.build((java.io.Reader)file);
> fmt.output(doc, System.out);
> } catch (Exception e) {
> e.printStackTrace();
> }
>
> The execution of the above program issued an error like this.
>
> java.io.IOException: Stream closed
> at java.io.InputStreamReader.ensureOpen(Unknown Source)
> at java.io.InputStreamReader.read(Unknown Source)
> at java.io.InputStreamReader.read(Unknown Source)
> at RequestParser2.main(RequestParser2.java:77)
>
> From the situation I can guess that the stream used by SAXBuilder
> is closed when the parsing is completed.
>
> If that's right, what closes the stream? SAXBuilder, or Xerces-J?
> Though I tried to find an answer, I couldn't.
>
> Chang-Ki Jeong
> newchang at dreamwiz.com
>
>
>
> -------------------------------------------------
> DreamWiz Free Mail @ http://www.dreamwiz.com/
> DreamSearch Click the world!!! http://search.dreamwiz.com/
>
>
> --0-964404149-982909564=:86780
> Content-Type: TEXT/HTML; CHARSET=US-ASCII
>
> <HTML>
> <BODY>
>
> <BR>I noticed that the 'file' stream as an argument of
> builder.build(file)
> <BR>in the 'FileReader' block was used in the previous
> 'BufferedReader'
> <BR>block.
> <BR>
> <BR>So I put the some codes into the 'FileReader' block to check that
> <BR>the 'file' stream is still opened.
> <BR>
> <BR> try {
> <BR> // build and output with
> FileReader cast to Reader
> <BR> System.out.println("\n\n**********
> ********\nbuild and output with FileReader cast to Reader.
> Ready? (hit 'Enter')");
> <BR> System.in.read();System.in.read();
> <BR>
> <BR> // added codes
> <BR> int ch;
> <BR> while((ch = file.read()) != -1) {
> <BR> System.out.print((char)ch);
> <BR> }
> <BR>
> <BR> doc = builder.build((java.io.Reader)file);
> <BR> fmt.output(doc, System.out);
> <BR> } catch (Exception e) {
> <BR> e.printStackTrace();
> <BR> }
> <BR>
> <BR>The execution of the above program issued an error like this.
> <BR>
> <BR> java.io.IOException: Stream closed
> <BR> at
> java.io.InputStreamReader.ensureOpen(Unknown Source)
> <BR> at
> java.io.InputStreamReader.read(Unknown Source)
> <BR> at
> java.io.InputStreamReader.read(Unknown Source)
> <BR> at
> RequestParser2.main(RequestParser2.java:77)
> <BR>
> <BR>From the situation I can guess that the stream used by SAXBuilder
> <BR>is closed when the parsing is completed.
> <BR>
> <BR>If that's right, what closes the stream? SAXBuilder, or Xerces-J?
> <BR>Though I tried to find an answer, I couldn't.
> <BR>
> <BR>Chang-Ki Jeong
> <BR>newchang at dreamwiz.com
> <BR>
> <BR></BODY>
> </HTML>
>
> <BR>
>
> <BR>
> <BR>
>
> <BR>
> <a HREF="http://www.dreamwiz.com/" TARGET=_blank><img
> SRC="http://mail.dreamwiz.com/newchang/cgi-bin/receive_check.c
> gi?mailbox=Sent&uid=00000000000000000052,X00000&key=acdc34c892
314fe1e56461fedf607f2a" BORDER="0"></a> <FONT SIZE=2><B>Your life on the >
net</FONT></B><br>
> -------------------------------------------------<br>
> DreamWiz Free Mail @ <a href="http://www.dreamwiz.com/"
> TARGET=_blank>http://www.dreamwiz.com/</a><br>
> DreamSearch Click the world!!! <a
> href="http://search.dreamwiz.com/"
> TARGET=_blank>http://search.dreamwiz.com/</a><br>
>
>
> --0-964404149-982909564=:86780--
>
>
> --__--__--
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr at yourhost.com
End of jdom-interest Digest
More information about the jdom-interest
mailing list