>Easiest is to do a "cvs diff -du" or if you still have the originals and
>don't have CVS you can do just "diff -u".
>
>> I notice we aren't currently doing any sanity checks on system or
>> public IDs. This should probably be added to the Verifier class, and
>> rolled into both DocType and EntityRef. I haven't looked at EntityRef
>> yet but I bet it's got a lot of the same issues with public and
>> system IDs as DocType.
>
>Sounds good.
>
>-jh-
Here's the diffs for the changes. They don't seem to break anything
that wasn't broken before. Mostly this adds verification of the
system and public IDs in both DocType and EntityRef, the root element
name in DocType, and the entity name in EntityRef. Failing these
causes the throwing of various runtime exceptions
(IllegalDataException and IllegalNameexception) so this shouldn't
break anybody's code.
It also allows null to be used for either system or public IDs in
DocType to differentiate a missing ID from the empty string. This
necessitated some small changes in some input and output classes.
I added one new Constructor to EntityRef to allow it to have a system
ID without a public ID.
I also added a setElementName() method in DocType.
I added checkSystemLiteral() and checkPublicID() methods in Verifier.
I made checkXMLName() in Verifier public so EntityRef and DocType
could use it. (They do allow colons in their names which
checkElementName() forbids.) I don't think this will cause a problem,
but if it does it could be package private.
Finally I fixed a few small errors I noticed in the doc comments here
and there.
? build
Index: src/java/org/jdom/DocType.java
===================================================================
RCS file: /home/cvspublic/jdom/src/java/org/jdom/DocType.java,v
retrieving revision 1.17
diff -d -u -r1.17 DocType.java
--- src/java/org/jdom/DocType.java 2002/01/08 09:17:10 1.17
+++ src/java/org/jdom/DocType.java 2002/02/03 11:03:43
@@ -113,11 +113,15 @@
* referenced DTD
* @param systemID String system ID of
* referenced DTD
+ * @throws IllegalDataException if the given system ID is not a legal
+ * system literal or the public ID is not a legal public ID.
+ * @throws IllegalNameException if the given root element name
is not a legal
+ * XML element name.
*/
public DocType(String elementName, String publicID, String systemID) {
- this.elementName = elementName;
- this.publicID = publicID;
- this.systemID = systemID;
+ setElementName(elementName);
+ setPublicID(publicID);
+ setSystemID(systemID);
}
/**
@@ -131,9 +135,13 @@
* element being constrained.
* @param systemID String system ID of
* referenced DTD
+ * @throws IllegalDataException if the given system ID is not a legal
+ * system literal.
+ * @throws IllegalNameException if the given root element name
is not a legal
+ * XML element name.
*/
public DocType(String elementName, String systemID) {
- this(elementName, "", systemID);
+ this(elementName, null, systemID);
}
/**
@@ -144,9 +152,11 @@
*
* @param elementName String name of
* element being constrained.
+ * @throws IllegalNameException if the given root element name
is not a legal
+ * XML element name.
*/
public DocType(String elementName) {
- this(elementName, "", "");
+ this(elementName, null, null);
}
/**
@@ -163,6 +173,29 @@
/**
*
+ * This will set the root element name declared by this
+ * DOCTYPE declaration.
+ *
+ *
+ * @return DocType DocType this DocType object
+ * @param elementName String name of
+ * root element being constrained.
+ * @throws IllegalNameException if the given root element name
is not a legal
+ * XML element name.
+ */
+ public DocType setElementName(String elementName) {
+ // This can contain a colon so we use checkXMLName()
+ // instead of checkElementName()
+ String reason = Verifier.checkXMLName(elementName);
+ if (reason != null) {
+ throw new IllegalNameException(elementName, "DocType", reason);
+ }
+ this.elementName = elementName;
+ return this;
+ }
+
+ /**
+ *
* This will retrieve the public ID of an externally
* referenced DTD, or an empty String if
* none is referenced.
@@ -180,12 +213,17 @@
* referenced DTD.
*
*
- * @return publicID String public ID of
- * referenced DTD.
+ * @return DocType DocType this DocType object
+ * @throws IllegalDataException if the given public ID is not a legal
+ * public ID.
*/
public DocType setPublicID(String publicID) {
+ String reason = Verifier.checkPublicID(publicID);
+ if (reason != null) {
+ throw new IllegalDataException(publicID, "DocType", reason);
+ }
this.publicID = publicID;
-
+
return this;
}
@@ -210,8 +248,14 @@
*
* @return systemID String system ID of
* referenced DTD.
+ * @throws IllegalDataException if the given system ID is not a legal
+ * system literal.
*/
public DocType setSystemID(String systemID) {
+ String reason = Verifier.checkSystemLiteral(systemID);
+ if (reason != null) {
+ throw new IllegalDataException(systemID, "DocType", reason);
+ }
this.systemID = systemID;
return this;
@@ -235,7 +279,7 @@
* This sets the {@link Document} holding this doctype.
*
*
- * @param document Document holding this doctype
+ * @param DocType Document holding this doctype
* @return Document this DocType modified
*/
protected DocType setDocument(Document document) {
Index: src/java/org/jdom/Element.java
===================================================================
RCS file: /home/cvspublic/jdom/src/java/org/jdom/Element.java,v
retrieving revision 1.106
diff -d -u -r1.106 Element.java
--- src/java/org/jdom/Element.java 2002/01/25 18:42:52 1.106
+++ src/java/org/jdom/Element.java 2002/02/03 11:03:43
@@ -215,7 +215,9 @@
* Element name.
*/
public Element setName(String name) {
- String reason = Verifier.checkElementName(name);
+ // Use checkXMLName() instead of checkElementName() here
+ // because we do need to allow this to contain a colon
+ String reason = Verifier.checkXMLName(name);
if (reason != null) {
throw new IllegalNameException(name, "element", reason);
}
Index: src/java/org/jdom/EntityRef.java
===================================================================
RCS file: /home/cvspublic/jdom/src/java/org/jdom/EntityRef.java,v
retrieving revision 1.5
diff -d -u -r1.5 EntityRef.java
--- src/java/org/jdom/EntityRef.java 2002/01/08 09:17:10 1.5
+++ src/java/org/jdom/EntityRef.java 2002/02/03 11:03:43
@@ -59,7 +59,7 @@
import java.io.Serializable;
/**
- * EntityRef Defines an XML entity in Java.
+ * EntityRef Defines an XML entity reference in Java.
*
* @author Brett McLaughlin
* @author Jason Hunter
@@ -101,24 +101,47 @@
*
*
* @param name String name of element.
+ * @throws IllegalNameException if the given name is not a legal
+ * XML name.
*/
public EntityRef(String name) {
- this.name = name;
+ this(name, null, null);
}
/**
*
* This will create a new EntityRef
+ * with the supplied name and system id.
+ *
+ *
+ * @param name String name of element.
+ * @throws IllegalNameException if the given name is not a legal
+ * XML name.
+ * @throws IllegalDataException if the given system ID is not a legal
+ * system literal.
+ */
+ public EntityRef(String name, String systemID) {
+ this(name, null, systemID);
+ }
+
+ /**
+ *
+ * This will create a new EntityRef
* with the supplied name, public id, and system id.
*
*
* @param name String name of element.
+ * @throws IllegalDataException if the given system ID is not a legal
+ * system literal or the the given public ID is not a
+ * legal public ID
+ * @throws IllegalNameException if the given name is not a legal
+ * XML name.
*/
public EntityRef(String name, String publicID, String systemID) {
- this.name = name;
- this.publicID = publicID;
- this.systemID = systemID;
+ setName(name);
+ setPublicID(publicID);
+ setSystemID(systemID);
}
/**
@@ -232,7 +255,7 @@
*
* @return public ID of this EntityRef
*/
- public java.lang.String getPublicID() {
+ public String getPublicID() {
return publicID;
}
@@ -244,7 +267,7 @@
*
* @return system ID of this EntityRef
*/
- public java.lang.String getSystemID() {
+ public String getSystemID() {
return systemID;
}
@@ -279,8 +302,16 @@
*
* @param name new name of the entity
* @return this EntityRef modified.
+ * @throws IllegalNameException if the given name is not a legal
+ * XML name.
*/
public EntityRef setName(String name) {
+ // This can contain a colon so we use checkXMLName()
+ // instead of checkElementName()
+ String reason = Verifier.checkXMLName(name);
+ if (reason != null) {
+ throw new IllegalNameException(name, "EntityRef", reason);
+ }
this.name = name;
return this;
}
@@ -292,8 +323,14 @@
*
* @param newPublicID new public id
* @return this EntityRef modified.
+ * @throws IllegalDataException if the given public ID is not a legal
+ * public ID.
*/
public EntityRef setPublicID(String newPublicID) {
+ String reason = Verifier.checkPublicID(publicID);
+ if (reason != null) {
+ throw new IllegalDataException(publicID, "EntityRef", reason);
+ }
this.publicID = newPublicID;
return this;
}
@@ -304,9 +341,15 @@
*
*
* @param newSystemID new system id
+ * @throws IllegalDataException if the given system ID is not a legal
+ * system literal.
* @return this EntityRef modified.
*/
public EntityRef setSystemID(String newSystemID) {
+ String reason = Verifier.checkSystemLiteral(systemID);
+ if (reason != null) {
+ throw new IllegalDataException(systemID, "EntityRef", reason);
+ }
this.systemID = newSystemID;
return this;
}
Index: src/java/org/jdom/Verifier.java
===================================================================
RCS file: /home/cvspublic/jdom/src/java/org/jdom/Verifier.java,v
retrieving revision 1.27
diff -d -u -r1.27 Verifier.java
--- src/java/org/jdom/Verifier.java 2002/01/25 18:42:52 1.27
+++ src/java/org/jdom/Verifier.java 2002/02/03 11:03:44
@@ -485,7 +485,7 @@
*
* @param data String data to check.
* @return String - reason data is invalid, or
- * null is name is OK.
+ * null if data is OK.
*/
public static final String checkCommentData(String data) {
String reason = null;
@@ -500,7 +500,85 @@
// If we got here, everything is OK
return null;
}
+
+ // [13] PubidChar ::= #x20 | #xD | #xA | [a-zA-Z0-9] |
[-'()+,./:=?;*#@$_%]
+ private static boolean isXMLPublicIDCharacter(char c) {
+
+ if (c >= 'a' && c <= 'z') return true;
+ if (c >= '?' && c <= 'Z') return true;
+ if (c >= '\'' && c <= ';') return true;
+
+ if (c == ' ') return true;
+ if (c == '!') return true;
+ if (c == '=') return true;
+ if (c == '#') return true;
+ if (c == '$') return true;
+ if (c == '_') return true;
+ if (c == '%') return true;
+ if (c == '\n') return true;
+ if (c == '\r') return true;
+ if (c == '\t') return true;
+
+ return false;
+ }
+
+ /**
+ *
+ * This will ensure that the data for a public identifier
+ * is appropriate.
+ *
+ *
+ * @param publicID String public ID to check.
+ * @return String - reason public ID is invalid, or
+ * null if public ID is OK.
+ */
+ public static final String checkPublicID(String publicID) {
+ String reason = null;
+
+ if (publicID == null) return null;
+ // This indicates there is no public ID
+
+ for (int i = 0; i < publicID.length(); i++) {
+ char c = publicID.charAt(i);
+ if (!isXMLPublicIDCharacter(c)) {
+ reason = c + " is not a legal character in public IDs";
+ break;
+ }
+ }
+
+ return reason;
+ }
+
+ /**
+ *
+ * This will ensure that the data for a system literal
+ * is appropriate.
+ *
+ *
+ * @param systemLiteral String system literal to check.
+ * @return String - reason system literal is invalid, or
+ * null if system literal is OK.
+ */
+ public static final String checkSystemLiteral(String systemLiteral) {
+ String reason = null;
+
+ if (systemLiteral == null) return null;
+ // This indicates there is no system ID
+
+ if (systemLiteral.indexOf('\'') != -1
+ && systemLiteral.indexOf('"') != -1) {
+ reason =
+ "System literals cannot simultaneously contain both
single and double quotes.";
+ }
+ else {
+ reason = checkCharacterData(systemLiteral);
+ }
+
+ return reason;
+ }
+
+
/**
*
* This is a utility function for sharing the base process of checking
@@ -511,7 +589,7 @@
* @return String - reason the name is invalid, or
* null if OK.
*/
- private static String checkXMLName(String name) {
+ public static String checkXMLName(String name) {
// Cannot be empty or null
if ((name == null) || (name.length() == 0)
|| (name.trim().equals(""))) {
Index: src/java/org/jdom/input/DOMBuilder.java
===================================================================
RCS file: /home/cvspublic/jdom/src/java/org/jdom/input/DOMBuilder.java,v
retrieving revision 1.39
diff -d -u -r1.39 DOMBuilder.java
--- src/java/org/jdom/input/DOMBuilder.java 2002/01/08 09:17:10 1.39
+++ src/java/org/jdom/input/DOMBuilder.java 2002/02/03 11:03:45
@@ -518,12 +518,8 @@
String systemID = domDocType.getSystemId();
DocType docType = factory.docType(domDocType.getName());
- if ((publicID != null) && (!publicID.equals(""))) {
- docType.setPublicID(publicID);
- }
- if ((systemID != null) && (!systemID.equals(""))) {
- docType.setSystemID(systemID);
- }
+ docType.setPublicID(publicID);
+ docType.setSystemID(systemID);
doc.setDocType(docType);
break;
Index: src/java/org/jdom/input/SAXHandler.java
===================================================================
RCS file: /home/cvspublic/jdom/src/java/org/jdom/input/SAXHandler.java,v
retrieving revision 1.32
diff -d -u -r1.32 SAXHandler.java
--- src/java/org/jdom/input/SAXHandler.java 2002/01/29 05:21:11 1.32
+++ src/java/org/jdom/input/SAXHandler.java 2002/02/03 11:03:45
@@ -788,7 +788,7 @@
*
* @param name String name of element listed in DTD
* @param publicId String public ID of DTD
- * @param systemId String syste ID of DTD
+ * @param systemId String system ID of DTD
*/
public void startDTD(String name, String publicId, String systemId)
throws SAXException {
Index: src/java/org/jdom/output/XMLOutputter.java
===================================================================
RCS file: /home/cvspublic/jdom/src/java/org/jdom/output/XMLOutputter.java,v
retrieving revision 1.72
diff -d -u -r1.72 XMLOutputter.java
--- src/java/org/jdom/output/XMLOutputter.java 2002/01/30 03:32:11 1.72
+++ src/java/org/jdom/output/XMLOutputter.java 2002/02/03 11:03:46
@@ -1179,13 +1179,13 @@
out.write("
Message-ID: <200202031537.IAA04556@dorothy.denveronline.net>
Few other thoughts.
1. What if the elementName in the DocType doesn't match the root element?
Probably should throw a ISE on further access (like missing root does).
2. What if you set the root element to a element whose name doesn't
match the one in the current DocType, should we:
a. do nothing and maybe have a ISE later
b. just remove the current DocType
c. install a new DocType with the proper name and a null public and
system id
3. What if you set a DocType whose elementName doesn't match the existing
root element, throw a IllegalAddException right then, or delay for a
ISE later.
Brad
From elharo at metalab.unc.edu Sun Feb 3 08:48:14 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:20 2004
Subject: [jdom-interest] DOCTYPE still giving me the worst headache!
In-Reply-To: <200202031537.IAA04556@dorothy.denveronline.net>
References: <200202031537.IAA04556@dorothy.denveronline.net>
Message-ID:
At 9:37 AM -0600 2/3/02, Bradley S. Huffman wrote:
>Few other thoughts.
>
>1. What if the elementName in the DocType doesn't match the root element?
This is completely legal. It is not *valid* but it is legal. (FYI,
the JavaDocs often use the word "valid" where the word "legal" is
what's really needed. We need to fix this before 1.0.) I have seen
documents in the wild that declared different root elements in the
DOCTYPE than they actually had.
> Probably should throw a ISE on further access (like missing root does).
>2. What if you set the root element to a element whose name doesn't
> match the one in the current DocType, should we:
> a. do nothing and maybe have a ISE later
> b. just remove the current DocType
> c. install a new DocType with the proper name and a null public and
> system id
d) do nothing and have no exceptions later. Having the root element
name declared by the DOCTYPE declaration be different from the actual
root element name is not an illegal state.
>3. What if you set a DocType whose elementName doesn't match the existing
> root element, throw a IllegalAddException right then, or delay for a
> ISE later.
>
Again, no. No exceptions will be thrown as a result of this at any time.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From dumdum420 at hotmail.com Sun Feb 3 13:28:36 2002
From: dumdum420 at hotmail.com (dumdum 420)
Date: Fri Aug 6 17:07:20 2004
Subject: [jdom-interest] Character encoding from UTF-8 to ISO-8859-1
Message-ID:
I have a xml feed with encoding set to UTF-8. This contains certain European
characters. I have to parse this XML and insert it into Oracle Database
which supports ISO-8859-1.
Once I accomplish the output of the insert make the characters some of them
look very very funny.
Is they a way in Java or a workaround how I can convert from UTF-8 to
ISO-8859-1 in a exact fashion.
Take care.
Bhanu Pabreja.
Here is a simple line try converting it to ISO-8859-1 from UTF-8 and you can
figure out how it is done.
The purpose of this abstract is to test passing foreign characters from the
Notes system, through UTF-8 xml, into Oracle, and then ultimately back out
into UTF-8 XML that sits on the file system. This abstract contains the
following foreign characters:
[ Euro symbol: € ] [ Full Quotes: “Competing on the Edge” ] [ Normal
Quotes: “Competing on the Edge” ] [ m-dash: – ] [ characters: ØÅ ] [ “e”
accent aigu: é ] [ “e” with circumflex: ê ] [ “a” accent grave: à ] [ “u”
with umlaut: ü ] [ “o” with umlaut: ö ] [ “a” with umlaut: ä ]
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
From petrovic at corp.earthlink.net Sun Feb 3 19:33:57 2002
From: petrovic at corp.earthlink.net (Mark S Petrovic)
Date: Fri Aug 6 17:07:20 2004
Subject: [jdom-interest] Re: JDOM document over SOAP
Message-ID: <20020203193357.A51605@corp.earthlink.net>
I ran across this interesting post while searching for tips for
sending a JDOM document from a SOAP service to a SOAP client:
> Most of the SOAP example code uses SOAP's bundled-in marshalling
> methods to set the outgoing parameters and values. Unless
> you're sending something complicated I found it best to use
> the Call object and a Vector to set the parameters. When SOAP
> returns a response it gives you a Response object, which is
> an XML document.
> SAXBuilder responseSAXTree = new SAXBuilder();
> Document doc = responseSAXTree.build( response );
> will create a JDOM object that you can use to read and manipulate
> to find the results of the call. You may find the SoapObject
> code in Load, an open-source project I manage, to be helpful
> in learning SOAP. Load is at http://www.pushtotest.com.
> -Frank
> -- Frank Cohen,
> founder, PushToTest, www.pushtotest.com, phone: 408 374 7426
> Come to PushToTest for Load, a free open-source tool for
> performance and scalability testing and data migration.
The elegance of this solution is quite appealing. However, a
version of the build() method of the SAXBuilder class that takes
an argument of type Response seems not to exist.
How does one address this?
Thank you.
From ppalomo at hotpop.com Mon Feb 4 01:09:06 2002
From: ppalomo at hotpop.com (Pedro)
Date: Fri Aug 6 17:07:20 2004
Subject: [jdom-interest] Xerxes Parser and JDOM
References: <200201210927.g0L9RhC03196@mailgate5.cinetic.de> <3C51FA66.AA70E854@acm.org> <3C580085.7070608@atosorigin.com>
Message-ID: <00bc01c1ad5b$99d5f650$f100000a@TI04DESpalomo>
Hi Laurent and Jason??
I have the same problem with JDOM and Xerces but i don't understand very
well your explanation.
Can you give me an example with directories anda files.
I think the problem is that i don't understand very well whay you try to do.
Thanks and my best regards from Spain.
PD: In my application i have many problems with versions of the same
libraries.
HAva you a "definitive"..:-) to this problem??
THANKS Again??
----- Original Message -----
From: "Laurent Bihanic"
To: "Jason Hunter"
Cc: "JDOM Interest"
Sent: Wednesday, January 30, 2002 3:17 PM
Subject: Re: [jdom-interest] Xerxes Parser and JDOM
>
> Hi, Jason,
>
> IMHO, this is a documentation issue. Whatever we decide must be described
> clearly in the JDOM installation documentation, either to state which JARs
the
> user needs to include in the classpath to use JDOM or to provide guideline
on
> how to bundle JDOM with an application or applet, i.e. describe how to
update
> the manifest to remove Xerces if the application uses another parser or
> another verson of Xerces.
>
> Both solutions are OK once properly documented.
>
> To choose, I'd prefer solution a) as I usually try to control the class
path
> of the application and thus tend to strip all Class-Path entries in
manifests
> to avoid version conflicts.
> A typical case is an application that uses Xerces 2.0 with JDOM and Xalan,
> JDOM and Xalan come bundled with different versions of Xerces 1.4 !
Stripping
> Class-Path entries from third-party software JARs and replacing them by a
> single one in the application main JAR file is a good way to prevent these
> version conflicts.
>
> Laurent
>
>
> Jason Hunter wrote:
>
> > A couple weeks ago Tobias wrote in complaining that his applet was
> > always trying to fetch xerces.jar from his server while he was using
> > crimson.jar as his parser, and wondered why. I pointed him at the
> > MANIFEST.MF file. Seems that was the culprit.
> >
> > So now we have a decision to make. Do we
> >
> > a) Remove the Class-Path line from the MANIFEST. Upside: People who
> > use Crimson won't see two 404 hits. Downside: People who use Xerces
> > will have to explicitly include it in the applet tags. Further
> > downside: The cool "java -jar jdom.jar" easter egg won't work anymore!
> >
> > b) Keep the Class-Path line. Upside: Easy Xerces and cool -jar.
> > Downside: Two wasted hits.
> >
> > I suspect there may be a third choice, or more upsides/downsides to this
> > issue, so I'm writing to the list to see if anyone else has a thought.
> >
> > -jh-
>
>
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
>
From rdritchi at bechtel.com Mon Feb 4 12:18:34 2002
From: rdritchi at bechtel.com (Ritchie, Rob)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Replace
Message-ID: <0FC5DE139BD5D1118F3B00805FA7410E02ACB1D6@BNES0013>
Hi,
I am wondering has any suggestions as to how I could implement a replace
function. Essentially I would like to parse out tags like and replace it with the value of x as a String
more text here
becomes
value of x here
more text here
Any suggestions on the best way to achieve this?
Thanks
Rob.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020204/e8b4b936/attachment.htm
From jhunter at servlets.com Mon Feb 4 15:39:57 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] DOCTYPE still giving me the worst headache!
References: <200201302225.g0UMP4o04260@trance.metalab.unc.edu>
<3C598D15.E4AC6610@servlets.com>
Message-ID: <3C5F1BCD.D46CA41@servlets.com>
> I made checkXMLName() in Verifier public so EntityRef and DocType
> could use it. (They do allow colons in their names which
> checkElementName() forbids.) I don't think this will cause a problem,
> but if it does it could be package private.
I don't think we should allow colons in JDOM element names. If we do,
people are going to try to put colons in element names as a way to
manage namespaces (since that's the obvious way to do it), and get
themselves into loads of trouble.
I know the easy counter argument is that the XML spec says XML
processors should allow colons in element names, but JDOM is not an XML
processor, it's a higher-level document object model. We should do what
is reasonable and makes sense. Besides, allowing colons seems counter
to supporting the Namespace spec.
-jh-
From elharo at metalab.unc.edu Mon Feb 4 19:13:16 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] DOCTYPE still giving me the worst headache!
In-Reply-To: <3C5F1BCD.D46CA41@servlets.com>
References: <200201302225.g0UMP4o04260@trance.metalab.unc.edu>
<3C598D15.E4AC6610@servlets.com>
<3C5F1BCD.D46CA41@servlets.com>
Message-ID:
>I don't think we should allow colons in JDOM element names. If we do,
>people are going to try to put colons in element names as a way to
>manage namespaces (since that's the obvious way to do it), and get
>themselves into loads of trouble.
>
I agree, but you mistook what I did. checkElementName() is still
there and still used for elements. That hasn't changed. Its behavior
has not changed. However *entity* names can contain colons (as can
other types of XML names like ID and IDREF attribute values). This
requires a different method to check. That's why I exposed and used
checkXMLName(). But I didn't in any way change the existing behavior
or interface of the Element class.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From jhunter at servlets.com Mon Feb 4 22:40:24 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] DOCTYPE still giving me the worst headache!
References: <200201302225.g0UMP4o04260@trance.metalab.unc.edu>
<3C598D15.E4AC6610@servlets.com>
<3C5F1BCD.D46CA41@servlets.com>
Message-ID: <3C5F7E58.3DB3B816@servlets.com>
Elliotte Rusty Harold wrote:
>
> >I don't think we should allow colons in JDOM element names. If we do,
> >people are going to try to put colons in element names as a way to
> >manage namespaces (since that's the obvious way to do it), and get
> >themselves into loads of trouble.
> >
>
> I agree, but you mistook what I did. checkElementName() is still
> there and still used for elements. That hasn't changed. Its behavior
> has not changed. However *entity* names can contain colons (as can
> other types of XML names like ID and IDREF attribute values). This
> requires a different method to check. That's why I exposed and used
> checkXMLName(). But I didn't in any way change the existing behavior
> or interface of the Element class.
Glad we agree! I'm still confused though. Here's the patch of
Element.java.
diff -d -u -r1.106 Element.java
--- src/java/org/jdom/Element.java 2002/01/25 18:42:52 1.106
+++ src/java/org/jdom/Element.java 2002/02/03 11:03:43
@@ -215,7 +215,9 @@
* Element name.
*/
public Element setName(String name) {
- String reason = Verifier.checkElementName(name);
+ // Use checkXMLName() instead of checkElementName() here
+ // because we do need to allow this to contain a colon
+ String reason = Verifier.checkXMLName(name);
if (reason != null) {
throw new IllegalNameException(name, "element", reason);
}
I read your comment and code to say you're allowing element names to
contain colons.
And here's the code in EntityRef:
public EntityRef setName(String name) {
+ // This can contain a colon so we use checkXMLName()
+ // instead of checkElementName()
+ String reason = Verifier.checkXMLName(name);
+ if (reason != null) {
+ throw new IllegalNameException(name, "EntityRef", reason);
+ }
Looks basically the same. Seems like perhaps you copy/paste typo'd the
Element version and really wanted checkElementName() afterall, which is
why we agree in principle if not in code?
-jh-
From elharo at metalab.unc.edu Tue Feb 5 06:14:06 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] DOCTYPE still giving me the worst headache!
In-Reply-To: <3C5F7E58.3DB3B816@servlets.com>
References: <200201302225.g0UMP4o04260@trance.metalab.unc.edu>
<3C598D15.E4AC6610@servlets.com>
<3C5F1BCD.D46CA41@servlets.com>
<3C5F7E58.3DB3B816@servlets.com>
Message-ID:
At 10:40 PM -0800 2/4/02, Jason Hunter wrote:
>diff -d -u -r1.106 Element.java
>--- src/java/org/jdom/Element.java 2002/01/25 18:42:52 1.106
>+++ src/java/org/jdom/Element.java 2002/02/03 11:03:43
>@@ -215,7 +215,9 @@
> * Element name.
> */
> public Element setName(String name) {
>- String reason = Verifier.checkElementName(name);
>+ // Use checkXMLName() instead of checkElementName() here
>+ // because we do need to allow this to contain a colon
>+ String reason = Verifier.checkXMLName(name);
> if (reason != null) {
> throw new IllegalNameException(name, "element", reason);
> }
>
>I read your comment and code to say you're allowing element names to
>contain colons.
>
Weird. Certainly looks like a mistake. I'm not sure what I was
thinking (if anything). I agree that shouldn't be there.
I have noticed that since I installed the latest WheelMouse extension
in jEdit it occasionally likes to paste the contents of the
clipboard in unexpected places. I think it's doing that when I press
the mouse wheel by accident. That's perhaps what happened here.
Normally it results in a syntax error, but in this case I guess I was
unlucky. Anyway, we agree. Don't check this in. It doesn't make sense.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From arosen at silverstream.com Tue Feb 5 08:50:10 2002
From: arosen at silverstream.com (Alex Rosen)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Character encoding from UTF-8 to ISO-8859-1
In-Reply-To:
Message-ID: <002301c1ae65$2d3b3770$6601a8c0@silverstream.com>
Trying to figure out character encoding issues is very tricky. There are a
number of places in the process where the problem could be. Even worse, it's
often confusing to look at a file and determine if it's correct or not,
because the character set you're using to view it is a factor.
If you have a JDOM document, then XMLOutputter will correctly output it in
the character encoding that you specify. Call setEncoding() on it, and then
call the version of output() that takes an OutputStream (not a Writer). (Or
use the version that takes a Writer, but make sure you set the Writer's
encoding properly.) This should work fine.
The "funny characters" you're seeing could be from several reasons: it's not
being stored in the database with the wrong encoding; it's being retrieved
with the wrong encoding; or most likely, you're viewing it using the wrong
encoding. The funny characters may just be the ISO-8859-1 characters, if
your system uses a different default character set.
Alex
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org]On Behalf Of dumdum 420
> Sent: Sunday, February 03, 2002 4:29 PM
> To: jdom-interest@jdom.org
> Subject: [jdom-interest] Character encoding from UTF-8 to ISO-8859-1
>
>
> I have a xml feed with encoding set to UTF-8. This contains
> certain European
> characters. I have to parse this XML and insert it into
> Oracle Database
> which supports ISO-8859-1.
>
> Once I accomplish the output of the insert make the
> characters some of them
> look very very funny.
>
> Is they a way in Java or a workaround how I can convert from UTF-8 to
> ISO-8859-1 in a exact fashion.
>
> Take care.
>
> Bhanu Pabreja.
>
> Here is a simple line try converting it to ISO-8859-1 from
> UTF-8 and you can
> figure out how it is done.
>
>
> The purpose of this abstract is to test passing foreign
> characters from the
> Notes system, through UTF-8 xml, into Oracle, and then
> ultimately back out
> into UTF-8 XML that sits on the file system. This abstract
> contains the
> following foreign characters:
> [ Euro symbol: ? ] [ Full Quotes: ?Competing on the Edge?
> ] [ Normal
> Quotes: ?Competing on the Edge? ] [ m-dash: ? ] [
> characters: ?? ] [ ?e?
> accent aigu: ? ] [ ?e? with circumflex: ? ] [ ?a? accent
> grave: ? ] [ ?u?
> with umlaut: ? ] [ ?o? with umlaut: ? ] [ ?a? with umlaut: ? ]
>
>
>
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@yourhost.com
From gp03 at uow.edu.au Wed Feb 6 13:03:49 2002
From: gp03 at uow.edu.au (Guillaume Potard)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] GetElementsByTagName in JDom ?
Message-ID: <00a501c1af51$c6732050$ca588282@echo>
Just wondering if GetElementsByTagName( Tag ) is implemented in JDom
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020206/5b8cc35b/attachment.htm
From bob at werken.com Tue Feb 5 20:27:04 2002
From: bob at werken.com (bob mcwhirter)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] GetElementsByTagName in JDom ?
In-Reply-To: <00a501c1af51$c6732050$ca588282@echo>
Message-ID:
> Just wondering if GetElementsByTagName( Tag ) is implemented in JDom
Not the recursive kind that DOM tends to have...
But, there is decent XPath support for JDOM.
http://jaxen.org/
-bob
From jhunter at servlets.com Tue Feb 5 21:48:17 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] builder.setIgnoreDTD()
Message-ID: <3C60C3A1.83D1EF84@servlets.com>
One thing on the TODO list is to add a builder.setIgnoreDTD() flag which
people can set if they want the builder to not read the external DTD.
Normally parsers do read external DTDs even when validation is off,
because they look for entities and such, and a lot of people find this
bothersome for offline work and such.
It's been mentioned this can be accomplished using an EntityResolver.
For example, I have success using the following:
import org.xml.sax.EntityResolver;
import org.xml.sax.InputSource;
import java.io.*;
public class NoOpEntityResolver implements EntityResolver {
public InputSource resolveEntity(String publicId, String systemId) {
return new InputSource(new StringBufferInputStream(""));
}
}
And in the builder calling:
builder.setEntityResolver(new NoOpEntityResolver());
So I'm thinking perhaps we should have setIgnoreDTD() automatically set
this entity resolver. I to remember someone (Brett?) warning there was
a problem with this. Perhaps the problem is that if you wanted to
actually resolve entities, you'd need to have something smarter than
this resolver.
So the question is, what are the problems with this approach, and should
we (a) implement setIgnoreDTD() as above or just (b) add an entry in the
FAQ about this. Or is there a (c) better option. Like in Xerces they
have a feature
http://apache.org/xml/features/nonvalidating/load-external-dtd, but in
Crimson and other parsers there's no counterpart last I checked.
Opinions welcome.
-jh-
From jmcruz at lcc.uma.es Wed Feb 6 01:26:29 2002
From: jmcruz at lcc.uma.es (Jesus Martinez)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] JDOMb7 SAXOutputter is not giving characters to a ContentHandler
Message-ID: <3C60F6C5.A03B849E@lcc.uma.es>
Hello,
When updating from JDOMb6 to JDOMb7, we are experiencing a problem using
SAXOutputter with a ContentHandler defined. The function characters( )
is always getting '\n' instead PCDATA.
With the previous version of the library (b6), that function is working
fine.
Any ideas?
Thanks in advice.
Jesus M.-
From hip at a.cs.okstate.edu Wed Feb 6 07:14:25 2002
From: hip at a.cs.okstate.edu (Bradley S. Huffman)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Re: XMLOutputter testing
In-Reply-To: Your message of "Tue, 05 Feb 2002 19:45:00 PST."
<3C60A6BC.A32554F8@servlets.com>
Message-ID: <200202061514.IAA24538@dorothy.denveronline.net>
Jason Hunter writes:
> The only thing I found is that if you turn text normalization on, then
> XHTML-style output is altered. For example:
>
>
> Here goes the body and a link.
>
>
> becomes
>
> Here goes thebodyand alink.
>
> and I personally always wanted something more like
>
> Here goes the body and a link.
>
That's the problem, everyone has their own view of what's best :) I was
thinking about a text indent mask to give the user a finer grain of control.
They could mask off indentation for text between start/start, start/end,
end/start, and end/end tags (the 4 cases where text can occur). I haven't
done it yet because, well, I still think there's a better way do this (don't
know what it is yet, but I think there's one).
> OK, I did a little more advanced testing and found another little bug in
> the xml:space behavior if trim all white is turned on.
>
> This file:
>
>
> Here goes the body and a xml:space="preserve" href="foo.html">link.
>
>
> becomes
>
>
>
> Here goes the body and a xml:space="preserve" href="foo.html">link.
>
>
> Which is nearly correct except I think " body" should be "body" because
> the tag set the space flag back to default which is trimming all.
> Correct?
Correct, you've found a bug.
Brad
From brett at newinstance.com Wed Feb 6 07:25:00 2002
From: brett at newinstance.com (Brett D. McLaughlin, Sr.)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] builder.setIgnoreDTD()
In-Reply-To: <3C60C3A1.83D1EF84@servlets.com>
Message-ID: <002401c1af22$7d163200$0a01a8c0@GANDALF>
> So I'm thinking perhaps we should have setIgnoreDTD() automatically
set
> this entity resolver. I to remember someone (Brett?) warning there
was
> a problem with this. Perhaps the problem is that if you wanted to
> actually resolve entities, you'd need to have something smarter than
> this resolver.
Yup. It doesn't just ignore the DTD; it ignores all entities. So I'm
sort of uncomfortable with the method being named setIgnoreDTD().
Instead, maybe setIgnoreEntities()?
Or just put something in the FAQ. I'm agnostic on the issue.
---
Brett McLaughlin, Sr.
Lutris Technologies [http://www.lutris.com]
O'Reilly Author [http://www.newInstance.com]
From mnott at vignette.com Wed Feb 6 07:57:53 2002
From: mnott at vignette.com (Nott, Matthias)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Character encoding from UTF-8 to ISO-8859-1
Message-ID:
You cannot transcode exactly UTF-8 to Latin1 as UTF-8 has a richer
set of characters and, especially, as UTF-8 is not a superset of
Latin1. That being said, I've written a mapping table which maps
commonly used characters to their html entities. Some characters,
like the Euro-Symbol, simply do not exist in Latin1, so I transcode
them to EUR. You might do something like that, or you just change
the character set of your database (update props$, but make sure
you first export all your data).
m
-----Original Message-----
From: Alex Rosen [mailto:arosen@silverstream.com]
Sent: Tuesday, February 05, 2002 5:50 PM
To: 'dumdum 420'; jdom-interest@jdom.org
Subject: RE: [jdom-interest] Character encoding from UTF-8 to ISO-8859-1
Trying to figure out character encoding issues is very tricky. There are a
number of places in the process where the problem could be. Even worse, it's
often confusing to look at a file and determine if it's correct or not,
because the character set you're using to view it is a factor.
If you have a JDOM document, then XMLOutputter will correctly output it in
the character encoding that you specify. Call setEncoding() on it, and then
call the version of output() that takes an OutputStream (not a Writer). (Or
use the version that takes a Writer, but make sure you set the Writer's
encoding properly.) This should work fine.
The "funny characters" you're seeing could be from several reasons: it's not
being stored in the database with the wrong encoding; it's being retrieved
with the wrong encoding; or most likely, you're viewing it using the wrong
encoding. The funny characters may just be the ISO-8859-1 characters, if
your system uses a different default character set.
Alex
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org]On Behalf Of dumdum 420
> Sent: Sunday, February 03, 2002 4:29 PM
> To: jdom-interest@jdom.org
> Subject: [jdom-interest] Character encoding from UTF-8 to ISO-8859-1
>
>
> I have a xml feed with encoding set to UTF-8. This contains
> certain European
> characters. I have to parse this XML and insert it into
> Oracle Database
> which supports ISO-8859-1.
>
> Once I accomplish the output of the insert make the
> characters some of them
> look very very funny.
>
> Is they a way in Java or a workaround how I can convert from UTF-8 to
> ISO-8859-1 in a exact fashion.
>
> Take care.
>
> Bhanu Pabreja.
>
> Here is a simple line try converting it to ISO-8859-1 from
> UTF-8 and you can
> figure out how it is done.
>
>
> The purpose of this abstract is to test passing foreign
> characters from the
> Notes system, through UTF-8 xml, into Oracle, and then
> ultimately back out
> into UTF-8 XML that sits on the file system. This abstract
> contains the
> following foreign characters:
> [ Euro symbol: EUR ] [ Full Quotes: "Competing on the Edge"
> ] [ Normal
> Quotes: "Competing on the Edge" ] [ m-dash: - ] [
> characters: ?? ] [ "e"
> accent aigu: ? ] [ "e" with circumflex: ? ] [ "a" accent
> grave: ? ] [ "u"
> with umlaut: ? ] [ "o" with umlaut: ? ] [ "a" with umlaut: ? ]
>
>
>
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@yourhost.com
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
From elharo at metalab.unc.edu Wed Feb 6 07:59:23 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] builder.setIgnoreDTD()
In-Reply-To: <3C60C3A1.83D1EF84@servlets.com>
References: <3C60C3A1.83D1EF84@servlets.com>
Message-ID:
Depending on the parser, there's normally a SAX property to turn this
off without creating your own entity resolver. In Xerces it's
http://apache.org/xml/features/nonvalidating/load-external-dtd
However, your suggestion does seem more likely to work across browsers.
On the other hand, here's what I very much don't like about using a
custom EntityResolver: it will be called not just for the external
DTD subset but also for any external entities referenced in the file
such as &my_signature_file;. It will set the replacement text of
these entities to the empty string and will not call the
skippedEntity() method in ContentHandler. Thus we won't be able to
transform them into JDOM EntityRef elements.
Which reminds me: SAXHandler doesn't handle skipped entity events
now. I should fix that regardless of what we do with this proposal.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From laurent.bihanic at atosorigin.com Wed Feb 6 08:41:17 2002
From: laurent.bihanic at atosorigin.com (Laurent Bihanic)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] builder.setIgnoreDTD()
References: <002401c1af22$7d163200$0a01a8c0@GANDALF>
Message-ID: <3C615CAD.50903@atosorigin.com>
Brett D. McLaughlin, Sr. wrote:
> Yup. It doesn't just ignore the DTD; it ignores all entities.
That may easily be resolved by using SAXHandler as NoOpEntityResolver (it
already implements this interface) as SAXHandler has the knwoledge of whether
the parser is in the middle of DTD processing or not.
The "inDTD" flag is set when the startDTD() callback is invoked by the parser.
But I don't know if the parser first calls this method with the original
public ID and system ID and then the EntityResolver or if it first calls the
entityResolver and then the startDTD() method. Any SAX guru?
Laurent
From brett at newinstance.com Wed Feb 6 08:44:29 2002
From: brett at newinstance.com (Brett D. McLaughlin, Sr.)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] builder.setIgnoreDTD()
In-Reply-To: <3C615CAD.50903@atosorigin.com>
Message-ID: <002601c1af2d$8ee33a90$0a01a8c0@GANDALF>
> Brett D. McLaughlin, Sr. wrote:
> > Yup. It doesn't just ignore the DTD; it ignores all entities.
>
> That may easily be resolved by using SAXHandler as NoOpEntityResolver
(it
> already implements this interface) as SAXHandler has the knwoledge of
> whether
> the parser is in the middle of DTD processing or not.
The entities are defined in the DTD, so if you ignore the DTD, you
therefore ignore what's in it, which means ignoring the entities ;-)
---
Brett McLaughlin, Sr.
Lutris Technologies [http://www.lutris.com]
O'Reilly Author [http://www.newInstance.com]
From elharo at metalab.unc.edu Wed Feb 6 09:18:45 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] SAXHandler skipped entity patch
Message-ID: <3C616575.1030305@metalab.unc.edu>
The following patch will add support for skipped entities to SAXHandler
in the event that the parser is not resolving external entities. I''ve
verified
that it compiles and doesn't break any tests. However, I'm not totally
fluent on the current logic of SAXHandler and org.jdom.input, so please
double check my skippedEntity() method for any obvious mistakes.
I also made some corrections to the JavaDoc for processsingInstruction().
? build
? saxhandlerdiff.txt
Index: src/java/org/jdom/input/SAXHandler.java
===================================================================
RCS file: /home/cvspublic/jdom/src/java/org/jdom/input/SAXHandler.java,v
retrieving revision 1.34
diff -d -u -r1.34 SAXHandler.java
--- src/java/org/jdom/input/SAXHandler.java 2002/02/06 02:11:42 1.34
+++ src/java/org/jdom/input/SAXHandler.java 2002/02/07 01:15:44
@@ -153,7 +153,8 @@
*
* Class initializer: Populate a table to translate SAX attribute
* type names into JDOM attribute type value (integer).
- *
+ *
+ *
* Note that all the mappings defined below are compliant with
* the SAX 2.0 specification exception for "ENUMERATION" with is
* specific to Crinsom 1.1.X and Xerces 2.0.0-betaX which report
@@ -448,12 +449,13 @@
/**
*
- * This will indicate that a processing instruction (other than
- * the XML declaration) has been encountered.
+ * This will indicate that a processing instruction has been
encountered.
+ * (The XML declaration is not a processing instrcution and will not
+ * be reported.)
*
*
* @param target String target of PI
- * @param data StringString containing all data sent to the PI.
* This typically looks like one or more attribute value
* pairs.
* @throws SAXException when things go wrong
@@ -475,6 +477,28 @@
/**
*
+ * This indicates that an unresolvable entity reference has been
encountered,
+ * normally because the external DTD subset has not been
+ * read.
+ *
+ *
+ * @param name String name of entity
+ * @throws SAXException when things go wrong
+ */
+ public void skippedEntity(String name)
+ throws SAXException {
+
+ // We don't handle parameter entity references.
+ if (name.startsWith("%")) return;
+
+ flushCharacters();
+
+ getCurrentElement().addContent(factory.entityRef(name));
+
+ }
+
+ /**
+ *
* This will add the prefix mapping to the JDOM
* Document object.
*
@@ -1067,4 +1091,5 @@
public Locator getDocumentLocator() {
return locator;
}
+
}
From elharo at metalab.unc.edu Wed Feb 6 09:38:35 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] builder.setIgnoreDTD()
In-Reply-To: <002601c1af2d$8ee33a90$0a01a8c0@GANDALF>
References: <002601c1af2d$8ee33a90$0a01a8c0@GANDALF>
Message-ID:
At 10:44 AM -0600 2/6/02, Brett D. McLaughlin, Sr. wrote:
>The entities are defined in the DTD, so if you ignore the DTD, you
>therefore ignore what's in it, which means ignoring the entities ;-)
>
You ignore the external DTD subset. That's not quite the same as
ignoring the DTD. For example, this document contains an external
entity that will be resolved even with DTD loading turned off:
]>
&test;
I don't think it's acceptable to replace the &test; entity with the
empty string. It's acceptable to replace it with an EntityRef object
but not with the empty string.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From brett at newinstance.com Wed Feb 6 09:40:33 2002
From: brett at newinstance.com (Brett D. McLaughlin, Sr.)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] builder.setIgnoreDTD()
In-Reply-To:
Message-ID: <002801c1af35$697446c0$0a01a8c0@GANDALF>
> You ignore the external DTD subset. That's not quite the same as
> ignoring the DTD. For example, this document contains an external
> entity that will be resolved even with DTD loading turned off:
>
>
> ]>
>
> &test;
>
>
> I don't think it's acceptable to replace the &test; entity with the
> empty string. It's acceptable to replace it with an EntityRef object
> but not with the empty string.
Agreed. However, we need to be very clear to users, as most (in my
experience) don't use internal subsets. Most are going to (illogically)
expect to not have to resolve DTDs, and yet be upset when their entities
don't come in expanded ;-)
---
Brett McLaughlin, Sr.
Lutris Technologies [http://www.lutris.com]
O'Reilly Author [http://www.newInstance.com]
From jhunter at servlets.com Wed Feb 6 09:57:24 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] JDOMb7 SAXOutputter is not giving characters to a
ContentHandler
References: <3C60F6C5.A03B849E@lcc.uma.es>
Message-ID: <3C616E84.E3F8C9D7@servlets.com>
Sorry, my memory doesn't go back that far and the development code has
changed a lot since even beta7. I'd suggest you try the latest code in
CVS and let us know if there's a problem still, and if so we'll make
sure it's fixed in beta8.
-jh-
Jesus Martinez wrote:
>
> Hello,
>
> When updating from JDOMb6 to JDOMb7, we are experiencing a problem using
> SAXOutputter with a ContentHandler defined. The function characters( )
> is always getting '\n' instead PCDATA.
>
> With the previous version of the library (b6), that function is working
> fine.
>
> Any ideas?
>
> Thanks in advice.
>
> Jesus M.-
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From hip at a.cs.okstate.edu Wed Feb 6 10:40:27 2002
From: hip at a.cs.okstate.edu (Bradley S. Huffman)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Re: XMLOutputter testing
In-Reply-To: Your message of "Wed, 06 Feb 2002 09:14:25 CST."
<200202061514.IAA24538@dorothy.denveronline.net>
Message-ID: <200202061841.LAA05134@dorothy.denveronline.net>
Jason Hunter writes:
> The only thing I found is that if you turn text normalization on, then
> XHTML-style output is altered. For example:
>
>
> Here goes the body and a link.
>
>
> becomes
>
> Here goes thebodyand alink.
>
> and I personally always wanted something more like
>
> Here goes the body and a link.
>
Oops, misread the example the first time. Hmmm, I see what you mean in
this example. Falls back to what is normalize. Right now XMLOutputter
use normalize as defined in Element.getTextNormalize, which is so
x.setContent(" blah, blah, blah ");
y.setContent("blah, blah, blah ");
(x.getTextNormalize()).equals(y.getTextNormalize()) == true
Which, in your example, doesn't give the desired results.
Brad
From jmcruz at lcc.uma.es Wed Feb 6 10:47:52 2002
From: jmcruz at lcc.uma.es (Jesus Martinez)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] JDOMb7 SAXOutputter is not giving characters to a
ContentHandler
References: <3C60F6C5.A03B849E@lcc.uma.es> <3C616E84.E3F8C9D7@servlets.com>
Message-ID: <3C617A58.71F2176C@lcc.uma.es>
Thank you Jason,
with the latest CVS code it works fine again.
Jesus M.-
Jason Hunter wrote:
> Sorry, my memory doesn't go back that far and the development code has
> changed a lot since even beta7. I'd suggest you try the latest code in
> CVS and let us know if there's a problem still, and if so we'll make
> sure it's fixed in beta8.
>
> -jh-
>
> Jesus Martinez wrote:
> >
> > Hello,
> >
> > When updating from JDOMb6 to JDOMb7, we are experiencing a problem using
> > SAXOutputter with a ContentHandler defined. The function characters( )
> > is always getting '\n' instead PCDATA.
> >
> > With the previous version of the library (b6), that function is working
> > fine.
> >
> > Any ideas?
> >
> > Thanks in advice.
> >
> > Jesus M.-
> >
> > _______________________________________________
> > To control your jdom-interest membership:
> > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From jhunter at servlets.com Wed Feb 6 10:50:22 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] builder.setIgnoreDTD()
References: <002601c1af2d$8ee33a90$0a01a8c0@GANDALF>
Message-ID: <3C617AEE.7CDBE04E@servlets.com>
I've updated the FAQ to have an entry about this. Search for
EntityResolver. Please read it and offer any changes that would make it
more understandable and technically accurate.
-jh-
From jmcruz at lcc.uma.es Wed Feb 6 11:04:49 2002
From: jmcruz at lcc.uma.es (Jesus Martinez)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] JDOMb7 SAXOutputter is not giving characters to a
ContentHandler
References: <3C60F6C5.A03B849E@lcc.uma.es> <3C616E84.E3F8C9D7@servlets.com>
Message-ID: <3C617E51.79D6EC2C@lcc.uma.es>
Oops,
sorry for the previous message. I just checked a wrong output. Unfortunately, with the
latest code, there is still the same problem in getting characters from SAXOutputter.
Apologize for any inconveniences.
Jesus M-
Jason Hunter wrote:
> Sorry, my memory doesn't go back that far and the development code has
> changed a lot since even beta7. I'd suggest you try the latest code in
> CVS and let us know if there's a problem still, and if so we'll make
> sure it's fixed in beta8.
>
> -jh-
>
> Jesus Martinez wrote:
> >
> > Hello,
> >
> > When updating from JDOMb6 to JDOMb7, we are experiencing a problem using
> > SAXOutputter with a ContentHandler defined. The function characters( )
> > is always getting '\n' instead PCDATA.
> >
> > With the previous version of the library (b6), that function is working
> > fine.
> >
> > Any ideas?
> >
> > Thanks in advice.
> >
> > Jesus M.-
> >
> > _______________________________________________
> > To control your jdom-interest membership:
> > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From jhunter at servlets.com Wed Feb 6 12:12:58 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] JDOMb7 SAXOutputter is not giving characters to a
ContentHandler
References: <3C60F6C5.A03B849E@lcc.uma.es> <3C616E84.E3F8C9D7@servlets.com> <3C617E51.79D6EC2C@lcc.uma.es>
Message-ID: <3C618E4A.B736FCDE@servlets.com>
OK, then please send a simple (five line) test case demonstrating the
problem. Note if your issue is that you see \n instead of \r\n the FAQ
tells you why that is.
-jh-
Jesus Martinez wrote:
>
> Oops,
>
> sorry for the previous message. I just checked a wrong output. Unfortunately, with the
> latest code, there is still the same problem in getting characters from SAXOutputter.
>
> Apologize for any inconveniences.
>
> Jesus M-
>
> Jason Hunter wrote:
>
> > Sorry, my memory doesn't go back that far and the development code has
> > changed a lot since even beta7. I'd suggest you try the latest code in
> > CVS and let us know if there's a problem still, and if so we'll make
> > sure it's fixed in beta8.
> >
> > -jh-
> >
> > Jesus Martinez wrote:
> > >
> > > Hello,
> > >
> > > When updating from JDOMb6 to JDOMb7, we are experiencing a problem using
> > > SAXOutputter with a ContentHandler defined. The function characters( )
> > > is always getting '\n' instead PCDATA.
> > >
> > > With the previous version of the library (b6), that function is working
> > > fine.
> > >
> > > Any ideas?
> > >
> > > Thanks in advice.
> > >
> > > Jesus M.-
> > >
> > > _______________________________________________
> > > To control your jdom-interest membership:
> > > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From noamt at yahoo.com Wed Feb 6 13:06:32 2002
From: noamt at yahoo.com (Noam Tamim)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] GetElementsByTagName in JDom ?
In-Reply-To: <00a501c1af51$c6732050$ca588282@echo>
Message-ID: <20020206210632.59786.qmail@web13908.mail.yahoo.com>
And I was wondering if FilterList is capable of filtering based on Element name.
Guillaume Potard wrote: Just wondering if GetElementsByTagName( Tag ) is implemented in JDom
_______
Noam.
---------------------------------
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020206/ed9f4559/attachment.htm
From arosen at silverstream.com Wed Feb 6 13:07:36 2002
From: arosen at silverstream.com (Alex Rosen)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Character encoding from UTF-8 to ISO-8859-1
In-Reply-To:
Message-ID: <001f01c1af52$4e3bde50$6a65810a@silverstream.com>
> You cannot transcode exactly UTF-8 to Latin1 as UTF-8 has a richer
> set of characters
True - if your document contains chars that aren't in the character encoding
that you're using, such as Czech or Chinese characters if you're using
Latin1, then they need to be escaped as character reference, like "Ӓ".
I forget if XMLOutputter does this for you - I think it doesn't, but it's
planned for the future.
> and, especially, as UTF-8 is not a superset of Latin1.
No, all of Unicode is supported by UTF-8, and Unicode is a superset of the
Latin1 (ISO-8859-1) character set.
Alex
From arosen at silverstream.com Wed Feb 6 13:55:43 2002
From: arosen at silverstream.com (Alex Rosen)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] GetElementsByTagName in JDom ?
In-Reply-To: <20020206210632.59786.qmail@web13908.mail.yahoo.com>
Message-ID: <002401c1af59$0743f990$6a65810a@silverstream.com>
Sure, that's what getChildren(String) does under the covers. (I believe that
FilterList is currently planned to be an internal, implementation class, not
a publicly accessible one.)
Alex
-----Original Message-----
From: jdom-interest-admin@jdom.org [mailto:jdom-interest-admin@jdom.org]On
Behalf Of Noam Tamim
Sent: Wednesday, February 06, 2002 4:07 PM
To: jdom-interest@jdom.org
Subject: Re: [jdom-interest] GetElementsByTagName in JDom ?
And I was wondering if FilterList is capable of filtering based on Element
name.
From jhunter at servlets.com Wed Feb 6 14:04:18 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] GetElementsByTagName in JDom ?
References: <20020206210632.59786.qmail@web13908.mail.yahoo.com>
Message-ID: <3C61A862.27844A90@servlets.com>
> And I was wondering if FilterList is capable of filtering based on Element name.
Yep, and we're planning to have the ability to iterate through a
document based on a filter like that. Cool, eh?
-jh-
From roland at netquant.com.br Wed Feb 6 14:37:37 2002
From: roland at netquant.com.br (Roland)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Generating PDF output using JDOM with iText
Message-ID: <5.1.0.14.0.20020206202800.030f4540@mail.netquant.com.br>
Hello,
I'm new to JDOM and here is what I want to do:
I want to take the whole tree and make it output a PDF file using
iText(http://www.lowagie.com/iText/).
To those who don't know what iText is: it is a library that enables you to
produce PDF documents from Java.
I was thinking about adding a class to org.jdom.output to enable this.
My interest is to keep this as flexible as possible. So that I could
generate output to XSL:FO if I wanted, by just writing another output
class. I wonder why there wasn't defined a general output class from which
the existing ones inherit.
Does anyone have an idea of what would be the best way of implementing my idea?
I realize that probably it would be better to build up my own Object tree
using a SAX parser and then call
tree.outputPDF() or
tree.outputXSLFO()
But if I implement a class that can be used with JDOM others will profit
from it also.
Best regards, Roland
From mnott at vignette.com Wed Feb 6 14:50:33 2002
From: mnott at vignette.com (Nott, Matthias)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Character encoding from UTF-8 to ISO-8859-1
Message-ID:
Well, oracle has another opinion about the superset
situation. Try alter database character set utf8
on a latin1 database... -> is not a superset of...
M
-----Original Message-----
From: Alex Rosen [mailto:arosen@silverstream.com]
Sent: Wednesday, February 06, 2002 10:08 PM
To: 'Nott, Matthias'; 'dumdum 420'; jdom-interest@jdom.org
Subject: RE: [jdom-interest] Character encoding from UTF-8 to ISO-8859-1
> You cannot transcode exactly UTF-8 to Latin1 as UTF-8 has a richer
> set of characters
True - if your document contains chars that aren't in the character encoding
that you're using, such as Czech or Chinese characters if you're using
Latin1, then they need to be escaped as character reference, like "Ӓ".
I forget if XMLOutputter does this for you - I think it doesn't, but it's
planned for the future.
> and, especially, as UTF-8 is not a superset of Latin1.
No, all of Unicode is supported by UTF-8, and Unicode is a superset of the
Latin1 (ISO-8859-1) character set.
Alex
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
From hip at a.cs.okstate.edu Wed Feb 6 21:08:38 2002
From: hip at a.cs.okstate.edu (Bradley S. Huffman)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Re: XMLOutputter testing
In-Reply-To: Your message of "Tue, 05 Feb 2002 19:45:00 PST."
<3C60A6BC.A32554F8@servlets.com>
Message-ID: <200202070509.WAA08440@dorothy.denveronline.net>
Here's a patch, indent() was using the settings of the defaultFormat
instead of the currentFormat settings.
Also fixed a potential problem with the constructor XMLOutputter(XMLOutputter).
Brad
Jason Hunter writes:
> OK, I did a little more advanced testing and found another little bug in
> the xml:space behavior if trim all white is turned on.
>
> This file:
>
>
> Here goes the body and a xml:space="preserve" href="foo.html">link.
>
>
> becomes
>
>
>
> Here goes the body and a xml:space="preserve" href="foo.html">link.
>
>
> Which is nearly correct except I think " body" should be "body" because
> the tag set the space flag back to default which is trimming all.
> Correct?
====================== Cut Here ======================
*** XMLOutputter.java Wed Feb 6 22:53:52 2002
--- XMLOutputter.new Wed Feb 6 22:58:52 2002
***************
*** 214,220 ****
* - default is false */
private boolean omitEncoding = false;
! class Format {
/** standard value to indent by, if we are indenting */
static final String STANDARD_INDENT = " ";
--- 214,220 ----
* - default is false */
private boolean omitEncoding = false;
! class Format implements Cloneable {
/** standard value to indent by, if we are indenting */
static final String STANDARD_INDENT = " ";
***************
*** 245,250 ****
--- 245,260 ----
boolean newlines = false;
Format() {}
+
+ protected Object clone() {
+ Format format = null;
+
+ try {
+ format = (Format) super.clone();
+ } catch (CloneNotSupportedException ce) { }
+
+ return format;
+ }
}
Format noFormatting = new Format();
***************
*** 274,280 ****
* @param indent the indent string, usually some number of spaces
*/
public XMLOutputter(String indent) {
! defaultFormat.indent = indent;
}
/**
--- 284,290 ----
* @param indent the indent string, usually some number of spaces
*/
public XMLOutputter(String indent) {
! setIndent( indent);
}
/**
***************
*** 291,297 ****
* printed, else new lines are ignored (compacted).
*/
public XMLOutputter(String indent, boolean newlines) {
! defaultFormat.indent = indent;
setNewlines( newlines);
}
--- 301,307 ----
* printed, else new lines are ignored (compacted).
*/
public XMLOutputter(String indent, boolean newlines) {
! setIndent( indent);
setNewlines( newlines);
}
***************
*** 311,318 ****
* "UTF-8" or "ISO-8859-1" or "US-ASCII"
*/
public XMLOutputter(String indent, boolean newlines, String encoding) {
! this.encoding = encoding;
! defaultFormat.indent = indent;
setNewlines( newlines);
}
--- 321,328 ----
* "UTF-8" or "ISO-8859-1" or "US-ASCII"
*/
public XMLOutputter(String indent, boolean newlines, String encoding) {
! setEncoding( encoding);
! setIndent( indent);
setNewlines( newlines);
}
***************
*** 330,336 ****
this.encoding = that.encoding;
this.omitDeclaration = that.omitDeclaration;
this.omitEncoding = that.omitEncoding;
! this.defaultFormat = that.defaultFormat;
}
// * * * * * * * * * * Set parameters methods * * * * * * * * * *
--- 340,346 ----
this.encoding = that.encoding;
this.omitDeclaration = that.omitDeclaration;
this.omitEncoding = that.omitEncoding;
! this.defaultFormat = (Format) that.defaultFormat.clone();
}
// * * * * * * * * * * Set parameters methods * * * * * * * * * *
***************
*** 804,810 ****
// Output final line separator
// We output this no matter what the newline flags say
! out.write(defaultFormat.lineSeparator);
out.flush();
}
--- 814,820 ----
// Output final line separator
// We output this no matter what the newline flags say
! out.write(currentFormat.lineSeparator);
out.flush();
}
***************
*** 1694,1700 ****
*/
protected void newline(Writer out) throws IOException {
if (currentFormat.newlines)
! out.write(defaultFormat.lineSeparator);
}
/**
--- 1704,1710 ----
*/
protected void newline(Writer out) throws IOException {
if (currentFormat.newlines)
! out.write(currentFormat.lineSeparator);
}
/**
***************
*** 1723,1734 ****
*/
protected void indent(Writer out, int level) throws IOException {
if (currentFormat.newlines) {
! if (defaultFormat.indent == null ||
! defaultFormat.indent.equals(""))
return;
for (int i = 0; i < level; i++) {
! out.write(defaultFormat.indent);
}
}
}
--- 1733,1744 ----
*/
protected void indent(Writer out, int level) throws IOException {
if (currentFormat.newlines) {
! if (currentFormat.indent == null ||
! currentFormat.indent.equals(""))
return;
for (int i = 0; i < level; i++) {
! out.write(currentFormat.indent);
}
}
}
From laurent.bihanic at atosorigin.com Thu Feb 7 01:39:20 2002
From: laurent.bihanic at atosorigin.com (Laurent Bihanic)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Generating PDF output using JDOM with iText
References: <5.1.0.14.0.20020206202800.030f4540@mail.netquant.com.br>
Message-ID: <3C624B48.1090106@atosorigin.com>
Hi,
Roland wrote:
> Hello,
> I'm new to JDOM and here is what I want to do:
>
> I want to take the whole tree and make it output a PDF file using
> iText(http://www.lowagie.com/iText/).
> To those who don't know what iText is: it is a library that enables you
> to produce PDF documents from Java.
> I was thinking about adding a class to org.jdom.output to enable this.
>
> My interest is to keep this as flexible as possible. So that I could
> generate output to XSL:FO if I wanted, by just writing another output
> class. I wonder why there wasn't defined a general output class from
> which the existing ones inherit.
>
> Does anyone have an idea of what would be the best way of implementing
> my idea?
The best is to use the existing classes present in JDOM's core:
- To interface directly with iText, you can directly use SAXOutputter (There's
an example in iText tutorial that shows how to interface iText to a SAX parser
using SAXiTextHandler) but it seems iText only supports SAX1 while JDOM
supports SAX2. Without SAX2 support in iText this won't work.
- To interface with an XSLT processor that will rely on a stylesheet to
generate XSL-FO output, you can use the org.jdom.transform.JDOMSource which
extends the javax.xml.transform.sax.SAXSource recognized by all the XSLT
processors supporting the JAXP TrAX interface (Xalan, Saxon, jd-xslt...).
Hope this helps,
Laurent
From joern at muehlencord.de Thu Feb 7 04:46:59 2002
From: joern at muehlencord.de (Joern Muehlencord)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Jar-Archive
Message-ID: <3C627743.40407@muehlencord.de>
Hi out there,
is there any reason, why I cannot run my program out of a jar file,
since I am using JDOM?
java -jar -cp /path/to/jdom.jar myprog.jar
Exception in thread "main" java.lang.NoClassDefFoundError:
org/jdom/JDOMException
(jdom.jar ist listet in die Classpath as well.)
Do I have to include the classes as well? Or do I need a specel tag in
the manifest-file? Any hints?
Thanx
Joern
--
The box said "Requires Win95, NT, or better," and so I installed Linux.
From hip at a.cs.okstate.edu Thu Feb 7 07:50:00 2002
From: hip at a.cs.okstate.edu (Bradley S. Huffman)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] GetElementsByTagName in JDom ?
In-Reply-To: Your message of "Thu, 07 Feb 2002 10:26:38 EST."
<003201c1afeb$d6915a70$6a65810a@silverstream.com>
Message-ID: <200202071549.IAA08779@dorothy.denveronline.net>
Alex Rosen writes:
> I have no real opinion on this. It's not really something that I'd use, but
> if it's useful to others, and people think it's worth the effort, and the
> API increase, then it's fine with me. IIRC Brad made it public, and then we
> decided to make everything non-public for now, since we can always make it
> public later but not vice versa, right?
Right, and on second thought it probably should remain non-public (the actual
class that is) and manipulated through the List interface. There's the idea
of a method in Element:
public List getContent(Filter) {.....
But at the time we didn't really have any interesting filters that provided
additonal functionality beyond the other get* methods so it was left out
for the time being.
Brad
> > -----Original Message-----
> > From: Bilton, Sasha [mailto:Sasha.Bilton@bskyb.com]
> > Sent: Thursday, February 07, 2002 6:37 AM
> > To: 'Alex Rosen'
> > Subject: RE: [jdom-interest] GetElementsByTagName in JDom ?
> >
> >
> > > From: Alex Rosen [mailto:arosen@silverstream.com]
> > >
> > > Sure, that's what getChildren(String) does under the covers.
> > > (I believe that
> > > FilterList is currently planned to be an internal,
> > > implementation class, not
> > > a publicly accessible one.)
> >
> > Maybe I'm missing the point, but wouldn't FilterList make a
> > good addition to
> > the public API?
> >
> > Sasha
>
From jhunter at servlets.com Thu Feb 7 09:34:33 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Jar-Archive
References: <3C627743.40407@muehlencord.de>
Message-ID: <3C62BAA9.18004CAB@servlets.com>
I believe when you "-jar" run a JAR file it ignores the classpath.
You'd need to have supporting JARs in your MANIFEST.MF for them to be
found.
-jh-
Joern Muehlencord wrote:
>
> Hi out there,
>
> is there any reason, why I cannot run my program out of a jar file,
> since I am using JDOM?
>
> java -jar -cp /path/to/jdom.jar myprog.jar
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/jdom/JDOMException
> (jdom.jar ist listet in die Classpath as well.)
>
> Do I have to include the classes as well? Or do I need a specel tag in
> the manifest-file? Any hints?
>
> Thanx
> Joern
> --
> The box said "Requires Win95, NT, or better," and so I installed Linux.
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From jhunter at servlets.com Thu Feb 7 09:37:20 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] GetElementsByTagName in JDom ?
References: <200202071549.IAA08779@dorothy.denveronline.net>
Message-ID: <3C62BB50.C08F2A8A@servlets.com>
Right, I don't think FilterList needs to be public, but the methods to
get content based on a Filter should be public, including a method to
get content recursively.
-jh-
"Bradley S. Huffman" wrote:
>
> Alex Rosen writes:
>
> > I have no real opinion on this. It's not really something that I'd use, but
> > if it's useful to others, and people think it's worth the effort, and the
> > API increase, then it's fine with me. IIRC Brad made it public, and then we
> > decided to make everything non-public for now, since we can always make it
> > public later but not vice versa, right?
>
> Right, and on second thought it probably should remain non-public (the actual
> class that is) and manipulated through the List interface. There's the idea
> of a method in Element:
>
> public List getContent(Filter) {.....
>
> But at the time we didn't really have any interesting filters that provided
> additonal functionality beyond the other get* methods so it was left out
> for the time being.
>
> Brad
>
> > > -----Original Message-----
> > > From: Bilton, Sasha [mailto:Sasha.Bilton@bskyb.com]
> > > Sent: Thursday, February 07, 2002 6:37 AM
> > > To: 'Alex Rosen'
> > > Subject: RE: [jdom-interest] GetElementsByTagName in JDom ?
> > >
> > >
> > > > From: Alex Rosen [mailto:arosen@silverstream.com]
> > > >
> > > > Sure, that's what getChildren(String) does under the covers.
> > > > (I believe that
> > > > FilterList is currently planned to be an internal,
> > > > implementation class, not
> > > > a publicly accessible one.)
> > >
> > > Maybe I'm missing the point, but wouldn't FilterList make a
> > > good addition to
> > > the public API?
> > >
> > > Sasha
> >
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From roland at netquant.com.br Thu Feb 7 11:46:33 2002
From: roland at netquant.com.br (Roland)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Is there a PDFOutputter anywhere?
Message-ID: <5.1.0.14.0.20020207174512.03108dd0@mail.netquant.com.br>
Hello,
I want to write a new class PDFOutputter using iText. Has anyone tried this
before? Can you send me the code sample if so?
Thanks Roland
From noamt at yahoo.com Thu Feb 7 12:56:39 2002
From: noamt at yahoo.com (Noam Tamim)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Re: [jdom-commits] CVS update: jdom
In-Reply-To: <20020207134659.0FAB21D801D@jools.org>
Message-ID: <20020207205639.81089.qmail@web13904.mail.yahoo.com>
Is there a mechanism in CVS that can show you what of the TODO list was done
in the last few months?
--- cvs@jools.org wrote:
> Modified Files:
> TODO.txt
> Log Message:
> Marking off things that have been accomplished. A good feeling.
=====
_______
Noam.
__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com
From dumdum420 at hotmail.com Fri Feb 8 07:26:58 2002
From: dumdum420 at hotmail.com (dumdum 420)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Character encoding from UTF-8 to ISO-8859-1
Message-ID:
Well thanks for all your suggestions!!
I got a very very interesting bit of solution!!!???
We have a WIN2K box and an AIX(IBM-Unix) box. Now I has done something like
this in my code.
FileInputStream fis = new FileInputStream(filePath);
// ensuring that the feed of XML file is UFT-8 this is important I wonder
though why?
InputStreamReader isr = new InputStreamReader(fis,"UTF-8");
String s = isr.getEncoding();
System.out.println(s);
Document doc = builder.build(isr);
Element root = doc.getRootElement();
bytes [] b = root.getElement("xxxxxx").getText().getBytes();
//converting to ISO-8859-1
String s = new String(b,"ISO-8859-1");
Now when I saved this string to ORACLE database it worked perfect.
But that is not all of it. I workked fine on W2K and on AIX it still could
not handle the EURO(€) character.
Now this was intersting that both the JVMs ,that of W2K and AIX are handling
the situations in a different fashion.
Anyways I got a situation soleved for the moment but it would have been
better that I could have done it on AIX avaoiding me to have a workaround
and wrting a RMI call for this updation.
Thanks a lot and any suggestions for this kind of behavior will really help
further.
Thanks.
dumdum420
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
From ADEVASIA at mobius.com Fri Feb 8 12:18:03 2002
From: ADEVASIA at mobius.com (Alex Devasia)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] XMLOutputter problem
Message-ID: <89B3700F1199D411A0CB00508BEE227E013C8099@ryentes1.mobius.com>
I notice blank lines get inserted between lines each time I edit an XML
file. The class is constructed as follows:
m_xmlOutputter = new XMLOutputter(" ", true);
I don't want to call m_xmlOutputter.setTextNormalize(true) because it
removes whitespace from actual values being written to the file. I just want
to prevent blank lines from being written to the file. Can I fix this
problem by calling some other method. I hope this gets fixed in version 8.
Thanks
From jhunter at servlets.com Fri Feb 8 12:59:27 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] XMLOutputter problem
References: <89B3700F1199D411A0CB00508BEE227E013C8099@ryentes1.mobius.com>
Message-ID: <3C643C2F.B6E153AC@servlets.com>
Your passing "true" indicates you want newlines added. Don't pass
true. You probably don't want to pass " " for the indent either. Just
use the default XMLOutputter constructor.
-jh-
Alex Devasia wrote:
>
> I notice blank lines get inserted between lines each time I edit an XML
> file. The class is constructed as follows:
> m_xmlOutputter = new XMLOutputter(" ", true);
> I don't want to call m_xmlOutputter.setTextNormalize(true) because it
> removes whitespace from actual values being written to the file. I just want
> to prevent blank lines from being written to the file. Can I fix this
> problem by calling some other method. I hope this gets fixed in version 8.
>
> Thanks
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From Jason.Robertson at acs-inc.com Fri Feb 8 13:20:07 2002
From: Jason.Robertson at acs-inc.com (Robertson, Jason)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] XMLOutputter problem
Message-ID:
If I'm to make an assumption about Alex's problem, there are meaningless
blank lines added to the document when it's saved. I think he wants the
newlines and the indent because he wants it to be pretty for a human. I have
the same problem but didn't care enough to ask about it. In my app, I have a
little class to merge several web.xml files and I get output like this:
Servlet1
com.me.Servlet1
Servlet2
com.me.Servlet2
...
See the blank lines occurring before the close tag? I think that's what he's
talking about. If he's not, then hey, anyone know how to solve this problem?
I'm using b7 and haven't tried pulling the latest code.
Jason
-----Original Message-----
From: Jason Hunter [mailto:jhunter@servlets.com]
Sent: Friday, February 08, 2002 3:59 PM
To: Alex Devasia
Cc: 'jdom-interest@jdom.org'
Subject: Re: [jdom-interest] XMLOutputter problem
Your passing "true" indicates you want newlines added. Don't pass
true. You probably don't want to pass " " for the indent either. Just
use the default XMLOutputter constructor.
-jh-
Alex Devasia wrote:
>
> I notice blank lines get inserted between lines each time I edit an XML
> file. The class is constructed as follows:
> m_xmlOutputter = new XMLOutputter(" ", true);
> I don't want to call m_xmlOutputter.setTextNormalize(true) because it
> removes whitespace from actual values being written to the file. I just
want
> to prevent blank lines from being written to the file. Can I fix this
> problem by calling some other method. I hope this gets fixed in version 8.
>
> Thanks
>
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
From ADEVASIA at mobius.com Fri Feb 8 13:33:56 2002
From: ADEVASIA at mobius.com (Alex Devasia)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] XMLOutputter problem
Message-ID: <89B3700F1199D411A0CB00508BEE227E013C809B@ryentes1.mobius.com>
That's the same problem. Each time my application runs a user can edit/add
entries that get written out to the XML file. Every time the file is written
to the number of blank lines keep increasing, as the file grows the # of
blank lines go up too.
-Alex
-----Original Message-----
From: Robertson, Jason [mailto:Jason.Robertson@acs-inc.com]
Sent: Friday, February 08, 2002 4:20 PM
To: 'Jason Hunter'; Alex Devasia
Cc: 'jdom-interest@jdom.org'
Subject: RE: [jdom-interest] XMLOutputter problem
If I'm to make an assumption about Alex's problem, there are meaningless
blank lines added to the document when it's saved. I think he wants the
newlines and the indent because he wants it to be pretty for a human. I have
the same problem but didn't care enough to ask about it. In my app, I have a
little class to merge several web.xml files and I get output like this:
Servlet1
com.me.Servlet1
Servlet2
com.me.Servlet2
...
See the blank lines occurring before the close tag? I think that's what he's
talking about. If he's not, then hey, anyone know how to solve this problem?
I'm using b7 and haven't tried pulling the latest code.
Jason
-----Original Message-----
From: Jason Hunter [mailto:jhunter@servlets.com]
Sent: Friday, February 08, 2002 3:59 PM
To: Alex Devasia
Cc: 'jdom-interest@jdom.org'
Subject: Re: [jdom-interest] XMLOutputter problem
Your passing "true" indicates you want newlines added. Don't pass
true. You probably don't want to pass " " for the indent either. Just
use the default XMLOutputter constructor.
-jh-
Alex Devasia wrote:
>
> I notice blank lines get inserted between lines each time I edit an XML
> file. The class is constructed as follows:
> m_xmlOutputter = new XMLOutputter(" ", true);
> I don't want to call m_xmlOutputter.setTextNormalize(true) because it
> removes whitespace from actual values being written to the file. I just
want
> to prevent blank lines from being written to the file. Can I fix this
> problem by calling some other method. I hope this gets fixed in version 8.
>
> Thanks
>
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
From jhunter at servlets.com Fri Feb 8 13:42:49 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] O'Reilly Open Source Convention Call For Speakers
Message-ID: <3C644659.83E8F92D@servlets.com>
>> CALL FOR SPEAKERS
Hi everyone,
I'm helping manage the Java Track at the O'Reilly Open Source Conference
this coming July. Below is the call for speakers in the hope that some
of you may be interested in speaking.
If you've created an open source product, here's your chance to talk
about it. If you're a power user of open source software, you can talk
about your experiences.
There are other tracks besides Java as well. :-)
-jh-
--
O'Reilly Open Source Convention
Sheraton San Diego Hotel and Marina
July 22-26, 2002 -- San Diego, CA
>> Call for Participation - Java Track
>> Proposals Due: March 1, 2002
The theme of this year's Open Source Convention is "Doing More With
Less."
This has several aspects: how business can do more with less money (by
adopting open source software), how developers do more with less time
and
financial support, how to make the most of what you've got (performance
tuning and little-known-of features), and how open source software
manages
to avoid the bloat that characterizes closed-source software.
The Java Open Source community is rich and varied with many projects
such as
Tomcat, Ant, JBoss, Avalon, OpenJMS, OpenEJB, Xerces, Xalan, Jikes,
NetBeans, and many more hosted by a variety of organizations. In
addition,
platform support for Java is expanding with the recent release of Mac OS
X
supporting JDK 1.3 and the upcoming release of the JDK for FreeBSD. In
this
rich open environment for Java, there is room for a variety of
presentations
on many topics.
Individuals and companies interested in making presentations, giving a
tutorial, or participating in panel discussions regarding operating
systems
at this year's Open Source Convention are invited to submit proposals.
Proposals will be considered in two classes: tutorials and convention
presentations (sessions).
Presentations by marketing staff or with a marketing focus will not be
accepted; neither will submissions made by anyone other than the
proposed
speaker.
Session presentations are 45 or 90 minutes long, and tutorials are
either a
half-day (3 hours) or a full day (6 hours). If you are interested in
participating in or moderating panel discussions, or otherwise
contributing
to the conference, please let us know (and please include your area of
expertise). If you have an idea for a panel discussion or a particularly
provocative group of panelists that you'd love to see square off, feel
free
to send your suggestions to osconidea@oreilly.com.
We are also planning 180 minutes of lightning talks on Friday. A
lightning
talk is a 5-minute tightly-focused presentation on any subject you like.
You
can discuss your favorite extension, rant, sing the praises of an
under-appreciated developer, plug your product or company, beg for a
job, or
even present a Shakespearean-style play (don't laugh--we had one of
these in
2001). Submit a lightning talk proposal using the form below. The
lightning
talk schedule will be announced a few weeks prior to the conference.
>> Submitting Proposals
Proposals may be submitted using the form at
http://conferences.oreillynet.com/cs/os2002/create/e_sess
Keep in mind that proposals need not be works of art. A quick summary or
abstract of the talk you plan to give is sufficient for consideration.
We
prefer outlines for tutorials. The proposal is what the conference
committees uses to select speakers, so give enough information that the
committee can tell what you'll be covering. As the conference
approaches, we
will request additional information about your proposal as necessary.
NOTE: All presenters whose talks are accepted (excluding Lightning
Talks)
will receive free registration at the conference. For each half-day
tutorial, the presenter receives one night's accommodation, a travel
allowance, and an honorarium. Registration will open April 1, 2002. If
you
would like an email notification when registration opens, please use the
form at
http://conferences.oreillynet.com/os2002/
>> Important Dates
Proposals Due: March 1, 2002
Speaker Notification: March 11, 2002
Presentation Files Due: April 29, 2002
From jhunter at servlets.com Fri Feb 8 13:50:52 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] XMLOutputter problem
References:
Message-ID: <3C64483C.F6164956@servlets.com>
The sometimes-extra-lines was a known issue in b7 (see the TODO from
back then) but it's fixed in the latest CVS.
-jh-
"Robertson, Jason" wrote:
>
> If I'm to make an assumption about Alex's problem, there are meaningless
> blank lines added to the document when it's saved. I think he wants the
> newlines and the indent because he wants it to be pretty for a human. I have
> the same problem but didn't care enough to ask about it. In my app, I have a
> little class to merge several web.xml files and I get output like this:
>
>
>
>
> Servlet1
> com.me.Servlet1
>
>
>
> Servlet2
> com.me.Servlet2
>
>
> ...
>
>
> See the blank lines occurring before the close tag? I think that's what he's
> talking about. If he's not, then hey, anyone know how to solve this problem?
>
> I'm using b7 and haven't tried pulling the latest code.
>
> Jason
>
> -----Original Message-----
> From: Jason Hunter [mailto:jhunter@servlets.com]
> Sent: Friday, February 08, 2002 3:59 PM
> To: Alex Devasia
> Cc: 'jdom-interest@jdom.org'
> Subject: Re: [jdom-interest] XMLOutputter problem
>
> Your passing "true" indicates you want newlines added. Don't pass
> true. You probably don't want to pass " " for the indent either. Just
> use the default XMLOutputter constructor.
>
> -jh-
>
> Alex Devasia wrote:
> >
> > I notice blank lines get inserted between lines each time I edit an XML
> > file. The class is constructed as follows:
> > m_xmlOutputter = new XMLOutputter(" ", true);
> > I don't want to call m_xmlOutputter.setTextNormalize(true) because it
> > removes whitespace from actual values being written to the file. I just
> want
> > to prevent blank lines from being written to the file. Can I fix this
> > problem by calling some other method. I hope this gets fixed in version 8.
> >
> > Thanks
> >
> > _______________________________________________
> > To control your jdom-interest membership:
> >
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> t.com
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> t.com
From tonyl at pillarsoftware.com Fri Feb 8 14:19:08 2002
From: tonyl at pillarsoftware.com (tonyl@pillarsoftware.com)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] O'Reilly Open Source Convention Call For Speakers
References: <3C644659.83E8F92D@servlets.com>
Message-ID: <017a01c1b0ee$a0bc8920$f46ede3f@THOTH>
I have been using Open Source over 13 years. I am 39 and have been coding
since I was 15
back in 1978 when I started on TRASH 80!
I was chief architect and systems programmer for system that handles
trillions of dollars in Foreign Currency Transactions each year. Billions
each day..!! The bank is running for is HUGE. Handles 1/6 of the worlds
assets.
It was coded using almost ALL open source tools.
Solaris EMACS
Solaris GNU C++
Solaris Bison
Solaris Flex
Solaris Perl
Solaris PHP
I WOULD love to talk and really pay Richard Stallman the credit he richly
deserves.
I consider myself an authority on GNU Software, having read and studied alot
of the source code
for over a decade.
While not Java...I can trace the roots of Open Source and show how Open
Source software is
BETTER that ANYTHING offered commercially. I will show how BIG Global
Corporations
use and TRUST Open Source with TRILLIONS of dollars.
I also...however...can temper that rant with the real world problems of
using Open Source.
Tony Leotta
President |
Pillar Software, Inc.
http://www.pillarsoftware.com/
----- Original Message -----
From: "Jason Hunter"
To: "JDOM Interest"
Sent: Friday, February 08, 2002 4:42 PM
Subject: [jdom-interest] O'Reilly Open Source Convention Call For Speakers
> >> CALL FOR SPEAKERS
>
> Hi everyone,
>
> I'm helping manage the Java Track at the O'Reilly Open Source Conference
> this coming July. Below is the call for speakers in the hope that some
> of you may be interested in speaking.
>
> If you've created an open source product, here's your chance to talk
> about it. If you're a power user of open source software, you can talk
> about your experiences.
>
> There are other tracks besides Java as well. :-)
>
> -jh-
>
> --
>
> O'Reilly Open Source Convention
> Sheraton San Diego Hotel and Marina
> July 22-26, 2002 -- San Diego, CA
>
> >> Call for Participation - Java Track
> >> Proposals Due: March 1, 2002
>
> The theme of this year's Open Source Convention is "Doing More With
> Less."
> This has several aspects: how business can do more with less money (by
> adopting open source software), how developers do more with less time
> and
> financial support, how to make the most of what you've got (performance
> tuning and little-known-of features), and how open source software
> manages
> to avoid the bloat that characterizes closed-source software.
>
> The Java Open Source community is rich and varied with many projects
> such as
> Tomcat, Ant, JBoss, Avalon, OpenJMS, OpenEJB, Xerces, Xalan, Jikes,
> NetBeans, and many more hosted by a variety of organizations. In
> addition,
> platform support for Java is expanding with the recent release of Mac OS
> X
> supporting JDK 1.3 and the upcoming release of the JDK for FreeBSD. In
> this
> rich open environment for Java, there is room for a variety of
> presentations
> on many topics.
>
> Individuals and companies interested in making presentations, giving a
> tutorial, or participating in panel discussions regarding operating
> systems
> at this year's Open Source Convention are invited to submit proposals.
> Proposals will be considered in two classes: tutorials and convention
> presentations (sessions).
>
> Presentations by marketing staff or with a marketing focus will not be
> accepted; neither will submissions made by anyone other than the
> proposed
> speaker.
>
> Session presentations are 45 or 90 minutes long, and tutorials are
> either a
> half-day (3 hours) or a full day (6 hours). If you are interested in
> participating in or moderating panel discussions, or otherwise
> contributing
> to the conference, please let us know (and please include your area of
> expertise). If you have an idea for a panel discussion or a particularly
> provocative group of panelists that you'd love to see square off, feel
> free
> to send your suggestions to osconidea@oreilly.com.
>
> We are also planning 180 minutes of lightning talks on Friday. A
> lightning
> talk is a 5-minute tightly-focused presentation on any subject you like.
> You
> can discuss your favorite extension, rant, sing the praises of an
> under-appreciated developer, plug your product or company, beg for a
> job, or
> even present a Shakespearean-style play (don't laugh--we had one of
> these in
> 2001). Submit a lightning talk proposal using the form below. The
> lightning
> talk schedule will be announced a few weeks prior to the conference.
>
> >> Submitting Proposals
>
> Proposals may be submitted using the form at
>
> http://conferences.oreillynet.com/cs/os2002/create/e_sess
>
> Keep in mind that proposals need not be works of art. A quick summary or
> abstract of the talk you plan to give is sufficient for consideration.
> We
> prefer outlines for tutorials. The proposal is what the conference
> committees uses to select speakers, so give enough information that the
> committee can tell what you'll be covering. As the conference
> approaches, we
> will request additional information about your proposal as necessary.
>
> NOTE: All presenters whose talks are accepted (excluding Lightning
> Talks)
> will receive free registration at the conference. For each half-day
> tutorial, the presenter receives one night's accommodation, a travel
> allowance, and an honorarium. Registration will open April 1, 2002. If
> you
> would like an email notification when registration opens, please use the
> form at
>
> http://conferences.oreillynet.com/os2002/
>
> >> Important Dates
>
> Proposals Due: March 1, 2002
> Speaker Notification: March 11, 2002
> Presentation Files Due: April 29, 2002
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
From joern at muehlencord.de Sat Feb 9 09:15:33 2002
From: joern at muehlencord.de (Joern Muehlencord)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] Jar-Archive
References: <3C627743.40407@muehlencord.de> <3C62BAA9.18004CAB@servlets.com>
Message-ID: <3C655935.36D18111@muehlencord.de>
Hi Jason,
> I believe when you "-jar" run a JAR file it ignores the classpath.
> You'd need to have supporting JARs in your MANIFEST.MF for them to be
> found.
That is right. I needed to include "Class-Path: jdom.jar" to the
manifest-file. xerces.jar is not needed - it is included bei jdom.jar.
Now it is ok, to put all three archives into one directory and start the
application out of the jar-file.
Thanx
Joern
--
Linux is like a wigwam - no Windows, no Gates and Apache inside
From jhunter at acm.org Sun Feb 10 18:11:30 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] JavaOne presentations (flame)
Message-ID: <3C672852.EA22DDE5@acm.org>
I just have to vent, and this crowd seems like a fine place to vent
about this particular thing.
I'm presenting a talk on JDOM at JavaOne this year, and Oh My God, the
slide submittal process is horrid. Absolutely draconian. Unlike *every
other conference* I've spoken at (dozens), at JavaOne there are people
who critique your slides on various Rules. These Rules are definitely
smart guidelines but at JavaOne they are literally *Rules*. If you
don't pass each and every rule down the line, they don't let you give
you talk.
One sample rule: You need a graphic on at least one out of every 6
pages. Need it or not, appropriate or not, you need a graphic. It's
supposed to keep your audience awake. Well, I guess I have to come up
with a graphic for the section where I compare JDOM with DOM. Any
ideas? I wonder if a picture from Anna Kournikova's new calendar would
do.
Another rule: You should have no more than six words per bullet point.
Wait, did I say "should"? I mean MUST as in the W3C spec meaning of the
word. Nothing longer than six words is .
That last one really bugs me. I personally find JavaOne slides 100%
useless after the talk because of this rule. I've downloaded slides in
years past from talks I couldn't attend. Here's what you get:
* JVM Performance In Process
* Garbage Collection In Real Time
Oh yeah, I'm really learning now. They say this rule is to keep the
point size up so you can read the slides during the show, but seems to
me:
* If you're in the show you're listening, not reading
* If you're not in the show, you can only read
(Notice the effective use of 9 word bullets there.)
So with big point sizes you can read my outline during the show, but
after I'm done talking, all the points are lost.
I was proud and I stood my moral ground and flaunted the rules -- I used
graphics only when I needed graphics and I tried to actually *say
something* with each bullet point. But no. The people reviewing the
talks actually counted my words and my graphic densities. I failed.
I'm told I need to revise now.
What's really ironic is last year the same basic slide outline was
accepted. I was just unlucky enough this year to get the Presentation
Nazi. I can almost hear him yell: "No presentation for you, one year!"
Maybe you're thinking I should obligingly bow to the "Rules" and be
tricky and bring my own slides in on a laptop on the presentation day.
No can do; they're on to that! You can't bring your own laptop to
present. Every other conference I've spoken at lets you. Why not at
JavaOne? They say it's to keep things simpler to setup, but really how
simple is it for me to load JDOM examples on their machine versus my
own?? Here's my theory: if anyone ever tries to make The Training
Alliance Nazis (tm) look bad (you know, someone in a bad mood -- try to
picture it), they'll know beforehand and have some leverage to encourage
you to change your slides.
I agree these guidelines make sense in general, but can we give the
speakers no credit? The best talks I've ever attended have slides that
don't in any way follow the JavaOne Rules. And some of the worst talks
I've ever attended have been at JavaOne. Maybe they're trying to raise
up the quality of these poor talks by rigidly enforcing these rules. I
think it's more likely they're creating poor talks by enforcing these
rules.
Ah well. At least I can still say what I want on stage. Um, probably.
I'll let you know if they actually let me speak live on stage or if it's
a tape recording.
-jh-
P.S. Sun speakers suffer from this just as much as outside people.
This is another reason why no one at Sun looks very happy the month
before JavaOne.
P.P.S. The slides haven't even gone to legal review yet. Last year in
legal review they changed "JDOM" to "The Document Object Model for Java"
on me and for a long time refused to change it back. You'd think they
would believe I knew the name of my project.
From Frank.Sauer at trcinc.com Sun Feb 10 20:28:31 2002
From: Frank.Sauer at trcinc.com (Frank Sauer)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] JavaOne presentations (flame)
Message-ID: <3BAC15E02315BC4783152AC5E9621BB516A159@trcexcsrv01.trcinc.com>
Wow, do you work for SUN now? How in the world did you get in
in the first place? I wish I had to deal with the slide nazis but I have yet
to meet the first non-SUN JavaOne speaker. Just venting, let's all vent :-)
Frank
P.S. I know you don't work for Sun, but with JDOM being a JSR and all,
I'm not too surprised to see you made it.
P.P.S. Good Luck! and I'll see you at JavaOne (but not as a speaker myself)
-----Original Message-----
From: Jason Hunter [mailto:jhunter@acm.org]
Sent: Sun 2/10/2002 9:11 PM
To: JDOM Interest
Cc:
Subject: [jdom-interest] JavaOne presentations (flame)
I just have to vent, and this crowd seems like a fine place to vent
about this particular thing.
I'm presenting a talk on JDOM at JavaOne this year, and Oh My God, the
slide submittal process is horrid. Absolutely draconian. Unlike *every
other conference* I've spoken at (dozens), at JavaOne there are people
who critique your slides on various Rules. These Rules are definitely
smart guidelines but at JavaOne they are literally *Rules*. If you
don't pass each and every rule down the line, they don't let you give
you talk.
One sample rule: You need a graphic on at least one out of every 6
pages. Need it or not, appropriate or not, you need a graphic. It's
supposed to keep your audience awake. Well, I guess I have to come up
with a graphic for the section where I compare JDOM with DOM. Any
ideas? I wonder if a picture from Anna Kournikova's new calendar would
do.
Another rule: You should have no more than six words per bullet point.
Wait, did I say "should"? I mean MUST as in the W3C spec meaning of the
word. Nothing longer than six words is .
That last one really bugs me. I personally find JavaOne slides 100%
useless after the talk because of this rule. I've downloaded slides in
years past from talks I couldn't attend. Here's what you get:
* JVM Performance In Process
* Garbage Collection In Real Time
Oh yeah, I'm really learning now. They say this rule is to keep the
point size up so you can read the slides during the show, but seems to
me:
* If you're in the show you're listening, not reading
* If you're not in the show, you can only read
(Notice the effective use of 9 word bullets there.)
So with big point sizes you can read my outline during the show, but
after I'm done talking, all the points are lost.
I was proud and I stood my moral ground and flaunted the rules -- I used
graphics only when I needed graphics and I tried to actually *say
something* with each bullet point. But no. The people reviewing the
talks actually counted my words and my graphic densities. I failed.
I'm told I need to revise now.
What's really ironic is last year the same basic slide outline was
accepted. I was just unlucky enough this year to get the Presentation
Nazi. I can almost hear him yell: "No presentation for you, one year!"
Maybe you're thinking I should obligingly bow to the "Rules" and be
tricky and bring my own slides in on a laptop on the presentation day.
No can do; they're on to that! You can't bring your own laptop to
present. Every other conference I've spoken at lets you. Why not at
JavaOne? They say it's to keep things simpler to setup, but really how
simple is it for me to load JDOM examples on their machine versus my
own?? Here's my theory: if anyone ever tries to make The Training
Alliance Nazis (tm) look bad (you know, someone in a bad mood -- try to
picture it), they'll know beforehand and have some leverage to encourage
you to change your slides.
I agree these guidelines make sense in general, but can we give the
speakers no credit? The best talks I've ever attended have slides that
don't in any way follow the JavaOne Rules. And some of the worst talks
I've ever attended have been at JavaOne. Maybe they're trying to raise
up the quality of these poor talks by rigidly enforcing these rules. I
think it's more likely they're creating poor talks by enforcing these
rules.
Ah well. At least I can still say what I want on stage. Um, probably.
I'll let you know if they actually let me speak live on stage or if it's
a tape recording.
-jh-
P.S. Sun speakers suffer from this just as much as outside people.
This is another reason why no one at Sun looks very happy the month
before JavaOne.
P.P.S. The slides haven't even gone to legal review yet. Last year in
legal review they changed "JDOM" to "The Document Object Model for Java"
on me and for a long time refused to change it back. You'd think they
would believe I knew the name of my project.
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From psilvey at mitre.org Mon Feb 11 07:23:12 2002
From: psilvey at mitre.org (Paul Silvey)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] JavaOne presentations (flame)
In-Reply-To: <3C672852.EA22DDE5@acm.org>
References: <3C672852.EA22DDE5@acm.org>
Message-ID:
Jason,
No matter what you end up having to do, please post a copy of the
slides you would have liked to use somewhere that others can access
freely. I've always enjoyed your presentation material because it is
useful without the voice-track. If you want to start an e-mail
petition, let me know, and I'll support your view to whomever it may
concern at Sun.
-Paul Silvey
The MITRE Corporation
>I just have to vent, and this crowd seems like a fine place to vent
>about this particular thing.
>
>I'm presenting a talk on JDOM at JavaOne this year, and Oh My God, the
>slide submittal process is horrid. Absolutely draconian. Unlike *every
>other conference* I've spoken at (dozens), at JavaOne there are people
>who critique your slides on various Rules. These Rules are definitely
>smart guidelines but at JavaOne they are literally *Rules*. If you
>don't pass each and every rule down the line, they don't let you give
>you talk.
>
>One sample rule: You need a graphic on at least one out of every 6
>pages. Need it or not, appropriate or not, you need a graphic. It's
>supposed to keep your audience awake. Well, I guess I have to come up
>with a graphic for the section where I compare JDOM with DOM. Any
>ideas? I wonder if a picture from Anna Kournikova's new calendar would
>do.
>
>Another rule: You should have no more than six words per bullet point.
>Wait, did I say "should"? I mean MUST as in the W3C spec meaning of the
>word. Nothing longer than six words is .
>
>That last one really bugs me. I personally find JavaOne slides 100%
>useless after the talk because of this rule. I've downloaded slides in
>years past from talks I couldn't attend. Here's what you get:
>
>* JVM Performance In Process
>* Garbage Collection In Real Time
>
>Oh yeah, I'm really learning now. They say this rule is to keep the
>point size up so you can read the slides during the show, but seems to
>me:
>
>* If you're in the show you're listening, not reading
>* If you're not in the show, you can only read
>
>(Notice the effective use of 9 word bullets there.)
>
>So with big point sizes you can read my outline during the show, but
>after I'm done talking, all the points are lost.
>
>I was proud and I stood my moral ground and flaunted the rules -- I used
>graphics only when I needed graphics and I tried to actually *say
>something* with each bullet point. But no. The people reviewing the
>talks actually counted my words and my graphic densities. I failed.
>I'm told I need to revise now.
>
>What's really ironic is last year the same basic slide outline was
>accepted. I was just unlucky enough this year to get the Presentation
>Nazi. I can almost hear him yell: "No presentation for you, one year!"
>
>Maybe you're thinking I should obligingly bow to the "Rules" and be
>tricky and bring my own slides in on a laptop on the presentation day.
>No can do; they're on to that! You can't bring your own laptop to
>present. Every other conference I've spoken at lets you. Why not at
>JavaOne? They say it's to keep things simpler to setup, but really how
>simple is it for me to load JDOM examples on their machine versus my
>own?? Here's my theory: if anyone ever tries to make The Training
>Alliance Nazis (tm) look bad (you know, someone in a bad mood -- try to
>picture it), they'll know beforehand and have some leverage to encourage
>you to change your slides.
>
>I agree these guidelines make sense in general, but can we give the
>speakers no credit? The best talks I've ever attended have slides that
>don't in any way follow the JavaOne Rules. And some of the worst talks
>I've ever attended have been at JavaOne. Maybe they're trying to raise
>up the quality of these poor talks by rigidly enforcing these rules. I
>think it's more likely they're creating poor talks by enforcing these
>rules.
>
>Ah well. At least I can still say what I want on stage. Um, probably.
>I'll let you know if they actually let me speak live on stage or if it's
>a tape recording.
>
>-jh-
>
>P.S. Sun speakers suffer from this just as much as outside people.
>This is another reason why no one at Sun looks very happy the month
>before JavaOne.
>
>P.P.S. The slides haven't even gone to legal review yet. Last year in
>legal review they changed "JDOM" to "The Document Object Model for Java"
>on me and for a long time refused to change it back. You'd think they
>would believe I knew the name of my project.
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@
>yourhost.com
From jhunter at acm.org Mon Feb 11 09:38:35 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:21 2004
Subject: [jdom-interest] JavaOne presentations (flame)
References: <3BAC15E02315BC4783152AC5E9621BB516A159@trcexcsrv01.trcinc.com>
Message-ID: <3C68019B.C151441E@acm.org>
Frank Sauer wrote:
>
> Wow, do you work for SUN now? How in the world did you get in
> in the first place? I wish I had to deal with the slide nazis but I have yet
> to meet the first non-SUN JavaOne speaker. Just venting, let's all vent :-)
Ha! Good question. The talk actually wasn't accepted at first. And
you're right, JavaOne is notorious for having dozens of talks about
Sun's favorite new technology (ie JSP taglibs) and missing out on whole
swaths of interesting other technologies (ie Apache Velocity). Last
year there were at least a dozen JAXP talks. As if you couldn't
understand all of JAXP in one short talk. And JDOM was left as an
alternate talk. This year I had to do a little lobbying after the
initial refusal. I think it helped that JDOM was a JSR and that I'm
Apache's representative to the JCP Executive Committee.
> P.P.S. Good Luck! and I'll see you at JavaOne (but not as a speaker myself)
Well, you could always join Sun. :-)
-jh-
From hip at a.cs.okstate.edu Mon Feb 11 13:08:44 2002
From: hip at a.cs.okstate.edu (Bradley S. Huffman)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] JavaOne presentations (flame)
In-Reply-To: Your message of "Mon, 11 Feb 2002 09:38:35 PST."
<3C68019B.C151441E@acm.org>
Message-ID: <200202112108.OAA17872@dorothy.denveronline.net>
What do you expect when they are the head rats in charge of the cheese. I
think for your talk you should dye your hair pink and wear a t-shirt that
says "Large coporate advertising disguised as a conference still sucks!"
:->
Jason Hunter writes:
> Frank Sauer wrote:
> > Wow, do you work for SUN now? How in the world did you get in
> > in the first place? I wish I had to deal with the slide nazis but I have yet
> > to meet the first non-SUN JavaOne speaker. Just venting, let's all vent :-)
>
> Ha! Good question. The talk actually wasn't accepted at first. And
> you're right, JavaOne is notorious for having dozens of talks about
> Sun's favorite new technology (ie JSP taglibs) and missing out on whole
> swaths of interesting other technologies (ie Apache Velocity). Last
> year there were at least a dozen JAXP talks. As if you couldn't
> understand all of JAXP in one short talk. And JDOM was left as an
> alternate talk. This year I had to do a little lobbying after the
> initial refusal. I think it helped that JDOM was a JSR and that I'm
> Apache's representative to the JCP Executive Committee.
From mike.bosch at benefitpoint.com Mon Feb 11 13:55:33 2002
From: mike.bosch at benefitpoint.com (Bosch, Mike)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] JavaOne presentations (flame)
Message-ID: <055A2E9C6E53D41196B800508BAC041F027A0C84@maybach.benefitpoint.com>
Which in addition you get the "privilege" of paying ~$2000 to go and listen
to corporate advertising.
Count me out on the conference unless one of our vendors gets me in.
-Mike
-----Original Message-----
From: Bradley S. Huffman [mailto:hip@a.cs.okstate.edu]
Sent: Monday, February 11, 2002 1:09 PM
To: jdom-interest@jdom.org
Subject: Re: [jdom-interest] JavaOne presentations (flame)
What do you expect when they are the head rats in charge of the cheese. I
think for your talk you should dye your hair pink and wear a t-shirt that
says "Large coporate advertising disguised as a conference still sucks!"
:->
Jason Hunter writes:
> Frank Sauer wrote:
> > Wow, do you work for SUN now? How in the world did you get in
> > in the first place? I wish I had to deal with the slide nazis but I have
yet
> > to meet the first non-SUN JavaOne speaker. Just venting, let's all vent
:-)
>
> Ha! Good question. The talk actually wasn't accepted at first. And
> you're right, JavaOne is notorious for having dozens of talks about
> Sun's favorite new technology (ie JSP taglibs) and missing out on whole
> swaths of interesting other technologies (ie Apache Velocity). Last
> year there were at least a dozen JAXP talks. As if you couldn't
> understand all of JAXP in one short talk. And JDOM was left as an
> alternate talk. This year I had to do a little lobbying after the
> initial refusal. I think it helped that JDOM was a JSR and that I'm
> Apache's representative to the JCP Executive Committee.
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
From jonbaer at digitalanywhere.com Mon Feb 11 14:35:59 2002
From: jonbaer at digitalanywhere.com (Jon Baer)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] JavaOne presentations (flame)
References: <055A2E9C6E53D41196B800508BAC041F027A0C84@maybach.benefitpoint.com>
Message-ID: <3C68474F.68378CDF@digitalanywhere.com>
Thank you, thank you, thank you.
Not for nothing, but I thought I was the only one who felt like that. I had
personally wasted alot of time, energy, and money @ these types of conferences (where
it seemed like the talker was very restricted and seemed smart but made no sense) and
yet when all is said and done I actually learn more from free seminars/slides from
people like Elliotte and such. Someone should tell Sun that when they try to be a
little "too controlling" they end up being like some other company we know. Now
quite honestly I can understand that some guidelines when applied to open source are
needed to avoid all out chaos but when you have done so much for the community
already and ur name is Jason Hunter with a few best selling books out, why even
question the slides to begin with?
- Jon
"Bosch, Mike" wrote:
> Which in addition you get the "privilege" of paying ~$2000 to go and listen
> to corporate advertising.
>
> Count me out on the conference unless one of our vendors gets me in.
>
> -Mike
>
> -----Original Message-----
> From: Bradley S. Huffman [mailto:hip@a.cs.okstate.edu]
> Sent: Monday, February 11, 2002 1:09 PM
> To: jdom-interest@jdom.org
> Subject: Re: [jdom-interest] JavaOne presentations (flame)
>
> What do you expect when they are the head rats in charge of the cheese. I
> think for your talk you should dye your hair pink and wear a t-shirt that
> says "Large coporate advertising disguised as a conference still sucks!"
>
> :->
>
> Jason Hunter writes:
>
> > Frank Sauer wrote:
> > > Wow, do you work for SUN now? How in the world did you get in
> > > in the first place? I wish I had to deal with the slide nazis but I have
> yet
> > > to meet the first non-SUN JavaOne speaker. Just venting, let's all vent
> :-)
> >
> > Ha! Good question. The talk actually wasn't accepted at first. And
> > you're right, JavaOne is notorious for having dozens of talks about
> > Sun's favorite new technology (ie JSP taglibs) and missing out on whole
> > swaths of interesting other technologies (ie Apache Velocity). Last
> > year there were at least a dozen JAXP talks. As if you couldn't
> > understand all of JAXP in one short talk. And JDOM was left as an
> > alternate talk. This year I had to do a little lobbying after the
> > initial refusal. I think it helped that JDOM was a JSR and that I'm
> > Apache's representative to the JCP Executive Committee.
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> t.com
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From Frank.Sauer at trcinc.com Mon Feb 11 15:11:23 2002
From: Frank.Sauer at trcinc.com (Frank Sauer)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] JavaOne presentations (flame)
Message-ID: <3BAC15E02315BC4783152AC5E9621BB558CE21@trcexcsrv01.trcinc.com>
Amen..... Nothing like OOPSLA if you ask me. Being vendor neutral
makes for an interesting conference. I have to go to JavaOne for
my employer (we have a booth), but most of the sessions suck. I
go there to meet old friends and to man the booth.
Frank
-----Original Message-----
From: Jon Baer [mailto:jonbaer@digitalanywhere.com]
Sent: Monday, February 11, 2002 5:36 PM
To: jdom-interest@jdom.org
Subject: Re: [jdom-interest] JavaOne presentations (flame)
Thank you, thank you, thank you.
Not for nothing, but I thought I was the only one who felt like that. I had
personally wasted alot of time, energy, and money @ these types of conferences (where
it seemed like the talker was very restricted and seemed smart but made no sense) and
yet when all is said and done I actually learn more from free seminars/slides from
people like Elliotte and such. Someone should tell Sun that when they try to be a
little "too controlling" they end up being like some other company we know. Now
quite honestly I can understand that some guidelines when applied to open source are
needed to avoid all out chaos but when you have done so much for the community
already and ur name is Jason Hunter with a few best selling books out, why even
question the slides to begin with?
- Jon
"Bosch, Mike" wrote:
> Which in addition you get the "privilege" of paying ~$2000 to go and listen
> to corporate advertising.
>
> Count me out on the conference unless one of our vendors gets me in.
>
> -Mike
>
> -----Original Message-----
> From: Bradley S. Huffman [mailto:hip@a.cs.okstate.edu]
> Sent: Monday, February 11, 2002 1:09 PM
> To: jdom-interest@jdom.org
> Subject: Re: [jdom-interest] JavaOne presentations (flame)
>
> What do you expect when they are the head rats in charge of the cheese. I
> think for your talk you should dye your hair pink and wear a t-shirt that
> says "Large coporate advertising disguised as a conference still sucks!"
>
> :->
>
> Jason Hunter writes:
>
> > Frank Sauer wrote:
> > > Wow, do you work for SUN now? How in the world did you get in
> > > in the first place? I wish I had to deal with the slide nazis but I have
> yet
> > > to meet the first non-SUN JavaOne speaker. Just venting, let's all vent
> :-)
> >
> > Ha! Good question. The talk actually wasn't accepted at first. And
> > you're right, JavaOne is notorious for having dozens of talks about
> > Sun's favorite new technology (ie JSP taglibs) and missing out on whole
> > swaths of interesting other technologies (ie Apache Velocity). Last
> > year there were at least a dozen JAXP talks. As if you couldn't
> > understand all of JAXP in one short talk. And JDOM was left as an
> > alternate talk. This year I had to do a little lobbying after the
> > initial refusal. I think it helped that JDOM was a JSR and that I'm
> > Apache's representative to the JCP Executive Committee.
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> t.com
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From Justin.Wood at mgxgroup.com Mon Feb 11 22:16:39 2002
From: Justin.Wood at mgxgroup.com (Justin Wood)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] JDOM vs electric
Message-ID:
I had a look in the mail archives from last year regarding this topic. Round about March Jason and Graham Glass (from the Mind Electric) did a bit of mudslinging.
http://www.servlets.com/archive/servlet/ReadMsg?msgId=7279&listName=jdom-interest
Graham said he would amend his page:
http://www.themindelectric.com/products/xml/jdom.html
Which he hasn't done. I'm sure that JDOM has come quite a way in the last year and this page is even more out of date. Has anyone done a benchmark? Are there big differences, apart from the constuction of the XML object? Has anyone used both and done a pro's and cons?
Regards
Justin
From dms at sosnoski.com Tue Feb 12 01:45:07 2002
From: dms at sosnoski.com (Dennis Sosnoski)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] JDOM vs electric
References:
Message-ID: <3C68E423.5020800@sosnoski.com>
You can see my performance comparison on XML developerWorks (including
JDOM, dom4j, EXML, etc.), at
http://www-106.ibm.com/developerworks/xml/library/x-injava/index.html.
There's a second article comparing usage that's been turned in to IBM
since the beginning of October; hopefully it'll be published soon. :-)
I've got updated results all graphed up and ready for publication on my
web site, whenever I can take the time to put the text together. Nothing
has changed with JDOM since the earlier results were published on
developerWorks, though - it's still beta 7. Whenever JDOM beta 8 is
released it sounds like it should show some improvements.
- Dennis
Justin Wood wrote:
>I had a look in the mail archives from last year regarding this topic. Round about March Jason and Graham Glass (from the Mind Electric) did a bit of mudslinging.
>
>http://www.servlets.com/archive/servlet/ReadMsg?msgId=7279&listName=jdom-interest
>
>Graham said he would amend his page:
>
>http://www.themindelectric.com/products/xml/jdom.html
>
>Which he hasn't done. I'm sure that JDOM has come quite a way in the last year and this page is even more out of date. Has anyone done a benchmark? Are there big differences, apart from the constuction of the XML object? Has anyone used both and done a pro's and cons?
>
>Regards
>Justin
>
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
From kevinj at develop.com Tue Feb 12 07:57:25 2002
From: kevinj at develop.com (Kevin Jones)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] JavaOne presentations (flame)
In-Reply-To: <3C68474F.68378CDF@digitalanywhere.com>
Message-ID: <006501c1b3dd$fca487f0$0200a8c0@develop.com>
Part of the problem is that the technical guys inside Sun seem to have
no say as to who does the talks. I did a BOF on Taglibs (sorry Jason) a
couple of years ago, after which I got invited onto the expert group
(sound of own trumpet blowing). We (as a company) they spoke to the Sun
leads on the expert group about getting 'big tent' talks, but they said
that basically they have no influence with Key3Media (the company that
arranges the conference).
And (after finally having talks accepted) I agree with Jason. The
process is nightmarish!
Kevin Jones
Developmentor
www.develop.com
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org] On Behalf Of Jon Baer
> Sent: 11 February 2002 22:36
> To: jdom-interest@jdom.org
> Subject: Re: [jdom-interest] JavaOne presentations (flame)
>
>
> Thank you, thank you, thank you.
>
> Not for nothing, but I thought I was the only one who felt
> like that. I had personally wasted alot of time, energy, and
> money @ these types of conferences (where it seemed like the
> talker was very restricted and seemed smart but made no
> sense) and yet when all is said and done I actually learn
> more from free seminars/slides from people like Elliotte and
> such. Someone should tell Sun that when they try to be a
> little "too controlling" they end up being like some other
> company we know. Now quite honestly I can understand that
> some guidelines when applied to open source are needed to
> avoid all out chaos but when you have done so much for the
> community already and ur name is Jason Hunter with a few best
> selling books out, why even question the slides to begin with?
>
> - Jon
>
> "Bosch, Mike" wrote:
>
> > Which in addition you get the "privilege" of paying ~$2000
> to go and
> > listen to corporate advertising.
> >
> > Count me out on the conference unless one of our vendors gets me in.
> >
> > -Mike
> >
> > -----Original Message-----
> > From: Bradley S. Huffman [mailto:hip@a.cs.okstate.edu]
> > Sent: Monday, February 11, 2002 1:09 PM
> > To: jdom-interest@jdom.org
> > Subject: Re: [jdom-interest] JavaOne presentations (flame)
> >
> > What do you expect when they are the head rats in charge of the
> > cheese. I think for your talk you should dye your hair pink
> and wear a
> > t-shirt that says "Large coporate advertising disguised as a
> > conference still sucks!"
> >
> > :->
> >
> > Jason Hunter writes:
> >
> > > Frank Sauer wrote:
> > > > Wow, do you work for SUN now? How in the world did you
> get in in
> > > > the first place? I wish I had to deal with the slide
> nazis but I
> > > > have
> > yet
> > > > to meet the first non-SUN JavaOne speaker. Just
> venting, let's all
> > > > vent
> > :-)
> > >
> > > Ha! Good question. The talk actually wasn't accepted at first.
> > > And you're right, JavaOne is notorious for having dozens of talks
> > > about Sun's favorite new technology (ie JSP taglibs) and
> missing out
> > > on whole swaths of interesting other technologies (ie Apache
> > > Velocity). Last year there were at least a dozen JAXP
> talks. As if
> > > you couldn't understand all of JAXP in one short talk.
> And JDOM was
> > > left as an alternate talk. This year I had to do a
> little lobbying
> > > after the initial refusal. I think it helped that JDOM was a JSR
> > > and that I'm Apache's representative to the JCP Executive
> Committee.
> > _______________________________________________
> > To control your jdom-interest membership:
> >
> http://lists.denveronline.net/mailman/options/>
jdom-interest/youraddr@y
> > ourhos
> > t.com
> > _______________________________________________
> > To control your jdom-interest membership:
> >
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@yourhost.com
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@you
rhost.com
From nina.fellows at eds.com Tue Feb 12 08:27:33 2002
From: nina.fellows at eds.com (Fellows, Nina L)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] NoClassDefFoundError: java/util/LinkList
Message-ID: <7A57F750AF65D411949C00508BDFD8180C7FE00F@USPLM202>
Hi!
I have installed the jdom-b7, executed build and build samples, set up
JAVA_HOME, and added xerces.jar, jdom.jar and build\classes to the
classpath. When running java samples.WarReader web.xml I receive
java.lang.NoClassDefFoundError: java/util/LinkedList
at org.jdom.input.SAXHandler.(SAXHandler.java:176)
at
org.jdom.input.SAXBuilder.createContentHandler
Message-ID:
hi there,
one new thing worth mentioning is that EXML+ 4.0, due out in a couple
of weeks, includes native support for DOM. so in addition to the
ease-of-use,
you now get native DOM compatability.
after releasing EXML+ 4.0, we'll rerun the benchmarks using xerces 2.0
and the latest version of DOM, and update the JDOM benchmark page.
EXML+ 4.0 also includes transparent bidirectional serialization of Java
objects to/from XML, Java persistence using XML, XML document pattern
matching
and many other goodies. it includes the source code for EXML and is free
for most commercial uses.
cheers,
graham
http://www.themindelectric.com
-----Original Message-----
From: jdom-interest-admin@jdom.org
[mailto:jdom-interest-admin@jdom.org]On Behalf Of Justin Wood
Sent: Tuesday, February 12, 2002 12:17 AM
To: jdom-interest@jdom.org
Subject: [jdom-interest] JDOM vs electric
I had a look in the mail archives from last year regarding this topic.
Round about March Jason and Graham Glass (from the Mind Electric) did a bit
of mudslinging.
http://www.servlets.com/archive/servlet/ReadMsg?msgId=7279&listName=jdom-int
erest
Graham said he would amend his page:
http://www.themindelectric.com/products/xml/jdom.html
Which he hasn't done. I'm sure that JDOM has come quite a way in the last
year and this page is even more out of date. Has anyone done a benchmark?
Are there big differences, apart from the constuction of the XML object? Has
anyone used both and done a pro's and cons?
Regards
Justin
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
From dms at sosnoski.com Tue Feb 12 09:21:47 2002
From: dms at sosnoski.com (Dennis Sosnoski)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] JDOM vs electric
References:
Message-ID: <3C694F2B.2@sosnoski.com>
Hi Graham,
When you update the page, I'd appreciate it if you'd add a link to my
benchmarks as well (either that, or at least take out the line about
being glad to link to other benchmarks).
For more representative results you should also look at doing a couple
of things differently in your test case. If EXML+ 4.0 still discards
whitespace sequences (in violation of the XML spec) you should use a
test document which does not include any extra whitespace. You should
also use something other than Xerces 1 as the parser for the JDOM test,
since Xerces 1 shows very poor performance on small documents (Xerces 2
is better). Finally, you should include dom4j as a comparison, since
dom4j is considerably more mature than JDOM and includes a number of
performance optimizations.
- Dennis
graham glass wrote:
>hi there,
>
>one new thing worth mentioning is that EXML+ 4.0, due out in a couple
>of weeks, includes native support for DOM. so in addition to the
>ease-of-use,
>you now get native DOM compatability.
>
>after releasing EXML+ 4.0, we'll rerun the benchmarks using xerces 2.0
>and the latest version of DOM, and update the JDOM benchmark page.
>
>EXML+ 4.0 also includes transparent bidirectional serialization of Java
>objects to/from XML, Java persistence using XML, XML document pattern
>matching
>and many other goodies. it includes the source code for EXML and is free
>for most commercial uses.
>
>cheers,
>graham
>
>http://www.themindelectric.com
>
>-----Original Message-----
>From: jdom-interest-admin@jdom.org
>[mailto:jdom-interest-admin@jdom.org]On Behalf Of Justin Wood
>Sent: Tuesday, February 12, 2002 12:17 AM
>To: jdom-interest@jdom.org
>Subject: [jdom-interest] JDOM vs electric
>
>
>I had a look in the mail archives from last year regarding this topic.
>Round about March Jason and Graham Glass (from the Mind Electric) did a bit
>of mudslinging.
>
>http://www.servlets.com/archive/servlet/ReadMsg?msgId=7279&listName=jdom-int
>erest
>
>Graham said he would amend his page:
>
>http://www.themindelectric.com/products/xml/jdom.html
>
>Which he hasn't done. I'm sure that JDOM has come quite a way in the last
>year and this page is even more out of date. Has anyone done a benchmark?
>Are there big differences, apart from the constuction of the XML object? Has
>anyone used both and done a pro's and cons?
>
>Regards
>Justin
>
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
>t.com
>
>
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
From Bob_Lee at averydennison.com Tue Feb 12 10:37:08 2002
From: Bob_Lee at averydennison.com (Bob_Lee@averydennison.com)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] JavaOne presentations (flame)
Message-ID:
Jason, can you publish the "rejected" slides on the web for those of us
who won't be attending? I've always enjoyed your talks.
-Bob Lee
From Peter.H.Roberts at bbh.com Tue Feb 12 11:21:07 2002
From: Peter.H.Roberts at bbh.com (Peter.H.Roberts@bbh.com)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] JavaOne presentations (flame) (Jason Hunter)
Message-ID:
In response to Jason,
I used to go religiously to Java One, but have found it not very usefull, and did not go last year, and we are not going this year. As you said, it seems the information dolled out is dumbed down. If I had gone I probably would have gone to your
talk, and then (horror) thought you were not as smart as I currently think. I really like JDOM, so my advice is don't go, but Java One is in SF and SF is beautifull in March. Try and give the talk at IBM WebSphere convention in May, I will be there. It's
beautifull in May also.
Peter:)
jdom-interest-admi
n@jdom.org To: jdom-interest@jdom.org
cc:
02/11/2002 02:04 Subject: jdom-interest digest, Vol 1 #841 - 3 msgs
AM
Please respond to
jdom-interest
Send jdom-interest mailing list submissions to
jdom-interest@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@jdom.org
You can reach the person managing the list at
jdom-interest-admin@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: Jar-Archive (Joern Muehlencord)
2. JavaOne presentations (flame) (Jason Hunte
3. RE: JavaOne presentations (flame) (Frank Sauer)
--__--__--
Message: 1
Date: Sat, 09 Feb 2002 18:15:33 +0100
From: Joern Muehlencord
To: Jason Hunter
Cc: jdom-interest
Subject: Re: [jdom-interest] Jar-Archive
Hi Jason,
> I believe when you "-jar" run a JAR file it ignores the classpath.
> You'd need to have supporting JARs in your MANIFEST.MF for them to be
> found.
That is right. I needed to include "Class-Path: jdom.jar" to the
manifest-file. xerces.jar is not needed - it is included bei jdom.jar.
Now it is ok, to put all three archives into one directory and start the
application out of the jar-file.
Thanx
Joern
--
Linux is like a wigwam - no Windows, no Gates and Apache inside
--__--__--
Message: 2
Date: Sun, 10 Feb 2002 18:11:30 -0800
From: Jason Hunter
To: JDOM Interest
Subject: [jdom-interest] JavaOne presentations (flame)
I just have to vent, and this crowd seems like a fine place to vent
about this particular thing.
I'm presenting a talk on JDOM at JavaOne this year, and Oh My God, the
slide submittal process is horrid. Absolutely draconian. Unlike *every
other conference* I've spoken at (dozens), at JavaOne there are people
who critique your slides on various Rules. These Rules are definitely
smart guidelines but at JavaOne they are literally *Rules*. If you
don't pass each and every rule down the line, they don't let you give
you talk.
One sample rule: You need a graphic on at least one out of every 6
pages. Need it or not, appropriate or not, you need a graphic. It's
supposed to keep your audience awake. Well, I guess I have to come up
with a graphic for the section where I compare JDOM with DOM. Any
ideas? I wonder if a picture from Anna Kournikova's new calendar would
do.
Another rule: You should have no more than six words per bullet point.
Wait, did I say "should"? I mean MUST as in the W3C spec meaning of the
word. Nothing longer than six words is .
That last one really bugs me. I personally find JavaOne slides 100%
useless after the talk because of this rule. I've downloaded slides in
years past from talks I couldn't attend. Here's what you get:
* JVM Performance In Process
* Garbage Collection In Real Time
Oh yeah, I'm really learning now. They say this rule is to keep the
point size up so you can read the slides during the show, but seems to
me:
* If you're in the show you're listening, not reading
* If you're not in the show, you can only read
(Notice the effective use of 9 word bullets there.)
So with big point sizes you can read my outline during the show, but
after I'm done talking, all the points are lost.
I was proud and I stood my moral ground and flaunted the rules -- I used
graphics only when I needed graphics and I tried to actually *say
something* with each bullet point. But no. The people reviewing the
talks actually counted my words and my graphic densities. I failed.
I'm told I need to revise now.
What's really ironic is last year the same basic slide outline was
accepted. I was just unlucky enough this year to get the Presentation
Nazi. I can almost hear him yell: "No presentation for you, one year!"
Maybe you're thinking I should obligingly bow to the "Rules" and be
tricky and bring my own slides in on a laptop on the presentation day.
No can do; they're on to that! You can't bring your own laptop to
present. Every other conference I've spoken at lets you. Why not at
JavaOne? They say it's to keep things simpler to setup, but really how
simple is it for me to load JDOM examples on their machine versus my
own?? Here's my theory: if anyone ever tries to make The Training
Alliance Nazis (tm) look bad (you know, someone in a bad mood -- try to
picture it), they'll know beforehand and have some leverage to encourage
you to change your slides.
I agree these guidelines make sense in general, but can we give the
speakers no credit? The best talks I've ever attended have slides that
don't in any way follow the JavaOne Rules. And some of the worst talks
I've ever attended have been at JavaOne. Maybe they're trying to raise
up the quality of these poor talks by rigidly enforcing these rules. I
think it's more likely they're creating poor talks by enforcing these
rules.
Ah well. At least I can still say what I want on stage. Um, probably.
I'll let you know if they actually let me speak live on stage or if it's
a tape recording.
-jh-
P.S. Sun speakers suffer from this just as much as outside people.
This is another reason why no one at Sun looks very happy the month
before JavaOne.
P.P.S. The slides haven't even gone to legal review yet. Last year in
legal review they changed "JDOM" to "The Document Object Model for Java"
on me and for a long time refused to change it back. You'd think they
would believe I knew the name of my project.
--__--__--
Message: 3
Subject: RE: [jdom-interest] JavaOne presentations (flame)
Date: Sun, 10 Feb 2002 23:28:31 -0500
From: "Frank Sauer"
To: "Jason Hunter" , "JDOM Interest"
V293LCBkbyB5b3Ugd29yayBmb3IgU1VOIG5vdz8gSG93IGluIHRoZSB3b3JsZCBkaWQgeW91IGdl
dCBpbiANCmluIHRoZSBmaXJzdCBwbGFjZT8gSSB3aXNoIEkgaGFkIHRvIGRlYWwgd2l0aCB0aGUg
c2xpZGUgbmF6aXMgYnV0IEkgaGF2ZSB5ZXQNCnRvIG1lZXQgdGhlIGZpcnN0IG5vbi1TVU4gSmF2
YU9uZSBzcGVha2VyLiBKdXN0IHZlbnRpbmcsIGxldCdzIGFsbCB2ZW50IDotKQ0KIA0KRnJhbmsN
CiANClAuUy4gSSBrbm93IHlvdSBkb24ndCB3b3JrIGZvciBTdW4sIGJ1dCB3aXRoIEpET00gYmVp
bmcgYSBKU1IgYW5kIGFsbCwNCkknbSBub3QgdG9vIHN1cnByaXNlZCB0byBzZWUgeW91IG1hZGUg
aXQuIA0KIA0KUC5QLlMuIEdvb2QgTHVjayEgYW5kIEknbGwgc2VlIHlvdSBhdCBKYXZhT25lIChi
dXQgbm90IGFzIGEgc3BlYWtlciBteXNlbGYpDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LSANCglGcm9tOiBKYXNvbiBIdW50ZXIgW21haWx0bzpqaHVudGVyQGFjbS5vcmddIA0KCVNlbnQ6
IFN1biAyLzEwLzIwMDIgOToxMSBQTSANCglUbzogSkRPTSBJbnRlcmVzdCANCglDYzogDQoJU3Vi
amVjdDogW2pkb20taW50ZXJlc3RdIEphdmFPbmUgcHJlc2VudGF0aW9ucyAoZmxhbWUpDQoJDQoJ
DQoNCglJIGp1c3QgaGF2ZSB0byB2ZW50LCBhbmQgdGhpcyBjcm93ZCBzZWVtcyBsaWtlIGEgZmlu
ZSBwbGFjZSB0byB2ZW50DQoJYWJvdXQgdGhpcyBwYXJ0aWN1bGFyIHRoaW5nLg0KCQ0KCUknbSBw
cmVzZW50aW5nIGEgdGFsayBvbiBKRE9NIGF0IEphdmFPbmUgdGhpcyB5ZWFyLCBhbmQgT2ggTXkg
R29kLCB0aGUNCglzbGlkZSBzdWJtaXR0YWwgcHJvY2VzcyBpcyBob3JyaWQuICBBYnNvbHV0ZWx5
IGRyYWNvbmlhbi4gIFVubGlrZSAqZXZlcnkNCglvdGhlciBjb25mZXJlbmNlKiBJJ3ZlIHNwb2tl
biBhdCAoZG96ZW5zKSwgYXQgSmF2YU9uZSB0aGVyZSBhcmUgcGVvcGxlDQoJd2hvIGNyaXRpcXVl
IHlvdXIgc2xpZGVzIG9uIHZhcmlvdXMgUnVsZXMuICBUaGVzZSBSdWxlcyBhcmUgZGVmaW5pdGVs
eQ0KCXNtYXJ0IGd1aWRlbGluZXMgYnV0IGF0IEphdmFPbmUgdGhleSBhcmUgbGl0ZXJhbGx5ICpS
dWxlcyouICBJZiB5b3UNCglkb24ndCBwYXNzIGVhY2ggYW5kIGV2ZXJ5IHJ1bGUgZG93biB0aGUg
bGluZSwgdGhleSBkb24ndCBsZXQgeW91IGdpdmUNCgl5b3UgdGFsay4NCgkNCglPbmUgc2FtcGxl
IHJ1bGU6ICBZb3UgbmVlZCBhIGdyYXBoaWMgb24gYXQgbGVhc3Qgb25lIG91dCBvZiBldmVyeSA2
DQoJcGFnZXMuICBOZWVkIGl0IG9yIG5vdCwgYXBwcm9wcmlhdGUgb3Igbm90LCB5b3UgbmVlZCBh
IGdyYXBoaWMuICBJdCdzDQoJc3VwcG9zZWQgdG8ga2VlcCB5b3VyIGF1ZGllbmNlIGF3YWtlLiAg
V2VsbCwgSSBndWVzcyBJIGhhdmUgdG8gY29tZSB1cA0KCXdpdGggYSBncmFwaGljIGZvciB0aGUg
c2VjdGlvbiB3aGVyZSBJIGNvbXBhcmUgSkRPTSB3aXRoIERPTS4gIEFueQ0KCWlkZWFzPyAgSSB3
b25kZXIgaWYgYSBwaWN0dXJlIGZyb20gQW5uYSBLb3Vybmlrb3ZhJ3MgbmV3IGNhbGVuZGFyIHdv
dWxkDQoJZG8uDQoJDQoJQW5vdGhlciBydWxlOiAgWW91IHNob3VsZCBoYXZlIG5vIG1vcmUgdGhh
biBzaXggd29yZHMgcGVyIGJ1bGxldCBwb2ludC4NCglXYWl0LCBkaWQgSSBzYXkgInNob3VsZCI/
ICBJIG1lYW4gTVVTVCBhcyBpbiB0aGUgVzNDIHNwZWMgbWVhbmluZyBvZiB0aGUNCgl3b3JkLiAg
Tm90aGluZyBsb25nZXIgdGhhbiBzaXggd29yZHMgaXMgPG9vcHMsIGN1dCwgY2FuJ3Qgc2F5IGFu
eW1vcmU+Lg0KCQ0KCVRoYXQgbGFzdCBvbmUgcmVhbGx5IGJ1Z3MgbWUuICBJIHBlcnNvbmFsbHkg
ZmluZCBKYXZhT25lIHNsaWRlcyAxMDAlDQoJdXNlbGVzcyBhZnRlciB0aGUgdGFsayBiZWNhdXNl
IG9mIHRoaXMgcnVsZS4gIEkndmUgZG93bmxvYWRlZCBzbGlkZXMgaW4NCgl5ZWFycyBwYXN0IGZy
b20gdGFsa3MgSSBjb3VsZG4ndCBhdHRlbmQuICBIZXJlJ3Mgd2hhdCB5b3UgZ2V0Og0KCQ0KCSog
SlZNIFBlcmZvcm1hbmNlIEluIFByb2Nlc3MNCgkqIEdhcmJhZ2UgQ29sbGVjdGlvbiBJbiBSZWFs
IFRpbWUNCgkNCglPaCB5ZWFoLCBJJ20gcmVhbGx5IGxlYXJuaW5nIG5vdy4gIFRoZXkgc2F5IHRo
aXMgcnVsZSBpcyB0byBrZWVwIHRoZQ0KCXBvaW50IHNpemUgdXAgc28geW91IGNhbiByZWFkIHRo
ZSBzbGlkZXMgZHVyaW5nIHRoZSBzaG93LCBidXQgc2VlbXMgdG8NCgltZToNCgkNCgkqIElmIHlv
dSdyZSBpbiB0aGUgc2hvdyB5b3UncmUgbGlzdGVuaW5nLCBub3QgcmVhZGluZw0KCSogSWYgeW91
J3JlIG5vdCBpbiB0aGUgc2hvdywgeW91IGNhbiBvbmx5IHJlYWQNCgkNCgkoTm90aWNlIHRoZSBl
ZmZlY3RpdmUgdXNlIG9mIDkgd29yZCBidWxsZXRzIHRoZXJlLikNCgkNCglTbyB3aXRoIGJpZyBw
b2ludCBzaXplcyB5b3UgY2FuIHJlYWQgbXkgb3V0bGluZSBkdXJpbmcgdGhlIHNob3csIGJ1dA0K
CWFmdGVyIEknbSBkb25lIHRhbGtpbmcsIGFsbCB0aGUgcG9pbnRzIGFyZSBsb3N0Lg0KCQ0KCUkg
d2FzIHByb3VkIGFuZCBJIHN0b29kIG15IG1vcmFsIGdyb3VuZCBhbmQgZmxhdW50ZWQgdGhlIHJ1
bGVzIC0tIEkgdXNlZA0KCWdyYXBoaWNzIG9ubHkgd2hlbiBJIG5lZWRlZCBncmFwaGljcyBhbmQg
SSB0cmllZCB0byBhY3R1YWxseSAqc2F5DQoJc29tZXRoaW5nKiB3aXRoIGVhY2ggYnVsbGV0IHBv
aW50LiAgQnV0IG5vLiAgVGhlIHBlb3BsZSByZXZpZXdpbmcgdGhlDQoJdGFsa3MgYWN0dWFsbHkg
Y291bnRlZCBteSB3b3JkcyBhbmQgbXkgZ3JhcGhpYyBkZW5zaXRpZXMuICBJIGZhaWxlZC4NCglJ
J20gdG9sZCBJIG5lZWQgdG8gcmV2aXNlIG5vdy4NCgkNCglXaGF0J3MgcmVhbGx5IGlyb25pYyBp
cyBsYXN0IHllYXIgdGhlIHNhbWUgYmFzaWMgc2xpZGUgb3V0bGluZSB3YXMNCglhY2NlcHRlZC4g
IEkgd2FzIGp1c3QgdW5sdWNreSBlbm91Z2ggdGhpcyB5ZWFyIHRvIGdldCB0aGUgUHJlc2VudGF0
aW9uDQoJTmF6aS4gIEkgY2FuIGFsbW9zdCBoZWFyIGhpbSB5ZWxsOiAgIk5vIHByZXNlbnRhdGlv
biBmb3IgeW91LCBvbmUgeWVhciEiDQoJDQoJTWF5YmUgeW91J3JlIHRoaW5raW5nIEkgc2hvdWxk
IG9ibGlnaW5nbHkgYm93IHRvIHRoZSAiUnVsZXMiIGFuZCBiZQ0KCXRyaWNreSBhbmQgYnJpbmcg
bXkgb3duIHNsaWRlcyBpbiBvbiBhIGxhcHRvcCBvbiB0aGUgcHJlc2VudGF0aW9uIGRheS4NCglO
byBjYW4gZG87IHRoZXkncmUgb24gdG8gdGhhdCEgIFlvdSBjYW4ndCBicmluZyB5b3VyIG93biBs
YXB0b3AgdG8NCglwcmVzZW50LiAgRXZlcnkgb3RoZXIgY29uZmVyZW5jZSBJJ3ZlIHNwb2tlbiBh
dCBsZXRzIHlvdS4gIFdoeSBub3QgYXQNCglKYXZhT25lPyAgVGhleSBzYXkgaXQncyB0byBrZWVw
IHRoaW5ncyBzaW1wbGVyIHRvIHNldHVwLCBidXQgcmVhbGx5IGhvdw0KCXNpbXBsZSBpcyBpdCBm
b3IgbWUgdG8gbG9hZCBKRE9NIGV4YW1wbGVzIG9uIHRoZWlyIG1hY2hpbmUgdmVyc3VzIG15DQoJ
b3duPz8gIEhlcmUncyBteSB0aGVvcnk6IGlmIGFueW9uZSBldmVyIHRyaWVzIHRvIG1ha2UgVGhl
IFRyYWluaW5nDQoJQWxsaWFuY2UgTmF6aXMgKHRtKSBsb29rIGJhZCAoeW91IGtub3csIHNvbWVv
bmUgaW4gYSBiYWQgbW9vZCAtLSB0cnkgdG8NCglwaWN0dXJlIGl0KSwgdGhleSdsbCBrbm93IGJl
Zm9yZWhhbmQgYW5kIGhhdmUgc29tZSBsZXZlcmFnZSB0byBlbmNvdXJhZ2UNCgl5b3UgdG8gY2hh
bmdlIHlvdXIgc2xpZGVzLg0KCQ0KCUkgYWdyZWUgdGhlc2UgZ3VpZGVsaW5lcyBtYWtlIHNlbnNl
IGluIGdlbmVyYWwsIGJ1dCBjYW4gd2UgZ2l2ZSB0aGUNCglzcGVha2VycyBubyBjcmVkaXQ/ICBU
aGUgYmVzdCB0YWxrcyBJJ3ZlIGV2ZXIgYXR0ZW5kZWQgaGF2ZSBzbGlkZXMgdGhhdA0KCWRvbid0
IGluIGFueSB3YXkgZm9sbG93IHRoZSBKYXZhT25lIFJ1bGVzLiAgQW5kIHNvbWUgb2YgdGhlIHdv
cnN0IHRhbGtzDQoJSSd2ZSBldmVyIGF0dGVuZGVkIGhhdmUgYmVlbiBhdCBKYXZhT25lLiAgTWF5
YmUgdGhleSdyZSB0cnlpbmcgdG8gcmFpc2UNCgl1cCB0aGUgcXVhbGl0eSBvZiB0aGVzZSBwb29y
IHRhbGtzIGJ5IHJpZ2lkbHkgZW5mb3JjaW5nIHRoZXNlIHJ1bGVzLiAgSQ0KCXRoaW5rIGl0J3Mg
bW9yZSBsaWtlbHkgdGhleSdyZSBjcmVhdGluZyBwb29yIHRhbGtzIGJ5IGVuZm9yY2luZyB0aGVz
ZQ0KCXJ1bGVzLg0KCQ0KCUFoIHdlbGwuICBBdCBsZWFzdCBJIGNhbiBzdGlsbCBzYXkgd2hhdCBJ
IHdhbnQgb24gc3RhZ2UuICBVbSwgcHJvYmFibHkuDQoJSSdsbCBsZXQgeW91IGtub3cgaWYgdGhl
eSBhY3R1YWxseSBsZXQgbWUgc3BlYWsgbGl2ZSBvbiBzdGFnZSBvciBpZiBpdCdzDQoJYSB0YXBl
IHJlY29yZGluZy4NCgkNCgktamgtDQoJDQoJUC5TLiAgU3VuIHNwZWFrZXJzIHN1ZmZlciBmcm9t
IHRoaXMganVzdCBhcyBtdWNoIGFzIG91dHNpZGUgcGVvcGxlLg0KCVRoaXMgaXMgYW5vdGhlciBy
ZWFzb24gd2h5IG5vIG9uZSBhdCBTdW4gbG9va3MgdmVyeSBoYXBweSB0aGUgbW9udGgNCgliZWZv
cmUgSmF2YU9uZS4NCgkNCglQLlAuUy4gIFRoZSBzbGlkZXMgaGF2ZW4ndCBldmVuIGdvbmUgdG8g
bGVnYWwgcmV2aWV3IHlldC4gIExhc3QgeWVhciBpbg0KCWxlZ2FsIHJldmlldyB0aGV5IGNoYW5n
ZWQgIkpET00iIHRvICJUaGUgRG9jdW1lbnQgT2JqZWN0IE1vZGVsIGZvciBKYXZhIg0KCW9uIG1l
IGFuZCBmb3IgYSBsb25nIHRpbWUgcmVmdXNlZCB0byBjaGFuZ2UgaXQgYmFjay4gIFlvdSdkIHRo
aW5rIHRoZXkNCgl3b3VsZCBiZWxpZXZlIEkga25ldyB0aGUgbmFtZSBvZiBteSBwcm9qZWN0Lg0K
CV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJVG8gY29u
dHJvbCB5b3VyIGpkb20taW50ZXJlc3QgbWVtYmVyc2hpcDoNCglodHRwOi8vbGlzdHMuZGVudmVy
b25saW5lLm5ldC9tYWlsbWFuL29wdGlvbnMvamRvbS1pbnRlcmVzdC95b3VyYWRkckB5b3VyaG9z
dC5jb20NCgkNCg0KDQoNCg0K
--__--__--
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
End of jdom-interest Digest
From ACE at rdacorp.com Tue Feb 12 13:28:28 2002
From: ACE at rdacorp.com (Eric Ace)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] Using JDOM to manipulate HTML
Message-ID: <6CB3FB42F4C2D4119F870002B3157AA504472553@corp_mail.rdacorp.com>
I want to use JDOM to manage presentation. Instead of using custom tags a la Struts, my thought is to have a presentation tier that queries business components and merges data into static HTML via JDOM. So, I need to be able to locate specific HTML elements by name or ID and modify them. For example:
...
I can ultimately get to the table I need to manipulate by getting all "table" elements, then looking for one that contains an ID attribute. What would be more programmatically clean though would be to manipulate the document via JDOM similarly to how I can via the DOM in JavaScript.
Am I completely missing the spirit of JDOM? Or, missing some fundamentally obvious point?
Thanks
-EAce
From todd.trimmer at trizetto.com Tue Feb 12 13:49:25 2002
From: todd.trimmer at trizetto.com (Trimmer, Todd)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] getText() and getAttributeValue()
Message-ID: <89D72635F8AFD4118E5B00B0D06822561D6FAC@s-coengl-e02>
For Element, if no textual content exists, getText() returns an empty
string. However, if getAttributeValue() is called for an attribute that does
not exist, null is returned. Why the inconsistency?
Under what circumstances would client code care to differentiate between an
attribute existing with empty string and the attibute not existing at all?
getAttributeValue() should return empty string if the attribute does not
exist because:
1) It makes it more consistent with getText()
2) One won't have to check for null on the return value.
Right now, my code is littered with:
String name = Parse.assure(elem.getAttributeValue("name"));
String id = Parse.assure(elem.getAttributeValue("id"));
// etc.
...where Parse.assure(String str) returns empty string if str is null; or
str unchanged if it is non-null. It sure would be nice to get rid of all
those checks.
Todd Trimmer
From jonbaer at digitalanywhere.com Tue Feb 12 14:01:01 2002
From: jonbaer at digitalanywhere.com (Jon Baer)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] getText() and getAttributeValue()
References: <89D72635F8AFD4118E5B00B0D06822561D6FAC@s-coengl-e02>
Message-ID: <3C69909D.A8890018@digitalanywhere.com>
I agree =) + 1
return (attribute == null) ? null : attribute.getValue();
-to-
return (attribute == null) ? "" : attribute.getValue();
- Jon
"Trimmer, Todd" wrote:
> For Element, if no textual content exists, getText() returns an empty
> string. However, if getAttributeValue() is called for an attribute that does
> not exist, null is returned. Why the inconsistency?
>
> Under what circumstances would client code care to differentiate between an
> attribute existing with empty string and the attibute not existing at all?
>
> getAttributeValue() should return empty string if the attribute does not
> exist because:
> 1) It makes it more consistent with getText()
> 2) One won't have to check for null on the return value.
>
> Right now, my code is littered with:
> String name = Parse.assure(elem.getAttributeValue("name"));
> String id = Parse.assure(elem.getAttributeValue("id"));
> // etc.
>
> ...where Parse.assure(String str) returns empty string if str is null; or
> str unchanged if it is non-null. It sure would be nice to get rid of all
> those checks.
>
> Todd Trimmer
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From graham-glass at mindspring.com Tue Feb 12 16:08:17 2002
From: graham-glass at mindspring.com (graham glass)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] JDOM vs electric
In-Reply-To: <3C694F2B.2@sosnoski.com>
Message-ID:
hi dennis,
we'll run your benchmarks independently to verify them.
the last time we chatted, it seemed like you were getting
significantly different results from us, which brought
setup and configuration issues to light.
cheers,
graham
-----Original Message-----
From: Dennis Sosnoski [mailto:dms@sosnoski.com]
Sent: Tuesday, February 12, 2002 11:22 AM
To: graham glass
Cc: jdom-interest@jdom.org; Justin Wood
Subject: Re: [jdom-interest] JDOM vs electric
Hi Graham,
When you update the page, I'd appreciate it if you'd add a link to my
benchmarks as well (either that, or at least take out the line about
being glad to link to other benchmarks).
For more representative results you should also look at doing a couple
of things differently in your test case. If EXML+ 4.0 still discards
whitespace sequences (in violation of the XML spec) you should use a
test document which does not include any extra whitespace. You should
also use something other than Xerces 1 as the parser for the JDOM test,
since Xerces 1 shows very poor performance on small documents (Xerces 2
is better). Finally, you should include dom4j as a comparison, since
dom4j is considerably more mature than JDOM and includes a number of
performance optimizations.
- Dennis
graham glass wrote:
>hi there,
>
>one new thing worth mentioning is that EXML+ 4.0, due out in a couple
>of weeks, includes native support for DOM. so in addition to the
>ease-of-use,
>you now get native DOM compatability.
>
>after releasing EXML+ 4.0, we'll rerun the benchmarks using xerces 2.0
>and the latest version of DOM, and update the JDOM benchmark page.
>
>EXML+ 4.0 also includes transparent bidirectional serialization of Java
>objects to/from XML, Java persistence using XML, XML document pattern
>matching
>and many other goodies. it includes the source code for EXML and is free
>for most commercial uses.
>
>cheers,
>graham
>
>http://www.themindelectric.com
>
>-----Original Message-----
>From: jdom-interest-admin@jdom.org
>[mailto:jdom-interest-admin@jdom.org]On Behalf Of Justin Wood
>Sent: Tuesday, February 12, 2002 12:17 AM
>To: jdom-interest@jdom.org
>Subject: [jdom-interest] JDOM vs electric
>
>
>I had a look in the mail archives from last year regarding this topic.
>Round about March Jason and Graham Glass (from the Mind Electric) did a bit
>of mudslinging.
>
>http://www.servlets.com/archive/servlet/ReadMsg?msgId=7279&listName=jdom-in
t
>erest
>
>Graham said he would amend his page:
>
>http://www.themindelectric.com/products/xml/jdom.html
>
>Which he hasn't done. I'm sure that JDOM has come quite a way in the last
>year and this page is even more out of date. Has anyone done a benchmark?
>Are there big differences, apart from the constuction of the XML object?
Has
>anyone used both and done a pro's and cons?
>
>Regards
>Justin
>
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourho
s
>t.com
>
>
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourho
st.com
>
From arosen at silverstream.com Tue Feb 12 16:12:54 2002
From: arosen at silverstream.com (Alex Rosen)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] NoClassDefFoundError: java/util/LinkList
In-Reply-To: <7A57F750AF65D411949C00508BDFD8180C7FE00F@USPLM202>
Message-ID: <000101c1b423$2f75aa20$612a5a41@silverstream.com>
Which version of Java are you using? Since LinkedList is part of the JDK 1.2
and higher runtime, it should just work, if your JRE is not corrupt in some
way. If you're using JDK 1.1.x, you'll need to use the special 1.1
compatible version of JDOM in jdom11.jar. Check out the FAQ on this at
jdom.org.
Alex
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org]On Behalf Of Fellows, Nina L
> Sent: Tuesday, February 12, 2002 11:28 AM
> To: 'jdom-interest@jdom.org'
> Subject: [jdom-interest] NoClassDefFoundError: java/util/LinkList
>
>
> Hi!
>
> I have installed the jdom-b7, executed build and build samples, set up
> JAVA_HOME, and added xerces.jar, jdom.jar and build\classes to the
> classpath. When running java samples.WarReader web.xml I receive
>
> java.lang.NoClassDefFoundError: java/util/LinkedList
> at org.jdom.input.SAXHandler.(SAXHandler.java:176)
> at
> org.jdom.input.SAXBuilder.createContentHandler at org.jdom.input.SAXBuilder.build(SAXBuilder.java:279)
> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:617)
> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:599)
> at samples.WarReader.read(Compiled Code)
> at samples.WarReader.main(WarReader.java:187)
>
> Where is it looking to try and find the LinkedList.class? Do
> I need to add
> that to the classpath? I found LinkedList.class in
> jdk1.2.2\jre\rt.jar and
> JavaSoft\JRE\1.2\librt.jar, but added those directories to
> the classpath had
> no effect.
>
>
> Nina Fellows
> nina.fellows@eds.com
>
>
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@yourhost.com
From dms at sosnoski.com Tue Feb 12 17:07:36 2002
From: dms at sosnoski.com (Dennis Sosnoski)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] JDOM vs electric
References:
Message-ID: <3C69BC58.3070206@sosnoski.com>
Hi Graham,
In the latest set of tests I've added some collections of smaller
documents. EXML does very well on small documents (especially the SOAP
collection, not too surprisingly!). It still performs fairly poorly on
larger documents, especially when the elimination of whitespace is taken
into account.
As we'd discussed previously, the differences in results look to be due
to several factors:
1. Your test uses a single very small document, of the type that EXML
appears optimized for
2. You test only against JDOM running Xerces, which is kind of shooting
fish in a barrel when it comes to performance comparisons. :-) If you're
really interested in seeing how EXML performs you should test against
some of the other alternatives.
3. EXML discards character data sequences consisting only of whitespace,
and thereby uses a dramatically lower number of objects in the document
representations; while this is fine for many applications, it biases the
tests. It's also not compliant with the XML spec, and should at least be
pointed out to users in your documentation
4. My tests are looking for the best performance the code is able to
give, so I take the best time of several runs, while your test uses the
average time; using average times for benchmarking applications using
Hot Spot JVMs is questionable, if you're going to do this at all you
need to run an extended series of test passes and discard all but the
last few.
5. My tests use memory settings of -Xms64M and -Xmx64M to give the JVM
plenty of memory; this is appropriate for a server enviroment, and makes
a big difference in how well Hot Spot handles code. Your test run uses
the default setting.
- Dennis
graham glass wrote:
>hi dennis,
>
>we'll run your benchmarks independently to verify them.
>
>the last time we chatted, it seemed like you were getting
>significantly different results from us, which brought
>setup and configuration issues to light.
>
>cheers,
>graham
>
>-----Original Message-----
>From: Dennis Sosnoski [mailto:dms@sosnoski.com]
>Sent: Tuesday, February 12, 2002 11:22 AM
>To: graham glass
>Cc: jdom-interest@jdom.org; Justin Wood
>Subject: Re: [jdom-interest] JDOM vs electric
>
>
>Hi Graham,
>
>When you update the page, I'd appreciate it if you'd add a link to my
>benchmarks as well (either that, or at least take out the line about
>being glad to link to other benchmarks).
>
>For more representative results you should also look at doing a couple
>of things differently in your test case. If EXML+ 4.0 still discards
>whitespace sequences (in violation of the XML spec) you should use a
>test document which does not include any extra whitespace. You should
>also use something other than Xerces 1 as the parser for the JDOM test,
>since Xerces 1 shows very poor performance on small documents (Xerces 2
>is better). Finally, you should include dom4j as a comparison, since
>dom4j is considerably more mature than JDOM and includes a number of
>performance optimizations.
>
> - Dennis
>
>graham glass wrote:
>
>>hi there,
>>
>>one new thing worth mentioning is that EXML+ 4.0, due out in a couple
>>of weeks, includes native support for DOM. so in addition to the
>>ease-of-use,
>>you now get native DOM compatability.
>>
>>after releasing EXML+ 4.0, we'll rerun the benchmarks using xerces 2.0
>>and the latest version of DOM, and update the JDOM benchmark page.
>>
>>EXML+ 4.0 also includes transparent bidirectional serialization of Java
>>objects to/from XML, Java persistence using XML, XML document pattern
>>matching
>>and many other goodies. it includes the source code for EXML and is free
>>for most commercial uses.
>>
>>cheers,
>>graham
>>
>>http://www.themindelectric.com
>>
>>-----Original Message-----
>>From: jdom-interest-admin@jdom.org
>>[mailto:jdom-interest-admin@jdom.org]On Behalf Of Justin Wood
>>Sent: Tuesday, February 12, 2002 12:17 AM
>>To: jdom-interest@jdom.org
>>Subject: [jdom-interest] JDOM vs electric
>>
>>
>>I had a look in the mail archives from last year regarding this topic.
>>Round about March Jason and Graham Glass (from the Mind Electric) did a bit
>>of mudslinging.
>>
>>http://www.servlets.com/archive/servlet/ReadMsg?msgId=7279&listName=jdom-in
>>
>t
>
>>erest
>>
>>Graham said he would amend his page:
>>
>>http://www.themindelectric.com/products/xml/jdom.html
>>
>>Which he hasn't done. I'm sure that JDOM has come quite a way in the last
>>year and this page is even more out of date. Has anyone done a benchmark?
>>Are there big differences, apart from the constuction of the XML object?
>>
>Has
>
>>anyone used both and done a pro's and cons?
>>
>>Regards
>>Justin
>>
>>_______________________________________________
>>To control your jdom-interest membership:
>>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourho
>>
>s
>
>>t.com
>>
>>
>>_______________________________________________
>>To control your jdom-interest membership:
>>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourho
>>
>st.com
>
>
>
>
>
From reddy at mahindrabt.com Tue Feb 12 23:38:24 2002
From: reddy at mahindrabt.com (Ravindra Reddy)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] RE:jdom-interest digest, Vol 1 #843 - 13 msgs
Message-ID: <2335358.1013566592328.JavaMail.Administrator@MOBI2>
Send jdom-interest mailing list submissions to
jdom-interest@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@jdom.org
You can reach the person managing the list at
jdom-interest-admin@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: JDOM vs electric (Dennis Sosnoski)
2. RE: JavaOne presentations (flame) (Kevin Jones)
3. NoClassDefFoundError: java/util/LinkList (Fellows, Nina L)
4. RE: JDOM vs electric (graham glass)
5. Re: JDOM vs electric (Dennis Sosnoski)
6. Re: JavaOne presentations (flame) (Bob_Lee@averydennison.com)
7. JavaOne presentations (flame) (Jason Hunter) (Peter.H.Roberts@bbh.com)
8. Using JDOM to manipulate HTML (Eric Ace)
9. getText() and getAttributeValue() (Trimmer, Todd)
10. Re: getText() and getAttributeValue() (Jon Baer)
11. RE: JDOM vs electric (graham glass)
12. RE: NoClassDefFoundError: java/util/LinkList (Alex Rosen)
13. Re: JDOM vs electric (Dennis Sosnoski)
--__--__--
Message: 1
Date: Tue, 12 Feb 2002 01:45:07 -0800
From: Dennis Sosnoski
To: Justin Wood
CC: jdom-interest@jdom.org
Subject: Re: [jdom-interest] JDOM vs electric
You can see my performance comparison on XML developerWorks (including
JDOM, dom4j, EXML, etc.), at
http://www-106.ibm.com/developerworks/xml/library/x-injava/index.html.
There's a second article comparing usage that's been turned in to IBM
since the beginning of October; hopefully it'll be published soon. :-)
I've got updated results all graphed up and ready for publication on my
web site, whenever I can take the time to put the text together. Nothing
has changed with JDOM since the earlier results were published on
developerWorks, though - it's still beta 7. Whenever JDOM beta 8 is
released it sounds like it should show some improvements.
- Dennis
Justin Wood wrote:
>I had a look in the mail archives from last year regarding this topic. Round about March Jason and Graham Glass (from the Mind Electric) did a bit of mudslinging.
>
>http://www.servlets.com/archive/servlet/ReadMsg?msgId=7279&listName=jdom-interest
>
>Graham said he would amend his page:
>
>http://www.themindelectric.com/products/xml/jdom.html
>
>Which he hasn't done. I'm sure that JDOM has come quite a way in the last year and this page is even more out of date. Has anyone done a benchmark? Are there big differences, apart from the constuction of the XML object? Has anyone used both and done a pro's and cons?
>
>Regards
>Justin
>
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
--__--__--
Message: 2
From: "Kevin Jones"
To:
Subject: RE: [jdom-interest] JavaOne presentations (flame)
Date: Tue, 12 Feb 2002 15:57:25 -0000
Part of the problem is that the technical guys inside Sun seem to have
no say as to who does the talks. I did a BOF on Taglibs (sorry Jason) a
couple of years ago, after which I got invited onto the expert group
(sound of own trumpet blowing). We (as a company) they spoke to the Sun
leads on the expert group about getting 'big tent' talks, but they said
that basically they have no influence with Key3Media (the company that
arranges the conference).
And (after finally having talks accepted) I agree with Jason. The
process is nightmarish!
Kevin Jones
Developmentor
www.develop.com
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org] On Behalf Of Jon Baer
> Sent: 11 February 2002 22:36
> To: jdom-interest@jdom.org
> Subject: Re: [jdom-interest] JavaOne presentations (flame)
>
>
> Thank you, thank you, thank you.
>
> Not for nothing, but I thought I was the only one who felt
> like that. I had personally wasted alot of time, energy, and
> money @ these types of conferences (where it seemed like the
> talker was very restricted and seemed smart but made no
> sense) and yet when all is said and done I actually learn
> more from free seminars/slides from people like Elliotte and
> such. Someone should tell Sun that when they try to be a
> little "too controlling" they end up being like some other
> company we know. Now quite honestly I can understand that
> some guidelines when applied to open source are needed to
> avoid all out chaos but when you have done so much for the
> community already and ur name is Jason Hunter with a few best
> selling books out, why even question the slides to begin with?
>
> - Jon
>
> "Bosch, Mike" wrote:
>
> > Which in addition you get the "privilege" of paying ~$$2000
> to go and
> > listen to corporate advertising.
> >
> > Count me out on the conference unless one of our vendors gets me in.
> >
> > -Mike
> >
> > -----Original Message-----
> > From: Bradley S. Huffman [mailto:hip@a.cs.okstate.edu]
> > Sent: Monday, February 11, 2002 1:09 PM
> > To: jdom-interest@jdom.org
> > Subject: Re: [jdom-interest] JavaOne presentations (flame)
> >
> > What do you expect when they are the head rats in charge of the
> > cheese. I think for your talk you should dye your hair pink
> and wear a
> > t-shirt that says "Large coporate advertising disguised as a
> > conference still sucks!"
> >
> > :->
> >
> > Jason Hunter writes:
> >
> > > Frank Sauer wrote:
> > > > Wow, do you work for SUN now? How in the world did you
> get in in
> > > > the first place? I wish I had to deal with the slide
> nazis but I
> > > > have
> > yet
> > > > to meet the first non-SUN JavaOne speaker. Just
> venting, let's all
> > > > vent
> > :-)
> > >
> > > Ha! Good question. The talk actually wasn't accepted at first.
> > > And you're right, JavaOne is notorious for having dozens of talks
> > > about Sun's favorite new technology (ie JSP taglibs) and
> missing out
> > > on whole swaths of interesting other technologies (ie Apache
> > > Velocity). Last year there were at least a dozen JAXP
> talks. As if
> > > you couldn't understand all of JAXP in one short talk.
> And JDOM was
> > > left as an alternate talk. This year I had to do a
> little lobbying
> > > after the initial refusal. I think it helped that JDOM was a JSR
> > > and that I'm Apache's representative to the JCP Executive
> Committee.
> > _______________________________________________
> > To control your jdom-interest membership:
> >
> http://lists.denveronline.net/mailman/options/>
jdom-interest/youraddr@y
> > ourhos
> > t.com
> > _______________________________________________
> > To control your jdom-interest membership:
> >
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@yourhost.com
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@you
rhost.com
--__--__--
Message: 3
From: "Fellows, Nina L"
To: "'jdom-interest@jdom.org'"
Date: Tue, 12 Feb 2002 10:27:33 -0600
Subject: [jdom-interest] NoClassDefFoundError: java/util/LinkList
Hi!
I have installed the jdom-b7, executed build and build samples, set up
JAVA_HOME, and added xerces.jar, jdom.jar and build\classes to the
classpath. When running java samples.WarReader web.xml I receive
java.lang.NoClassDefFoundError: java/util/LinkedList
at org.jdom.input.SAXHandler.(SAXHandler.java:176)
at
org.jdom.input.SAXBuilder.createContentHandler
To: , "Justin Wood"
Subject: RE: [jdom-interest] JDOM vs electric
Date: Tue, 12 Feb 2002 10:40:25 -0600
hi there,
one new thing worth mentioning is that EXML+ 4.0, due out in a couple
of weeks, includes native support for DOM. so in addition to the
ease-of-use,
you now get native DOM compatability.
after releasing EXML+ 4.0, we'll rerun the benchmarks using xerces 2.0
and the latest version of DOM, and update the JDOM benchmark page.
EXML+ 4.0 also includes transparent bidirectional serialization of Java
objects to/from XML, Java persistence using XML, XML document pattern
matching
and many other goodies. it includes the source code for EXML and is free
for most commercial uses.
cheers,
graham
http://www.themindelectric.com
-----Original Message-----
From: jdom-interest-admin@jdom.org
[mailto:jdom-interest-admin@jdom.org]On Behalf Of Justin Wood
Sent: Tuesday, February 12, 2002 12:17 AM
To: jdom-interest@jdom.org
Subject: [jdom-interest] JDOM vs electric
I had a look in the mail archives from last year regarding this topic.
Round about March Jason and Graham Glass (from the Mind Electric) did a bit
of mudslinging.
http://www.servlets.com/archive/servlet/ReadMsg?msgId=7279&listName=jdom-int
erest
Graham said he would amend his page:
http://www.themindelectric.com/products/xml/jdom.html
Which he hasn't done. I'm sure that JDOM has come quite a way in the last
year and this page is even more out of date. Has anyone done a benchmark?
Are there big differences, apart from the constuction of the XML object? Has
anyone used both and done a pro's and cons?
Regards
Justin
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
--__--__--
Message: 5
Date: Tue, 12 Feb 2002 09:21:47 -0800
From: Dennis Sosnoski
To: graham glass
CC: jdom-interest@jdom.org, Justin Wood
Subject: Re: [jdom-interest] JDOM vs electric
Hi Graham,
When you update the page, I'd appreciate it if you'd add a link to my
benchmarks as well (either that, or at least take out the line about
being glad to link to other benchmarks).
For more representative results you should also look at doing a couple
of things differently in your test case. If EXML+ 4.0 still discards
whitespace sequences (in violation of the XML spec) you should use a
test document which does not include any extra whitespace. You should
also use something other than Xerces 1 as the parser for the JDOM test,
since Xerces 1 shows very poor performance on small documents (Xerces 2
is better). Finally, you should include dom4j as a comparison, since
dom4j is considerably more mature than JDOM and includes a number of
performance optimizations.
- Dennis
graham glass wrote:
>hi there,
>
>one new thing worth mentioning is that EXML+ 4.0, due out in a couple
>of weeks, includes native support for DOM. so in addition to the
>ease-of-use,
>you now get native DOM compatability.
>
>after releasing EXML+ 4.0, we'll rerun the benchmarks using xerces 2.0
>and the latest version of DOM, and update the JDOM benchmark page.
>
>EXML+ 4.0 also includes transparent bidirectional serialization of Java
>objects to/from XML, Java persistence using XML, XML document pattern
>matching
>and many other goodies. it includes the source code for EXML and is free
>for most commercial uses.
>
>cheers,
>graham
>
>http://www.themindelectric.com
>
>-----Original Message-----
>From: jdom-interest-admin@jdom.org
>[mailto:jdom-interest-admin@jdom.org]On Behalf Of Justin Wood
>Sent: Tuesday, February 12, 2002 12:17 AM
>To: jdom-interest@jdom.org
>Subject: [jdom-interest] JDOM vs electric
>
>
>I had a look in the mail archives from last year regarding this topic.
>Round about March Jason and Graham Glass (from the Mind Electric) did a bit
>of mudslinging.
>
>http://www.servlets.com/archive/servlet/ReadMsg?msgId=7279&listName=jdom-int
>erest
>
>Graham said he would amend his page:
>
>http://www.themindelectric.com/products/xml/jdom.html
>
>Which he hasn't done. I'm sure that JDOM has come quite a way in the last
>year and this page is even more out of date. Has anyone done a benchmark?
>Are there big differences, apart from the constuction of the XML object? Has
>anyone used both and done a pro's and cons?
>
>Regards
>Justin
>
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
>t.com
>
>
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
--__--__--
Message: 6
From: Bob_Lee@averydennison.com
Subject: Re: [jdom-interest] JavaOne presentations (flame)
To: jdom-interest@jdom.org
Date: Tue, 12 Feb 2002 10:37:08 -0800
Jason, can you publish the "rejected" slides on the web for those of us
who won't be attending? I've always enjoyed your talks.
-Bob Lee
--__--__--
Message: 7
From: Peter.H.Roberts@bbh.com
To: jdom-interest@jdom.org
Date: Tue, 12 Feb 2002 14:21:07 -0500
Subject: [jdom-interest] JavaOne presentations (flame) (Jason Hunter)
In response to Jason,
I used to go religiously to Java One, but have found it not very usefull, and did not go last year, and we are not going this year. As you said, it seems the information dolled out is dumbed down. If I had gone I probably would have gone to your
talk, and then (horror) thought you were not as smart as I currently think. I really like JDOM, so my advice is don't go, but Java One is in SF and SF is beautifull in March. Try and give the talk at IBM WebSphere convention in May, I will be there. It's
beautifull in May also.
Peter:)
jdom-interest-admi
n@jdom.org To: jdom-interest@jdom.org
cc:
02/11/2002 02:04 Subject: jdom-interest digest, Vol 1 #841 - 3 msgs
AM
Please respond to
jdom-interest
Send jdom-interest mailing list submissions to
jdom-interest@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@jdom.org
You can reach the person managing the list at
jdom-interest-admin@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: Jar-Archive (Joern Muehlencord)
2. JavaOne presentations (flame) (Jason Hunte
3. RE: JavaOne presentations (flame) (Frank Sauer)
-- __--__--
Message: 1
Date: Sat, 09 Feb 2002 18:15:33 +0100
From: Joern Muehlencord
To: Jason Hunter
Cc: jdom-interest
Subject: Re: [jdom-interest] Jar-Archive
Hi Jason,
> I believe when you "-jar" run a JAR file it ignores the classpath.
> You'd need to have supporting JARs in your MANIFEST.MF for them to be
> found.
That is right. I needed to include "Class-Path: jdom.jar" to the
manifest-file. xerces.jar is not needed - it is included bei jdom.jar.
Now it is ok, to put all three archives into one directory and start the
application out of the jar-file.
Thanx
Joern
--
Linux is like a wigwam - no Windows, no Gates and Apache inside
-- __--__--
Message: 2
Date: Sun, 10 Feb 2002 18:11:30 -0800
From: Jason Hunter
To: JDOM Interest
Subject: [jdom-interest] JavaOne presentations (flame)
I just have to vent, and this crowd seems like a fine place to vent
about this particular thing.
I'm presenting a talk on JDOM at JavaOne this year, and Oh My God, the
slide submittal process is horrid. Absolutely draconian. Unlike *every
other conference* I've spoken at (dozens), at JavaOne there are people
who critique your slides on various Rules. These Rules are definitely
smart guidelines but at JavaOne they are literally *Rules*. If you
don't pass each and every rule down the line, they don't let you give
you talk.
One sample rule: You need a graphic on at least one out of every 6
pages. Need it or not, appropriate or not, you need a graphic. It's
supposed to keep your audience awake. Well, I guess I have to come up
with a graphic for the section where I compare JDOM with DOM. Any
ideas? I wonder if a picture from Anna Kournikova's new calendar would
do.
Another rule: You should have no more than six words per bullet point.
Wait, did I say "should"? I mean MUST as in the W3C spec meaning of the
word. Nothing longer than six words is .
That last one really bugs me. I personally find JavaOne slides 100%
useless after the talk because of this rule. I've downloaded slides in
years past from talks I couldn't attend. Here's what you get:
* JVM Performance In Process
* Garbage Collection In Real Time
Oh yeah, I'm really learning now. They say this rule is to keep the
point size up so you can read the slides during the show, but seems to
me:
* If you're in the show you're listening, not reading
* If you're not in the show, you can only read
(Notice the effective use of 9 word bullets there.)
So with big point sizes you can read my outline during the show, but
after I'm done talking, all the points are lost.
I was proud and I stood my moral ground and flaunted the rules -- I used
graphics only when I needed graphics and I tried to actually *say
something* with each bullet point. But no. The people reviewing the
talks actually counted my words and my graphic densities. I failed.
I'm told I need to revise now.
What's really ironic is last year the same basic slide outline was
accepted. I was just unlucky enough this year to get the Presentation
Nazi. I can almost hear him yell: "No presentation for you, one year!"
Maybe you're thinking I should obligingly bow to the "Rules" and be
tricky and bring my own slides in on a laptop on the presentation day.
No can do; they're on to that! You can't bring your own laptop to
present. Every other conference I've spoken at lets you. Why not at
JavaOne? They say it's to keep things simpler to setup, but really how
simple is it for me to load JDOM examples on their machine versus my
own?? Here's my theory: if anyone ever tries to make The Training
Alliance Nazis (tm) look bad (you know, someone in a bad mood -- try to
picture it), they'll know beforehand and have some leverage to encourage
you to change your slides.
I agree these guidelines make sense in general, but can we give the
speakers no credit? The best talks I've ever attended have slides that
don't in any way follow the JavaOne Rules. And some of the worst talks
I've ever attended have been at JavaOne. Maybe they're trying to raise
up the quality of these poor talks by rigidly enforcing these rules. I
think it's more likely they're creating poor talks by enforcing these
rules.
Ah well. At least I can still say what I want on stage. Um, probably.
I'll let you know if they actually let me speak live on stage or if it's
a tape recording.
-jh-
P.S. Sun speakers suffer from this just as much as outside people.
This is another reason why no one at Sun looks very happy the month
before JavaOne.
P.P.S. The slides haven't even gone to legal review yet. Last year in
legal review they changed "JDOM" to "The Document Object Model for Java"
on me and for a long time refused to change it back. You'd think they
would believe I knew the name of my project.
-- __--__--
Message: 3
Subject: RE: [jdom-interest] JavaOne presentations (flame)
Date: Sun, 10 Feb 2002 23:28:31 -0500
From: "Frank Sauer"
To: "Jason Hunter" , "JDOM Interest"
V293LCBkbyB5b3Ugd29yayBmb3IgU1VOIG5vdz8gSG93IGluIHRoZSB3b3JsZCBkaWQgeW91IGdl
dCBpbiANCmluIHRoZSBmaXJzdCBwbGFjZT8gSSB3aXNoIEkgaGFkIHRvIGRlYWwgd2l0aCB0aGUg
c2xpZGUgbmF6aXMgYnV0IEkgaGF2ZSB5ZXQNCnRvIG1lZXQgdGhlIGZpcnN0IG5vbi1TVU4gSmF2
YU9uZSBzcGVha2VyLiBKdXN0IHZlbnRpbmcsIGxldCdzIGFsbCB2ZW50IDotKQ0KIA0KRnJhbmsN
CiANClAuUy4gSSBrbm93IHlvdSBkb24ndCB3b3JrIGZvciBTdW4sIGJ1dCB3aXRoIEpET00gYmVp
bmcgYSBKU1IgYW5kIGFsbCwNCkknbSBub3QgdG9vIHN1cnByaXNlZCB0byBzZWUgeW91IG1hZGUg
aXQuIA0KIA0KUC5QLlMuIEdvb2QgTHVjayEgYW5kIEknbGwgc2VlIHlvdSBhdCBKYXZhT25lIChi
dXQgbm90IGFzIGEgc3BlYWtlciBteXNlbGYpDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LSANCglGcm9tOiBKYXNvbiBIdW50ZXIgW21haWx0bzpqaHVudGVyQGFjbS5vcmddIA0KCVNlbnQ6
IFN1biAyLzEwLzIwMDIgOToxMSBQTSANCglUbzogSkRPTSBJbnRlcmVzdCANCglDYzogDQoJU3Vi
amVjdDogW2pkb20taW50ZXJlc3RdIEphdmFPbmUgcHJlc2VudGF0aW9ucyAoZmxhbWUpDQoJDQoJ
DQoNCglJIGp1c3QgaGF2ZSB0byB2ZW50LCBhbmQgdGhpcyBjcm93ZCBzZWVtcyBsaWtlIGEgZmlu
ZSBwbGFjZSB0byB2ZW50DQoJYWJvdXQgdGhpcyBwYXJ0aWN1bGFyIHRoaW5nLg0KCQ0KCUknbSBw
cmVzZW50aW5nIGEgdGFsayBvbiBKRE9NIGF0IEphdmFPbmUgdGhpcyB5ZWFyLCBhbmQgT2ggTXkg
R29kLCB0aGUNCglzbGlkZSBzdWJtaXR0YWwgcHJvY2VzcyBpcyBob3JyaWQuICBBYnNvbHV0ZWx5
IGRyYWNvbmlhbi4gIFVubGlrZSAqZXZlcnkNCglvdGhlciBjb25mZXJlbmNlKiBJJ3ZlIHNwb2tl
biBhdCAoZG96ZW5zKSwgYXQgSmF2YU9uZSB0aGVyZSBhcmUgcGVvcGxlDQoJd2hvIGNyaXRpcXVl
IHlvdXIgc2xpZGVzIG9uIHZhcmlvdXMgUnVsZXMuICBUaGVzZSBSdWxlcyBhcmUgZGVmaW5pdGVs
eQ0KCXNtYXJ0IGd1aWRlbGluZXMgYnV0IGF0IEphdmFPbmUgdGhleSBhcmUgbGl0ZXJhbGx5ICpS
dWxlcyouICBJZiB5b3UNCglkb24ndCBwYXNzIGVhY2ggYW5kIGV2ZXJ5IHJ1bGUgZG93biB0aGUg
bGluZSwgdGhleSBkb24ndCBsZXQgeW91IGdpdmUNCgl5b3UgdGFsay4NCgkNCglPbmUgc2FtcGxl
IHJ1bGU6ICBZb3UgbmVlZCBhIGdyYXBoaWMgb24gYXQgbGVhc3Qgb25lIG91dCBvZiBldmVyeSA2
DQoJcGFnZXMuICBOZWVkIGl0IG9yIG5vdCwgYXBwcm9wcmlhdGUgb3Igbm90LCB5b3UgbmVlZCBh
IGdyYXBoaWMuICBJdCdzDQoJc3VwcG9zZWQgdG8ga2VlcCB5b3VyIGF1ZGllbmNlIGF3YWtlLiAg
V2VsbCwgSSBndWVzcyBJIGhhdmUgdG8gY29tZSB1cA0KCXdpdGggYSBncmFwaGljIGZvciB0aGUg
c2VjdGlvbiB3aGVyZSBJIGNvbXBhcmUgSkRPTSB3aXRoIERPTS4gIEFueQ0KCWlkZWFzPyAgSSB3
b25kZXIgaWYgYSBwaWN0dXJlIGZyb20gQW5uYSBLb3Vybmlrb3ZhJ3MgbmV3IGNhbGVuZGFyIHdv
dWxkDQoJZG8uDQoJDQoJQW5vdGhlciBydWxlOiAgWW91IHNob3VsZCBoYXZlIG5vIG1vcmUgdGhh
biBzaXggd29yZHMgcGVyIGJ1bGxldCBwb2ludC4NCglXYWl0LCBkaWQgSSBzYXkgInNob3VsZCI/
ICBJIG1lYW4gTVVTVCBhcyBpbiB0aGUgVzNDIHNwZWMgbWVhbmluZyBvZiB0aGUNCgl3b3JkLiAg
Tm90aGluZyBsb25nZXIgdGhhbiBzaXggd29yZHMgaXMgPG9vcHMsIGN1dCwgY2FuJ3Qgc2F5IGFu
eW1vcmU+Lg0KCQ0KCVRoYXQgbGFzdCBvbmUgcmVhbGx5IGJ1Z3MgbWUuICBJIHBlcnNvbmFsbHkg
ZmluZCBKYXZhT25lIHNsaWRlcyAxMDAlDQoJdXNlbGVzcyBhZnRlciB0aGUgdGFsayBiZWNhdXNl
IG9mIHRoaXMgcnVsZS4gIEkndmUgZG93bmxvYWRlZCBzbGlkZXMgaW4NCgl5ZWFycyBwYXN0IGZy
b20gdGFsa3MgSSBjb3VsZG4ndCBhdHRlbmQuICBIZXJlJ3Mgd2hhdCB5b3UgZ2V0Og0KCQ0KCSog
SlZNIFBlcmZvcm1hbmNlIEluIFByb2Nlc3MNCgkqIEdhcmJhZ2UgQ29sbGVjdGlvbiBJbiBSZWFs
IFRpbWUNCgkNCglPaCB5ZWFoLCBJJ20gcmVhbGx5IGxlYXJuaW5nIG5vdy4gIFRoZXkgc2F5IHRo
aXMgcnVsZSBpcyB0byBrZWVwIHRoZQ0KCXBvaW50IHNpemUgdXAgc28geW91IGNhbiByZWFkIHRo
ZSBzbGlkZXMgZHVyaW5nIHRoZSBzaG93LCBidXQgc2VlbXMgdG8NCgltZToNCgkNCgkqIElmIHlv
dSdyZSBpbiB0aGUgc2hvdyB5b3UncmUgbGlzdGVuaW5nLCBub3QgcmVhZGluZw0KCSogSWYgeW91
J3JlIG5vdCBpbiB0aGUgc2hvdywgeW91IGNhbiBvbmx5IHJlYWQNCgkNCgkoTm90aWNlIHRoZSBl
ZmZlY3RpdmUgdXNlIG9mIDkgd29yZCBidWxsZXRzIHRoZXJlLikNCgkNCglTbyB3aXRoIGJpZyBw
b2ludCBzaXplcyB5b3UgY2FuIHJlYWQgbXkgb3V0bGluZSBkdXJpbmcgdGhlIHNob3csIGJ1dA0K
CWFmdGVyIEknbSBkb25lIHRhbGtpbmcsIGFsbCB0aGUgcG9pbnRzIGFyZSBsb3N0Lg0KCQ0KCUkg
d2FzIHByb3VkIGFuZCBJIHN0b29kIG15IG1vcmFsIGdyb3VuZCBhbmQgZmxhdW50ZWQgdGhlIHJ1
bGVzIC0tIEkgdXNlZA0KCWdyYXBoaWNzIG9ubHkgd2hlbiBJIG5lZWRlZCBncmFwaGljcyBhbmQg
SSB0cmllZCB0byBhY3R1YWxseSAqc2F5DQoJc29tZXRoaW5nKiB3aXRoIGVhY2ggYnVsbGV0IHBv
aW50LiAgQnV0IG5vLiAgVGhlIHBlb3BsZSByZXZpZXdpbmcgdGhlDQoJdGFsa3MgYWN0dWFsbHkg
Y291bnRlZCBteSB3b3JkcyBhbmQgbXkgZ3JhcGhpYyBkZW5zaXRpZXMuICBJIGZhaWxlZC4NCglJ
J20gdG9sZCBJIG5lZWQgdG8gcmV2aXNlIG5vdy4NCgkNCglXaGF0J3MgcmVhbGx5IGlyb25pYyBp
cyBsYXN0IHllYXIgdGhlIHNhbWUgYmFzaWMgc2xpZGUgb3V0bGluZSB3YXMNCglhY2NlcHRlZC4g
IEkgd2FzIGp1c3QgdW5sdWNreSBlbm91Z2ggdGhpcyB5ZWFyIHRvIGdldCB0aGUgUHJlc2VudGF0
aW9uDQoJTmF6aS4gIEkgY2FuIGFsbW9zdCBoZWFyIGhpbSB5ZWxsOiAgIk5vIHByZXNlbnRhdGlv
biBmb3IgeW91LCBvbmUgeWVhciEiDQoJDQoJTWF5YmUgeW91J3JlIHRoaW5raW5nIEkgc2hvdWxk
IG9ibGlnaW5nbHkgYm93IHRvIHRoZSAiUnVsZXMiIGFuZCBiZQ0KCXRyaWNreSBhbmQgYnJpbmcg
bXkgb3duIHNsaWRlcyBpbiBvbiBhIGxhcHRvcCBvbiB0aGUgcHJlc2VudGF0aW9uIGRheS4NCglO
byBjYW4gZG87IHRoZXkncmUgb24gdG8gdGhhdCEgIFlvdSBjYW4ndCBicmluZyB5b3VyIG93biBs
YXB0b3AgdG8NCglwcmVzZW50LiAgRXZlcnkgb3RoZXIgY29uZmVyZW5jZSBJJ3ZlIHNwb2tlbiBh
dCBsZXRzIHlvdS4gIFdoeSBub3QgYXQNCglKYXZhT25lPyAgVGhleSBzYXkgaXQncyB0byBrZWVw
IHRoaW5ncyBzaW1wbGVyIHRvIHNldHVwLCBidXQgcmVhbGx5IGhvdw0KCXNpbXBsZSBpcyBpdCBm
b3IgbWUgdG8gbG9hZCBKRE9NIGV4YW1wbGVzIG9uIHRoZWlyIG1hY2hpbmUgdmVyc3VzIG15DQoJ
b3duPz8gIEhlcmUncyBteSB0aGVvcnk6IGlmIGFueW9uZSBldmVyIHRyaWVzIHRvIG1ha2UgVGhl
IFRyYWluaW5nDQoJQWxsaWFuY2UgTmF6aXMgKHRtKSBsb29rIGJhZCAoeW91IGtub3csIHNvbWVv
bmUgaW4gYSBiYWQgbW9vZCAtLSB0cnkgdG8NCglwaWN0dXJlIGl0KSwgdGhleSdsbCBrbm93IGJl
Zm9yZWhhbmQgYW5kIGhhdmUgc29tZSBsZXZlcmFnZSB0byBlbmNvdXJhZ2UNCgl5b3UgdG8gY2hh
bmdlIHlvdXIgc2xpZGVzLg0KCQ0KCUkgYWdyZWUgdGhlc2UgZ3VpZGVsaW5lcyBtYWtlIHNlbnNl
IGluIGdlbmVyYWwsIGJ1dCBjYW4gd2UgZ2l2ZSB0aGUNCglzcGVha2VycyBubyBjcmVkaXQ/ICBU
aGUgYmVzdCB0YWxrcyBJJ3ZlIGV2ZXIgYXR0ZW5kZWQgaGF2ZSBzbGlkZXMgdGhhdA0KCWRvbid0
IGluIGFueSB3YXkgZm9sbG93IHRoZSBKYXZhT25lIFJ1bGVzLiAgQW5kIHNvbWUgb2YgdGhlIHdv
cnN0IHRhbGtzDQoJSSd2ZSBldmVyIGF0dGVuZGVkIGhhdmUgYmVlbiBhdCBKYXZhT25lLiAgTWF5
YmUgdGhleSdyZSB0cnlpbmcgdG8gcmFpc2UNCgl1cCB0aGUgcXVhbGl0eSBvZiB0aGVzZSBwb29y
IHRhbGtzIGJ5IHJpZ2lkbHkgZW5mb3JjaW5nIHRoZXNlIHJ1bGVzLiAgSQ0KCXRoaW5rIGl0J3Mg
bW9yZSBsaWtlbHkgdGhleSdyZSBjcmVhdGluZyBwb29yIHRhbGtzIGJ5IGVuZm9yY2luZyB0aGVz
ZQ0KCXJ1bGVzLg0KCQ0KCUFoIHdlbGwuICBBdCBsZWFzdCBJIGNhbiBzdGlsbCBzYXkgd2hhdCBJ
IHdhbnQgb24gc3RhZ2UuICBVbSwgcHJvYmFibHkuDQoJSSdsbCBsZXQgeW91IGtub3cgaWYgdGhl
eSBhY3R1YWxseSBsZXQgbWUgc3BlYWsgbGl2ZSBvbiBzdGFnZSBvciBpZiBpdCdzDQoJYSB0YXBl
IHJlY29yZGluZy4NCgkNCgktamgtDQoJDQoJUC5TLiAgU3VuIHNwZWFrZXJzIHN1ZmZlciBmcm9t
IHRoaXMganVzdCBhcyBtdWNoIGFzIG91dHNpZGUgcGVvcGxlLg0KCVRoaXMgaXMgYW5vdGhlciBy
ZWFzb24gd2h5IG5vIG9uZSBhdCBTdW4gbG9va3MgdmVyeSBoYXBweSB0aGUgbW9udGgNCgliZWZv
cmUgSmF2YU9uZS4NCgkNCglQLlAuUy4gIFRoZSBzbGlkZXMgaGF2ZW4ndCBldmVuIGdvbmUgdG8g
bGVnYWwgcmV2aWV3IHlldC4gIExhc3QgeWVhciBpbg0KCWxlZ2FsIHJldmlldyB0aGV5IGNoYW5n
ZWQgIkpET00iIHRvICJUaGUgRG9jdW1lbnQgT2JqZWN0IE1vZGVsIGZvciBKYXZhIg0KCW9uIG1l
IGFuZCBmb3IgYSBsb25nIHRpbWUgcmVmdXNlZCB0byBjaGFuZ2UgaXQgYmFjay4gIFlvdSdkIHRo
aW5rIHRoZXkNCgl3b3VsZCBiZWxpZXZlIEkga25ldyB0aGUgbmFtZSBvZiBteSBwcm9qZWN0Lg0K
CV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJVG8gY29u
dHJvbCB5b3VyIGpkb20taW50ZXJlc3QgbWVtYmVyc2hpcDoNCglodHRwOi8vbGlzdHMuZGVudmVy
b25saW5lLm5ldC9tYWlsbWFuL29wdGlvbnMvamRvbS1pbnRlcmVzdC95b3VyYWRkckB5b3VyaG9z
dC5jb20NCgkNCg0KDQoNCg0K
-- __--__--
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
End of jdom-interest Digest
--__--__--
Message: 8
Date: Tue, 12 Feb 2002 16:28:28 -0500
From: "Eric Ace"
To:
Subject: [jdom-interest] Using JDOM to manipulate HTML
I want to use JDOM to manage presentation. Instead of using custom tags a la Struts, my thought is to have a presentation tier that queries business components and merges data into static HTML via JDOM. So, I need to be able to locate specific HTML elements by name or ID and modify them. For example:
...
I can ultimately get to the table I need to manipulate by getting all "table" elements, then looking for one that contains an ID attribute. What would be more programmatically clean though would be to manipulate the document via JDOM similarly to how I can via the DOM in JavaScript.
Am I completely missing the spirit of JDOM? Or, missing some fundamentally obvious point?
Thanks
-EAce
--__--__--
Message: 9
From: "Trimmer, Todd"
To: "'jdom-interest@jdom.org'"
Date: Tue, 12 Feb 2002 14:49:25 -0700
Subject: [jdom-interest] getText() and getAttributeValue()
For Element, if no textual content exists, getText() returns an empty
string. However, if getAttributeValue() is called for an attribute that does
not exist, null is returned. Why the inconsistency?
Under what circumstances would client code care to differentiate between an
attribute existing with empty string and the attibute not existing at all?
getAttributeValue() should return empty string if the attribute does not
exist because:
1) It makes it more consistent with getText()
2) One won't have to check for null on the return value.
Right now, my code is littered with:
String name = Parse.assure(elem.getAttributeValue("name"));
String id = Parse.assure(elem.getAttributeValue("id"));
// etc.
...where Parse.assure(String str) returns empty string if str is null; or
str unchanged if it is non-null. It sure would be nice to get rid of all
those checks.
Todd Trimmer
--__--__--
Message: 10
Date: Tue, 12 Feb 2002 17:01:01 -0500
From: Jon Baer
To: jdom-interest@jdom.org
Subject: Re: [jdom-interest] getText() and getAttributeValue()
I agree =) + 1
return (attribute == null) ? null : attribute.getValue();
-to-
return (attribute == null) ? "" : attribute.getValue();
- Jon
"Trimmer, Todd" wrote:
> For Element, if no textual content exists, getText() returns an empty
> string. However, if getAttributeValue() is called for an attribute that does
> not exist, null is returned. Why the inconsistency?
>
> Under what circumstances would client code care to differentiate between an
> attribute existing with empty string and the attibute not existing at all?
>
> getAttributeValue() should return empty string if the attribute does not
> exist because:
> 1) It makes it more consistent with getText()
> 2) One won't have to check for null on the return value.
>
> Right now, my code is littered with:
> String name = Parse.assure(elem.getAttributeValue("name"));
> String id = Parse.assure(elem.getAttributeValue("id"));
> // etc.
>
> ...where Parse.assure(String str) returns empty string if str is null; or
> str unchanged if it is non-null. It sure would be nice to get rid of all
> those checks.
>
> Todd Trimmer
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
--__--__--
Message: 11
From: "graham glass"
To: "Dennis Sosnoski"
Cc: , "Justin Wood"
Subject: RE: [jdom-interest] JDOM vs electric
Date: Tue, 12 Feb 2002 18:08:17 -0600
hi dennis,
we'll run your benchmarks independently to verify them.
the last time we chatted, it seemed like you were getting
significantly different results from us, which brought
setup and configuration issues to light.
cheers,
graham
-----Original Message-----
From: Dennis Sosnoski [mailto:dms@sosnoski.com]
Sent: Tuesday, February 12, 2002 11:22 AM
To: graham glass
Cc: jdom-interest@jdom.org; Justin Wood
Subject: Re: [jdom-interest] JDOM vs electric
Hi Graham,
When you update the page, I'd appreciate it if you'd add a link to my
benchmarks as well (either that, or at least take out the line about
being glad to link to other benchmarks).
For more representative results you should also look at doing a couple
of things differently in your test case. If EXML+ 4.0 still discards
whitespace sequences (in violation of the XML spec) you should use a
test document which does not include any extra whitespace. You should
also use something other than Xerces 1 as the parser for the JDOM test,
since Xerces 1 shows very poor performance on small documents (Xerces 2
is better). Finally, you should include dom4j as a comparison, since
dom4j is considerably more mature than JDOM and includes a number of
performance optimizations.
- Dennis
graham glass wrote:
>hi there,
>
>one new thing worth mentioning is that EXML+ 4.0, due out in a couple
>of weeks, includes native support for DOM. so in addition to the
>ease-of-use,
>you now get native DOM compatability.
>
>after releasing EXML+ 4.0, we'll rerun the benchmarks using xerces 2.0
>and the latest version of DOM, and update the JDOM benchmark page.
>
>EXML+ 4.0 also includes transparent bidirectional serialization of Java
>objects to/from XML, Java persistence using XML, XML document pattern
>matching
>and many other goodies. it includes the source code for EXML and is free
>for most commercial uses.
>
>cheers,
>graham
>
>http://www.themindelectric.com
>
>-----Original Message-----
>From: jdom-interest-admin@jdom.org
>[mailto:jdom-interest-admin@jdom.org]On Behalf Of Justin Wood
>Sent: Tuesday, February 12, 2002 12:17 AM
>To: jdom-interest@jdom.org
>Subject: [jdom-interest] JDOM vs electric
>
>
>I had a look in the mail archives from last year regarding this topic.
>Round about March Jason and Graham Glass (from the Mind Electric) did a bit
>of mudslinging.
>
>http://www.servlets.com/archive/servlet/ReadMsg?msgId=7279&listName=jdom-in
t
>erest
>
>Graham said he would amend his page:
>
>http://www.themindelectric.com/products/xml/jdom.html
>
>Which he hasn't done. I'm sure that JDOM has come quite a way in the last
>year and this page is even more out of date. Has anyone done a benchmark?
>Are there big differences, apart from the constuction of the XML object?
Has
>anyone used both and done a pro's and cons?
>
>Regards
>Justin
>
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourho
s
>t.com
>
>
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourho
st.com
>
--__--__--
Message: 12
From: "Alex Rosen"
To: "'Fellows, Nina L'" ,
Subject: RE: [jdom-interest] NoClassDefFoundError: java/util/LinkList
Date: Tue, 12 Feb 2002 19:12:54 -0500
Which version of Java are you using? Since LinkedList is part of the JDK 1.2
and higher runtime, it should just work, if your JRE is not corrupt in some
way. If you're using JDK 1.1.x, you'll need to use the special 1.1
compatible version of JDOM in jdom11.jar. Check out the FAQ on this at
jdom.org.
Alex
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org]On Behalf Of Fellows, Nina L
> Sent: Tuesday, February 12, 2002 11:28 AM
> To: 'jdom-interest@jdom.org'
> Subject: [jdom-interest] NoClassDefFoundError: java/util/LinkList
>
>
> Hi!
>
> I have installed the jdom-b7, executed build and build samples, set up
> JAVA_HOME, and added xerces.jar, jdom.jar and build\classes to the
> classpath. When running java samples.WarReader web.xml I receive
>
> java.lang.NoClassDefFoundError: java/util/LinkedList
> at org.jdom.input.SAXHandler.(SAXHandler.java:176)
> at
> org.jdom.input.SAXBuilder.createContentHandler at org.jdom.input.SAXBuilder.build(SAXBuilder.java:279)
> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:617)
> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:599)
> at samples.WarReader.read(Compiled Code)
> at samples.WarReader.main(WarReader.java:187)
>
> Where is it looking to try and find the LinkedList.class? Do
> I need to add
> that to the classpath? I found LinkedList.class in
> jdk1.2.2\jre\rt.jar and
> JavaSoft\JRE\1.2\librt.jar, but added those directories to
> the classpath had
> no effect.
>
>
> Nina Fellows
> nina.fellows@eds.com
>
>
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@yourhost.com
--__--__--
Message: 13
Date: Tue, 12 Feb 2002 17:07:36 -0800
From: Dennis Sosnoski
To: graham glass
CC: jdom-interest@jdom.org, Justin Wood
Subject: Re: [jdom-interest] JDOM vs electric
Hi Graham,
In the latest set of tests I've added some collections of smaller
documents. EXML does very well on small documents (especially the SOAP
collection, not too surprisingly!). It still performs fairly poorly on
larger documents, especially when the elimination of whitespace is taken
into account.
As we'd discussed previously, the differences in results look to be due
to several factors:
1. Your test uses a single very small document, of the type that EXML
appears optimized for
2. You test only against JDOM running Xerces, which is kind of shooting
fish in a barrel when it comes to performance comparisons. :-) If you're
really interested in seeing how EXML performs you should test against
some of the other alternatives.
3. EXML discards character data sequences consisting only of whitespace,
and thereby uses a dramatically lower number of objects in the document
representations; while this is fine for many applications, it biases the
tests. It's also not compliant with the XML spec, and should at least be
pointed out to users in your documentation
4. My tests are looking for the best performance the code is able to
give, so I take the best time of several runs, while your test uses the
average time; using average times for benchmarking applications using
Hot Spot JVMs is questionable, if you're going to do this at all you
need to run an extended series of test passes and discard all but the
last few.
5. My tests use memory settings of -Xms64M and -Xmx64M to give the JVM
plenty of memory; this is appropriate for a server enviroment, and makes
a big difference in how well Hot Spot handles code. Your test run uses
the default setting.
- Dennis
graham glass wrote:
>hi dennis,
>
>we'll run your benchmarks independently to verify them.
>
>the last time we chatted, it seemed like you were getting
>significantly different results from us, which brought
>setup and configuration issues to light.
>
>cheers,
>graham
>
>-----Original Message-----
>From: Dennis Sosnoski [mailto:dms@sosnoski.com]
>Sent: Tuesday, February 12, 2002 11:22 AM
>To: graham glass
>Cc: jdom-interest@jdom.org; Justin Wood
>Subject: Re: [jdom-interest] JDOM vs electric
>
>
>Hi Graham,
>
>When you update the page, I'd appreciate it if you'd add a link to my
>benchmarks as well (either that, or at least take out the line about
>being glad to link to other benchmarks).
>
>For more representative results you should also look at doing a couple
>of things differently in your test case. If EXML+ 4.0 still discards
>whitespace sequences (in violation of the XML spec) you should use a
>test document which does not include any extra whitespace. You should
>also use something other than Xerces 1 as the parser for the JDOM test,
>since Xerces 1 shows very poor performance on small documents (Xerces 2
>is better). Finally, you should include dom4j as a comparison, since
>dom4j is considerably more mature than JDOM and includes a number of
>performance optimizations.
>
> - Dennis
>
>graham glass wrote:
>
>>hi there,
>>
>>one new thing worth mentioning is that EXML+ 4.0, due out in a couple
>>of weeks, includes native support for DOM. so in addition to the
>>ease-of-use,
>>you now get native DOM compatability.
>>
>>after releasing EXML+ 4.0, we'll rerun the benchmarks using xerces 2.0
>>and the latest version of DOM, and update the JDOM benchmark page.
>>
>>EXML+ 4.0 also includes transparent bidirectional serialization of Java
>>objects to/from XML, Java persistence using XML, XML document pattern
>>matching
>>and many other goodies. it includes the source code for EXML and is free
>>for most commercial uses.
>>
>>cheers,
>>graham
>>
>>http://www.themindelectric.com
>>
>>-----Original Message-----
>>From: jdom-interest-admin@jdom.org
>>[mailto:jdom-interest-admin@jdom.org]On Behalf Of Justin Wood
>>Sent: Tuesday, February 12, 2002 12:17 AM
>>To: jdom-interest@jdom.org
>>Subject: [jdom-interest] JDOM vs electric
>>
>>
>>I had a look in the mail archives from last year regarding this topic.
>>Round about March Jason and Graham Glass (from the Mind Electric) did a bit
>>of mudslinging.
>>
>>http://www.servlets.com/archive/servlet/ReadMsg?msgId=7279&listName=jdom-in
>>
>t
>
>>erest
>>
>>Graham said he would amend his page:
>>
>>http://www.themindelectric.com/products/xml/jdom.html
>>
>>Which he hasn't done. I'm sure that JDOM has come quite a way in the last
>>year and this page is even more out of date. Has anyone done a benchmark?
>>Are there big differences, apart from the constuction of the XML object?
>>
>Has
>
>>anyone used both and done a pro's and cons?
>>
>>Regards
>>Justin
>>
>>_______________________________________________
>>To control your jdom-interest membership:
>>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourho
>>
>s
>
>>t.com
>>
>>
>>_______________________________________________
>>To control your jdom-interest membership:
>>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourho
>>
>st.com
>
>
>
>
>
--__--__--
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
End of jdom-interest Digest
*********************************************************
Disclaimer
This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.
*********************************************************
Visit us at http://www.mahindrabt.com
From Sasha.Bilton at bskyb.com Wed Feb 13 01:04:01 2002
From: Sasha.Bilton at bskyb.com (Bilton, Sasha)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] getText() and getAttributeValue()
Message-ID:
> From: Jon Baer [mailto:jonbaer@digitalanywhere.com]
> return (attribute == null) ? null : attribute.getValue();
> -to-
> return (attribute == null) ? "" : attribute.getValue();
+1, I agree too.
**********************************************************************
Information in this email is confidential and may be privileged.
It is intended for the addressee only. If you have received it in error,
please notify the sender immediately and delete it from your system.
You should not otherwise copy it, retransmit it or use or disclose its
contents to anyone.
Thank you for your co-operation.
**********************************************************************
From jhunter at servlets.com Wed Feb 13 01:26:05 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] getText() and getAttributeValue()
References: <89D72635F8AFD4118E5B00B0D06822561D6FAC@s-coengl-e02>
Message-ID: <3C6A312D.47E9A6C5@servlets.com>
> For Element, if no textual content exists, getText() returns an empty
> string. However, if getAttributeValue() is called for an attribute that does
> not exist, null is returned. Why the inconsistency?
What is the text of
It's "".
What is the text of
It's "" also because it's semantically identical to .
Now, what is the text of this attrib value?
It's clearly "".
What is the text of this attrib value?
There is none, so it's null.
> Under what circumstances would client code care to differentiate between an
> attribute existing with empty string and the attibute not existing at all?
I'm sure there are many cases.
> getAttributeValue() should return empty string if the attribute does not
> exist because:
> 1) It makes it more consistent with getText()
> 2) One won't have to check for null on the return value.
>
> Right now, my code is littered with:
> String name = Parse.assure(elem.getAttributeValue("name"));
> String id = Parse.assure(elem.getAttributeValue("id"));
> // etc.
>
> ...where Parse.assure(String str) returns empty string if str is null; or
> str unchanged if it is non-null. It sure would be nice to get rid of all
> those checks.
What you'd really want is getAttributeValue(String name, String
fallback). It's even more powerful since "" doesn't have to be the
fallback. We had that before but it was removed since people didn't
like its ability to "mask errors". I personally would rather have it.
-jh-
From Boerries.Ludwig at t-systems.com Wed Feb 13 00:26:53 2002
From: Boerries.Ludwig at t-systems.com (=?utf-8?Q?B=C3=B6rries_Ludwig?=)
Date: Fri Aug 6 17:07:22 2004
Subject: AW: [jdom-interest] Using JDOM to manipulate HTML
In-Reply-To: <6CB3FB42F4C2D4119F870002B3157AA504472553@corp_mail.rdacorp.com>
Message-ID:
Hi Eric,
I do the same thing. The biggest disadvantage of Struts is, that a page cannot be edited in an ordinary HTML-editor. The disadvantage of using XML/JDOM is, that I have to correct the tags, produced from the HTML-editor, to correct XML-syntax and that I couldn't use some html-elements ( instead of ).
What I still miss is a library wich makes the manipulation of a HTML/JDOM-representation more easily. It took me some time to get an Element of a table by ID, get the parent of the ID, dublicate the Element with my model, and delete the original element. To add complete HTML-fragments to JDOM was to implement, too.
I used pure Xerces at the beginning, but JDOM made the manipulation of elements much easier.
Hope we can share our experiences.
Viele Gruesse
Boerries Ludwig
.....................................................
> -----Urspr?ngliche Nachricht-----
> Von: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org]Im Auftrag von Eric Ace
> Gesendet: Dienstag, 12. Februar 2002 22:28
> An: jdom-interest@jdom.org
> Betreff: [jdom-interest] Using JDOM to manipulate HTML
>
>
> I want to use JDOM to manage presentation. Instead of using
> custom tags a la Struts, my thought is to have a presentation
> tier that queries business components and merges data into static
> HTML via JDOM. So, I need to be able to locate specific HTML
> elements by name or ID and modify them. For example:
>
>
> ...
>
>
> I can ultimately get to the table I need to manipulate by getting
> all "table" elements, then looking for one that contains an ID
> attribute. What would be more programmatically clean though would
> be to manipulate the document via JDOM similarly to how I can via
> the DOM in JavaScript.
>
> Am I completely missing the spirit of JDOM? Or, missing some
> fundamentally obvious point?
>
> Thanks
>
> -EAce
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yourad
dr@yourhost.com
From bart at wdi.co.uk Wed Feb 13 02:16:55 2002
From: bart at wdi.co.uk (Bart Read)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] getText() and getAttributeValue()
References: <89D72635F8AFD4118E5B00B0D06822561D6FAC@s-coengl-e02> <3C6A312D.47E9A6C5@servlets.com>
Message-ID: <001201c1b477$91893200$dc00a8c0@JOHNNYBRAVO>
> > getAttributeValue() should return empty string if the attribute does not
> > exist because:
> > 1) It makes it more consistent with getText()
> > 2) One won't have to check for null on the return value.
> >
> > Right now, my code is littered with:
> > String name = Parse.assure(elem.getAttributeValue("name"));
> > String id = Parse.assure(elem.getAttributeValue("id"));
> > // etc.
> >
> > ...where Parse.assure(String str) returns empty string if str is null;
or
> > str unchanged if it is non-null. It sure would be nice to get rid of all
> > those checks.
>
> What you'd really want is getAttributeValue(String name, String
> fallback). It's even more powerful since "" doesn't have to be the
> fallback. We had that before but it was removed since people didn't
> like its ability to "mask errors". I personally would rather have it.
>
Actually I really like this idea. Sure, one side effect of this is that is
could "mask" errors, but really no more so than for example the
getProperty(String key, String defaultValue) method of the
java.util.Properties class. One situation where it WOULD be very useful is
if you have an attribute that should have a default value -- you could
assign it without having to either (i) turn on validation, or (ii) do
something like:
String value = element.getAttributeValue("myAttribute");
value = (value != null ? value : "default");
which is a maybe a wee bit cumbersome. Certainly, I'd be in favour of
re-introducing this method. However, what I definitely DON'T want to do is
spark off a huge debate over an issue that's already been discussed in
considerable depth, and which many people are happy about, so if the
consensus is "no" then I'll happily go with that.
Cheers,
Bart Read
---------- Automatically inserted by WDI Mailserver ----------------
This message has been scanned for virus, trojans, illegal relays and
spam. If you have any comments, problems or questions please do not
hesitate to contact:
Abbotsbury Software Ltd
Tel: +44 1305 871543 Fax: +44 1305 871688
Email: postmaster@wdi.co.uk
Web: http://www.wdi.co.uk/virus.phtml
From jonbaer at digitalanywhere.com Wed Feb 13 03:12:32 2002
From: jonbaer at digitalanywhere.com (Jon Baer)
Date: Fri Aug 6 17:07:22 2004
Subject: AW: [jdom-interest] Using JDOM to manipulate HTML
References:
Message-ID: <3C6A4A20.CA837C77@digitalanywhere.com>
Not sure if it relates but from the TODO:
* Consider an HTMLBuilder that reads not-necessarily-well-formed HTML and
produces a JDOM Document. The approach I'd suggest is to build on top of
JTidy first. That gives a working implementation fast, at the cost of a
157K Tidy.jar in the distribution. After that, perhaps someone would lead
an effort to change the JTidy code to build a JDOM Document directly,
instead of making a DOM Document or XML stream first. That would be a lot
faster, use less memory, and make our dist smaller. See
http://www.sourceforge.net/projects/jtidy for Tidy.
- Jon
B?rries Ludwig wrote:
> Hi Eric,
>
> I do the same thing. The biggest disadvantage of Struts is, that a page cannot be edited in an ordinary HTML-editor. The disadvantage of using XML/JDOM is, that I have to correct the tags, produced from the HTML-editor, to correct XML-syntax and that I couldn't use some html-elements ( instead of ).
>
> What I still miss is a library wich makes the manipulation of a HTML/JDOM-representation more easily. It took me some time to get an Element of a table by ID, get the parent of the ID, dublicate the Element with my model, and delete the original element. To add complete HTML-fragments to JDOM was to implement, too.
>
> I used pure Xerces at the beginning, but JDOM made the manipulation of elements much easier.
>
> Hope we can share our experiences.
>
> Viele Gruesse
>
> Boerries Ludwig
>
> .....................................................
>
> > -----Urspr??ngliche Nachricht-----
> > Von: jdom-interest-admin@jdom.org
> > [mailto:jdom-interest-admin@jdom.org]Im Auftrag von Eric Ace
> > Gesendet: Dienstag, 12. Februar 2002 22:28
> > An: jdom-interest@jdom.org
> > Betreff: [jdom-interest] Using JDOM to manipulate HTML
> >
> >
> > I want to use JDOM to manage presentation. Instead of using
> > custom tags a la Struts, my thought is to have a presentation
> > tier that queries business components and merges data into static
> > HTML via JDOM. So, I need to be able to locate specific HTML
> > elements by name or ID and modify them. For example:
> >
> >
> > ...
> >
> >
> > I can ultimately get to the table I need to manipulate by getting
> > all "table" elements, then looking for one that contains an ID
> > attribute. What would be more programmatically clean though would
> > be to manipulate the document via JDOM similarly to how I can via
> > the DOM in JavaScript.
> >
> > Am I completely missing the spirit of JDOM? Or, missing some
> > fundamentally obvious point?
> >
> > Thanks
> >
> > -EAce
> > _______________________________________________
> > To control your jdom-interest membership:
> > http://lists.denveronline.net/mailman/options/jdom-interest/yourad
> dr@yourhost.com
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From jonbaer at digitalanywhere.com Wed Feb 13 03:15:53 2002
From: jonbaer at digitalanywhere.com (Jon Baer)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] getText() and getAttributeValue()
References: <89D72635F8AFD4118E5B00B0D06822561D6FAC@s-coengl-e02> <3C6A312D.47E9A6C5@servlets.com> <001201c1b477$91893200$dc00a8c0@JOHNNYBRAVO>
Message-ID: <3C6A4AE8.B898D81B@digitalanywhere.com>
Seems like this was also already on TODO:
Consider Mike Jennings' proposal of two new methods on Element:
public String getAttributeValue(String name, String default)
public String getAttributeValue(String name, Namespace ns, String default)
http://lists.denveronline.net/lists/jdom-interest/2000-December/004155.html
I like the default idea.
- Jon
Bart Read wrote:
> > > getAttributeValue() should return empty string if the attribute does not
> > > exist because:
> > > 1) It makes it more consistent with getText()
> > > 2) One won't have to check for null on the return value.
> > >
> > > Right now, my code is littered with:
> > > String name = Parse.assure(elem.getAttributeValue("name"));
> > > String id = Parse.assure(elem.getAttributeValue("id"));
> > > // etc.
> > >
> > > ...where Parse.assure(String str) returns empty string if str is null;
> or
> > > str unchanged if it is non-null. It sure would be nice to get rid of all
> > > those checks.
> >
> > What you'd really want is getAttributeValue(String name, String
> > fallback). It's even more powerful since "" doesn't have to be the
> > fallback. We had that before but it was removed since people didn't
> > like its ability to "mask errors". I personally would rather have it.
> >
>
> Actually I really like this idea. Sure, one side effect of this is that is
> could "mask" errors, but really no more so than for example the
> getProperty(String key, String defaultValue) method of the
> java.util.Properties class. One situation where it WOULD be very useful is
> if you have an attribute that should have a default value -- you could
> assign it without having to either (i) turn on validation, or (ii) do
> something like:
>
> String value = element.getAttributeValue("myAttribute");
> value = (value != null ? value : "default");
>
> which is a maybe a wee bit cumbersome. Certainly, I'd be in favour of
> re-introducing this method. However, what I definitely DON'T want to do is
> spark off a huge debate over an issue that's already been discussed in
> considerable depth, and which many people are happy about, so if the
> consensus is "no" then I'll happily go with that.
>
> Cheers,
> Bart Read
>
> ---------- Automatically inserted by WDI Mailserver ----------------
> This message has been scanned for virus, trojans, illegal relays and
> spam. If you have any comments, problems or questions please do not
> hesitate to contact:
> Abbotsbury Software Ltd
> Tel: +44 1305 871543 Fax: +44 1305 871688
> Email: postmaster@wdi.co.uk
> Web: http://www.wdi.co.uk/virus.phtml
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From philip.nelson at omniresources.com Wed Feb 13 06:11:23 2002
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] getText() and getAttributeValue()
Message-ID:
This is exactly right. At one time there was a project that Alex had
started to move the default value issue to a helper class. Even that got
too much as all the variations on the right helpers started to add up.
I think the best answer is, it can be done with a helper class, it can be
done in a subclass and it can be done very easily in the calling code, so it
doesn't need to be addressed by JDOM right now.
-----Original Message-----
From: Jason Hunter
To: Trimmer, Todd
Cc: 'jdom-interest@jdom.org'
Sent: 2/13/02 3:26 AM
Subject: Re: [jdom-interest] getText() and getAttributeValue()
> For Element, if no textual content exists, getText() returns an empty
> string. However, if getAttributeValue() is called for an attribute
that does
> not exist, null is returned. Why the inconsistency?
What is the text of
It's "".
What is the text of
It's "" also because it's semantically identical to .
Now, what is the text of this attrib value?
It's clearly "".
What is the text of this attrib value?
There is none, so it's null.
> Under what circumstances would client code care to differentiate
between an
> attribute existing with empty string and the attibute not existing at
all?
I'm sure there are many cases.
> getAttributeValue() should return empty string if the attribute does
not
> exist because:
> 1) It makes it more consistent with getText()
> 2) One won't have to check for null on the return value.
>
> Right now, my code is littered with:
> String name = Parse.assure(elem.getAttributeValue("name"));
> String id = Parse.assure(elem.getAttributeValue("id"));
> // etc.
>
> ...where Parse.assure(String str) returns empty string if str is null;
or
> str unchanged if it is non-null. It sure would be nice to get rid of
all
> those checks.
What you'd really want is getAttributeValue(String name, String
fallback). It's even more powerful since "" doesn't have to be the
fallback. We had that before but it was removed since people didn't
like its ability to "mask errors". I personally would rather have it.
-jh-
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@you
rhost.com
From jeff.singer at vine.co.za Wed Feb 13 06:31:58 2002
From: jeff.singer at vine.co.za (Jeff Singer)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] Underlying JDOM Parser
Message-ID:
I am testing JDOM b7 with xerces2. I don't know if there are any issues with
using xerces2 and b7 ?
But mainly, how do I tell which underlying parser JDOM is using? I am using
a SaxBuilder.
Thanks in advance
Jeff Singer
From Jacob.Robertson at argushealth.com Wed Feb 13 07:27:25 2002
From: Jacob.Robertson at argushealth.com (Robertson, Jacob)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] RE: Using JDOM to manipulate HTML
Message-ID:
In order to get a jdom document of an HTML file, I created a class for
my company that uses the org.w3c.tidy package. I've included a dumbed
down cut-and-paste version of the class (can't really post proprietary
code from my company), but this code is the basic idea. What I've
excluded is handling of some of the limitations of Tidy that doesn't
correctly handle things like some comments, and
Anyway -- here's the code...
import org.jdom.*;
import org.jdom.input.*;
import org.jdom.output.*;
import org.w3c.dom.*;
import org.w3c.tidy.*;
// etc ...
public class DocBuilder {
public static org.jdom.Document buildDocument(File file) throws
IOException, JDOMException {
org.w3c.dom.Document domHtmlDoc = getHTMLDocument(file);
org.jdom.Document jdomDoc = getJDOMDoc(domHtmlDoc);
return jdomDoc;
}
private static org.w3c.dom.Document getHTMLDocument(File file) throws
IOException, JDOMException {
FileInputStream fin = new FileInputStream(file);
Tidy tidy = new Tidy();
tidy.setMakeClean(false);
//tidy.setQuiet(true);
tidy.setShowWarnings(true); //tidy.setShowWarnings(false);
tidy.setTidyMark(false);
tidy.setNumEntities(true);
tidy.setQuoteAmpersand(true);
tidy.setQuoteMarks(true);
tidy.setQuoteNbsp(false);
tidy.setHideEndTags(false);
tidy.setDropEmptyParas(false);
org.w3c.dom.Document doc = tidy.parseDOM(fin, null);
fin.close();
return doc;
}
private static org.jdom.Document getJDOMDoc(org.w3c.dom.Document doc) {
DOMBuilder db = new DOMBuilder();
org.jdom.Document jdomDoc = db.build(doc);
return jdomDoc;
}
}
From fooanny at yahoo.com Wed Feb 13 03:58:15 2002
From: fooanny at yahoo.com (Jared Checkley)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] jdom-contrib
Message-ID: <000201c1b485$b8e17d40$7a00a8c0@Jazzy>
Hi,
Is there any chance I can download the actual binary .jar file for
jdom-contrib? If not, would you be so kind as to send it to me (I have
a fast connection), as I am keen to test out a few of the features? I
have tried to build it myself but it's proving to be quite troublesome -
the build process complains about the getAttributeType() method not
existing.
Your help appreciated.
Best regards,
Jared
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020213/04de65b6/attachment.htm
From Q.M.Qasim at Bradford.ac.uk Wed Feb 13 06:55:23 2002
From: Q.M.Qasim at Bradford.ac.uk (Q.M.Qasim@Bradford.ac.uk)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] Searching an XML file
Message-ID: <1013612123.3c6a7e5b4bfa9@webmail.brad.ac.uk>
Hi
I want to search an XML file with a search query. Following is a sample of my
xml file.
qas
qa
qa
qas
I am trying to search for every element that may contain content
such as 'qas'. I wrote the following method, but there are some potential
problems with it. (1) It only searches the first element of and never
goes to the second element. (2) It only searches the first
element of element and never goes to the second element.
If I try to search for 'qas', then I get the following error:
name is "fg" , directory is "directory", size is" 8"
[Ljava.lang.String;@2b6651
Exception in thread "main" java.lang.NullPointerException
at Jdom_files.searchFiles(Jdom_files.java:154)
at Jdom_files.main(Jdom_files.java:193)
I will be very grateful if someone can tell what i may be doing wrong and if
possible provide me with code showing how I can search through the element. My
method is as follows:
public String searchFiles(String search)
{
String[] none= {"No Files Found"};
// defaultTable = table;
Element root = document.getRootElement();
List files = root.getChildren("file");
Iterator i=files.iterator();
while (i.hasNext())
{
Element file= (Element)i.next();
int count=0;
//// set up loop to read description//
String description = file.getChild("description").getText();
//if (search.equals(description))
int q = search.compareTo(description);
if (q==0)
{
String name=file.getAttributeValue("name");
String directory =file.getAttributeValue("directory");
String size = file.getAttributeValue("size");
String[] data= {name,directory,size};
System.out.println( "name is " +name +" directory is "+ directory +"
size is "+ size);
//defaultTable.addRow(data);
count++; // increment number of description tag found
}//// end of loop//
else if (count==0)
{ // if no description tag found
//String[] none= {"No Files Found"};
//defaultTable.addRow(none);
System.out.println(none);
}
}
return null;
}
Regards
Qasim
-------------------------------------------------
This mail sent through IMP: webmail.brad.ac.uk
From Boerries.Ludwig at t-systems.com Wed Feb 13 08:46:03 2002
From: Boerries.Ludwig at t-systems.com (=?US-ASCII?Q?Borries_Ludwig?=)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest]  &
In-Reply-To: <3C6A312D.47E9A6C5@servlets.com>
Message-ID:
Hi,
am using JDOM to create HTML-pages. I want to fill up the entry of a
list-box in html with blanks, so that all lines are outlined to the right.
I cannot use " " because the browser ignores that (or is there a way ?). So
I tried and , but JDOM (anElement.setText()) replaces & with an
&
Help is very welcome.
Boerries
From jhunter at servlets.com Wed Feb 13 10:18:02 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] Underlying JDOM Parser
References:
Message-ID: <3C6AADDA.1A973024@servlets.com>
> I am testing JDOM b7 with xerces2. I don't know if there are any issues with
> using xerces2 and b7 ?
I tested that last week and found the SAX features nicely reliable, but
there were a few issues with DOM input and output. In the current TODO
you'll see the bugs I filed.
> But mainly, how do I tell which underlying parser JDOM is using? I am using
> a SaxBuilder.
Good question. You can tell JDOM which parser to use. If you don't, it
tries to use JAXP, and if JAXP fails it tries Xerces. But as far as
which version was found, since it depends on what's in your classpath,
you could be in the dark. I don't know if parsers expose that
information. On a quick look I don't see it.
-jh-
From jhunter at servlets.com Wed Feb 13 11:08:05 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest]  &
References:
Message-ID: <3C6AB995.6743600A@servlets.com>
Since setText() takes as a literal whatever you pass, write the
character as its unicode value. That's \uxxxx where xxxx is the hex for
160. I think that'll probably work. If not, you'll have to
additionally modify the outputter a little to write in response
to that character. Look at the code that escapes character entities.
We're working on a general-purpose solution to that.
-jh-
Borries Ludwig wrote:
>
> Hi,
>
> am using JDOM to create HTML-pages. I want to fill up the entry of a
> list-box in html with blanks, so that all lines are outlined to the right.
>
> I cannot use " " because the browser ignores that (or is there a way ?). So
> I tried and , but JDOM (anElement.setText()) replaces & with an
> &
>
> Help is very welcome.
>
> Boerries
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From james.todd at Sun.COM Wed Feb 13 11:53:48 2002
From: james.todd at Sun.COM (james todd)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] getText() and getAttributeValue()
References: <89D72635F8AFD4118E5B00B0D06822561D6FAC@s-coengl-e02> <3C6A312D.47E9A6C5@servlets.com>
Message-ID: <3C6AC44C.CF9DF6AB@Sun.COM>
> What you'd really want is getAttributeValue(String name, String
> fallback). It's even more powerful since "" doesn't have to be the
> fallback. We had that before but it was removed since people didn't
> like its ability to "mask errors". I personally would rather have it.
+1
- james
Jason Hunter wrote:
>
> > For Element, if no textual content exists, getText() returns an empty
> > string. However, if getAttributeValue() is called for an attribute that does
> > not exist, null is returned. Why the inconsistency?
>
> What is the text of
>
>
>
> It's "".
>
> What is the text of
>
>
>
> It's "" also because it's semantically identical to .
>
> Now, what is the text of this attrib value?
>
>
>
> It's clearly "".
>
> What is the text of this attrib value?
>
>
>
> There is none, so it's null.
>
> > Under what circumstances would client code care to differentiate between an
> > attribute existing with empty string and the attibute not existing at all?
>
> I'm sure there are many cases.
>
> > getAttributeValue() should return empty string if the attribute does not
> > exist because:
> > 1) It makes it more consistent with getText()
> > 2) One won't have to check for null on the return value.
> >
> > Right now, my code is littered with:
> > String name = Parse.assure(elem.getAttributeValue("name"));
> > String id = Parse.assure(elem.getAttributeValue("id"));
> > // etc.
> >
> > ...where Parse.assure(String str) returns empty string if str is null; or
> > str unchanged if it is non-null. It sure would be nice to get rid of all
> > those checks.
>
> What you'd really want is getAttributeValue(String name, String
> fallback). It's even more powerful since "" doesn't have to be the
> fallback. We had that before but it was removed since people didn't
> like its ability to "mask errors". I personally would rather have it.
>
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From rpcee at operamail.com Wed Feb 13 03:15:03 2002
From: rpcee at operamail.com (rpcee)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] getText() and getAttributeValue()
Message-ID: <3C85C6AB@operamail.com>
I have used == null on getAttributeValue() because some schemas allow an
element to be identified or referenced (xsd:element name=... and xsd:element
ref=...);
i could change to check for "" because "" would not be valid but somehow ==
null is more definite (it's only a toy program; I'm not sure if it relates to
the real world).
on a minor related note, should Element's getAttribute() methods document what
happens if the attribute doesn't exist?
Rich
From ACE at rdacorp.com Wed Feb 13 13:05:02 2002
From: ACE at rdacorp.com (Eric Ace)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] JDOM parsing
Message-ID: <6CB3FB42F4C2D4119F870002B3157AA504472590@corp_mail.rdacorp.com>
I have an XHTML doc. I load it into a JDOM Document object and then just display it using the following code:
SAXBuilder builder = new SAXBuilder();
Document doc = builder.build(new File(test-xhtml.html));
fmt.output(doc, System.out);
The output shows the TD tags modified to specify rowspan/colspan. Is this supposed to be? Can this behavior be overridden? Thanks.
INPUT FILE (test-xhtml.html) :
=======================
Virtual Library
| HD1 | HD2 | HD3 | HD4 |
| R3C1 | R3C2 | R3C3 | R3C4 |
OUTPUT:
=======================
Virtual Library
| HD1 | HD2 | HD3 | HD4 |
| R1C1 | R1C2 | R1C3 | R1C4 |
From jhunter at servlets.com Wed Feb 13 17:26:23 2002
From: jhunter at servlets.com (Jason Hunter)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] Typing of the parent
Message-ID: <3C6B123F.118739EC@servlets.com>
Recently we changed various JDOM classes like Comment and PI to instead
of having:
protected Document document;
protected Element parent;
They just have:
protected Object parent;
And the parent reference serves double-duty for each. We've had Element
this way for a while, and we just brought the other classes in line. It
saves around 4 bytes per instance. The slightly annoying thing is that
this does affect some people doing fancy things in subclasses. So
Question One is, how many of you really are affected?
Question Two is, for classes like EntityRef and Text which can only have
Element parents and can't be attached at the Document level, should we
change their:
protected Element parent;
to
protected Object parent;
for consistency? Brad points out that some subclassers may prefer to
have a more abstracted notion of what is a parent. The counter argument
is that Attribute should keep Element as its parent since to do
otherwise would feel strange, so why should Text be much different?
Opinions welcome.
-jh-
From ace at rdacorp.com Wed Feb 13 17:57:31 2002
From: ace at rdacorp.com (Eric Ace)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] JDOM parsing of XHTML document
Message-ID:
All,
I have an XHTML file. I load it into a JDOM Document object and then just display it using the following code:
SAXBuilder builder = new SAXBuilder();
Document doc = builder.build(new File("test-xhtml.html"));
fmt.output(doc, System.out);
The output has the tags modified to specify rowspan & colspan attributes - these were not present in the input. Is this supposed to be? Can this behavior be overridden? Thanks.
INPUT FILE (test-xhtml.html) :
==============================
Virtual Library
| HD1 | HD2 | HD3 | HD4 |
| R3C1 | R3C2 | R3C3 | R3C4 |
OUTPUT:
=======================
Virtual Library
| HD1 | HD2 | HD3 | HD4 |
| R1C1 | R1C2 | R1C3 | R1C4 |
From laurent.bihanic at atosorigin.com Thu Feb 14 00:16:15 2002
From: laurent.bihanic at atosorigin.com (Laurent Bihanic)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] jdom-contrib
References: <000201c1b485$b8e17d40$7a00a8c0@Jazzy>
Message-ID: <3C6B724F.3020804@atosorigin.com>
Hi,
The getAttributeType was introduced lately in JDOM and was not available in
JDOM Beta 7.
Thus, to compile and use the org.jdom.contrib.ids package, you need to get the
latest JDOM core from CVS.
Laurent
Jared Checkley wrote:
> *Hi,*
>
> **
>
> *Is there any chance I can download the actual binary ..jar file for
> jdom-contrib? If not, would you be so kind as to send it to me (I have
> a fast connection), as I am keen to test out a few of the features? I
> have tried to build it myself but it's proving to be quite troublesome -
> the build process complains about the getAttributeType() method not
> existing.*
>
> **
>
> *Your help appreciated.*
>
> **
>
> *Best regards,*
>
> **
>
> *Jared*
>
--
wWw Zzzzz
(- -)
-------------ooO-(_)-Ooo-----------------------------------------------
Laurent Bihanic | Tel: +33 (0)1 55.91.21.93 (Direct line)
Atos Origin | +33 (0)1 55.91.20.00
Int?gration - e-Business | Fax: +33 (0)1 55.91.22.31
Les Miroirs - Bat. C |
18, avenue d'Alsace |
F-92926 La Defense Cedex | e-Mail: laurent.bihanic@atosorigin.com
-----------------------------------------------------------------------
"Microsoft isn't the answer. Microsoft is the question and the answer
is no."
DISCLAIMER:
The opinions expressed are entirely my own and may not necessarily be
those of my employer. Also, I am not now nor have I ever been a
lawyer. My opinions are provided as-is with absolutely no warrantee of
merchantability or fitness for any particular use. Besides, you can't
prove I typed this. No body saw me type this. Who says I typed this?
From schnemac at zhwin.ch Thu Feb 14 04:37:18 2002
From: schnemac at zhwin.ch (Marcus Schneller)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] Socket: Logical end of fle problem
Message-ID: <3C6BAF7E.9020502@zhwin.ch>
Hello
I try to pass a BufferedReader from a Socket to the build(Reader reader)
Method. To avoid that the parser closes the Stream i did following:
import java.io.BufferedReader;
import java.io.InputStreamReader;
public class MyBufferedReader extends BufferedReader{
public MyBufferedReader(InputStreamReader i) {
super(i);
}
public void close() {
}
}
To find the logical end of the file a did following;
import org.xml.sax.helpers.XMLFilterImpl;
import org.xml.sax.*;
public class SocketFilter extends XMLFilterImpl {
/** Variablen, die das Ende des Documents erkennen sollen */
private int level;
private String firstTag;
public void startElement(String uri, String localName,
String qName, Attributes atts) throws SAXException {
if (level++ == 0)
firstTag = localName;
super.startElement(uri, localName, qName, atts);
System.out.println("start"+ localName);
}
public void endElement(String uri, String localName,
String qName) throws SAXException {
if ((--level == 0) || firstTag.equals(localName))
throw new SAXException("Finished");
super.endElement(uri, localName, qName);
System.out.println("stop"+ localName);
}
}
The class I create the SaxBuilder looks like this:
import java.io.InputStream;
import java.io.*;
import org.jdom.Document;
import org.jdom.Element;
import org.jdom.JDOMException;
import org.jdom.input.SAXBuilder;
import org.jdom.Namespace;
public class InputDocumentHandler{
private Document doc;
private SAXBuilder builder;
private Namespace ns;
public InputDocumentHandler() {
builder = new SAXBuilder("org.apache.xerces.parsers.SAXParser");
builder.setXMLFilter(new SocketFilter());
}
public void createDocument(Reader reader) throws JDOMException{
try{
doc = builder.build(reader);
System.out.println(doc.toString());
ns = doc.getRootElement().getNamespace();
}
catch(JDOMException j){
throw new JDOMException("Fehler beim Erzeugen des Documents:
"+ j.getMessage());
}
}
When running the System.out.println(doc.toString()); Statement says:
[Document: No DOCTYPE declaration, No root element]
and the ns = doc.getRootElement().getNamespace(); Statement throws a
NullPointerEcxepiotn.
What do I do wrong?
I read the FAQ on http://xml.apache.org/xerces-j/faq-write.html#faq-11
about the Socket problem, but didn't manage to get it to work with
SAXBuilder.
Thanks for help
marcus
From Mark.Mauerwerk at gopa.de Thu Feb 14 06:39:22 2002
From: Mark.Mauerwerk at gopa.de (Mauerwerk, Mark)
Date: Fri Aug 6 17:07:22 2004
Subject: [jdom-interest] generate XML conformly to dtd
Message-ID:
Hi,
I'm developing a sort of XML generator which shall build up a XML
document from the scratch but conformly to a DTD. While I found the
first task quite simple to build XML documents from the scratch with
JDOM, it seems more difficult to do this in a more generic way conformly
to a DTD (e.g retrieving a DOM object from a DTD, put the data values
from an arbitrary data source in and build the XML document).
I think a DTD parser could be heplful to support that work but it seems
that the most common packages supporting XML don't support that way
(extracting a document structure from a DTD).
My method of resolution is to use schema instead: e.g. parse the schema
(i.e. get the structure and constraints), vailidate the data from any
data source (represented by Java data) and build the document containing
the validated Java data with the structure derived from the schema.
But, I think a generic XML generator is a very common approach in
practice and may be I have overseen something already existing. So whats
your experience with similar approaches.
Thanks in advance
Mark
From todd.trimmer at trizetto.com Thu Feb 14 09:32:34 2002
From: todd.trimmer at trizetto.com (Trimmer, Todd)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] getText() and getAttributeValue()
Message-ID: <89D72635F8AFD4118E5B00B0D06822561D6FAF@s-coengl-e02>
Let me phrase it like this:
Why would any method of any class in any API that returns String want to
return null instead of empty string?
An empty string is analagous to the concept of the empty set. For all
theoretical purposes, empty string will suffice. null shows that not only
does a certain value not exist, but no memory was allocated for it on the
chance that it did exist. If we use 2's complement to remove the ambiguity
of positive and negative zero, why would we want the clutter of both empty
string and null to represent empty set?
The problem with a method returning a null reference when String was
expected is that the returned value might not be examined right away. It
might be passed around to other systems. This can easily lend to the arisal
of the dangerous Null Flag Bug Pattern.
And that's essentially what getAttributeValue() is doing now -- it's
creating a null flag to report an error.
This is the mindset it was written under: the method will return the value
of the specified attribute. If the attribute does not exist, the programmer
made an error by even making the request, therefore return null to notify
him of this.
My proposal is not to "mask errors" (who started this superstition?) but to
gracefully recoup from errors. That's why the empty string is returned. I
know that even though the programmer asked for the value of something that
does not exist, that programmer can still gracefully proceed with an empty
string in his hand. If one were REALLY concerned with making sure the
programmer was aware of his error, getAttributeValue() would have been
written to throw a java.util.NoSuchElementException or such a long time ago.
I daresay that any method of and kind should only return null if that
represents a legitimate working state of the system the method's class is
encapsulating -- never to represent an error, and never when String is the
return type.
Todd Trimmer
From philip.nelson at omniresources.com Thu Feb 14 09:45:06 2002
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Typing of the parent
Message-ID:
The Decorator code I did for Brett's book will be affected by this as would
any "walk the tree" type of code. Wouldn't jaxen be affected as well?
I think that Text and EntityRef should do the same thing as Element. Sure
it makes sense for an attribute to know that it's parent is an element.
But, that's an easy check. If each part of JDOM does this in a consistent
way, it's pretty easy for a subclasser to strap on a node implementation.
It's not that hard anyway, particularly now that String is replaced by Text
but consistency aids the intangible aspect of any api that makes it work
like you think it should.
-----Original Message-----
From: Jason Hunter
To: JDOM Interest
Sent: 2/13/02 7:26 PM
Subject: [jdom-interest] Typing of the parent
Recently we changed various JDOM classes like Comment and PI to instead
of having:
protected Document document;
protected Element parent;
They just have:
protected Object parent;
And the parent reference serves double-duty for each. We've had Element
this way for a while, and we just brought the other classes in line. It
saves around 4 bytes per instance. The slightly annoying thing is that
this does affect some people doing fancy things in subclasses. So
Question One is, how many of you really are affected?
Question Two is, for classes like EntityRef and Text which can only have
Element parents and can't be attached at the Document level, should we
change their:
protected Element parent;
to
protected Object parent;
for consistency? Brad points out that some subclassers may prefer to
have a more abstracted notion of what is a parent. The counter argument
is that Attribute should keep Element as its parent since to do
otherwise would feel strange, so why should Text be much different?
Opinions welcome.
-jh-
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@you
rhost.com
From philip.nelson at omniresources.com Thu Feb 14 09:49:29 2002
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] getText() and getAttributeValue()
Message-ID:
>I daresay that any method of and kind should only return null if that
>represents a legitimate working state of the system the method's class
>is encapsulating -- never to represent an error, and never when String is
>the return type.
And those of us that think null is the appropriate response feel that
returning "" on a non exsistent attribute is masking knowledge of what the
xml actually contains. You can make excellent application specific
arguments about this issue, but not at the level JDOM sits.
From arosen at silverstream.com Thu Feb 14 10:29:37 2002
From: arosen at silverstream.com (Alex Rosen)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] getText() and getAttributeValue()
In-Reply-To: <89D72635F8AFD4118E5B00B0D06822561D6FAF@s-coengl-e02>
Message-ID: <005601c1b585$8fdf79f0$6a65810a@silverstream.com>
> And that's essentially what getAttributeValue() is doing now -- it's
> creating a null flag to report an error.
Why do you assume that the attribute not being present is an error? It may
be perfectly valid.
According to the XML spec, there is no difference between
and , but there is a difference between
and . That's why JDOM must distinguish between
these two values in getAttributeValue().
> I daresay that any method of and kind should only return null if that
> represents a legitimate working state of the system the method's class is
> encapsulating -- never to represent an error, and never when
> String is the return type.
There can be situations where both an empty string and an absent string are
both legitimate states, so neither one is an error.
Alex
From bob at werken.com Thu Feb 14 10:31:11 2002
From: bob at werken.com (bob mcwhirter)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Typing of the parent
In-Reply-To:
Message-ID:
> The Decorator code I did for Brett's book will be affected by this as would
> any "walk the tree" type of code. Wouldn't jaxen be affected as well?
Right off-hand, I don't think so. Jaxen mostly deals in terms of
java.lang.Object anyhow, defering to an OM-specific Navigator to
determine what the heck that object truly is (using instanceof
calls, typically). Will certainly need to run the tests against
the new code, but I imagine nothing will break.
From servlets at mindspring.com Thu Feb 14 10:29:53 2002
From: servlets at mindspring.com (Jason Hunter)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] getText() and getAttributeValue()
References: <89D72635F8AFD4118E5B00B0D06822561D6FAF@s-coengl-e02>
Message-ID: <3C6C0221.36238A7A@mindspring.com>
> Why would any method of any class in any API that returns String want to
> return null instead of empty string?
I think Phil said it best. At the relatively low-level of JDOM, more
information is better.
As a second argument, we need
Attribute Element.getAttribute(String)
to return null if the attribute doesn't exist. We're not going to
return a NO_ATTRIBUTE constant or anything fancy. So for consistency,
we should have getAttributeValue(String) return null also. The "value"
method is a convenience on top of the former.
> If one were REALLY concerned with making sure the
> programmer was aware of his error, getAttributeValue() would have been
> written to throw a java.util.NoSuchElementException or such a long time ago.
How ironic! It was! We changed to null after a vote.
-jh-
From jonbaer at digitalanywhere.com Thu Feb 14 13:34:26 2002
From: jonbaer at digitalanywhere.com (Jon Baer)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] getText() and getAttributeValue()
References: <89D72635F8AFD4118E5B00B0D06822561D6FAF@s-coengl-e02> <3C6C0221.36238A7A@mindspring.com>
Message-ID: <3C6C2D62.2872C1C6@digitalanywhere.com>
This might sound like a dumb question, but what would occur with XML that doesn't
validate it's DTD in which case default attribute values are omitted. In the case of
pulling say a where attribute bar="1" by default according to the DTD/XSD
(like the case of the XHTML example from before), in which case
getAttributeValue("bar") would yield null vs. "1".
- Jon
Jason Hunter wrote:
> > Why would any method of any class in any API that returns String want to
> > return null instead of empty string?
>
> I think Phil said it best. At the relatively low-level of JDOM, more
> information is better.
>
> As a second argument, we need
>
> Attribute Element.getAttribute(String)
>
> to return null if the attribute doesn't exist. We're not going to
> return a NO_ATTRIBUTE constant or anything fancy. So for consistency,
> we should have getAttributeValue(String) return null also. The "value"
> method is a convenience on top of the former.
>
> > If one were REALLY concerned with making sure the
> > programmer was aware of his error, getAttributeValue() would have been
> > written to throw a java.util.NoSuchElementException or such a long time ago.
>
> How ironic! It was! We changed to null after a vote.
>
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From todd.trimmer at trizetto.com Thu Feb 14 14:53:46 2002
From: todd.trimmer at trizetto.com (Trimmer, Todd)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] getText() and getAttributeValue()
Message-ID: <89D72635F8AFD4118E5B00B0D06822561D6FB0@s-coengl-e02>
[Alex Rosen]
> According to the XML spec, there is no difference between
> and , but there is a difference between
> and . That's why JDOM must
> distinguish between
> these two values in getAttributeValue().
But when calling getAttributeValue() you are choosing to ignore this
difference. You just want the text, if present, and move on.
This is the 80% use case. The 20% use case that DOES CARE
differs from shouldn't be granted the convenience of
getAttributeValue(). They should be forced to use getAttribute() to check
for that difference.
If I want to safety check...
element.getAttribute("foo").getValue();
I would write:
Attribute attr = element.getAttribute("foo");
String value = "";
if (attr != null)
value = attr.getValue();
But if I want to safety check...
element.getAttributeValue("foo");
I would write:
String value = element.getAttributeValue("foo");
if (value == null)
value = "";
Gee. Not a lot of savings here beyond the four characters I save in writing
getAttributeValue("foo") vs. getAttribute("foo").getValue(). Suddenly, this
*convenience* method doesn't seem very convenient, does it? It doesn't save
me any work at all.
[Philip Nelson]
> And those of us that think null is the appropriate response feel that
> returning "" on a non exsistent attribute is masking knowledge of what the
> xml actually contains. You can make excellent application specific
> arguments about this issue, but not at the level JDOM sits.
Again, I *WANT* to be shielded from the difference betweeen
and when calling getAttributeValue(). This is what W3C DOM's
getAttribute() does. And since JDOM is using the 80/20 guideline,
application use IS appropriate when making design considerations at this
level.
getAttributeValue() should not double its functionality by both getting an
attribute value AND detecting the existence/non-existence of an attribute.
That's why it shouldn't return null when empty string and empty string alone
completely satisfies the first mentioned function.
[Jason Hunter]
> I think Phil said it best. At the relatively low-level of JDOM, more
> information is better.
Sure thing. The 20% use case that wants the extra information can use
getAttribute().
[Jason Hunter]
> As a second argument, we need
> Attribute Element.getAttribute(String)
> to return null if the attribute doesn't exist. We're not going to
> return a NO_ATTRIBUTE constant or anything fancy. So for consistency,
> we should have getAttributeValue(String) return null also. The "value"
> method is a convenience on top of the former.
If getAttributeValue() merely wraps around getAttribute(), with both being
able to return null, then getAttributeValue() provides NO CONVENIENCE AT ALL
(or relatively none), as you can see in my examples above.
getContent() or getChildren() always return a list. Even if there is no
content or no children we still get an empty list. Why not null? Because the
List interface already has an analogue of the empty set, the empty list, and
can return an object represting it. The String class does too -- the empty
string. No, Attribute or Element do not have these constructions, nor do I
propose we create them. This is why I'm not arguing against returning null
for getAttribute() or getChild() (I would prefer exceptions, but that has
already been voted on, so I won't push it). I am arguing that since List
already has an "empty" instantiation, and JDOM uses it, then why doesn't
JDOM use the empty instantiation of String, the empty string, in methods
that return String?
To sum up:
1) getAttributeValue() returning empty string falls on the 80% side
2) The 20% side should use getAttribute() to get information on such a
nuance
3) Having getAttributeValue() return null forces it to such a trivial
advancement beyond getAttribute("foo").getValue(), that it is reduced to
fluff.
Todd Trimmer
p.s. -- I like the element.getAttributeValue(name, defaultValue) idea, too.
From hip at a.cs.okstate.edu Thu Feb 14 16:21:28 2002
From: hip at a.cs.okstate.edu (Bradley S. Huffman)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] getText() and getAttributeValue()
In-Reply-To: Your message of "Thu, 14 Feb 2002 15:53:46 MST."
<89D72635F8AFD4118E5B00B0D06822561D6FB0@s-coengl-e02>
Message-ID: <200202150022.RAA24306@dorothy.denveronline.net>
"Trimmer, Todd" writes:
> If I want to safety check...
>
> element.getAttribute("foo").getValue();
>
> I would write:
>
> Attribute attr = element.getAttribute("foo");
> String value = "";
>
> if (attr != null)
> value = attr.getValue();
>
> But if I want to safety check...
>
> element.getAttributeValue("foo");
>
> I would write:
>
> String value = element.getAttributeValue("foo");
>
> if (value == null)
> value = "";
>
> Gee. Not a lot of savings here beyond the four characters I save in writing
> getAttributeValue("foo") vs. getAttribute("foo").getValue(). Suddenly, this
> *convenience* method doesn't seem very convenient, does it? It doesn't save
> me any work at all.
But it does clearly show that getAttributeValue can return null and gives
a clear indication how your application handles it. In cases like this, I
think most C/Java programmers will associate a null as a return value with
not finding what they where looking for.
> 3) Having getAttributeValue() return null forces it to such a trivial
> advancement beyond getAttribute("foo").getValue(), that it is reduced to
> fluff.
So we should get rid of getAttributeValue?
> p.s. -- I like the element.getAttributeValue(name, defaultValue) idea, too.
I don't because it's behavior isn't intuitive without looking at the
docs. Example getAttributeValue("drawf","Sleepy"), does this method
look for a attribute "drawf", then a attribute "Sleepy"?. To me
String value = element.getAttributeValue("drawf");
if (value == null)
value = "Sleepy";
is preferable because it reads well and clearly shows what the code does.
Brad
From elharo at metalab.unc.edu Fri Feb 15 02:47:41 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Underlying JDOM Parser
In-Reply-To: <3C6AADDA.1A973024@servlets.com>
References:
<3C6AADDA.1A973024@servlets.com>
Message-ID:
>Good question. You can tell JDOM which parser to use. If you don't, it
>tries to use JAXP, and if JAXP fails it tries Xerces. But as far as
>which version was found, since it depends on what's in your classpath,
>you could be in the dark. I don't know if parsers expose that
>information. On a quick look I don't see it.
>
I think it's been suggested as a standard SAX property for future
releases of SAX. But in the meantime asking for the name of the
XMLReader implementation class with getClass().getName() would
probably be enough. For DOM you could look at the package name of the
DOM Document implementation class.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From JBeech at dmu.ac.uk Fri Feb 15 03:11:25 2002
From: JBeech at dmu.ac.uk (Steve Beech)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] depracation - is all you need...
Message-ID: <6D2CACF507A7D31187AF00508B5E194B05462F5A@atnas.dmu.ac.uk>
Dear All,
I'm new to JDOM and have been using a Y2000 book to learn.
However, when I come to test my code I keep getting:
Note: C:\jakarta-tomcat-3.2.3\webapps\angelUM\WEBINF\Classes\JDOMTest.java
uses or overrides a deprecated API.
Note: Recompile with -deprecation for details.
Finished JDOMTest.
This only occurs when I use the method:
root.addAttribute("attName","attValue");
but looking in the archives I can find no mention of this being depracated.
Can anybody tell me where I'm going wrong.
Thanks in advance,
Steve
----------------------------------------------------------------------------
-------------------------
Steve Beech Tel: 0116
207 8162
Software Developer e-mail:
jbeech@dmu.ac.uk
Room 0.36 Portland Building e-mail: steve@monkey-media.co.uk
De Montfort University
The Gateway, Leicester LE1 9BH
----------------------------------------------------------------------------
------------------------
From noamt at yahoo.com Fri Feb 15 06:18:36 2002
From: noamt at yahoo.com (Noam Tamim)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] depracation - is all you need...
In-Reply-To: <6D2CACF507A7D31187AF00508B5E194B05462F5A@atnas.dmu.ac.uk>
Message-ID: <20020215141836.51645.qmail@web13908.mail.yahoo.com>
Steve Beech wrote:
root.addAttribute("attName","attValue");
but looking in the archives I can find no mention of this being depracated.
Can anybody tell me where I'm going wrong.
Element.addAttribute(string,string) has been deprecated a while ago. Its replacement
is Element.setAttribute(string,string), which is a convenience-method for
Element.setAttribute(Attribute).
_______
Noam.
---------------------------------
Do You Yahoo!?
Got something to say? Say it better with Yahoo! Video Mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020215/eeb22601/attachment.htm
From arosen at silverstream.com Fri Feb 15 10:08:09 2002
From: arosen at silverstream.com (Alex Rosen)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] JDOM parsing
In-Reply-To: <6CB3FB42F4C2D4119F870002B3157AA504472590@corp_mail.rdacorp.com>
Message-ID: <000101c1b64b$ba075650$d56e810a@silverstream.com>
IIRC, by the time SAXBuilder gets the data from the parser, any default
values for attributes have already been filled in. So there's no way for us
to know if the value was in the original XML file or not. But hasn't there
been some work on attribute types that would let us figure this out? I
forget.
Also, if can know that you're using the Xerces parser, check out
http://xml.apache.org/xerces-j/features.html - the features
http://apache.org/xml/features/nonvalidating/load-dtd-grammar and
http://apache.org/xml/features/nonvalidating/load-external-dtd look
promising.
Alex
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org]On Behalf Of Eric Ace
> Sent: Wednesday, February 13, 2002 4:05 PM
> To: jdom-interest@jdom.org
> Subject: [jdom-interest] JDOM parsing
>
>
> I have an XHTML doc. I load it into a JDOM Document object
> and then just display it using the following code:
>
>
> SAXBuilder builder = new SAXBuilder();
> Document doc = builder.build(new
> File(test-xhtml.html));
> fmt.output(doc, System.out);
>
> The output shows the TD tags modified to specify
> rowspan/colspan. Is this supposed to be? Can this behavior be
> overridden? Thanks.
>
> INPUT FILE (test-xhtml.html) :
> =======================
>
> PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "DTD/xhtml1-transitional.dtd">
> xml:lang="en" lang="en">
>
> Virtual Library
>
>
>
>
> | HD1 | HD2 | HD3 | HD4 |
>
>
> | R3C1 | R3C2 | R3C3 | R3C4 |
>
>
>
>
>
> OUTPUT:
> =======================
>
> Transitional//EN" "DTD/xhtml1-transitional.dtd">
> xml:lang="en" lang="en">
>
> Virtual Library
>
>
>
>
> | colspan="1">HD1 | HD2 | rowspan="1" colspan="1">HD3 | colspan="1">HD4 |
>
>
> | colspan="1">R1C1 | R1C2 | rowspan="1" colspan="1">R1C3 | colspan="1">R1C4 |
>
>
>
>
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@yourhost.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2844 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20020215/335a8e0e/winmail.bin
From arosen at silverstream.com Fri Feb 15 10:12:49 2002
From: arosen at silverstream.com (Alex Rosen)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] generate XML conformly to dtd
In-Reply-To:
Message-ID: <000401c1b64c$61a3a990$d56e810a@silverstream.com>
This seems very related to the in-memory validation feature that we'd
eventually like to add - see TODO.txt. (Jason, should we add this specific
feature to the list too? Also, would XNI provide this info better than
dtdparser, if we were using Xerces2 (or another XNI parser)?)
So, it's probably something we'd like to do, but we don't know if/when it's
going to happen, unless you'd like to tackle it.
Alex
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org]On Behalf Of Mauerwerk, Mark
> Sent: Thursday, February 14, 2002 9:39 AM
> To: jdom-interest@jdom.org
> Subject: [jdom-interest] generate XML conformly to dtd
>
>
> Hi,
>
> I'm developing a sort of XML generator which shall build up a XML
> document from the scratch but conformly to a DTD. While I found the
> first task quite simple to build XML documents from the scratch with
> JDOM, it seems more difficult to do this in a more generic
> way conformly
> to a DTD (e.g retrieving a DOM object from a DTD, put the data values
> from an arbitrary data source in and build the XML document).
>
> I think a DTD parser could be heplful to support that work
> but it seems
> that the most common packages supporting XML don't support that way
> (extracting a document structure from a DTD).
>
> My method of resolution is to use schema instead: e.g. parse
> the schema
> (i.e. get the structure and constraints), vailidate the data from any
> data source (represented by Java data) and build the document
> containing
> the validated Java data with the structure derived from the schema.
>
> But, I think a generic XML generator is a very common approach in
> practice and may be I have overseen something already
> existing. So whats
> your experience with similar approaches.
>
> Thanks in advance
> Mark
>
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@yourhost.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2656 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20020215/7ffe1d50/winmail.bin
From arosen at silverstream.com Fri Feb 15 10:14:12 2002
From: arosen at silverstream.com (Alex Rosen)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] getText() and getAttributeValue()
In-Reply-To: <3C6C2D62.2872C1C6@digitalanywhere.com>
Message-ID: <000d01c1b64c$92296280$d56e810a@silverstream.com>
IIRC, even if you turn off validation, the DTD is still read and the default
values are still added to the SAX stream.
Alex
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org]On Behalf Of Jon Baer
> Sent: Thursday, February 14, 2002 4:34 PM
> To: jdom-interest@jdom.org
> Subject: Re: [jdom-interest] getText() and getAttributeValue()
>
>
> This might sound like a dumb question, but what would occur
> with XML that doesn't
> validate it's DTD in which case default attribute values are
> omitted. In the case of
> pulling say a where attribute bar="1" by default
> according to the DTD/XSD
> (like the case of the XHTML example from before), in which case
> getAttributeValue("bar") would yield null vs. "1".
>
> - Jon
From jhunter at acm.org Fri Feb 15 11:28:38 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Underlying JDOM Parser
References:
<3C6AADDA.1A973024@servlets.com>
Message-ID: <3C6D6166.4D7568C0@acm.org>
Elliotte Rusty Harold wrote:
>
> >Good question. You can tell JDOM which parser to use. If you don't, it
> >tries to use JAXP, and if JAXP fails it tries Xerces. But as far as
> >which version was found, since it depends on what's in your classpath,
> >you could be in the dark. I don't know if parsers expose that
> >information. On a quick look I don't see it.
> >
>
> I think it's been suggested as a standard SAX property for future
> releases of SAX. But in the meantime asking for the name of the
> XMLReader implementation class with getClass().getName() would
> probably be enough. For DOM you could look at the package name of the
> DOM Document implementation class.
That would indicate the parser name, but not the version, right?
-jh-
From jhunter at acm.org Fri Feb 15 11:30:02 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] depracation - is all you need...
References: <6D2CACF507A7D31187AF00508B5E194B05462F5A@atnas.dmu.ac.uk>
Message-ID: <3C6D61BA.5A3B4D74@acm.org>
It's now named setAttribute(). The compiler will tell you this if you
compile with "-deprecation for details". It's also in the Javadocs for
the method. It's also in the CHANGES.txt file.
-jh-
Steve Beech wrote:
>
> Dear All,
>
> I'm new to JDOM and have been using a Y2000 book to learn.
> However, when I come to test my code I keep getting:
>
> Note: C:\jakarta-tomcat-3.2.3\webapps\angelUM\WEBINF\Classes\JDOMTest.java
> uses or overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> Finished JDOMTest.
>
> This only occurs when I use the method:
>
> root.addAttribute("attName","attValue");
>
> but looking in the archives I can find no mention of this being depracated.
> Can anybody tell me where I'm going wrong.
>
> Thanks in advance,
>
> Steve
>
> ----------------------------------------------------------------------------
> -------------------------
> Steve Beech Tel: 0116
> 207 8162
> Software Developer e-mail:
> jbeech@dmu.ac.uk
> Room 0.36 Portland Building e-mail: steve@monkey-media.co.uk
> De Montfort University
> The Gateway, Leicester LE1 9BH
> ----------------------------------------------------------------------------
> ------------------------
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From elharo at metalab.unc.edu Fri Feb 15 11:49:44 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Underlying JDOM Parser
In-Reply-To: <3C6D6166.4D7568C0@acm.org>
References:
<3C6AADDA.1A973024@servlets.com>
<3C6D6166.4D7568C0@acm.org>
Message-ID:
At 11:28 AM -0800 2/15/02, Jason Hunter wrote:
>Elliotte Rusty Harold wrote:
>>
>> >Good question. You can tell JDOM which parser to use. If you don't, it
>> >tries to use JAXP, and if JAXP fails it tries Xerces. But as far as
>> >which version was found, since it depends on what's in your classpath,
>> >you could be in the dark. I don't know if parsers expose that
>> >information. On a quick look I don't see it.
>> >
>>
>> I think it's been suggested as a standard SAX property for future
>> releases of SAX. But in the meantime asking for the name of the
>> XMLReader implementation class with getClass().getName() would
>> probably be enough. For DOM you could look at the package name of the
>> DOM Document implementation class.
>
>That would indicate the parser name, but not the version, right?
>
Right. However, it might be enough to tell the difference between
major versions if the parser name changed between versions. I assume
this is just for debugging, in which case any reasonable string we
could offer to the developer might be helpful.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From noamt at yahoo.com Fri Feb 15 13:35:47 2002
From: noamt at yahoo.com (Noam Tamim)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] depracation - is all you need...
In-Reply-To: <3C6D61BA.5A3B4D74@acm.org>
Message-ID: <20020215213547.16763.qmail@web13908.mail.yahoo.com>
--- Jason Hunter wrote:
> It's now named setAttribute(). The compiler will tell you this if you
> compile with "-deprecation for details". It's also in the Javadocs for
> the method. It's also in the CHANGES.txt file.
Actually, if he compiles with "-deprecation for details", the compiler will
probably complain about not knowing what "for details" is..
=====
_______
Noam.
__________________________________________________
Do You Yahoo!?
Got something to say? Say it better with Yahoo! Video Mail
http://mail.yahoo.com
From todd.trimmer at trizetto.com Fri Feb 15 14:01:30 2002
From: todd.trimmer at trizetto.com (Trimmer, Todd)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] getText() and getAttributeValue()
Message-ID: <89D72635F8AFD4118E5B00B0D06822561D6FB3@s-coengl-e02>
>> p.s. -- I like the element.getAttributeValue(name, defaultValue) idea,
too.
> I don't because it's behavior isn't intuitive without looking at the
> docs. Example getAttributeValue("drawf","Sleepy"), does this method
> look for a attribute "drawf", then a attribute "Sleepy"?. To me
>
> String value = element.getAttributeValue("drawf");
> if (value == null)
> value = "Sleepy";
> is preferable because it reads well and clearly shows what the code does.
getAttributeValue("dwarf", "Sleepy") is clear because it looks similar to:
I also strongly disagree that your code reads well. If I had to do 20
attribute reads in a row, my code would be cluttered with those checks. It's
repetitious, arduous, and looks messy. It's better to encapsulate the
checks.
Why is getXXX(key, defaultValue) so abhorrent? After seeing Jason Hunter's
ParameterParserClass in Java Servlet Programming, which is chock-full of
methods like this, how can one not appreciate the power and beauty of such a
method?
Todd Trimmer
From jhunter at acm.org Fri Feb 15 15:11:46 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] getText() and getAttributeValue()
References: <89D72635F8AFD4118E5B00B0D06822561D6FB3@s-coengl-e02>
Message-ID: <3C6D95B2.F716E617@acm.org>
> Why is getXXX(key, defaultValue) so abhorrent? After seeing Jason Hunter's
> ParameterParserClass in Java Servlet Programming, which is chock-full of
> methods like this, how can one not appreciate the power and beauty of such a
> method?
>
> Todd Trimmer
Todd knows how to help his cause with carefully placed suck ups. :-)
But besides that, since Properties.getProperty(String, String) has set
the standard in Java land, I don't think it's unreasonable people will
know what getAttributeValue(String, String) does without reading docs.
-jh-
From jason at jmlie.com Fri Feb 15 22:23:59 2002
From: jason at jmlie.com (Jason Long)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Replace existing CDATA
In-Reply-To:
Message-ID:
I have an Element name as follows:
I am using the following code to remove the CDATA and replace it with a
processed version of itself.
eltName.removeContent((CDATA) eltName.getContent().get(0));
eltName.addContent(new CDATA(fileName));
Is there a cleaner or better way to accomplish this?
Best Regards,
Jason Long - President
Supernova Software - supernovasoftware.com
BS Physics, MS Chemical Engineering
From adams at multispex.com Fri Feb 15 23:06:05 2002
From: adams at multispex.com (ShantAdam)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Classpath solution
Message-ID: <000801c1b6b8$67a09760$7301fea9@shantadam>
Alright;
I checked everything ans I did as it was told in other emails on the same subject.
I'm still getting the error message:
Eception in thread "main" java.lang.NoClassDefFoundError: SAXTest("Myfile.xml")
Meanwhile, I have the classpath looking at xerces.jar and jdom.jar. And I know it
has nothing to do with my java class.
"CLASSPATH: .;C:\Program Files\jdk1.3.1_01\lib\tools.jar;
C:\Program Files\xml_api\jdom-b7\lib\ant.jar;
C:\Program Files\xml_api\jdom-b7\lib\xerces.jar;
C:\Program Files\xml_api\jdom-b7\build\jdom.jar;
C:\Program Files\xml_api\jdom-b7\lib\jaxp.jar;
C:\Program Files\xml_api\jdom-b7\lib\collections.jar"
I'm running java 1.3.1 on windowsME and downloaded JDOM-B7 binary.
I tried to get the recent source files with WinCVS I just wasn't able. Maybe I said
a source was missing in my files. By recreating it might help?
Anyone that has solutions for me?
Multispex Designs
Rep.: Shant Adam
Tel.: (514) 827-4840
adams@multispex.com
http://www.multispex.com
---
Visual technology service provider.
Fournisseur de service de technologie visuel.
---
Copyright 1998-2002?
Multispex Designs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020216/8ffddd65/attachment.htm
From elharo at metalab.unc.edu Sat Feb 16 13:47:54 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] CDATA class inconsistencies
Message-ID: <3C6ED38A.7090504@metalab.unc.edu>
1. In the CDATA class the javadoc sayst that "It is intended to provide
a modular, *perantable* method of representing CDATA."
I don't know whether that should be printable or parentable or something
else, but I'm almost certain it needs to be fixed.
2. Shouldn't CDATA be a subclass of Text? The JDOM methods are almost
all the same. I can imagine many aplications not caring about the
difference.
--
Elliotte
From elharo at metalab.unc.edu Sat Feb 16 13:55:43 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Merging text nodes
In-Reply-To:
References:
Message-ID:
DOM3 is beginning to add methods to *normalize* documents and
elements. In brief this means that all CDATA section nodes are
converted to text nodes and all adjacent text nodes are combined.
Thus each text node contains the maximum possible contiguous run of
text.
In JDOM we are mostly doing this automatically. That is, the Element
class notices if one Text node is added immediately after another and
if so merges them. However, there are a few holes in the process. For
instance, if two text nodes are separated by an Element node which is
then deleted, the newly adjacent text nodes are not merged. Is this
something that's worth fixing?
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From elharo at metalab.unc.edu Sat Feb 16 13:45:18 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Replace existing CDATA
In-Reply-To:
References:
Message-ID:
At 12:23 AM -0600 2/16/02, Jason Long wrote:
>I have an Element name as follows:
>
>
>
>
>
>I am using the following code to remove the CDATA and replace it with a
>processed version of itself.
>
> eltName.removeContent((CDATA) eltName.getContent().get(0));
> eltName.addContent(new CDATA(fileName));
>
>Is there a cleaner or better way to accomplish this?
>
Just looking at it I don't think that code would work. It seems to me
that it would throw a ClasscastException. eltName.getContent().get(0)
would not return the CDATA section node. It would return the first
text node which contains only white space.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From jason at supernovasoftware.com Sat Feb 16 14:10:27 2002
From: jason at supernovasoftware.com (Jason Long)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Replace existing CDATA
In-Reply-To:
Message-ID:
Sorry my mistake. The actual XML is as follows:
The code does work since there is no whitespace.
Best Regards,
Jason Long - President
Supernova Software - supernovasoftware.com
BS Physics, MS Chemical Engineering
-----Original Message-----
From: jdom-interest-admin@jdom.org
[mailto:jdom-interest-admin@jdom.org]On Behalf Of Elliotte Rusty Harold
Sent: Saturday, February 16, 2002 3:45 PM
To: Jason Long; JDOM
Subject: Re: [jdom-interest] Replace existing CDATA
At 12:23 AM -0600 2/16/02, Jason Long wrote:
>I have an Element name as follows:
>
>
>
>
>
>I am using the following code to remove the CDATA and replace it with a
>processed version of itself.
>
> eltName.removeContent((CDATA) eltName.getContent().get(0));
> eltName.addContent(new CDATA(fileName));
>
>Is there a cleaner or better way to accomplish this?
>
Just looking at it I don't think that code would work. It seems to me
that it would throw a ClasscastException. eltName.getContent().get(0)
would not return the CDATA section node. It would return the first
text node which contains only white space.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
From elharo at metalab.unc.edu Sat Feb 16 14:18:01 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Replace existing CDATA
In-Reply-To:
References:
Message-ID:
At 4:10 PM -0600 2/16/02, Jason Long wrote:
>Sorry my mistake. The actual XML is as follows:
>
>Cry.mp3]]>
>
In that case the simplest way is probably
eltName.setText(eltName.getText());
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From hip at a.cs.okstate.edu Sat Feb 16 17:43:28 2002
From: hip at a.cs.okstate.edu (Bradley S. Huffman)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Merging text nodes
In-Reply-To: Your message of "Sat, 16 Feb 2002 16:55:43 EST."
Message-ID: <200202170144.SAA19816@dorothy.denveronline.net>
Elliotte Rusty Harold writes:
> DOM3 is beginning to add methods to *normalize* documents and
> elements. In brief this means that all CDATA section nodes are
> converted to text nodes and all adjacent text nodes are combined.
> Thus each text node contains the maximum possible contiguous run of
> text.
>
> In JDOM we are mostly doing this automatically. That is, the Element
> class notices if one Text node is added immediately after another and
> if so merges them. However, there are a few holes in the process. For
> instance, if two text nodes are separated by an Element node which is
> then deleted, the newly adjacent text nodes are not merged. Is this
> something that's worth fixing?
Just looked at ContentList and it should be fairly easy to do, come
to think of it the merge should probably be taken out of Element and
moved to ContentList so Text, CDATA adds are consistent.
I like consistent behaviour, +1 for me.
Brad
From arosen at silverstream.com Sat Feb 16 19:24:05 2002
From: arosen at silverstream.com (Alex Rosen)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] CDATA class inconsistencies
In-Reply-To: <3C6ED38A.7090504@metalab.unc.edu>
Message-ID: <000401c1b762$8e0ba390$6601a8c0@silverstream.com>
> 2. Shouldn't CDATA be a subclass of Text? The JDOM methods are almost
> all the same. I can imagine many aplications not caring about the
> difference.
I agree - or just have one Text class, with a switch to tell XMLOutputter
whether to output it as a CDATA section or a plain text node.
Alex
From elharo at metalab.unc.edu Sat Feb 16 19:57:16 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] CDATA class inconsistencies
In-Reply-To: <000401c1b762$8e0ba390$6601a8c0@silverstream.com>
References: <000401c1b762$8e0ba390$6601a8c0@silverstream.com>
Message-ID:
At 10:24 PM -0500 2/16/02, Alex Rosen wrote:
>> 2. Shouldn't CDATA be a subclass of Text? The JDOM methods are almost
>> all the same. I can imagine many aplications not caring about the
>> difference.
>
>I agree - or just have one Text class, with a switch to tell XMLOutputter
>whether to output it as a CDATA section or a plain text node.
>
That makes sense, and it sounds awfully familiar. I suspect it's been
suggested before and that the only reason we have two classes now is
that the CDATA class got added when we were still using Strings for
text nodes.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From elharo at metalab.unc.edu Sat Feb 16 20:00:58 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Merging text nodes
In-Reply-To: <200202170144.g1H1ipm11092@trance.metalab.unc.edu>
References: <200202170144.g1H1ipm11092@trance.metalab.unc.edu>
Message-ID:
At 7:43 PM -0600 2/16/02, Bradley S. Huffman wrote:
>Just looked at ContentList and it should be fairly easy to do, come
>to think of it the merge should probably be taken out of Element and
>moved to ContentList so Text, CDATA adds are consistent.
>
OK, but if the code's going to go in ContentList then somebody else
is going to need to write it because I don't have a clue what's going
on in there and would feel very uncomfortable messing with its
internals.
Wherever the change is made, the tricky bit is going to be deciding
whether to merge adjacent Text and CDATA nodes. If we do merge them,
do we merge them into a Text node or a CDATA node? Probably the
latter. If someone's deliberately added a CDATA node, then they're
probably more concerned about having it preserved than the text node.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From hip at a.cs.okstate.edu Sat Feb 16 20:45:26 2002
From: hip at a.cs.okstate.edu (Bradley S. Huffman)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Merging text nodes
In-Reply-To: Your message of "Sat, 16 Feb 2002 23:00:58 EST."
Message-ID: <200202170444.VAA03670@dorothy.denveronline.net>
Elliotte Rusty Harold writes:
> At 7:43 PM -0600 2/16/02, Bradley S. Huffman wrote:
>
> >Just looked at ContentList and it should be fairly easy to do, come
> >to think of it the merge should probably be taken out of Element and
> >moved to ContentList so Text, CDATA adds are consistent.
> >
>
> OK, but if the code's going to go in ContentList then somebody else
> is going to need to write it because I don't have a clue what's going
> on in there and would feel very uncomfortable messing with its
> internals.
No problem, I know that code by heart :) The kicker is add(int,Object),
for example
element.addContent( new Element("e1")); // index = 0
element.addContent( new Text("This is a test")); // index = 1
element.addContent( new Element("e2")); // index = 2
List list = element.getContent();
list = element.add(2, new Text(", only a test");
with Text nodes merged then list.get(2) yields e2 instead of a Text node.
But I can live with that if others can.
> Wherever the change is made, the tricky bit is going to be deciding
> whether to merge adjacent Text and CDATA nodes. If we do merge them,
> do we merge them into a Text node or a CDATA node? Probably the
> latter. If someone's deliberately added a CDATA node, then they're
> probably more concerned about having it preserved than the text node.
Right now adjacent Text and CDATA nodes are not merge because XMLOutputter
escapes <, &, etc. in Text and not in CDATA (but there are other ways to
handle that problem).
In Element.getText() Text and CDATA are concatinated into a single String.
What about EntityRef? For example with
Cats & Dogs
the element.getText() yields "Cats Dogs", not "Cats & Dogs" which I
would find more useful.
Would a method like Element.getText(Map) be useful for concatinating Text,
CDATA, and EntityRef into a String?
Brad
From hip at a.cs.okstate.edu Sat Feb 16 20:55:20 2002
From: hip at a.cs.okstate.edu (Bradley S. Huffman)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] CDATA class inconsistencies
In-Reply-To: Your message of "Sat, 16 Feb 2002 22:57:16 EST."
Message-ID: <200202170454.VAA04494@dorothy.denveronline.net>
Elliotte Rusty Harold writes:
> At 10:24 PM -0500 2/16/02, Alex Rosen wrote:
> >> 2. Shouldn't CDATA be a subclass of Text? The JDOM methods are almost
> >> all the same. I can imagine many aplications not caring about the
> >> difference.
> >
> >I agree - or just have one Text class, with a switch to tell XMLOutputter
> >whether to output it as a CDATA section or a plain text node.
> >
>
> That makes sense, and it sounds awfully familiar. I suspect it's been
> suggested before and that the only reason we have two classes now is
> that the CDATA class got added when we were still using Strings for
> text nodes.
The archives seem to support you suspicion. One idea would be to have
CDATA as a subclass of Text like you said, with Text having a flag for
whether it contains unescaped data. I think it would make merging Text/CDATA,
and outputting easy to keep correct.
Brad
From elharo at metalab.unc.edu Sat Feb 16 20:54:55 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Merging text nodes
In-Reply-To: <200202170445.g1H4jem19676@trance.metalab.unc.edu>
References: <200202170445.g1H4jem19676@trance.metalab.unc.edu>
Message-ID:
At 10:45 PM -0600 2/16/02, Bradley S. Huffman wrote:
>In Element.getText() Text and CDATA are concatinated into a single String.
>What about EntityRef? For example with
>
> Cats & Dogs
>
>the element.getText() yields "Cats Dogs", not "Cats & Dogs" which I
>would find more useful.
>
The problem is that the text isn't "Cats & Dogs". It's "Cats &
Dogs" and we have no way to get that. I agree, getText() does fail
when faced with Cats & Dogs, but honestly I think
getText() fails when faced with Cats <em>and</em> Dogs
too. I don't like the current incarnation of this method at all, but
I think EntityRef is the least of its troubles.
The assumption is that developers won't be using EntityRef for simple
predefined things like & but for more complex things like ©,
, or &signature-file;. Currently the EntityRef class does not
provide any means for us to store or retrieve the replacement text of
an entity which may contain large quantities of both text and markup
in the general case.
The way DOM handles this is to allow the EntityRef to have children.
I'm not sure we want to do that, but maybe we do in the future. It
needs more thought and discussion.
>Would a method like Element.getText(Map) be useful for concatinating Text,
>CDATA, and EntityRef into a String?
>
At first hearing, it sounds too complicated and not really extensible
in the long term.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From hip at a.cs.okstate.edu Sat Feb 16 21:30:59 2002
From: hip at a.cs.okstate.edu (Bradley S. Huffman)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Merging text nodes
In-Reply-To: Your message of "Sat, 16 Feb 2002 23:54:55 EST."
Message-ID: <200202170530.WAA07330@dorothy.denveronline.net>
Elliotte Rusty Harold writes:
> >Would a method like Element.getText(Map) be useful for concatinating Text,
> >CDATA, and EntityRef into a String?
> >
> At first hearing, it sounds too complicated and not really extensible
> in the long term.
I not suggesting anything complicated just a convenience to make
Element.getText a little more useful by giving developers a easy way to map
EntityRef names to the String they want inserted in the result String. The
default would be to wrap EntityRef name in &; like XMLOutputter. But if they
provide a Map that maps String->Object then Object.toString is used.
Maintaining the Map and it's contents would be their responsiblity.
Speaking of EntityRef, should Element.setText parse the String for entities?
Brad
From elharo at metalab.unc.edu Sat Feb 16 22:30:50 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Merging text nodes
In-Reply-To: <200202170531.g1H5VYm21426@trance.metalab.unc.edu>
References: <200202170531.g1H5VYm21426@trance.metalab.unc.edu>
Message-ID:
At 11:30 PM -0600 2/16/02, Bradley S. Huffman wrote:
>Speaking of EntityRef, should Element.setText parse the String for entities?
>
Absolutely not. "Cats & Dogs" is legal content for a text node.
It consists of 15 characters including the ampersand followed by the
three letters a, m, p. and the semicolon.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From elharo at metalab.unc.edu Sat Feb 16 22:33:34 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Merging text nodes
In-Reply-To: <200202170531.g1H5VYm21426@trance.metalab.unc.edu>
References: <200202170531.g1H5VYm21426@trance.metalab.unc.edu>
Message-ID:
At 11:30 PM -0600 2/16/02, Bradley S. Huffman wrote:
>I not suggesting anything complicated just a convenience to make
>Element.getText a little more useful by giving developers a easy way to map
>EntityRef names to the String they want inserted in the result String.
If we chose to do this, the only sensible place to do it would be the
EntityRef class. There's no reason to put this logic in Element or
Text.
>The
>default would be to wrap EntityRef name in &; like XMLOutputter. But if they
>provide a Map that maps String->Object then Object.toString is used.
>Maintaining the Map and it's contents would be their responsiblity.
>
A String is insufficient. Entity references may point to a lot more
than strings.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From adams at multispex.com Sun Feb 17 13:00:21 2002
From: adams at multispex.com (ShantAdam)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] building jdom
Message-ID: <001801c1b7f6$1e0b9d40$7301fea9@shantadam>
OK !
I CVS-ed the jdom source files and came to build it and I got this error message at the end:
[javac] too many errors.
[javac] 132 errors
BUILD FAILED
C:\Program Files\xml_api\jdom\build.xml:158:Compile failed,message should have been provided.
Prior this error message, I got as many as 100 lines of "ambiguous class" [javac] error messages and "java.io.IOException".
Meanwhile, I have this as a classpath:
CLASSPATH=
".;
C:\Program Files\jdk1.3.1_01\lib\tools.jar;
C:\Program Files\xml_api\jdom\lib\xerces.jar;
C:\Program Files\xml_api\jdom\lib\crimson.jar;
C:\Program Files\xml_api\jdom\lib\jaxp.jar;
C:\Program Files\xml_api\jdom\lib\xalan.jar;
C:\Program Files\xml_api\sax2\sax2-r2pre3.jar;
C:\Program Files\jakarta-ant\bootstrap\lib\ant.jar"
and this as path:
PATH=
"C:\PROGRA~1\COMMON~1\MICROS~1\MSInfo\;
C:\WINDOWS;
C:\WINDOWS\COMMAND;
C:\Program Files\Mts;
C:\Program Files\jdk1.3.1_01\bin;
C:\Program Files\jakarta-ant\bootstrap\bin"
and I'm runing on windowsME.
Now, what about that !?!
Multispex Designs
Rep.: Shant Adam
Tel.: (514) 827-4840
adams@multispex.com
http://www.multispex.com
---
Visual technology service provider.
Fournisseur de service de technologie visuel.
---
Copyright 1998-2002?
Multispex Designs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020217/a603dd57/attachment.htm
From hip at a.cs.okstate.edu Sun Feb 17 13:36:15 2002
From: hip at a.cs.okstate.edu (Bradley S. Huffman)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Merging text nodes
In-Reply-To: Your message of "Sun, 17 Feb 2002 01:30:50 EST."
Message-ID: <200202172136.OAA20830@dorothy.denveronline.net>
Elliotte Rusty Harold writes:
> At 11:30 PM -0600 2/16/02, Bradley S. Huffman wrote:
>
> >Speaking of EntityRef, should Element.setText parse the String for entities?
>
> Absolutely not. "Cats & Dogs" is legal content for a text node.
> It consists of 15 characters including the ampersand followed by the
> three letters a, m, p. and the semicolon.
Let me restate that, should there be a additional method that does parse
entities? Would something like
element.setTextParsed("Cats &something; Dogs");
as a convenience for
element.addContent(new Text("Cats "));
element.addContent(new EntityRef("something"));
element.addContent(new Text(" Dogs"));
be useful or would it be unnecessary clutter in the API? Probably clutter.
Brad
From johnf at goldsoft.com.au Sun Feb 17 13:52:23 2002
From: johnf at goldsoft.com.au (John)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] JDOM and Swing View
Message-ID: <007301c1b7fd$6226bf80$1eb5fea9@honeysuckle>
Hi
Has anyone written the View side of the JDOM architecture? I want to be able to edit JDOM documents in a Swing component.
John
------------------------------------------------------------
Dr John Foster
GOLD SOFTWARE International Pty Ltd
P O Box 5033
Laburnum
Victoria 3130
Australia
Phone: 04 1173 7288
Fax: 03 9878 7844
e-mail: johnf@goldsoft.com.au
WWW: http://www.goldsoft.com.au
------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020218/4eb3eb8f/attachment.htm
From abrighto at netscape.net Sat Feb 16 14:52:57 2002
From: abrighto at netscape.net (abrighto@netscape.net)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] jdom and jdk1.4: EntityResolver no longer called
Message-ID: <72FF4438.1ED838F9.0091AE98@netscape.net>
Hi all,
The new jdk1.4 runtime library now contains the org.xml packages,
which kind of forces you to use them, it seems (I was previously
using xerces.jar).
Since upgrading to jdk1.4, I am having problems with DTDs not being
resolved. The problem is that the EntityResolver is not being called.
The error message is then:
"Relative URI "UIInfo.dtd"; can not be resolved without a base URI"
Here is the related code. Any ideas on how to make this work with jdk1.4?
/** Parse the XML document */
private static void _parseDocument(BufferedReader in) {
SAXBuilder builder = new SAXBuilder(true);
builder.setEntityResolver(new EntityResolver() {
public InputSource resolveEntity (String publicId, String systemId) {
URL url = Resources.getResource("UIInfo.dtd");
try {
return new InputSource(url.openStream());
}
catch(Exception e) {
throw new RuntimeException("Error resolving entity: " +
publicId + ": " + e.toString());
}
}
});
try {
Document doc = builder.build(in);
Element rootElement = doc.getRootElement();
Iterator it = rootElement.getChildren().listIterator();
while(it.hasNext()) {
Element e = (Element)it.next();
_parseElement(e);
}
}
catch (JDOMException ex) {
ex.printStackTrace();
throw new RuntimeException("Error reading " + XML_FILE + ": " + ex.getMessage());
}
}
Thanks,
Allan Brighton
--
__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/
Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
From jonbaer at digitalanywhere.com Sun Feb 17 16:43:20 2002
From: jonbaer at digitalanywhere.com (Jon Baer)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] JDOM and Swing View
References: <007301c1b7fd$6226bf80$1eb5fea9@honeysuckle>
Message-ID: <3C704E28.9E6A680B@digitalanywhere.com>
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020217/00775837/attachment.htm
From John.Webber at jentro.com Sun Feb 17 23:29:42 2002
From: John.Webber at jentro.com (John L. Webber - Jentro AG)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] getText() and getAttributeValue()
References: <89D72635F8AFD4118E5B00B0D06822561D6FB3@s-coengl-e02> <3C6D95B2.F716E617@acm.org>
Message-ID: <3C70AD66.931AE42B@jentro.com>
Jason Hunter wrote:
>
> > Why is getXXX(key, defaultValue) so abhorrent? After seeing Jason Hunter's
> > ParameterParserClass in Java Servlet Programming, which is chock-full of
> > methods like this, how can one not appreciate the power and beauty of such a
> > method?
> >
> > Todd Trimmer
>
> Todd knows how to help his cause with carefully placed suck ups. :-)
>
> But besides that, since Properties.getProperty(String, String) has set
> the standard in Java land, I don't think it's unreasonable people will
> know what getAttributeValue(String, String) does without reading docs.
+1 for this suggestion. I have tons of parsing code that looks as
cluttered as Todd's example -- I'd love to be able to replace it with
the suggested change
John Webber
--
---------------------------------------------------------
Jentro AG
John L. Webber, Software Development
---------------------------------------------------------
Peter-Henlein-Strasse 28, 85540 Haar/Munich, Germany
Tel. +49 89 462 385 0 mailto:John.Webber@jentro.com
Fax +49 89 462 385 29 http://www.jentro.com
---------------------------------------------------------
From elharo at metalab.unc.edu Sun Feb 17 13:44:13 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] Merging text nodes
In-Reply-To: <200202172136.g1HLahm23090@trance.metalab.unc.edu>
References: <200202172136.g1HLahm23090@trance.metalab.unc.edu>
Message-ID:
At 3:36 PM -0600 2/17/02, Bradley S. Huffman wrote:
>Let me restate that, should there be a additional method that does parse
>entities? Would something like
>
> element.setTextParsed("Cats &something; Dogs");
>
>as a convenience for
>
> element.addContent(new Text("Cats "));
> element.addContent(new EntityRef("something"));
> element.addContent(new Text(" Dogs"));
>
>be useful or would it be unnecessary clutter in the API? Probably clutter.
>
It is unnecessary clutter. Worse yet, it presents an incorrect
picture of the structure and semantics of an XML document. Text nodes
are strings (in JDOM). Entity references are entity references. We
shouldn't mix them up.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From adams at multispex.com Mon Feb 18 05:42:43 2002
From: adams at multispex.com (ShantAdam)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] jdom run
Message-ID: <002501c1b882$25231540$7301fea9@shantadam>
So now I have the jdom.jar in my classpath as follows:
CLASSPATH=
".;
C:\Program Files\jdk1.3.1_01\lib\tools.jar;
C:\Program Files\jakarta-ant\bootstrap\lib\ant.jar;
C:\Program Files\xml_api\jdom\build\jdom.jar;
C:\Program Files\xml_api\jdom\lib\xerces.jar;
C:\Program Files\xml_api\jdom\lib\crimson.jar;
C:\Program Files\xml_api\jdom\lib\jaxp.jar;
C:\Program Files\xml_api\jdom\lib\xalan.jar;
C:\Program Files\xml_api\sax2\sax2-r2pre3.jar;"
I have these files copied in the following directory:
C:\Program Files\JavaSoft\JRE\1.3.1\lib\ext
crimson.jar
jaxp.jar
jdom.jar
sax2-r2pre3.jar
xalan.jar
xerces.jar
Same files are copied in this directory:
C:\Program Files\jdk1.3.1_01\jre\lib\ext
crimson.jar
jaxp.jar
jdom.jar
sax2-r2pre3.jar
xalan.jar
xerces.jar
But I'm getting this error message:
Exception in thread "main" java.lang.NoClassDefFoundError:
SAXTest("NamHyData")
when I'm runing my SAXTest.class with the following code:
import java.io.File;
import org.jdom.Document;
import org.jdom.Element;
import org.jdom.JDOMException;
import org.jdom.input.SAXBuilder;
public class SAXTest{
public static void main(String[] args){
if (args.length != 1){
System.out.println("Usage: SAXTest(filename to parse)");
return;
}
try{
//Request document building without validation
SAXBuilder builder = new SAXBuilder(false);
Document doc = builder.build(new File(args[0]));
System.out.println("Document successfully read");
}
catch(JDOMException e){
e.printStackTrace();
}
}
}
What can you determine as wrong move or programming?
Multispex Designs
Rep.: Shant Adam
Tel.: (514) 827-4840
adams@multispex.com
http://www.multispex.com
---
Visual technology service provider.
Fournisseur de service de technologie visuel.
---
Copyright 1998-2002?
Multispex Designs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020218/d9e95935/attachment.htm
From JBeech at dmu.ac.uk Mon Feb 18 06:03:35 2002
From: JBeech at dmu.ac.uk (Steve Beech)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] InputSource?
Message-ID: <6D2CACF507A7D31187AF00508B5E194B05462F6F@atnas.dmu.ac.uk>
Dear All,
I have a problem. I have a server/client set up and want to send a XML doc
from client to server.
Server then reads XML doc using JDOM.
On the client I create a printwriter on the socket like so....
out = new PrintWriter(testSocket.getOutputStream(), true);
and write my xml doc using....
out.println("P98047183");
On server I open an input source thus:
InputSource is = new InputSource(socket.getInputStream());
and then call my JDOM method:
jdh.saxDoc(is, out);
Method is as follows:
public void saxDoc (InputSource is, PrintWriter out) throws IOException,
JDOMException {
SAXBuilder builder = new SAXBuilder(false);
Document doc = builder.build(is);
}
However, this just hangs and never appears to finish building. I think I
must be using InputSource incorrectly or something.
Can anybody help?
Thanks in advance,
Steve
----------------------------------------------------------------------------
-------------------------
Steve Beech Tel: 0116
207 8162
Software Developer e-mail:
jbeech@dmu.ac.uk
Room 0.36 Portland Building e-mail: steve@monkey-media.co.uk
De Montfort University
The Gateway, Leicester LE1 9BH
----------------------------------------------------------------------------
------------------------
From nina.fellows at eds.com Mon Feb 18 10:46:13 2002
From: nina.fellows at eds.com (Fellows, Nina L)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] JDOMExecption NoClassDefFoundError
Message-ID: <7A57F750AF65D411949C00508BDFD8180C7FE028@USPLM202>
I am receiving a NoClassDefFoundError: org/jdom/JDOMException. When
compiling I received an error stating that I need to throw or catch the
JDOMException. I put a catch around it. My classpath has the
xerces.jar;jdom.jar;build\classes in that order. I can see the JDOMException
class in jdom.jar. What is going on? Below is the code:
import org.jdom.*;
//import org.jdom.JDOMException;
import org.jdom.DocType;
import org.jdom.Document;
import org.jdom.Element;
import org.jdom.input.SAXBuilder;
import org.jdom.output.XMLOutputter;
import org.xml.sax.*;
public void doPost(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException
{
String tmp = null;
Document inDoc = null;
boolean doValidate = false; // use validating parser
SAXBuilder builder = null;
XMLOutputter outputter = null;
ByteArrayOutputStream bytes = null;
response.setContentType("text/html");
PrintWriter out = response.getWriter();
builder = new SAXBuilder(doValidate);
try {
inDoc = builder.build(new ByteArrayInputStream(tmp.getBytes()));
}
catch (org.jdom.JDOMException je) {}
}
Thanks for any help!
Nina Fellows
Email: nina.fellows@eds.com
From aw at orange-interactive.de Mon Feb 18 06:10:15 2002
From: aw at orange-interactive.de (Andreas Wolf)
Date: Fri Aug 6 17:07:23 2004
Subject: AW: [jdom-interest] jdom run
In-Reply-To: <002501c1b882$25231540$7301fea9@shantadam>
Message-ID:
Hi!
Make sure the source-file containing your SAXTest class is named
'SAXTest.java'. The compiled class must spell 'SAXTest.class'
just tested your code and the java.lang.NoClassDefFoundError occurs if the
file isn't named correctly.
Orange-Interactive GmbH
Andreas Wolf
-----Urspr?ngliche Nachricht-----
Von: jdom-interest-admin@jdom.org [mailto:jdom-interest-admin@jdom.org]Im
Auftrag von ShantAdam
Gesendet: Montag, 18. Februar 2002 14:43
An: jdom - interest
Betreff: [jdom-interest] jdom run
So now I have the jdom.jar in my classpath as follows:
CLASSPATH=
".;
C:\Program Files\jdk1.3.1_01\lib\tools.jar;
C:\Program Files\jakarta-ant\bootstrap\lib\ant.jar;
C:\Program Files\xml_api\jdom\build\jdom.jar;
C:\Program Files\xml_api\jdom\lib\xerces.jar;
C:\Program Files\xml_api\jdom\lib\crimson.jar;
C:\Program Files\xml_api\jdom\lib\jaxp.jar;
C:\Program Files\xml_api\jdom\lib\xalan.jar;
C:\Program Files\xml_api\sax2\sax2-r2pre3.jar;"
I have these files copied in the following directory:
C:\Program Files\JavaSoft\JRE\1.3.1\lib\ext
crimson.jar
jaxp.jar
jdom.jar
sax2-r2pre3.jar
xalan.jar
xerces.jar
Same files are copied in this directory:
C:\Program Files\jdk1.3.1_01\jre\lib\ext
crimson.jar
jaxp.jar
jdom.jar
sax2-r2pre3.jar
xalan.jar
xerces.jar
But I'm getting this error message:
Exception in thread "main" java.lang.NoClassDefFoundError:
SAXTest("NamHyData")
when I'm runing my SAXTest.class with the following code:
import java.io.File;
import org.jdom.Document;
import org.jdom.Element;
import org.jdom.JDOMException;
import org.jdom.input.SAXBuilder;
public class SAXTest{
public static void main(String[] args){
if (args.length != 1){
System.out.println("Usage: SAXTest(filename to parse)");
return;
}
try{
//Request document building without validation
SAXBuilder builder = new SAXBuilder(false);
Document doc = builder.build(new File(args[0]));
System.out.println("Document successfully read");
}
catch(JDOMException e){
e.printStackTrace();
}
}
}
What can you determine as wrong move or programming?
Multispex Designs
Rep.: Shant Adam
Tel.: (514) 827-4840
adams@multispex.com
http://www.multispex.com
---
Visual technology service provider.
Fournisseur de service de technologie visuel.
---
Copyright 1998-2002?
Multispex Designs?
From easleydp at hotmail.com Mon Feb 18 12:23:22 2002
From: easleydp at hotmail.com (David Easley)
Date: Fri Aug 6 17:07:23 2004
Subject: [jdom-interest] JDOM problems since switching to JSDK 1.4
Message-ID:
Am having problems using JDOM beta 7 with JSDK 1.4.0
Get a different problem depending on whether I'm using NetBeans or Forte
IDE. Everything was OK with JSDK 1.3.1
See error details below.
Thanks for any help,
David
--
In NetBeans
===========
Error on line 2: Relative URI: "com/bygsystems/lde/DTDs/TmplDesc.dtd"; can
not be resolved without base URI.
Here is the beginning of my XML file:
...
In Forte
========
...
FINE: [bygsystems.lde.TemplateManager] Looking for templates in
C:\Java\Forte4J\DPE_proj\LessonDataEditor\Template Descriptors
FINE: [bygsystems.lde.TemplateManager] Processing 7 TLDs...
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION o
****************
Another exception has been detected while we were handling last error.
Dumping informatccurred at PC=0x6D35DDFE
Function=JVM_InitializeCompiler+0x874C
Library=C:\Java\j2sdk1.4.ion about last error:
ERROR REPORT FILE = (N/A)
PC = 0x6D35DDFE
SIGN0\jre\bin\client\jvm.dll
Current Java thread:
at java.lang.Throwable.fillInStackTrace(Native Method)
- locked <02A48BB8> (a java.lang.AbstractMethodError)
at java.lang.Throwable.(Throwable.java:180)
at java.lang.Error.(Error.java:37)
at java.lang.LinkageError.(LinkageError.java:26)
at
java.lang.IncompatibleClassChangeError.(IncompatibleClassChangeError.java:26)
at java.lang.AbstractMethodError.(AbstractMethodError.java:27)
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
From Barry at Burd.org Mon Feb 18 11:03:14 2002
From: Barry at Burd.org (Barry Burd)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Lightweight JDOM? (again)
Message-ID: <000d01c1b8ae$ebd5c440$5b00a8c0@groucho>
I've searched the archives, and I can't find answers to my specific
questions about JDOM's lightweightness.
I've read that "injects more XML semantics into the tree than does DOM. To
DOM, everything is Node. To JDOM, you have Attribute, Element, and
Namespace nodes." How does that make JDOM more lightweight than DOM?
I've read that, with JDOM "an XML document can be seen as a whole, and any
member of that document is available at any time." Does this mean that, with
DOM, any member of a document isn't available at any time? If so, can you
clarify? To reach a deeply nested node in a DOM tree, you have to start at
the top, and go through various descendent nodes. Do you not have to do with
with JDOM?
I think I've read that DOM requires you to have the entire document in
memory all at once, but JDOM can have pieces of the document in memory at
once (and yet maintain a global view of the document). If this is the case,
how does JDOM achieve this where DOM does not?
Thank you.
From jhunter at acm.org Mon Feb 18 13:25:20 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] JDOM problems since switching to JSDK 1.4
References:
Message-ID: <3C717140.D927590D@acm.org>
> In NetBeans
> ===========
>
> Error on line 2: Relative URI: "com/bygsystems/lde/DTDs/TmplDesc.dtd"; can
> not be resolved without base URI.
>
> Here is the beginning of my XML file:
>
>
>
You're probably passing a stream to the builder, and so the builder has
no way to resolve the relative URI there. Pass a file instead. It's
just like the error msg says.
> In Forte
> ========
>
> ...
> FINE: [bygsystems.lde.TemplateManager] Looking for templates in
> C:\Java\Forte4J\DPE_proj\LessonDataEditor\Template Descriptors
> FINE: [bygsystems.lde.TemplateManager] Processing 7 TLDs...
>
> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION o
>
> ****************
> Another exception has been detected while we were handling last error.
> Dumping informatccurred at PC=0x6D35DDFE
> Function=JVM_InitializeCompiler+0x874C
> Library=C:\Java\j2sdk1.4.ion about last error:
> ERROR REPORT FILE = (N/A)
> PC = 0x6D35DDFE
> SIGN0\jre\bin\client\jvm.dll
That looks like a JVM bug.
-jh-
From philip.nelson at omniresources.com Mon Feb 18 17:30:06 2002
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] jdom run
Message-ID:
So did you say
Java SAXText("NanHyData")
Or
Java SAXTest NanHyData
#2 is the correct answer
-----Original Message-----
But I'm getting this error message:
Exception in thread "main" java.lang.NoClassDefFoundError:
SAXTest("NamHyData")
From philip.nelson at omniresources.com Mon Feb 18 17:43:03 2002
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Lightweight JDOM? (again)
Message-ID:
> I've searched the archives, and I can't find answers to my
> specific questions about JDOM's lightweightness.
>
> I've read that "injects more XML semantics into the tree than
> does DOM. To DOM, everything is Node. To JDOM, you have
> Attribute, Element, and Namespace nodes." How does that make
> JDOM more lightweight than DOM?
It doesn't make it more lightweight. That fact that DOM classes implement a
Node interface and JDOM doesn't doesn't mean much for being lightweight. It
means that you don't have to use factories to create a new instance of a
class like you do with DOM.
>
> I've read that, with JDOM "an XML document can be seen as a
> whole, and any member of that document is available at any
> time." Does this mean that, with DOM, any member of a
> document isn't available at any time? If so, can you clarify?
> To reach a deeply nested node in a DOM tree, you have to
> start at the top, and go through various descendent nodes. Do
> you not have to do with with JDOM?
Yes. The syntax is much simpler though.
>
> I think I've read that DOM requires you to have the entire
> document in memory all at once, but JDOM can have pieces of
> the document in memory at once (and yet maintain a global
> view of the document). If this is the case, how does JDOM
> achieve this where DOM does not?
That would be a good JDOM trick. Actually, the hope is that a deferred
builder can load partial documents but I think this will be put off until
after the 1.0 release. From the looks of it, the "lightweight" aspect is
going to be most realized in the next beta. Getting the api to work
correctly has been the first order of business here.
From philip.nelson at omniresources.com Mon Feb 18 17:48:37 2002
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Merging text nodes
Message-ID:
> It is unnecessary clutter. Worse yet, it presents an incorrect
> picture of the structure and semantics of an XML document. Text nodes
> are strings (in JDOM). Entity references are entity references. We
> shouldn't mix them up.
I agree. I did make a case for mixing Text and EntityRef when trying to
figure out a way for attribute values to have entity refs in them. Since
we're not going to support that feature, I think we should avoid trying to
do to much in this direction.
From hip at a.cs.okstate.edu Mon Feb 18 19:04:11 2002
From: hip at a.cs.okstate.edu (Bradley S. Huffman)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Merging text nodes
In-Reply-To: Your message of "Mon, 18 Feb 2002 19:48:37 CST."
Message-ID: <200202190303.UAA03259@dorothy.denveronline.net>
> > It is unnecessary clutter. Worse yet, it presents an incorrect
> > picture of the structure and semantics of an XML document. Text nodes
> > are strings (in JDOM). Entity references are entity references. We
> > shouldn't mix them up.
>
> I agree. I did make a case for mixing Text and EntityRef when trying to
> figure out a way for attribute values to have entity refs in them. Since
> we're not going to support that feature, I think we should avoid trying to
> do to much in this direction.
So we shouldn't allow the following sequence of code?
Element e = new Element("title");
e.addContent( new Text("Cats "));
e.addContent( new EntityRef("connect"));
e.addContent( new Text(" Dogs"));
Which produces the same structure for the element's content as running
]>
Cats &connect; Dogs
thru SAXBuilder with setExpandEntities(false).
From jhunter at acm.org Mon Feb 18 19:54:33 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Merging text nodes
References: <200202190303.UAA03259@dorothy.denveronline.net>
Message-ID: <3C71CC79.8A839850@acm.org>
"Bradley S. Huffman" wrote:
>
> > > It is unnecessary clutter. Worse yet, it presents an incorrect
> > > picture of the structure and semantics of an XML document. Text nodes
> > > are strings (in JDOM). Entity references are entity references. We
> > > shouldn't mix them up.
> >
> > I agree. I did make a case for mixing Text and EntityRef when trying to
> > figure out a way for attribute values to have entity refs in them. Since
> > we're not going to support that feature, I think we should avoid trying to
> > do to much in this direction.
>
> So we shouldn't allow the following sequence of code?
>
> Element e = new Element("title");
> e.addContent( new Text("Cats "));
> e.addContent( new EntityRef("connect"));
> e.addContent( new Text(" Dogs"));
>
> Which produces the same structure for the element's content as running
>
>
>
> ]>
> Cats &connect; Dogs
>
> thru SAXBuilder with setExpandEntities(false).
From philip.nelson at omniresources.com Mon Feb 18 20:17:44 2002
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Merging text nodes
Message-ID:
> >
> > So we shouldn't allow the following sequence of code?
> >
> > Element e = new Element("title");
> > e.addContent( new Text("Cats "));
> > e.addContent( new EntityRef("connect"));
> > e.addContent( new Text(" Dogs"));
> From what I understand we're all saying, you can do that, but
> we won't do any fancy merging behind the scenes.
Right.
From easleydp at hotmail.com Tue Feb 19 01:22:40 2002
From: easleydp at hotmail.com (David Easley)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Re: JDOM problems since switching to JSDK 1.4
Message-ID:
>You're probably passing a stream to the builder, and so the builder has
>no way to resolve the relative URI there. Pass a file instead. It's
>just like the error msg says.
Jason,
Thanks for that tip - I'm now parsing again. It's strange that the stream
approach worked in 1.3 but not in 1.4.
David
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
From arosen at silverstream.com Tue Feb 19 07:59:05 2002
From: arosen at silverstream.com (Alex Rosen)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Lightweight JDOM? (again)
In-Reply-To: <000d01c1b8ae$ebd5c440$5b00a8c0@groucho>
Message-ID: <000b01c1b95e$5c994ee0$6a65810a@silverstream.com>
I don't think that JDOM is any more lightweight than DOM memory-wise, and it
may never be. It is more lightweight in the size and elegance of the API. To
me, that's what "lightweight" means in relation to JDOM.
> I've read that, with JDOM "an XML document can be seen as a whole, and any
> member of that document is available at any time." Does this mean that,
with
> DOM, any member of a document isn't available at any time? If so, can you
> clarify? To reach a deeply nested node in a DOM tree, you have to start at
> the top, and go through various descendent nodes. Do you not have to do
with
> with JDOM?
This was probably meant to compare JDOM to SAX, rather than DOM. In both DOM
and JDOM you have the entire tree in memory, but with SAX you get only a
stream of events.
Alex
From arosen at silverstream.com Tue Feb 19 08:01:12 2002
From: arosen at silverstream.com (Alex Rosen)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] InputSource?
In-Reply-To: <6D2CACF507A7D31187AF00508B5E194B05462F6F@atnas.dmu.ac.uk>
Message-ID: <000c01c1b95e$a84ae6f0$6a65810a@silverstream.com>
Did you try the suggestion in the JDOM FAQ?
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org]On Behalf Of Steve Beech
> Sent: Monday, February 18, 2002 9:04 AM
> To: 'jdom-interest'
> Subject: [jdom-interest] InputSource?
>
>
> Dear All,
>
> I have a problem. I have a server/client set up and want to
> send a XML doc
> from client to server.
> Server then reads XML doc using JDOM.
>
> On the client I create a printwriter on the socket like so....
> out = new PrintWriter(testSocket.getOutputStream(), true);
> and write my xml doc using....
> out.println("P98047183 quest>");
>
> On server I open an input source thus:
> InputSource is = new InputSource(socket.getInputStream());
>
> and then call my JDOM method:
>
> jdh.saxDoc(is, out);
>
> Method is as follows:
>
> public void saxDoc (InputSource is, PrintWriter out) throws
> IOException,
> JDOMException {
> SAXBuilder builder = new SAXBuilder(false);
> Document doc = builder.build(is);
> }
>
> However, this just hangs and never appears to finish
> building. I think I
> must be using InputSource incorrectly or something.
> Can anybody help?
>
> Thanks in advance,
> Steve
>
> --------------------------------------------------------------
> --------------
> -------------------------
> Steve Beech
> Tel: 0116
> 207 8162
> Software Developer e-mail:
> jbeech@dmu.ac.uk
> Room 0.36 Portland Building e-mail: steve@monkey-media.co.uk
> De Montfort University
> The Gateway, Leicester LE1 9BH
> --------------------------------------------------------------
> --------------
> ------------------------
>
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@yourhost.com
From arosen at silverstream.com Tue Feb 19 08:19:22 2002
From: arosen at silverstream.com (Alex Rosen)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Merging text nodes
In-Reply-To: <200202170444.VAA03670@dorothy.denveronline.net>
Message-ID: <000d01c1b961$31e768a0$6a65810a@silverstream.com>
I never thought that merging text nodes under the covers was a particularly
important feature. It probably wouldn't happen very often; it adds
complexity to the code; and anyone that actually cares can just do it
themselves.
> The kicker is add(int,Object),
> for example
>
> element.addContent( new Element("e1")); // index = 0
> element.addContent( new Text("This is a test")); // index = 1
> element.addContent( new Element("e2")); // index = 2
> List list = element.getContent();
> list = element.add(2, new Text(", only a test");
>
> with Text nodes merged then list.get(2) yields e2 instead of a Text node.
> But I can live with that if others can.
I think this might be a problem... suppose you were iterating over the
children, adding or removing nodes? Presumably set() and remove() would also
merge newly-adjacent text nodes, which could cause the following (weird, but
legal) code to fail:
List content = element.getContent();
int count = content.size();
for (int i = 0; i < count; i++)
content.set(i, "text");
It also violates the contract of the List interface: the JavaDoc for
add(int, Object) says "Shifts the element currently at that position (if
any) and any subsequent elements to the right (adds one to their indices)."
And similarly for remove(int).
Alex Rosen
alex@silverstream.com
From hip at a.cs.okstate.edu Tue Feb 19 08:55:47 2002
From: hip at a.cs.okstate.edu (Bradley S. Huffman)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Merging text nodes
In-Reply-To: Your message of "Tue, 19 Feb 2002 11:19:22 EST."
<000d01c1b961$31e768a0$6a65810a@silverstream.com>
Message-ID: <200202191657.JAA27271@dorothy.denveronline.net>
Alex Rosen writes:
> I think this might be a problem... suppose you were iterating over the
> children, adding or removing nodes? Presumably set() and remove() would also
> merge newly-adjacent text nodes, which could cause the following (weird, but
> legal) code to fail:
Or just iterating over the content in general, take the sequence Text, Element,
Text. If during the interation you do a remove() on Element, what does
previous() and next() return? The Text node before Element, the two Text nodes
merged. The more I think of it, anymore automatic merging not might not be
such a good idea.
Brad
From dms at sosnoski.com Tue Feb 19 09:44:15 2002
From: dms at sosnoski.com (Dennis Sosnoski)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Merging text nodes
References: <000d01c1b961$31e768a0$6a65810a@silverstream.com>
Message-ID: <3C728EEF.6090201@sosnoski.com>
I agree with Alex that the auto-magical text merging behavior can create
problems. Why not use a normalize()-type method to handle this (which
could even be in a support class, rather than in the core classes)? That
way the code complexity is reduced and there's no overhead for checking
possible merges unless the user actually makes the request.
- Dennis
Alex Rosen wrote:
>I never thought that merging text nodes under the covers was a particularly
>important feature. It probably wouldn't happen very often; it adds
>complexity to the code; and anyone that actually cares can just do it
>themselves.
>
>>The kicker is add(int,Object),
>>for example
>>
>> element.addContent( new Element("e1")); // index = 0
>> element.addContent( new Text("This is a test")); // index = 1
>> element.addContent( new Element("e2")); // index = 2
>> List list = element.getContent();
>> list = element.add(2, new Text(", only a test");
>>
>>with Text nodes merged then list.get(2) yields e2 instead of a Text node.
>>But I can live with that if others can.
>>
>
>I think this might be a problem... suppose you were iterating over the
>children, adding or removing nodes? Presumably set() and remove() would also
>merge newly-adjacent text nodes, which could cause the following (weird, but
>legal) code to fail:
>
>List content = element.getContent();
>int count = content.size();
>for (int i = 0; i < count; i++)
> content.set(i, "text");
>
>It also violates the contract of the List interface: the JavaDoc for
>add(int, Object) says "Shifts the element currently at that position (if
>any) and any subsequent elements to the right (adds one to their indices)."
>And similarly for remove(int).
>
>Alex Rosen
>alex@silverstream.com
>
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
From bob at werken.com Tue Feb 19 10:09:39 2002
From: bob at werken.com (bob mcwhirter)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Merging text nodes
In-Reply-To: <3C728EEF.6090201@sosnoski.com>
Message-ID:
On Tue, 19 Feb 2002, Dennis Sosnoski wrote:
> I agree with Alex that the auto-magical text merging behavior can create
> problems. Why not use a normalize()-type method to handle this (which
> could even be in a support class, rather than in the core classes)? That
> way the code complexity is reduced and there's no overhead for checking
> possible merges unless the user actually makes the request.
I agree whole-heartedly with this recommendation.
If anything is done dynamically, on-the-fly, then programatically
constructed documents may undergo an 'optimization' run after
each modification. I think it's best to externalize this functionality,
and let the developer decide when/if this should be done.
Possibly, add a switch to the FooBuilders (or make it default) to
use the normalization after the document is built.
Any sort of piece-wise normalization will cause fits, and it'll
be difficult to know when document construction is 'done' without
the aide of the developer building the document.
-bob
From jhunter at acm.org Tue Feb 19 10:25:56 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] jdom and jdk1.4: EntityResolver no longer called
References: <72FF4438.1ED838F9.0091AE98@netscape.net>
Message-ID: <3C7298B4.68539465@acm.org>
I was hoping someone else with more information might write to help
you. But since they haven't, I'll say what I can.
I would look into what parser JDK 1.4 is using. I suspect it's some
version of Crimson as selected by JAXP since JAXP is now in the JDK.
Write the list when you find out since it'll be good for us to know.
Then I'd look into if that Crimson version has any known problems like
this, and I'd file a bug if they don't already know. We can help you
with that.
Finally, if it is a parser bug as I suspect, then I'd change parsers to
Xerces either by using the JAXP API to select Xerces, or you can use
SAXBuilder itself to select Xerces. SAXBuilder by default uses JAXP to
select a parser, but you can choose explicitly.
I suggest you investigate JDK 1.4 because this will hit other people, so
hopefully we can understand the issue and not just go straight to
avoidance.
-jh-
abrighto@netscape.net wrote:
>
> Hi all,
>
> The new jdk1.4 runtime library now contains the org.xml packages,
> which kind of forces you to use them, it seems (I was previously
> using xerces.jar).
>
> Since upgrading to jdk1.4, I am having problems with DTDs not being
> resolved. The problem is that the EntityResolver is not being called.
> The error message is then:
>
> "Relative URI "UIInfo.dtd"; can not be resolved without a base URI"
>
> Here is the related code. Any ideas on how to make this work with jdk1.4?
>
> /** Parse the XML document */
> private static void _parseDocument(BufferedReader in) {
> SAXBuilder builder = new SAXBuilder(true);
> builder.setEntityResolver(new EntityResolver() {
> public InputSource resolveEntity (String publicId, String systemId) {
> URL url = Resources.getResource("UIInfo.dtd");
> try {
> return new InputSource(url.openStream());
> }
> catch(Exception e) {
> throw new RuntimeException("Error resolving entity: " +
> publicId + ": " + e.toString());
> }
> }
> });
>
> try {
> Document doc = builder.build(in);
> Element rootElement = doc.getRootElement();
> Iterator it = rootElement.getChildren().listIterator();
> while(it.hasNext()) {
> Element e = (Element)it.next();
> _parseElement(e);
> }
> }
> catch (JDOMException ex) {
> ex.printStackTrace();
> throw new RuntimeException("Error reading " + XML_FILE + ": " + ex.getMessage());
> }
> }
>
> Thanks,
> Allan Brighton
>
> --
>
> __________________________________________________________________
> Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/
>
> Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From jhunter at acm.org Tue Feb 19 10:29:13 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Merging text nodes
References:
Message-ID: <3C729979.23345D8A@acm.org>
> On Tue, 19 Feb 2002, Dennis Sosnoski wrote:
>
> > I agree with Alex that the auto-magical text merging behavior can create
> > problems. Why not use a normalize()-type method to handle this (which
> > could even be in a support class, rather than in the core classes)? That
> > way the code complexity is reduced and there's no overhead for checking
> > possible merges unless the user actually makes the request.
>
> I agree whole-heartedly with this recommendation.
I do also.
> If anything is done dynamically, on-the-fly, then programatically
> constructed documents may undergo an 'optimization' run after
> each modification. I think it's best to externalize this functionality,
> and let the developer decide when/if this should be done.
>
> Possibly, add a switch to the FooBuilders (or make it default) to
> use the normalization after the document is built.
We do normalize during SAXBuilder build time. That's because SAX's
characters() callback may be called dozens of times for a single text
block depending on the parser, so we use string buffers to piece them
together before creating a Text object. For DOMBuilder we do a direct
mapping to what was in DOM.
-jh-
From SOEREN.ARLETH at oracle.com Tue Feb 19 12:03:23 2002
From: SOEREN.ARLETH at oracle.com (soeren.arleth)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] jdom and jdk1.4: EntityResolver no longer called
Message-ID: <7199155.1014149003199.JavaMail.nobody@web155>
Hi,
just to add some information... Crimson it is.
Recently I installed 1.4.0 in which I have found the the following code. This shows for a fact what Jason suspected:
public static SAXParserFactory newInstance()
throws FactoryConfigurationError
{
try {
return (SAXParserFactory) FactoryFinder.find(
/* The default property name according to the JAXP spec */
"javax.xml.parsers.SAXParserFactory",
/* The fallback implementation class name */
"org.apache.crimson.jaxp.SAXParserFactoryImpl");
} catch (FactoryFinder.ConfigurationError e) {
throw new FactoryConfigurationError(e.getException(),
e.getMessage());
}
}
cheers
S?ren
___________________________________
Soeren Arleth - Oracle Denmark
SME Java Development
EMEA Java/XML Professional Community
I was hoping someone else with more information might write to help
you. But since they haven't, I'll say what I can.
I would look into what parser JDK 1.4 is using. I suspect it's some
version of Crimson as selected by JAXP since JAXP is now in the JDK.
Write the list when you find out since it'll be good for us to know.
Then I'd look into if that Crimson version has any known problems like
this, and I'd file a bug if they don't already know. We can help you
with that.
Finally, if it is a parser bug as I suspect, then I'd change parsers to
Xerces either by using the JAXP API to select Xerces, or you can use
SAXBuilder itself to select Xerces. SAXBuilder by default uses JAXP to
select a parser, but you can choose explicitly.
I suggest you investigate JDK 1.4 because this will hit other people, so
hopefully we can understand the issue and not just go straight to
avoidance.
-jh-
abrighto@netscape.net wrote:
>
> Hi all,
>
> The new jdk1.4 runtime library now contains the org.xml packages,
> which kind of forces you to use them, it seems (I was previously
> using xerces.jar).
>
> Since upgrading to jdk1.4, I am having problems with DTDs not being
> resolved. The problem is that the EntityResolver is not being called.
> The error message is then:
>
> "Relative URI "UIInfo.dtd"; can not be resolved without a base URI"
>
> Here is the related code. Any ideas on how to make this work with jdk1.4?
>
> /** Parse the XML document */
> private static void _parseDocument(BufferedReader in) {
> SAXBuilder builder = new SAXBuilder(true);
> builder.setEntityResolver(new EntityResolver() {
> public InputSource resolveEntity (String publicId, String systemId) {
> URL url = Resources.getResource("UIInfo.dtd");
> try {
> return new InputSource(url.openStream());
> }
> catch(Exception e) {
> throw new RuntimeException("Error resolving entity: " +
> publicId + ": " + e.toString());
> }
> }
> });
>
> try {
> Document doc = builder.build(in);
> Element rootElement = doc.getRootElement();
> Iterator it = rootElement.getChildren().listIterator();
> while(it.hasNext()) {
> Element e = (Element)it.next();
> _parseElement(e);
> }
> }
> catch (JDOMException ex) {
> ex.printStackTrace();
> throw new RuntimeException("Error reading " + XML_FILE + ": " + ex.getMessage());
> }
> }
>
> Thanks,
> Allan Brighton
>
> --
>
> __________________________________________________________________
> Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/
>
> Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020219/cf762469/attachment.htm
From SOEREN.ARLETH at oracle.com Tue Feb 19 12:04:17 2002
From: SOEREN.ARLETH at oracle.com (soeren.arleth)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] jdom and jdk1.4: EntityResolver no longer called
Message-ID: <4404619.1014149057482.JavaMail.nobody@web155>
Hi,
just to add some information... Crimson it is.
Recently I installed 1.4.0 in which I have found the the following code. This shows for a fact what Jason suspected:
public static SAXParserFactory newInstance()
throws FactoryConfigurationError
{
try {
return (SAXParserFactory) FactoryFinder.find(
/* The default property name according to the JAXP spec */
"javax.xml.parsers.SAXParserFactory",
/* The fallback implementation class name */
"org.apache.crimson.jaxp.SAXParserFactoryImpl");
} catch (FactoryFinder.ConfigurationError e) {
throw new FactoryConfigurationError(e.getException(),
e.getMessage());
}
}
cheers
S?ren
___________________________________
Soeren Arleth - Oracle Denmark
SME Java Development
EMEA Java/XML Professional Community
I was hoping someone else with more information might write to help
you. But since they haven't, I'll say what I can.
I would look into what parser JDK 1.4 is using. I suspect it's some
version of Crimson as selected by JAXP since JAXP is now in the JDK.
Write the list when you find out since it'll be good for us to know.
Then I'd look into if that Crimson version has any known problems like
this, and I'd file a bug if they don't already know. We can help you
with that.
Finally, if it is a parser bug as I suspect, then I'd change parsers to
Xerces either by using the JAXP API to select Xerces, or you can use
SAXBuilder itself to select Xerces. SAXBuilder by default uses JAXP to
select a parser, but you can choose explicitly.
I suggest you investigate JDK 1.4 because this will hit other people, so
hopefully we can understand the issue and not just go straight to
avoidance.
-jh-
abrighto@netscape.net wrote:
>
> Hi all,
>
> The new jdk1.4 runtime library now contains the org.xml packages,
> which kind of forces you to use them, it seems (I was previously
> using xerces.jar).
>
> Since upgrading to jdk1.4, I am having problems with DTDs not being
> resolved. The problem is that the EntityResolver is not being called.
> The error message is then:
>
> "Relative URI "UIInfo.dtd"; can not be resolved without a base URI"
>
> Here is the related code. Any ideas on how to make this work with jdk1.4?
>
> /** Parse the XML document */
> private static void _parseDocument(BufferedReader in) {
> SAXBuilder builder = new SAXBuilder(true);
> builder.setEntityResolver(new EntityResolver() {
> public InputSource resolveEntity (String publicId, String systemId) {
> URL url = Resources.getResource("UIInfo.dtd");
> try {
> return new InputSource(url.openStream());
> }
> catch(Exception e) {
> throw new RuntimeException("Error resolving entity: " +
> publicId + ": " + e.toString());
> }
> }
> });
>
> try {
> Document doc = builder.build(in);
> Element rootElement = doc.getRootElement();
> Iterator it = rootElement.getChildren().listIterator();
> while(it.hasNext()) {
> Element e = (Element)it.next();
> _parseElement(e);
> }
> }
> catch (JDOMException ex) {
> ex.printStackTrace();
> throw new RuntimeException("Error reading " + XML_FILE + ": " + ex.getMessage());
> }
> }
>
> Thanks,
> Allan Brighton
>
> --
>
> __________________________________________________________________
> Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/
>
> Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020219/52110f74/attachment.htm
From SOEREN.ARLETH at oracle.com Tue Feb 19 12:06:29 2002
From: SOEREN.ARLETH at oracle.com (soeren.arleth)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] jdom and jdk1.4: EntityResolver no longer called
Message-ID: <6879429.1014149189242.JavaMail.nobody@web155>
Hi,
just to add some information... Crimson it is.
Recently I installed 1.4.0 in which I have found the the following code. This shows for a fact what Jason suspected:
public static SAXParserFactory newInstance()
throws FactoryConfigurationError
{
try {
return (SAXParserFactory) FactoryFinder.find(
/* The default property name according to the JAXP spec */
"javax.xml.parsers.SAXParserFactory",
/* The fallback implementation class name */
"org.apache.crimson.jaxp.SAXParserFactoryImpl");
} catch (FactoryFinder.ConfigurationError e) {
throw new FactoryConfigurationError(e.getException(),
e.getMessage());
}
}
cheers
S?ren
___________________________________
Soeren Arleth - Oracle Denmark
SME Java Development
EMEA Java/XML Professional Community
I was hoping someone else with more information might write to help
you. But since they haven't, I'll say what I can.
I would look into what parser JDK 1.4 is using. I suspect it's some
version of Crimson as selected by JAXP since JAXP is now in the JDK.
Write the list when you find out since it'll be good for us to know.
Then I'd look into if that Crimson version has any known problems like
this, and I'd file a bug if they don't already know. We can help you
with that.
Finally, if it is a parser bug as I suspect, then I'd change parsers to
Xerces either by using the JAXP API to select Xerces, or you can use
SAXBuilder itself to select Xerces. SAXBuilder by default uses JAXP to
select a parser, but you can choose explicitly.
I suggest you investigate JDK 1.4 because this will hit other people, so
hopefully we can understand the issue and not just go straight to
avoidance.
-jh-
abrighto@netscape.net wrote:
>
> Hi all,
>
> The new jdk1.4 runtime library now contains the org.xml packages,
> which kind of forces you to use them, it seems (I was previously
> using xerces.jar).
>
> Since upgrading to jdk1.4, I am having problems with DTDs not being
> resolved. The problem is that the EntityResolver is not being called.
> The error message is then:
>
> "Relative URI "UIInfo.dtd"; can not be resolved without a base URI"
>
> Here is the related code. Any ideas on how to make this work with jdk1.4?
>
> /** Parse the XML document */
> private static void _parseDocument(BufferedReader in) {
> SAXBuilder builder = new SAXBuilder(true);
> builder.setEntityResolver(new EntityResolver() {
> public InputSource resolveEntity (String publicId, String systemId) {
> URL url = Resources.getResource("UIInfo.dtd");
> try {
> return new InputSource(url.openStream());
> }
> catch(Exception e) {
> throw new RuntimeException("Error resolving entity: " +
> publicId + ": " + e.toString());
> }
> }
> });
>
> try {
> Document doc = builder.build(in);
> Element rootElement = doc.getRootElement();
> Iterator it = rootElement.getChildren().listIterator();
> while(it.hasNext()) {
> Element e = (Element)it.next();
> _parseElement(e);
> }
> }
> catch (JDOMException ex) {
> ex.printStackTrace();
> throw new RuntimeException("Error reading " + XML_FILE + ": " + ex.getMessage());
> }
> }
>
> Thanks,
> Allan Brighton
>
> --
>
> __________________________________________________________________
> Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/
>
> Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020219/e5278bfb/attachment.htm
From SOEREN.ARLETH at oracle.com Tue Feb 19 12:09:23 2002
From: SOEREN.ARLETH at oracle.com (soeren.arleth)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] jdom and jdk1.4: EntityResolver no longer called
Message-ID: <6430546.1014149363275.JavaMail.nobody@web155>
Hi,
just to add some information... Crimson it is.
Recently I installed 1.4.0 in which I have found the the following code. This shows for a fact what Jason suspected:
public static SAXParserFactory newInstance()
throws FactoryConfigurationError
{
try {
return (SAXParserFactory) FactoryFinder.find(
/* The default property name according to the JAXP spec */
"javax.xml.parsers.SAXParserFactory",
/* The fallback implementation class name */
"org.apache.crimson.jaxp.SAXParserFactoryImpl");
} catch (FactoryFinder.ConfigurationError e) {
throw new FactoryConfigurationError(e.getException(),
e.getMessage());
}
}
cheers
S?ren
___________________________________
Soeren Arleth - Oracle Denmark
SME Java Development
EMEA Java/XML Professional Community
I was hoping someone else with more information might write to help
you. But since they haven't, I'll say what I can.
I would look into what parser JDK 1.4 is using. I suspect it's some
version of Crimson as selected by JAXP since JAXP is now in the JDK.
Write the list when you find out since it'll be good for us to know.
Then I'd look into if that Crimson version has any known problems like
this, and I'd file a bug if they don't already know. We can help you
with that.
Finally, if it is a parser bug as I suspect, then I'd change parsers to
Xerces either by using the JAXP API to select Xerces, or you can use
SAXBuilder itself to select Xerces. SAXBuilder by default uses JAXP to
select a parser, but you can choose explicitly.
I suggest you investigate JDK 1.4 because this will hit other people, so
hopefully we can understand the issue and not just go straight to
avoidance.
-jh-
abrighto@netscape.net wrote:
>
> Hi all,
>
> The new jdk1.4 runtime library now contains the org.xml packages,
> which kind of forces you to use them, it seems (I was previously
> using xerces.jar).
>
> Since upgrading to jdk1.4, I am having problems with DTDs not being
> resolved. The problem is that the EntityResolver is not being called.
> The error message is then:
>
> "Relative URI "UIInfo.dtd"; can not be resolved without a base URI"
>
> Here is the related code. Any ideas on how to make this work with jdk1.4?
>
> /** Parse the XML document */
> private static void _parseDocument(BufferedReader in) {
> SAXBuilder builder = new SAXBuilder(true);
> builder.setEntityResolver(new EntityResolver() {
> public InputSource resolveEntity (String publicId, String systemId) {
> URL url = Resources.getResource("UIInfo.dtd");
> try {
> return new InputSource(url.openStream());
> }
> catch(Exception e) {
> throw new RuntimeException("Error resolving entity: " +
> publicId + ": " + e.toString());
> }
> }
> });
>
> try {
> Document doc = builder.build(in);
> Element rootElement = doc.getRootElement();
> Iterator it = rootElement.getChildren().listIterator();
> while(it.hasNext()) {
> Element e = (Element)it.next();
> _parseElement(e);
> }
> }
> catch (JDOMException ex) {
> ex.printStackTrace();
> throw new RuntimeException("Error reading " + XML_FILE + ": " + ex.getMessage());
> }
> }
>
> Thanks,
> Allan Brighton
>
> --
>
> __________________________________________________________________
> Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/
>
> Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020219/6a042df8/attachment.htm
From niallsemail at yahoo.com Tue Feb 19 17:43:51 2002
From: niallsemail at yahoo.com (=?iso-8859-1?q?Niall=20Mcloughlin?=)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Definitive Schema validation in Beta 8
Message-ID: <20020220014351.18383.qmail@web14206.mail.yahoo.com>
What are the chances of getting some definitive
examples of validation against schema in the docs for
Beta 8 ? I know this is the realm of the parser, but
xerces.orgs doco isn't too handy and there seems to be
a need for it. Myself included.
Also, in-memory validation was a TODO for Beta 8, has
it been included ?
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
From jhunter at acm.org Tue Feb 19 17:53:24 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Definitive Schema validation in Beta 8
References: <20020220014351.18383.qmail@web14206.mail.yahoo.com>
Message-ID: <3C730194.C8157D40@acm.org>
Niall Mcloughlin wrote:
>
> What are the chances of getting some definitive
> examples of validation against schema in the docs for
> Beta 8 ? I know this is the realm of the parser, but
> xerces.orgs doco isn't too handy and there seems to be
> a need for it. Myself included.
If someone wants to write it up, it'd make a good FAQ entry.
> Also, in-memory validation was a TODO for Beta 8, has
> it been included ?
Nope, it's postponed.
-jh-
From jhunter at acm.org Tue Feb 19 18:46:45 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] getText() and getAttributeValue()
References: <89D72635F8AFD4118E5B00B0D06822561D6FB3@s-coengl-e02> <3C6D95B2.F716E617@acm.org> <3C70AD66.931AE42B@jentro.com>
Message-ID: <3C730E15.F84297A9@acm.org>
> Jason Hunter wrote:
> >
> > > Why is getXXX(key, defaultValue) so abhorrent? After seeing Jason Hunter's
> > > ParameterParserClass in Java Servlet Programming, which is chock-full of
> > > methods like this, how can one not appreciate the power and beauty of such a
> > > method?
> > >
> > > Todd Trimmer
> >
> > Todd knows how to help his cause with carefully placed suck ups. :-)
> >
> > But besides that, since Properties.getProperty(String, String) has set
> > the standard in Java land, I don't think it's unreasonable people will
> > know what getAttributeValue(String, String) does without reading docs.
>
> +1 for this suggestion. I have tons of parsing code that looks as
> cluttered as Todd's example -- I'd love to be able to replace it with
> the suggested change
>
> John Webber
I just checked in the change. Enjoy, John. :-)
-jh-
From kevinj at develop.com Wed Feb 20 06:59:49 2002
From: kevinj at develop.com (Kevin Jones)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] jdom and jdk1.4: EntityResolver no longer called
In-Reply-To: <72FF4438.1ED838F9.0091AE98@netscape.net>
Message-ID: <011501c1ba1f$3f5b5ff0$0200a8c0@develop.com>
You can tell JDOM which parser to use.
Try this
SAXBuilder sb = new SAXBuilder("org.apache.xerces.parsers.SAXParser",
true);
If you want to use Xerces2,
Kevin Jones
Developmentor
www.develop.com
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org] On Behalf Of
> abrighto@netscape.net
> Sent: 16 February 2002 22:53
> To: jdom-interest@jdom.org
> Subject: [jdom-interest] jdom and jdk1.4: EntityResolver no
> longer called
>
>
> Hi all,
>
> The new jdk1.4 runtime library now contains the org.xml packages,
> which kind of forces you to use them, it seems (I was previously
> using xerces.jar).
>
> Since upgrading to jdk1.4, I am having problems with DTDs not
> being resolved. The problem is that the EntityResolver is not
> being called. The error message is then:
>
> "Relative URI "UIInfo.dtd"; can not be resolved without a base URI"
>
> Here is the related code. Any ideas on how to make this work
> with jdk1.4?
>
> /** Parse the XML document */
> private static void _parseDocument(BufferedReader in) {
> SAXBuilder builder = new SAXBuilder(true);
> builder.setEntityResolver(new EntityResolver() {
> public InputSource resolveEntity (String publicId,
> String systemId) {
> URL url = Resources.getResource("UIInfo.dtd");
> try {
> return new InputSource(url.openStream());
> }
> catch(Exception e) {
> throw new RuntimeException("Error resolving entity: " +
> publicId + ": " + e.toString());
> }
> }
> });
>
> try {
> Document doc = builder.build(in);
> Element rootElement = doc.getRootElement();
> Iterator it = rootElement.getChildren().listIterator();
> while(it.hasNext()) {
> Element e = (Element)it.next();
> _parseElement(e);
> }
> }
> catch (JDOMException ex) {
> ex.printStackTrace();
> throw new RuntimeException("Error reading " +
> XML_FILE + ": " + ex.getMessage());
> }
> }
>
> Thanks,
> Allan Brighton
>
> --
>
>
>
>
> __________________________________________________________________
> Your favorite stores, helpful shopping tools and great gift
> ideas. Experience the convenience of buying online with
> Shop@Netscape! http://shopnow.netscape.com/
>
> Get your own FREE, personal Netscape Mail account today at
http://webmail.netscape.com/
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@you
rhost.com
From kevinj at develop.com Wed Feb 20 06:59:49 2002
From: kevinj at develop.com (Kevin Jones)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Definitive Schema validation in Beta 8
In-Reply-To: <20020220014351.18383.qmail@web14206.mail.yahoo.com>
Message-ID: <011601c1ba1f$40111b60$0200a8c0@develop.com>
As an example of getting JDOM to do schema validation
SAXBuilder sb = new SAXBuilder("org.apache.xerces.parsers.SAXParser",
true);
sb.setFeature("http://apache.org/xml/features/validation/schema", true);
sb.setProperty("http://apache.org/xml/properties/schema/external-schemaL
ocation",
"http://www.w3.org/2001/12/soap-envelope
http://localhost/blog/soap-envelope.xsd");
Document dom = sb.build(is);
If you want to pass more namespaces the name/value pairs are whitespace
separated, like this
sb.setProperty("http://apache.org/xml/properties/schema/external-schemaL
ocation",
"http://www.w3.org/2001/12/soap-envelope
http://localhost/blog/soap-envelope.xsd" + " " +
"http://kevinj.develop.com/weblog/weblog.xsd
http://localhost/blog/weblog.xsd");
Is there a standard format for the FAQ? Should I post it here or to
somebody privately?
Kevin Jones
Developmentor
www.develop.com
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org] On Behalf Of Niall Mcloughlin
> Sent: 20 February 2002 01:44
> To: jdom-interest@jdom.org
> Subject: [jdom-interest] Definitive Schema validation in Beta 8
>
>
> What are the chances of getting some definitive
> examples of validation against schema in the docs for
> Beta 8 ? I know this is the realm of the parser, but
> xerces.orgs doco isn't too handy and there seems to be a need
> for it. Myself included.
>
> Also, in-memory validation was a TODO for Beta 8, has
> it been included ?
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com >
_______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@yourhost.com
From joanr at k-os.com Wed Feb 20 07:15:30 2002
From: joanr at k-os.com (Joan Roch)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Bug in AttributeList.java
Message-ID: <200202201015300044.1F2500B8@mail.k-os.com>
--------------------------------------------------------------------------------
This bug report applies to:
JDOM-b8-dev - Checked out from CVS on Feb. 20, 2002
--------------------------------------------------------------------------------
I am not 100% sure the bug comes from AttributeList.java, but it's my best guess.
There seem to be a discrepancy between the reported number of Attributes in the list and the actual number of Attributes. None of my methods modify the AttributeList in any way. I don't see right any other explanation for such an Exception being thrown, but I don't have the knowledge to point out this bug, nor the time to acquire that knowledge :(
--------------------------------------------------------------------------------
The error is the following:
java.util.NoSuchElementException
at java.util.AbstractList$Itr.next(Unknown Source)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:190)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:212)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:212)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:212)
at com.ermis.html.XhtmlTemplate.(XhtmlTemplate.java:124)
at com.ermis.html.XhtmlPage.(XhtmlPage.java:68)
at TemplateTest.main(TemplateTest.java:22)
--------------------------------------------------------------------------------
Here is my code in XhtmlTemplate:
184: private void exploreElement(Element element) {
185: // we first explore the attributes of the current Element
186: List attributes = element.getAttributes();
187: Iterator attributeIterator = attributes.iterator();
188: while (attributeIterator.hasNext()) {
189 /* LOG */ logger.debug("*** Exploring: <" + element.getName() + "> " + attributes.size() + " attributes.");
190: Attribute attribute = (Attribute) attributeIterator.next();
191: // we check if the attribute is the special identifier
192: if (attribute.getName().equals(IDENTIFIER)) {
193: // special identifier - we store the current element for future reference
194: addIdentifiedElement(attribute.getValue(), element);
195: } else {
196: // normal attribute - we check if the attribute value contains a variable
197: REMatch[] variables = varRegExp.getAllMatches(attribute.getValue());
198: for (int i = 0; i < variables.length; i++) {
199: addVariableReference(variables[i].toString(1), attribute);
200: }
201: }
202: }
[..]
221: }
--------------------------------------------------------------------------------
The LOG file output:
0 [main] INFO TemplateTest - BasicConfigurator used.
160 [main] INFO com.ermis.html.XhtmlTemplate - Template found at 'file:/C:/Ermis/ermismail/templates/LinkTrackingHelper-list.xhtml'
771 [main] DEBUG com.ermis.html.XhtmlTemplate - Template 'file:/C:/Ermis/ermismail/templates/LinkTrackingHelper-list.xhtml' successfully parsed.
781 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: 0 attributes.
781 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: 0 attributes.
781 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: 0 attributes.
791 [main] DEBUG com.ermis.html.XhtmlTemplate - Reference to ${ermis.mailingId} found in 'org.jdom.Text'.
791 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <body> 0 attributes.
791 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <p> 0 attributes.
791 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <b> 0 attributes.
791 [main] DEBUG com.ermis.html.XhtmlTemplate - Reference to ${ermis.mailingId} found in 'org.jdom.Text'.
791 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <form> 2 attributes.
791 [main] DEBUG com.ermis.html.XhtmlTemplate - Reference to ${ermis.servlet} found in 'org.jdom.Attribute'.
791 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <ermis> 1 attributes.
801 [main] DEBUG com.ermis.html.XhtmlTemplate - <ermis ermis-id="trackable-link"> added.
java.util.NoSuchElementException
at java.util.AbstractList$Itr.next(Unknown Source)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:190)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:212)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:212)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:212)
at com.ermis.html.XhtmlTemplate.<init>(XhtmlTemplate.java:124)
at com.ermis.html.XhtmlPage.<init>(XhtmlPage.java:68)
at TemplateTest.main(TemplateTest.java:22)
--------------------------------------------------------------------------------
And the parsed XML file:
<html>
<head>
<title>Mailing ID: ${mailingId}
Mailing ID: ${mailingId}
--------------------------------------------------------------------------------
From joanr at k-os.com Wed Feb 20 07:30:06 2002
From: joanr at k-os.com (Joan Roch)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Bug in AttributeList.java - part 2
References: <200202201015300044.1F2500B8@mail.k-os.com>
Message-ID: <200202201030060625.1F3260DC@mail.k-os.com>
--------------------------------------------------------------------------------
This bug report applies to:
JDOM-b8-dev - Checked out from CVS on Feb. 20, 2002
--------------------------------------------------------------------------------
While trying to go around the supposed bug, I hit another one, most probably related, and that may help you pinpoint the problem in the AttributeList class.
There seem to be a discrepancy between the reported number of Attributes in the list and the actual number of Attributes. None of my methods modify the AttributeList in any way. I don't see right any other explanation for such an Exception being thrown, but I don't have the knowledge to point out this bug, nor the time to acquire that knowledge :(
--------------------------------------------------------------------------------
The error is the following:
java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
at java.util.ArrayList.RangeCheck(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at org.jdom.AttributeList.get(AttributeList.java:339)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:198)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
at com.ermis.html.XhtmlTemplate.(XhtmlTemplate.java:124)
at com.ermis.html.XhtmlPage.(XhtmlPage.java:68)
at TemplateTest.main(TemplateTest.java:22)
--------------------------------------------------------------------------------
Here is my modified code in XhtmlTemplate:
184: private void exploreElement(Element element) {
185: // we first explore the attributes of the current Element
186: List attributes = element.getAttributes();
187: /* LOG */ logger.debug("*** Exploring: <" + element.getName() + "> " + attributes.size() + " attributes.");
188:
189:// BUG IN JDOM - AttributeList - Original code
190:// Iterator attributeIterator = attributes.iterator();
191:// while (attributeIterator.hasNext()) {
192:// Attribute attribute = (Attribute) attributeIterator.next();
193:// BUG IN JDOM - AttributeList - Original code
194:
195:// BUG IN JDOM - AttributeList - Temporary solution
196: int attributesSize = attributes.size();
197: for (int index = 0; index < attributesSize; index++) {
198: Attribute attribute = (Attribute) attributes.get(index);
199:// BUG IN JDOM - AttributeList - Temporary solution
200:
201: // we check if the attribute is the special identifier
202: if (attribute.getName().equals(IDENTIFIER)) {
203: // special identifier - we store the current element for future reference
204: addIdentifiedElement(attribute.getValue(), element);
205: } else {
206: // normal attribute - we check if the attribute value contains a variable
207: REMatch[] variables = varRegExp.getAllMatches(attribute.getValue());
208: for (int i = 0; i < variables.length; i++) {
209: addVariableReference(variables[i].toString(1), attribute);
210: }
211: }
212: }
[..]
--------------------------------------------------------------------------------
The LOG file output:
171 [main] INFO com.ermis.html.XhtmlTemplate - Template found at 'file:/C:/Ermis/ermismail/templates/LinkTrackingHelper-list.xhtml'
832 [main] DEBUG com.ermis.html.XhtmlTemplate - Template 'file:/C:/Ermis/ermismail/templates/LinkTrackingHelper-list.xhtml' successfully parsed.
832 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: 0 attributes.
842 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: 0 attributes.
842 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: 0 attributes.
842 [main] DEBUG com.ermis.html.XhtmlTemplate - Reference to ${ermis.mailingId} found in 'org.jdom.Text'.
842 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <body> 0 attributes.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <p> 0 attributes.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <b> 0 attributes.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - Reference to ${ermis.mailingId} found in 'org.jdom.Text'.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <form> 2 attributes.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - Reference to ${ermis.servlet} found in 'org.jdom.Attribute'.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <ermis> 1 attributes.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - <ermis ermis-id="trackable-link"> added.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <table> 3 attributes.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - <table ermis-id="zling"> added.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <tr> 0 attributes.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <td> 1 attributes.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <small> 0 attributes.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - Reference to ${ermis.url} found in 'org.jdom.Text'.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <tr> 0 attributes.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <td> 1 attributes.
852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <input> 3 attributes.
862 [main] DEBUG com.ermis.html.XhtmlTemplate - Reference to ${ermis.i} found in 'org.jdom.Attribute'.
862 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <td> 3 attributes.
862 [main] DEBUG com.ermis.html.XhtmlTemplate - <td ermis-id="gronk"> added.
java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
at java.util.ArrayList.RangeCheck(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at org.jdom.AttributeList.get(AttributeList.java:339)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:198)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
at com.ermis.html.XhtmlTemplate.<init>(XhtmlTemplate.java:124)
at com.ermis.html.XhtmlPage.<init>(XhtmlPage.java:68)
at TemplateTest.main(TemplateTest.java:22)
--------------------------------------------------------------------------------
And the parsed XML file:
<html>
<head>
<title>Mailing ID: ${mailingId}
Mailing ID: ${mailingId}
--------------------------------------------------------------------------------
From hip at a.cs.okstate.edu Wed Feb 20 09:14:10 2002
From: hip at a.cs.okstate.edu (Bradley S. Huffman)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Bug in AttributeList.java - part 2
In-Reply-To: Your message of "Wed, 20 Feb 2002 10:30:06 EST."
<200202201030060625.1F3260DC@mail.k-os.com>
Message-ID: <200202201715.KAA17556@dorothy.denveronline.net>
I ran your xml file and looked at the Elements/Attributes created and
didn't see any problems with AttributeList.
What's the value of attributesSize at line 196? If it's not the same as
line 187, someone is modifing it somewhere. Try printing attributes.size()
after line 204 and 209 to make sure those 2 methods are not modifing
element.
You don't have multiple threads operating on the same document? JDOM methods
are not syncronized.
Brad
Joan Roch writes:
> -----------------------------------------------------------------------------
> ---
> This bug report applies to:
> JDOM-b8-dev - Checked out from CVS on Feb. 20, 2002
> -----------------------------------------------------------------------------
> ---
>
> While trying to go around the supposed bug, I hit another one, most probably
> related, and that may help you pinpoint the problem in the AttributeList clas
> s.
>
> There seem to be a discrepancy between the reported number of Attributes in t
> he list and the actual number of Attributes. None of my methods modify the At
> tributeList in any way. I don't see right any other explanation for such an E
> xception being thrown, but I don't have the knowledge to point out this bug,
> nor the time to acquire that knowledge :(
>
> -----------------------------------------------------------------------------
> ---
>
> The error is the following:
>
> java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
> at java.util.ArrayList.RangeCheck(Unknown Source)
> at java.util.ArrayList.get(Unknown Source)
> at org.jdom.AttributeList.get(AttributeList.java:339)
> at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:198)
> at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
> at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
> at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
> at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
> at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
> at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
> at com.ermis.html.XhtmlTemplate.(XhtmlTemplate.java:124)
> at com.ermis.html.XhtmlPage.(XhtmlPage.java:68)
> at TemplateTest.main(TemplateTest.java:22)
>
> -----------------------------------------------------------------------------
> ---
>
> Here is my modified code in XhtmlTemplate:
>
> 184: private void exploreElement(Element element) {
> 185: // we first explore the attributes of the current Element
> 186: List attributes = element.getAttributes();
> 187: /* LOG */ logger.debug("*** Exploring: <" + element.getName() + "> "
> + attributes.size() + " attributes.");
> 188:
> 189:// BUG IN JDOM - AttributeList - Original code
> 190:// Iterator attributeIterator = attributes.iterator();
> 191:// while (attributeIterator.hasNext()) {
> 192:// Attribute attribute = (Attribute) attributeIterator.next();
> 193:// BUG IN JDOM - AttributeList - Original code
> 194:
> 195:// BUG IN JDOM - AttributeList - Temporary solution
> 196: int attributesSize = attributes.size();
> 197: for (int index = 0; index < attributesSize; index++) {
> 198: Attribute attribute = (Attribute) attributes.get(index);
> 199:// BUG IN JDOM - AttributeList - Temporary solution
> 200:
> 201: // we check if the attribute is the special identifier
> 202: if (attribute.getName().equals(IDENTIFIER)) {
> 203: // special identifier - we store the current element for future r
> eference
> 204: addIdentifiedElement(attribute.getValue(), element);
> 205: } else {
> 206: // normal attribute - we check if the attribute value contains a
> variable
> 207: REMatch[] variables = varRegExp.getAllMatches(attribute.getValue(
> ));
> 208: for (int i = 0; i < variables.length; i++) {
> 209: addVariableReference(variables[i].toString(1), attribute);
> 210: }
> 211: }
> 212: }
> [..]
>
>
> -----------------------------------------------------------------------------
> ---
>
> The LOG file output:
>
> 171 [main] INFO com.ermis.html.XhtmlTemplate - Template found at 'file:/C:/E
> rmis/ermismail/templates/LinkTrackingHelper-list.xhtml'
> 832 [main] DEBUG com.ermis.html.XhtmlTemplate - Template 'file:/C:/Ermis/erm
> ismail/templates/LinkTrackingHelper-list.xhtml' successfully parsed.
> 832 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: 0 attr
> ibutes.
> 842 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: 0 attr
> ibutes.
> 842 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: 0 att
> ributes.
> 842 [main] DEBUG com.ermis.html.XhtmlTemplate - Reference to ${ermis.mailing
> Id} found in 'org.jdom.Text'.
> 842 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <body> 0 attr
> ibutes.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <p> 0 attribu
> tes.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <b> 0 attribu
> tes.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - Reference to ${ermis.mailing
> Id} found in 'org.jdom.Text'.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <form> 2 attr
> ibutes.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - Reference to ${ermis.servlet
> } found in 'org.jdom.Attribute'.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <ermis> 1 att
> ributes.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - <ermis ermis-id="trackable-l
> ink"> added.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <table> 3 att
> ributes.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - <table ermis-id="zling"> add
> ed.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <tr> 0 attrib
> utes.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <td> 1 attrib
> utes.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <small> 0 att
> ributes.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - Reference to ${ermis.url} fo
> und in 'org.jdom.Text'.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <tr> 0 attrib
> utes.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <td> 1 attrib
> utes.
> 852 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <input> 3 att
> ributes.
> 862 [main] DEBUG com.ermis.html.XhtmlTemplate - Reference to ${ermis.i} foun
> d in 'org.jdom.Attribute'.
> 862 [main] DEBUG com.ermis.html.XhtmlTemplate - *** Exploring: <td> 3 attrib
> utes.
> 862 [main] DEBUG com.ermis.html.XhtmlTemplate - <td ermis-id="gronk"> added.
> java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
> at java.util.ArrayList.RangeCheck(Unknown Source)
> at java.util.ArrayList.get(Unknown Source)
> at org.jdom.AttributeList.get(AttributeList.java:339)
> at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:198)
> at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
> at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
> at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
> at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
> at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
> at com.ermis.html.XhtmlTemplate.exploreElement(XhtmlTemplate.java:222)
> at com.ermis.html.XhtmlTemplate.<init>(XhtmlTemplate.java:124)
> at com.ermis.html.XhtmlPage.<init>(XhtmlPage.java:68)
> at TemplateTest.main(TemplateTest.java:22)
>
> -----------------------------------------------------------------------------
> ---
>
> And the parsed XML file:
>
> <html>
> <head>
> <title>Mailing ID: ${mailingId}
>
>
> Mailing ID: ${mailingId}
>
>
>
>
> -----------------------------------------------------------------------------
> ---
>
>
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost
> .com
From fooanny at yahoo.com Wed Feb 20 05:13:32 2002
From: fooanny at yahoo.com (Jared Checkley)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] make jtree use dtd to create xml
Message-ID: <000901c1ba10$65c29aa0$ca00a8c0@Jazzy>
Hi,
Is it possible to make a JTree behave according to a predefined DTD i.e.
I want to be able to add and edit nodes on the JTree, but only in a
manner consistent with the DTD? I then want XML to be generated from
that JTree. Any ideas how I go about this?
Cheers in advance,
Jared
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020220/f7abf599/attachment.htm
From sv3n at gmx.at Wed Feb 20 10:59:19 2002
From: sv3n at gmx.at (sv3n@gmx.at)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] DOCTYPE instruction & JDOMSource
Message-ID:
Hi!
Hope this is not too much of a newbie question here:
Having xstl templates containing the following xsl:output element:
I was hoping to receive a html file containing the specified doctype instruction.
This seems to work ok when directly transforming with xalan, using some code like this:
JDOMSource source = new JDOMSource(document);
Result result = new StreamResult(out);
transformer.transform(source, result);
When I instead of transforming directly to a StreamResult use a
JDOMResult und print the document using XMLOutputter:
JDOMSource source = new JDOMSource(document);
JDOMResult result = new JDOMResult();
transformer.transform(source, result);
XMLOutputter outputter = new XMLOutptutter(" ", true);
outputter.output(result.getDocument(), out);
Then the DOCTYPE instruction is missing in the resulting html.
Anybody, any clues for me ?
thanks,
gernot.
From jhunter at acm.org Wed Feb 20 11:51:29 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] DOCTYPE instruction & JDOMSource
References:
Message-ID: <3C73FE41.A819AD3B@acm.org>
Are you using the latest code in CVS?
-jh-
sv3n@gmx.at wrote:
>
> Hi!
>
> Hope this is not too much of a newbie question here:
>
> Having xstl templates containing the following xsl:output element:
>
> doctype-public="-//W3C//DTDHTML 4.0 Transitional//EN"
> doctype-system="http://www.w3.org/TR/REC-html4/loose.dtd" indent="yes"/>
>
> I was hoping to receive a html file containing the specified doctype instruction.
>
> This seems to work ok when directly transforming with xalan, using some code like this:
>
> JDOMSource source = new JDOMSource(document);
> Result result = new StreamResult(out);
> transformer.transform(source, result);
>
> When I instead of transforming directly to a StreamResult use a
> JDOMResult und print the document using XMLOutputter:
>
> JDOMSource source = new JDOMSource(document);
> JDOMResult result = new JDOMResult();
> transformer.transform(source, result);
> XMLOutputter outputter = new XMLOutptutter(" ", true);
> outputter.output(result.getDocument(), out);
>
> Then the DOCTYPE instruction is missing in the resulting html.
>
> Anybody, any clues for me ?
>
> thanks,
>
> gernot.
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From nostromo at arcor.de Wed Feb 20 12:49:47 2002
From: nostromo at arcor.de (nostromo@arcor.de)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] XSLT JDOM example Deadlock.
Message-ID: <3102331.1014238187340.JavaMail.nobody@saga>
Hi!
I am trying the whole day to get the example from http://www-106.ibm.com/developerworks/xml/library/x-tipjdom.html (using jdom and xslt
running).
The Thread deadlocks at the line with the command
xmlOutputter.output(sourceDoc, sourceOut);
(jdom 0.6, xalan2, and jdk 1.3)
Had anyone experienced similar things?
There are other sample solutions out there?
Pleace help.
Eryk.
-----------------------------------------------------------------------
Text: Riester-Rente - Kassieren Sie das Geld vom Staat:
Zum F?rderungsrechner! http://www.arcor.de/home/redir.php/riesterrente
-----------------------------------------------------------------------
From rpcee at operamail.com Mon Feb 18 08:35:20 2002
From: rpcee at operamail.com (rpcee)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] jdom run
Message-ID: <3C95D517@operamail.com>
It looks like you ran it with:
java SAXTest("NamHyData")
presumably should have been:
java SAXTest NamHyData
From johnf at goldsoft.com.au Wed Feb 20 15:44:57 2002
From: johnf at goldsoft.com.au (John)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Reading DTD error
Message-ID: <000001c1ba78$876d1780$1eb5fea9@honeysuckle>
Hi all
I have downloaded a DTD from the w3c web-site for MathML and XHTML:
http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd
When I attemt to parse a document using this DTD, I get an exception from org.jdom.input.SAXBuilder.build().
"Error in building: The markup declarations contained or pointed to by the document type declaration must be well-formed."
Any ideas? I assume this should be a valid DTD.
John
The stack trace gives:
org.jdom.JDOMException: Error in building: The markup declarations contained or pointed to by the document type declaration must be well-formed.
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:306)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:650)
at au.com.goldsoft.MathXHTML.MathXHTMLToJDOM.convert(MathXHTMLToJDOM.java:31)
at au.com.goldsoft.MathXHTML.EditorPane.processText(EditorPane.java:102)
at au.com.goldsoft.MathXHTML.EditorPane.processURL(EditorPane.java:124)
at au.com.goldsoft.MathXHTML.EditorPane.(EditorPane.java:92)
at au.com.goldsoft.MathXHTML.EditorPane.main(EditorPane.java:145)
Caused by: org.xml.sax.SAXException: The markup declarations contained or pointed to by the document type declaration must be well-formed.
at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:979)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:287)
... 6 more
Root cause: org.xml.sax.SAXException: The markup declarations contained or pointed to by the document type declaration must be well-formed.
at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:979)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:287)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:650)
at au.com.goldsoft.MathXHTML.MathXHTMLToJDOM.convert(MathXHTMLToJDOM.java:31)
at au.com.goldsoft.MathXHTML.EditorPane.processText(EditorPane.java:102)
at au.com.goldsoft.MathXHTML.EditorPane.processURL(EditorPane.java:124)
at au.com.goldsoft.MathXHTML.EditorPane.(EditorPane.java:92)
at au.com.goldsoft.MathXHTML.EditorPane.main(EditorPane.java:145)
Root cause: org.xml.sax.SAXException: The markup declarations contained or pointed to by the document type declaration must be well-formed.
at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:979)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:287)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:650)
at au.com.goldsoft.MathXHTML.MathXHTMLToJDOM.convert(MathXHTMLToJDOM.java:31)
at au.com.goldsoft.MathXHTML.EditorPane.processText(EditorPane.java:102)
at au.com.goldsoft.MathXHTML.EditorPane.processURL(EditorPane.java:124)
at au.com.goldsoft.MathXHTML.EditorPane.(EditorPane.java:92)
at au.com.goldsoft.MathXHTML.EditorPane.main(EditorPane.java:145)If I try to get a stack trace as well, the message is garbaged, thus:
If I try to print the exception message, and a stack trace, I get the following garbage:
Eorrrgo.rj dionm .bJuDiOlMdEixncge:p tTihoen :m aErrkruopr dienc lbaurialtdiionngs: cTohnet amianrekdu po rd epcolianrtaetdi otnos bcyo ntthaei ndeodc uomre npto itnytpeed dteoc lbayr atthieo nd omcuusmte nbte twyeplel -dfeocrlmaerda.t
ion must be well-formed.
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:306)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:650)
at au.com.goldsoft.MathXHTML.MathXHTMLToJDOM.convert(MathXHTMLToJDOM.java:31)
at au.com.goldsoft.MathXHTML.EditorPane.processText(EditorPane.java:102)
at au.com.goldsoft.MathXHTML.EditorPane.processURL(EditorPane.java:124)
at au.com.goldsoft.MathXHTML.EditorPane.(EditorPane.java:92)
at au.com.goldsoft.MathXHTML.EditorPane.main(EditorPane.java:145)
Caused by: org.xml.sax.SAXException: The markup declarations contained or pointed to by the document type declaration must be well-formed.
at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:979)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:287)
... 6 more
Root cause: org.xml.sax.SAXException: The markup declarations contained or pointed to by the document type declaration must be well-formed.
at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:979)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:287)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:650)
at au.com.goldsoft.MathXHTML.MathXHTMLToJDOM.convert(MathXHTMLToJDOM.java:31)
at au.com.goldsoft.MathXHTML.EditorPane.processText(EditorPane.java:102)
at au.com.goldsoft.MathXHTML.EditorPane.processURL(EditorPane.java:124)
at au.com.goldsoft.MathXHTML.EditorPane.(EditorPane.java:92)
at au.com.goldsoft.MathXHTML.EditorPane.main(EditorPane.java:145)
Root cause: org.xml.sax.SAXException: The markup declarations contained or pointed to by the document type declaration must be well-formed.
at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:979)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:287)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:650)
at au.com.goldsoft.MathXHTML.MathXHTMLToJDOM.convert(MathXHTMLToJDOM.java:31)
at au.com.goldsoft.MathXHTML.EditorPane.processText(EditorPane.java:102)
at au.com.goldsoft.MathXHTML.EditorPane.processURL(EditorPane.java:124)
at au.com.goldsoft.MathXHTML.EditorPane.(EditorPane.java:92)
at au.com.goldsoft.MathXHTML.EditorPane.main(EditorPane.java:145)
------------------------------------------------------------
Dr John Foster
GOLD SOFTWARE International Pty Ltd
P O Box 5033
Laburnum
Victoria 3130
Australia
Phone: 04 1173 7288
Fax: 03 9878 7844
e-mail: johnf@goldsoft.com.au
WWW: http://www.goldsoft.com.au
------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020221/633ffbca/attachment.htm
From Jacob.Robertson at argushealth.com Thu Feb 21 09:38:20 2002
From: Jacob.Robertson at argushealth.com (Robertson, Jacob)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] RE: Kevin Jones Example Schema Validation
Message-ID:
Hi Kevin,
I've been trying like crazy to get your example to work with the current
sources from cvs, and I keep running into a wall. Rather than me try to
ask this mailing list to solve my problems for me, would it be possible
for you to throw together a comprehensive example that includes complete
(but brief) Java code, and some actual xml and xsd files (small
examples) that we can put on our local drives? Something that is
guarranteed to run so everyone has a starting point. Just post the
contents of the 3 files, along with where we should put them to make the
example work.
Thanks,
Jacob.Robertson@argushealth.com
From gernot at kabsi.at Thu Feb 21 03:47:21 2002
From: gernot at kabsi.at (Gernot Koller)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] DOCTYPE instruction & JDOMSource
Message-ID: <200202211147.MAA22660@ns1.yeah.co.at>
jhunter@acm.org wrote:
> Are you using the latest code in CVS?
>
Sorry, forgot to tell what version I was using.
Originally I was working with JDOM Beta 7 binary build, but I took the
time and could verify the problem with todays CVS snapshot, too.
This is the code to reproduce the problem:
--------------------- 8< ------------------------------
import java.io.FileOutputStream;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.stream.StreamResult;
import javax.xml.transform.stream.StreamSource;
import org.jdom.Document;
import org.jdom.Element;
import org.jdom.output.XMLOutputter;
import org.jdom.transform.JDOMResult;
import org.jdom.transform.JDOMSource;
public class jdomtest
{
public static void main(String[] args)
{
try
{
FileOutputStream out =
new FileOutputStream("output.html");
Transformer transformer =
TransformerFactory.newInstance().newTransformer(
new StreamSource("stylesheet.xsl"));
Element root = new Element("root");
Document document = new Document(root);
JDOMSource source = new JDOMSource(document);
JDOMResult result = new JDOMResult();
transformer.transform(source, result);
XMLOutputter outputter = new XMLOutputter(" ", true);
outputter.output(result.getDocument(), out);
out.close();
StreamResult result2 = new StreamResult("output2.html");
transformer.transform(source, result2);
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
----------------------- 8< -----------------------
using the following stylesheet.xsl
----------------------- 8< -----------------------
Hello World!
----------------------- 8< -----------------------
resulting in two output files which should be equal to my opinion but
differ in the DOCTYPE instruction:
output.html:
----------------------- 8< -----------------------
Hello World!
----------------------- 8< -----------------------
output2.html:
----------------------- 8< -----------------------
hello World!
----------------------- 8< -----------------------
thanks,
gernot
From clewisf at us.ibm.com Thu Feb 21 15:00:44 2002
From: clewisf at us.ibm.com (Fred Clewis)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Alternatives to the Schema 'textEntity' idea
Message-ID:
Sorry if this is not particularly JDOM related, but perhaps a JDOM feature
can help.
I have a situation where an applications users configure the application
via several xml files. The values that the user would enter into the
various elements and attributes cry out for some kind of text substitution
facility that would allow common strings to be defined in one place.
The application has taken a turn towards schemas rather than DTDs so I
don't have the old parameter entity facility. In addition, hopes for
usage of the schemas 'textEntity' feature were dashed when I realized I was
looking at 1999 schema specs and it had been removed in 2001.
I realize that petty text substitution is frowned upon by XML purist, but
is there a mechanism for this? Also, does the JDOM entityResolver class
help here?
thanks for any ideas,
Fred Clewis
From jhunter at acm.org Thu Feb 21 21:24:53 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] cvs.jdom.org down
Message-ID: <3C75D625.E9937659@acm.org>
As some of you have noticed, cvs.jdom.org appears to be having disk
space issues. I notified Jools (our maintainer) earlier today and am
waiting to hear from him.
-jh-
From kevinj at develop.com Fri Feb 22 01:16:18 2002
From: kevinj at develop.com (Kevin Jones)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] RE: Kevin Jones Example Schema Validation
In-Reply-To:
Message-ID: <028301c1bb81$96fd9120$0200a8c0@develop.com>
I sent Jacob an example privately, I've just added the example to my web
site[1].
[1] http://kevinj.develop.com/jdom/validate.zip
Kevin Jones
Developmentor
www.develop.com
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org] On Behalf Of Robertson, Jacob
> Sent: 21 February 2002 17:38
> To: jdom-interest@jdom.org
> Subject: [jdom-interest] RE: Kevin Jones Example Schema Validation
>
>
> Hi Kevin,
>
> I've been trying like crazy to get your example to work with
> the current sources from cvs, and I keep running into a wall.
> Rather than me try to ask this mailing list to solve my
> problems for me, would it be possible for you to throw
> together a comprehensive example that includes complete (but
> brief) Java code, and some actual xml and xsd files (small
> examples) that we can put on our local drives? Something
> that is guarranteed to run so everyone has a starting point.
> Just post the contents of the 3 files, along with where we
> should put them to make the example work.
>
> Thanks,
>
> Jacob.Robertson@argushealth.com
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@yourhost.com
From karpov at sigma.ispras.ru Fri Feb 22 06:16:06 2002
From: karpov at sigma.ispras.ru (Eugene Karpov)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] External DTD
Message-ID: <200202221413.g1MEDqn26545@gate.ispras.ru>
How do I set external DTD to validate the specified XML before parsing via SAXBuilder?
--
B.R.
Eugene
From r0cker at hotmail.com Fri Feb 22 08:35:43 2002
From: r0cker at hotmail.com (Rocker Bill)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
Message-ID:
Hi,
Has anyone out there got any idea how to move subtrees within a document,
while maintaining the hierarchy structure of the subtree. I have managed to
recursively obtain a list of the children beneath an element, but am having
trouble placing these elements (as they were originally structured) beneath
a new element. It appears the setChildren( List inList) method does a one
layer placement and does not maintain the hierarchy - is this in fact the
case?? I guess I could recursively place these children below the new
element - but that seems like unnecessary overkill. Are there any better or
more appealing ways to attempt such a thing? Any quick suggestions or
comments would be welcome... as the hair on my head is rapidly thinning!
Chrs,
Ash
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
From jhunter at acm.org Fri Feb 22 10:12:45 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
References:
Message-ID: <3C768A1D.C8CE1B96@acm.org>
An element retains its children when it's moved, so I don't know what
problem you could be having. Just detach the element from its own
parent and splice it somewhere else, and all its children will tag along
for the ride.
If you think you spotted a bug, try the latest code from CVS (it's back
up).
-jh-
Rocker Bill wrote:
>
> Hi,
>
> Has anyone out there got any idea how to move subtrees within a document,
> while maintaining the hierarchy structure of the subtree. I have managed to
> recursively obtain a list of the children beneath an element, but am having
> trouble placing these elements (as they were originally structured) beneath
> a new element. It appears the setChildren( List inList) method does a one
> layer placement and does not maintain the hierarchy - is this in fact the
> case?? I guess I could recursively place these children below the new
> element - but that seems like unnecessary overkill. Are there any better or
> more appealing ways to attempt such a thing? Any quick suggestions or
> comments would be welcome... as the hair on my head is rapidly thinning!
>
> Chrs,
> Ash
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From Sullivan.Sean at menlolog.com Fri Feb 22 10:55:53 2002
From: Sullivan.Sean at menlolog.com (Sullivan, Sean C - MLG)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] JDOM and Apache Xerces-J 2.0.0
Message-ID: <7B73D5F649D0D311B1E30008C7A4D92A116D7532@cnfqs029.cnf.prod.cnf.com>
Is anybody using JDOM in conjunction with Apache Xerces-J 2.0.0?
http://xml.apache.org/xerces2-j/index.html
Xerces-J 2.0.0 was released in February 2002
Regards,
-Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020222/3130df50/attachment.htm
From elharo at metalab.unc.edu Fri Feb 22 11:04:42 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:24 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
In-Reply-To: <3C768A1D.C8CE1B96@acm.org>
References:
<3C768A1D.C8CE1B96@acm.org>
Message-ID:
At 10:12 AM -0800 2/22/02, Jason Hunter wrote:
>An element retains its children when it's moved, so I don't know what
>problem you could be having. Just detach the element from its own
>parent and splice it somewhere else, and all its children will tag along
>for the ride.
>
I think what he's asking for is something more akin to
DocumentFragfment in DOM; i.e. he doesn't want to move an Element. He
wants to move a sequence of three elements, two text nodes, a
comment, and perhaps a few more text nodes. You might be able to do
this using Lists. I'm not sure.
OK, I just looked at the JavaDoc and I don't think we can do that, at
least not in the most general case. I think what we'd need would be
an addContent(List) method. We have setContent(List) but not
addContent(list). You could do it in two steps by retrieving the
content of the element you wanted to put it in with getContent() and
then using the methods of the List interface.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From jhunter at acm.org Fri Feb 22 11:24:53 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] JDOM and Apache Xerces-J 2.0.0
References: <7B73D5F649D0D311B1E30008C7A4D92A116D7532@cnfqs029.cnf.prod.cnf.com>
Message-ID: <3C769B05.76D7440C@acm.org>
> Is anybody using JDOM in conjunction with Apache Xerces-J 2.0.0?
>
>
>
> http://xml.apache.org/xerces2-j/index.html
>
>
>
> Xerces-J 2.0.0 was released in February 2002
I did some testing with 2.0.0 and found some bugs (mostly involving DOM
I/O) which I filed in their bug database. See the TODO for a listing.
Brad also did performance testing and found that it slowed down on large
files, as compared to 1.4.4. For these two reasons we have 1.4.4 as the
current default.
I'd be curious if anyone else has experience?
-jh-
From jhunter at acm.org Fri Feb 22 11:26:34 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
References:
<3C768A1D.C8CE1B96@acm.org>
Message-ID: <3C769B6A.7E9FC6CD@acm.org>
Elliotte Rusty Harold wrote:
>
> At 10:12 AM -0800 2/22/02, Jason Hunter wrote:
> >An element retains its children when it's moved, so I don't know what
> >problem you could be having. Just detach the element from its own
> >parent and splice it somewhere else, and all its children will tag along
> >for the ride.
> >
>
> I think what he's asking for is something more akin to
> DocumentFragfment in DOM; i.e. he doesn't want to move an Element. He
> wants to move a sequence of three elements, two text nodes, a
> comment, and perhaps a few more text nodes. You might be able to do
> this using Lists. I'm not sure.
>
> OK, I just looked at the JavaDoc and I don't think we can do that, at
> least not in the most general case. I think what we'd need would be
> an addContent(List) method. We have setContent(List) but not
> addContent(list). You could do it in two steps by retrieving the
> content of the element you wanted to put it in with getContent() and
> then using the methods of the List interface.
Kind of like:
elt.getContent().addAll(otherelt.getContent())
Except the content being moved will have parents so this won't work
exactly. You'll have to iterate over them and detach each before the
move. Might as well just set up an iterator and do a detach/add for
each right there.
-jh-
From joanr at k-os.com Fri Feb 22 11:36:30 2002
From: joanr at k-os.com (Joan Roch)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
In-Reply-To: <3C769B6A.7E9FC6CD@acm.org>
References:
<3C768A1D.C8CE1B96@acm.org>
<3C769B6A.7E9FC6CD@acm.org>
Message-ID: <200202221436300056.2A60ACA3@mail.k-os.com>
>Kind of like:
>
>elt.getContent().addAll(otherelt.getContent())
>
>Except the content being moved will have parents so this won't work
>exactly. You'll have to iterate over them and detach each before the
>move. Might as well just set up an iterator and do a detach/add for
>each right there.
This implies to identify each object (using "instanceof") in the list and then cast thoses objects into their specific classes because detach() is not defined in an interface common to each Object found in a JDOM tree... sigh. Maybe it would be a good idea to define an interface for all those objects that can be found in a JDOM tree.
Regards,
Joan
From jhunter at acm.org Fri Feb 22 12:08:51 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
References:
<3C768A1D.C8CE1B96@acm.org>
<3C769B6A.7E9FC6CD@acm.org> <200202221436300056.2A60ACA3@mail.k-os.com>
Message-ID: <3C76A553.AB429AE9@acm.org>
Joan Roch wrote:
>
> >Kind of like:
> >
> >elt.getContent().addAll(otherelt.getContent())
> >
> >Except the content being moved will have parents so this won't work
> >exactly. You'll have to iterate over them and detach each before the
> >move. Might as well just set up an iterator and do a detach/add for
> >each right there.
>
> This implies to identify each object (using "instanceof") in the list and then cast thoses objects into their specific classes because detach() is not defined in an interface common to each Object found in a JDOM tree... sigh. Maybe it would be a good idea to define an interface for all those objects that can be found in a JDOM tree.
Yes, this is one situation where that would be really nice. But I'm too
busy to start that debate again just now.
-jh-
From kevinj at develop.com Fri Feb 22 14:55:48 2002
From: kevinj at develop.com (Kevin Jones)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] JDOM and Apache Xerces-J 2.0.0
In-Reply-To: <3C769B05.76D7440C@acm.org>
Message-ID: <034001c1bbf4$12c4db70$0200a8c0@develop.com>
I'm using a CVS build of JDOM against Xerces 2 (I wanted the better
Schema support in 2).
I've not done any perf tests so I can't comment but it's coped with
everything I've thrown at it so far (which isn't a great deal yet),
Kevin Jones
Developmentor
www.develop.com
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org] On Behalf Of Jason Hunter
> Sent: 22 February 2002 19:25
> To: Sullivan, Sean C - MLG
> Cc: 'jdom-interest@jdom.org'
> Subject: Re: [jdom-interest] JDOM and Apache Xerces-J 2.0.0
>
>
> > Is anybody using JDOM in conjunction with Apache Xerces-J 2.0.0?
> >
> >
> >
> > http://xml.apache.org/xerces2-j/index.html
> >
> >
> >
> > Xerces-J 2.0.0 was released in February 2002
>
> I did some testing with 2.0.0 and found some bugs (mostly
> involving DOM
> I/O) which I filed in their bug database. See the TODO for a
> listing.
> Brad also did performance testing and found that it slowed
> down on large files, as compared to 1.4.4. For these two
> reasons we have 1.4.4 as the current default.
>
> I'd be curious if anyone else has experience?
>
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@yourhost.com
From r0cker at hotmail.com Sat Feb 23 00:36:25 2002
From: r0cker at hotmail.com (Rocker Bill)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
Message-ID:
Hi,
Without getting myself too lost, I am trying to move a sequence of elements
with associated content from one top level parent to another, within the
same document... such as...
In the above case, I want to move the subtree containing ele2 and ele3 from
the parent, ele1, to beneath the new parent ele4 (ele2 and ele3 will also
have associated content).
It sounds like what you guys are suggesting is what I am after. From my
limited understanding of the clone() method... it just clones one element
and not the entire subtree below an element too(??)... so I guess an
iterative approach would be most logical -- using Lists(??).
Am I correct to assume, you are suggesting to recursively collect the
children from the old parent within a List, then recursively add each
element under the new parent (detaching every element from the original
parent along the way)?? Then just use oldParentEle.removeChildren() to
remove the previous subtree structure from the original parent element? To
sound naive, what would you suggest as the best way to maintain the original
hierarchy of the subtree under the new parent element?? -- Or am I
completely off the path you are both discussing?
Chrs,
Ash
>From: Jason Hunter
>To: Elliotte Rusty Harold
>CC: Rocker Bill , jdom-interest@jdom.org
>Subject: Re: [jdom-interest] Moving Subtrees using JDOM
>Date: Fri, 22 Feb 2002 11:26:34 -0800
>
>Elliotte Rusty Harold wrote:
> >
> > At 10:12 AM -0800 2/22/02, Jason Hunter wrote:
> > >An element retains its children when it's moved, so I don't know what
> > >problem you could be having. Just detach the element from its own
> > >parent and splice it somewhere else, and all its children will tag
>along
> > >for the ride.
> > >
> >
> > I think what he's asking for is something more akin to
> > DocumentFragfment in DOM; i.e. he doesn't want to move an Element. He
> > wants to move a sequence of three elements, two text nodes, a
> > comment, and perhaps a few more text nodes. You might be able to do
> > this using Lists. I'm not sure.
> >
> > OK, I just looked at the JavaDoc and I don't think we can do that, at
> > least not in the most general case. I think what we'd need would be
> > an addContent(List) method. We have setContent(List) but not
> > addContent(list). You could do it in two steps by retrieving the
> > content of the element you wanted to put it in with getContent() and
> > then using the methods of the List interface.
>
>Kind of like:
>
>elt.getContent().addAll(otherelt.getContent())
>
>Except the content being moved will have parents so this won't work
>exactly. You'll have to iterate over them and detach each before the
>move. Might as well just set up an iterator and do a detach/add for
>each right there.
>
>-jh-
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
From jhunter at acm.org Sat Feb 23 00:53:16 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
References:
Message-ID: <3C77587C.5BC7950@acm.org>
Rocker Bill wrote:
>
> Hi,
>
> Without getting myself too lost, I am trying to move a sequence of elements
> with associated content from one top level parent to another, within the
> same document... such as...
>
>
>
>
>
>
>
>
>
>
>
> In the above case, I want to move the subtree containing ele2 and ele3 from
> the parent, ele1, to beneath the new parent ele4 (ele2 and ele3 will also
> have associated content).
ele4.addContent(ele2.detach());
That should be all you need. ele2 will take his children. We're
talking about if you want to move ele1 and ele4 (siblings) to a
different root that you have to do it iteratively.
-jh-
From r0cker at hotmail.com Sat Feb 23 01:41:00 2002
From: r0cker at hotmail.com (Rocker Bill)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
Message-ID:
Thanks - works sweetly.
>From: Jason Hunter
>To: Rocker Bill
>CC: elharo@metalab.unc.edu, jdom-interest@jdom.org
>Subject: Re: [jdom-interest] Moving Subtrees using JDOM
>Date: Sat, 23 Feb 2002 00:53:16 -0800
>
>Rocker Bill wrote:
> >
> > Hi,
> >
> > Without getting myself too lost, I am trying to move a sequence of
>elements
> > with associated content from one top level parent to another, within the
> > same document... such as...
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > In the above case, I want to move the subtree containing ele2 and ele3
>from
> > the parent, ele1, to beneath the new parent ele4 (ele2 and ele3 will
>also
> > have associated content).
>
>ele4.addContent(ele2.detach());
>
>That should be all you need. ele2 will take his children. We're
>talking about if you want to move ele1 and ele4 (siblings) to a
>different root that you have to do it iteratively.
>
>-jh-
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
From noamt at yahoo.com Sat Feb 23 05:57:26 2002
From: noamt at yahoo.com (Noam Tamim)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
In-Reply-To: <3C76A553.AB429AE9@acm.org>
Message-ID: <20020223135726.49634.qmail@web13903.mail.yahoo.com>
--- Jason Hunter wrote:
> > >elt.getContent().addAll(otherelt.getContent())
> > This implies to identify each object (using "instanceof") in the list and
> then cast thoses objects into their specific classes because detach() is
> not defined in an interface common to each Object found in a JDOM tree...
> sigh. Maybe it would be a good idea to define an interface for all those
> objects that can be found in a JDOM tree.
> Yes, this is one situation where that would be really nice. But I'm too
> busy to start that debate again just now.
So how about adding the suggested elt.addContent(List) that will iterate over
that list, do all the casts needed, detach whatever needs detaching, then add
it to elt?
Should be a simple method, I think. Only thing to consider is if it should be
a method of Element, or a utility method in jdom.contrib.
=====
Noam.
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
From elharo at metalab.unc.edu Sat Feb 23 09:09:28 2002
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
In-Reply-To: <20020223135726.49634.qmail@web13903.mail.yahoo.com>
References: <20020223135726.49634.qmail@web13903.mail.yahoo.com>
Message-ID:
At 5:57 AM -0800 2/23/02, Noam Tamim wrote:
>So how about adding the suggested elt.addContent(List) that will iterate over
>
>that list, do all the casts needed, detach whatever needs detaching, then add
>it to elt?
>Should be a simple method, I think. Only thing to consider is if it should be
>a method of Element, or a utility method in jdom.contrib.
>
Either way, this is tricky. For instance, what if something in the
list doesn't need to be detached?
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
From jhunter at acm.org Sat Feb 23 10:59:30 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
References: <20020223135726.49634.qmail@web13903.mail.yahoo.com>
Message-ID: <3C77E692.91A3C960@acm.org>
Elliotte Rusty Harold wrote:
>
> At 5:57 AM -0800 2/23/02, Noam Tamim wrote:
>
> >So how about adding the suggested elt.addContent(List) that will iterate over
> >
> >that list, do all the casts needed, detach whatever needs detaching, then add
> >it to elt?
> >Should be a simple method, I think. Only thing to consider is if it should be
> >a method of Element, or a utility method in jdom.contrib.
> >
>
> Either way, this is tricky. For instance, what if something in the
> list doesn't need to be detached?
Well, detach() is a no-op for parentless objects.
The downside with the auto-detach idea is that addContent(Element)
doesn't auto-detach and will throw if you try to add a parented object.
addContent(List) shouldn't behave differently. And my gut instinct is
addContent(Element) shouldn't be changed to remove children from
parents.
-jh-
From bob at werken.com Sat Feb 23 12:45:01 2002
From: bob at werken.com (bob mcwhirter)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
In-Reply-To: <3C77E692.91A3C960@acm.org>
Message-ID:
> The downside with the auto-detach idea is that addContent(Element)
> doesn't auto-detach and will throw if you try to add a parented object.
> addContent(List) shouldn't behave differently. And my gut instinct is
> addContent(Element) shouldn't be changed to remove children from
> parents.
I disagree.
I've seen naive programmer create an Element, and then attempt to
re-use it (across threads, or whatnot) and attach it to multiple
documents. With the exception, the problem became clear rather
quickly. Without an exception, using auto-reparenting, you'd
simply end up with documents that didn't contain the Element
you thought you'd added (and never explicitly removed).
-bob
From noamt at yahoo.com Sat Feb 23 14:50:01 2002
From: noamt at yahoo.com (Noam Tamim)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
In-Reply-To:
Message-ID: <20020223225001.97133.qmail@web13903.mail.yahoo.com>
--- Elliotte Rusty Harold wrote:
> >So how about adding the suggested elt.addContent(List) that will iterate
> Either way, this is tricky. For instance, what if something in the
> list doesn't need to be detached?
Well, after looking into it, this is what I came up with:
a. While iterating over a getContent() List, you shouldn't try to
detach() anything - the iterator's fail-safe policy will cause it
to throw a ConcurentModificationExcepion;
b. detach() is, as I understand it, merely a convenience method
that calls parent.remove(this) on the node; so if I iterate over
a live list, I don't even need it - I can simply use itr.remove().
c. Since I don't need detach() anymore, I don't need to do any
casting.
Therefore, a utility method that gets a live FilterList will look
something like this one:
public static void moveContent(List content, Element to) {
Iterator i=content.iterator();
List list=to.getContent();
while (i.hasNext()) {
Object o=i.next();
i.remove();
list.add(o);
}
}
The remaining problem is handling document fragments that are not
stored in one List (and may have different parents). It is not really
a problem - it can be solved quite easily in fact - the problem is
that one method can't deal with both cases. A method that, unlike
the above moveContent(), is given a random list of nodes, must cast
and call detach() on every item in it - but the detach must NOT be
from the same list (see point a above).
=====
Noam.
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
From bob at werken.com Sat Feb 23 21:24:37 2002
From: bob at werken.com (bob mcwhirter)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
In-Reply-To:
Message-ID:
Yah... I apparently read Jason's email too quickly (and
insufficiently). I read that he wanted to change addContent(Element)
to reparent, and stop throwing exceptions.
Mea culpa.
-bob
On Sat, 23 Feb 2002, Hallvard Tratteberg wrote:
> Bob,
>
> > > And my gut instinct is addContent(Element) shouldn't be changed
> > > to remove children from parents.
> >
> > I disagree.
> >
> > I've seen naive programmer create an Element, and then attempt to
> > re-use it (across threads, or whatnot) and attach it to multiple
> > documents. With the exception, the problem became clear rather
> > quickly. Without an exception, using auto-reparenting, you'd
> > simply end up with documents that didn't contain the Element
> > you thought you'd added (and never explicitly removed).
>
> Jason writes "addContent(Element) shouldn't be changed to remove children
> from parents". Isn't that what you also say? I read it that "Without an
> exception, using auto-reparenting, you'd simply end up with documents that
> didn't contain the Element you thought you'd added (and never explicitly
> removed)." is a bad thing, so you actually agree???
>
> Hallvard
>
From jhunter at acm.org Sat Feb 23 22:13:14 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
References: <20020223225001.97133.qmail@web13903.mail.yahoo.com>
Message-ID: <3C78847A.53D2CA12@acm.org>
Noam Tamim wrote:
>
> --- Elliotte Rusty Harold wrote:
> > >So how about adding the suggested elt.addContent(List) that will iterate
> > Either way, this is tricky. For instance, what if something in the
> > list doesn't need to be detached?
>
> Well, after looking into it, this is what I came up with:
> a. While iterating over a getContent() List, you shouldn't try to
> detach() anything - the iterator's fail-safe policy will cause it
> to throw a ConcurentModificationExcepion;
> b. detach() is, as I understand it, merely a convenience method
> that calls parent.remove(this) on the node; so if I iterate over
> a live list, I don't even need it - I can simply use itr.remove().
> c. Since I don't need detach() anymore, I don't need to do any
> casting.
Excellent point!
> Therefore, a utility method that gets a live FilterList will look
> something like this one:
> public static void moveContent(List content, Element to) {
> Iterator i=content.iterator();
> List list=to.getContent();
> while (i.hasNext()) {
> Object o=i.next();
> i.remove();
> list.add(o);
> }
> }
Good looking code.
> The remaining problem is handling document fragments that are not
> stored in one List (and may have different parents). It is not really
> a problem - it can be solved quite easily in fact - the problem is
> that one method can't deal with both cases. A method that, unlike
> the above moveContent(), is given a random list of nodes, must cast
> and call detach() on every item in it - but the detach must NOT be
> from the same list (see point a above).
Ah, filters will soon come to the rescue...
moveContent(elt.getContent(someFilterOnSubtree), to);
-jh-
From joan at ermis.com Sat Feb 23 11:15:21 2002
From: joan at ermis.com (Joan Roch)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
In-Reply-To: <3C77E692.91A3C960@acm.org>
References: <20020223135726.49634.qmail@web13903.mail.yahoo.com>
<3C77E692.91A3C960@acm.org>
Message-ID: <200202231415210607.03BF81BA@mail.ermis.com>
Hi,
As I said before, but apparently there is a debate lurking in there, the best solution, IMHO, would be to have a common interface for Element, Text, CDATA, etc. where the detach() method would be defined (among a few others). This would greatly simplify the casting operation in the loop over the List, and add some structure to the API.
The impact would be null, and the benefits quite interesting. And the interface could be written in just a few minutes.
But then again, I have been told that the debate shouldn't be started all over again... :)
Regards,
Joan
*********** REPLY SEPARATOR ***********
On 2002-02-23 at 10:59 Jason Hunter wrote:
>Elliotte Rusty Harold wrote:
>>
>> At 5:57 AM -0800 2/23/02, Noam Tamim wrote:
>>
>> >So how about adding the suggested elt.addContent(List) that will
>iterate over
>> >
>> >that list, do all the casts needed, detach whatever needs detaching,
>then add
>> >it to elt?
>> >Should be a simple method, I think. Only thing to consider is if it
>should be
>> >a method of Element, or a utility method in jdom.contrib.
>> >
>>
>> Either way, this is tricky. For instance, what if something in the
>> list doesn't need to be detached?
>
>Well, detach() is a no-op for parentless objects.
>
>The downside with the auto-detach idea is that addContent(Element)
>doesn't auto-detach and will throw if you try to add a parented object.
>addContent(List) shouldn't behave differently. And my gut instinct is
>addContent(Element) shouldn't be changed to remove children from
>parents.
>
>-jh-
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From MDoraisamy at SELECTICA.com Sat Feb 23 22:34:36 2002
From: MDoraisamy at SELECTICA.com (Mani Doraisamy)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] JDOM and XSLT
Message-ID:
Hi all,
What is the fastest XSLT processor available in market. I am
using JDOM and I would like to do XSLT so that I can present
it as HTML.
Another question,
my JDOM structure is huge and the Elements in the structure
actually gets the value from performance intensive calculations
and database operations, by overriding getText() method. Now
when i want to do XSLT i wouldnt want the entire tree for XSLT.
Although i can pass the whole tree for XSLT, what is the most
performant way of doing XSLT for the subtree?
mani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020224/6295a3b9/attachment.htm
From noamt at yahoo.com Sun Feb 24 01:34:43 2002
From: noamt at yahoo.com (Noam Tamim)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Moving Subtrees using JDOM
In-Reply-To: <3C78847A.53D2CA12@acm.org>
Message-ID: <20020224093443.98667.qmail@web13904.mail.yahoo.com>
--- Jason Hunter wrote:
> > Therefore, a utility method that gets a live FilterList will look
> > something like this one:
> > public static void moveContent(List content, Element to) {
...
> > The remaining problem is handling document fragments that are not
> > stored in one List (and may have different parents). It is not really
> > a problem - it can be solved quite easily in fact - the problem is
> > that one method can't deal with both cases. A method that, unlike
> > the above moveContent(), is given a random list of nodes, must cast
> > and call detach() on every item in it - but the detach must NOT be
> > from the same list (see point a above).
>
> Ah, filters will soon come to the rescue...
I'm not sure they will solve everything. The Filter.match(Object)
method, as I understand, works like the FileFilter.accept(File)
method. So if all objects (strings, elements, etc.) come from
the same FilterList, it'll work fine - for example, if I want
to move all elements that contain "foo" in their name, it'll be
easy to do it;
But in the case mentioned above, it won't work -
I want (do I? maybe nobody needs to do it anyway) to be able
to pass a List of objects from different sources, detach them
from their parents, and have them adopted by another. If the List
passed to the method is NOT a FilterList, this method will do:
public static void moveObjects(List objects, Element to) {
Iterator i=objects.iterator();
List list=to.getContent();
while (i.hasNext()) {
list.add(detach(i.next()));
// detach(Object) is yet another simple utility method,
// that does instanceof checks, casts, and detaches.
}
}
Thing is, it is very important that the first moveContent() will
be passed a FilterList, while the second moveObjects() is passed
a (non-Filter)List. A way of enforcing it is asking if the list
is a ContentList.FilterList, but that can only be done by members
of org.jdom, not by external utility methods.
=====
Noam.
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
From ddlucas at lse.com Sun Feb 24 01:42:53 2002
From: ddlucas at lse.com (David D. Lucas)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] performance on tonights CVS
Message-ID: <3C78B59D.7090206@lse.com>
I pulled down the CVS source tonight and wanted to know how the current
JDOM is handling the parsing as compared to JDOM beta 7. I used
different SAX parsers and the samples.TestXMLOutput (slightly modified)
to run a few repeating tests.
What I have found seems to indicate that outputting a JDOM tree to XML
for a large file (1.85MB) is about 3 times faster now than JDOM beta 7.
Great job!!!
However, something in the way SAX is being used has impacted my Builder.
build performance which has slipped some 40% in the wrong direction.
I have not profiled it yet, but was wanting to know if anyone has a
quick explaination or suggestion on how to get it back up to beta 7
build speeds.
As a side note, it looks like memory usage is a bit better in the
current CVS snapshot than beta 7.
Any help would be appreciated. I know that 1.85MB XML is a bit large,
but that is what my client wants. We are processing some large
MQSeries messages and are using JDOM to manipulate the information.
Thanks in advance,
Dave
--
+------------------------------------------------------------+
| David Lucas mailto:ddlucas@lse.com |
| Lucas Software Engineering, Inc. (740) 964-6248 Voice |
| Unix,Java,C++,CORBA,XML,EJB (614) 668-4020 Mobile |
| Middleware,Frameworks (888) 866-4728 Fax/Msg |
+------------------------------------------------------------+
| GPS Location: 40.0150 deg Lat, -82.6378 deg Long |
| IMHC: "Jesus Christ is the way, the truth, and the life." |
| IMHC: "I know where I am; I know where I'm going." <>< |
+------------------------------------------------------------+
Notes: PGP Key Block=http://www.lse.com/~ddlucas/pgpblock.txt
IMHO="in my humble opinion" IMHC="in my humble conviction"
All trademarks above are those of their respective owners.
From warb at tgf.tc.faa.gov Mon Feb 25 05:52:56 2002
From: warb at tgf.tc.faa.gov (Dan Warburton)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] jdom beta 7 xmlOuttputer
Message-ID:
We are using the xmlOutputter. When we specify "no new lines" it still puts
a new line between the
processing instructions and the root element. I'd like it not to do that.
Thanks.
Dan Warburton FAA/ACT-510
Work: 609.485.4480
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Warburton, Dan.vcf
Type: text/x-vcard
Size: 882 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20020225/32da4eca/WarburtonDan.vcf
From arosen at silverstream.com Mon Feb 25 06:29:59 2002
From: arosen at silverstream.com (Alex Rosen)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] performance on tonights CVS
In-Reply-To: <3C78B59D.7090206@lse.com>
Message-ID: <001c01c1be08$e84a16f0$6601a8c0@silverstream.com>
One thing that's been added since beta 7 is the "buffer" code in SAXHandler,
that tries to preserve the internal subset of the DTD. Try commenting out
all that code in SAXHandler and see if the speed improves. (I wonder if
we'll need to add a method to turn off this feature for performance
reasons...)
Alex
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org]On Behalf Of David D. Lucas
> Sent: Sunday, February 24, 2002 4:43 AM
> To: jdom-interest@jdom.org
> Subject: [jdom-interest] performance on tonights CVS
>
>
> I pulled down the CVS source tonight and wanted to know how
> the current
> JDOM is handling the parsing as compared to JDOM beta 7. I used
> different SAX parsers and the samples.TestXMLOutput (slightly
> modified)
> to run a few repeating tests.
>
> What I have found seems to indicate that outputting a JDOM
> tree to XML
> for a large file (1.85MB) is about 3 times faster now than
> JDOM beta 7.
> Great job!!!
>
> However, something in the way SAX is being used has impacted
> my Builder.
> build performance which has slipped some 40% in the wrong direction.
> I have not profiled it yet, but was wanting to know if anyone has a
> quick explaination or suggestion on how to get it back up to beta 7
> build speeds.
>
> As a side note, it looks like memory usage is a bit better in the
> current CVS snapshot than beta 7.
>
> Any help would be appreciated. I know that 1.85MB XML is a
> bit large,
> but that is what my client wants. We are processing some large
> MQSeries messages and are using JDOM to manipulate the information.
>
> Thanks in advance,
> Dave
>
> --
>
> +------------------------------------------------------------+
> | David Lucas mailto:ddlucas@lse.com |
> | Lucas Software Engineering, Inc. (740) 964-6248 Voice |
> | Unix,Java,C++,CORBA,XML,EJB (614) 668-4020 Mobile |
> | Middleware,Frameworks (888) 866-4728 Fax/Msg |
> +------------------------------------------------------------+
> | GPS Location: 40.0150 deg Lat, -82.6378 deg Long |
> | IMHC: "Jesus Christ is the way, the truth, and the life." |
> | IMHC: "I know where I am; I know where I'm going." <>< |
> +------------------------------------------------------------+
>
> Notes: PGP Key Block=http://www.lse.com/~ddlucas/pgpblock.txt
> IMHO="in my humble opinion" IMHC="in my humble conviction"
> All trademarks above are those of their respective owners.
>
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@yourhost.com
From yuri.dewit at metaserver.com Mon Feb 25 08:42:51 2002
From: yuri.dewit at metaserver.com (Yuri de Wit)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Setting parser specific properties in JDOM builders.
Message-ID:
I need to set this Xerces property
"http://apache.org/xml/properties/schema/external-schemaLocation" in the
xerces parser used by JDOM. How can I do it? DOMBuilder/SAXBuilder dont seem
to expose something like setProperty().
Thanks,
Yuri
From noamt at yahoo.com Mon Feb 25 09:21:22 2002
From: noamt at yahoo.com (Noam Tamim)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Setting parser specific properties in JDOM builders.
In-Reply-To:
Message-ID: <20020225172122.34586.qmail@web13908.mail.yahoo.com>
The version of SAXBuilder currently in CVS does have a setProperty() and setFeature() methods.
Yuri de Wit wrote: I need to set this Xerces property
"http://apache.org/xml/properties/schema/external-schemaLocation" in the
xerces parser used by JDOM. How can I do it? DOMBuilder/SAXBuilder dont seem
to expose something like setProperty().
Thanks,
Yuri
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
Noam.
---------------------------------
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020225/693d2c7d/attachment.htm
From arosen at silverstream.com Mon Feb 25 09:13:00 2002
From: arosen at silverstream.com (Alex Rosen)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Minor SAXBuilder fix
Message-ID: <002701c1be1f$ae7f3380$6601a8c0@silverstream.com>
On 11/5/01, we changed SAXBuilder so that saxDriverClass no longer gets set
after creating the parser using JAXP (see
http://www.servlets.com/archive/servlet/ReadMsg?msgId=160131&listName=jdom-i
nterest). So in our error messages, we can no longer rely on saxDriverClass
to tell the user which parser we're complaining about - we have to actually
get the parser's class each time.
Also - we are still setting saxDriverClass, if JAXP is not available. I
assume that this is an OK thing to do? It should only be a problem if JAXP
is not initially available to your SAXBuilder, but then it become available
the second time. Seems unlikely.
Alex
-------------- next part --------------
Index: SAXBuilder.java
===================================================================
RCS file: /home/cvspublic/jdom/src/java/org/jdom/input/SAXBuilder.java,v
retrieving revision 1.63
diff -c -r1.63 SAXBuilder.java
*** SAXBuilder.java 2002/02/08 02:49:41 1.63
--- SAXBuilder.java 2002/02/26 01:10:56
***************
*** 608,614 ****
// No entity expansion available
throw new JDOMException(
"Entity expansion feature not recognized by " +
! saxDriverClass);
*/
}
catch (SAXNotSupportedException e) {
--- 608,614 ----
// No entity expansion available
throw new JDOMException(
"Entity expansion feature not recognized by " +
! parser.getClass().getName());
*/
}
catch (SAXNotSupportedException e) {
***************
*** 616,622 ****
// No entity expansion available
throw new JDOMException(
"Entity expansion feature not supported by " +
! saxDriverClass);
*/
}
}
--- 616,622 ----
// No entity expansion available
throw new JDOMException(
"Entity expansion feature not supported by " +
! parser.getClass().getName());
*/
}
}
***************
*** 633,642 ****
parser.setFeature(feature, value);
} catch (SAXNotSupportedException e) {
throw new JDOMException(
! displayName + " feature not supported for SAX driver " + saxDriverClass);
} catch (SAXNotRecognizedException e) {
throw new JDOMException(
! displayName + " feature not recognized for SAX driver " + saxDriverClass);
}
}
--- 633,642 ----
parser.setFeature(feature, value);
} catch (SAXNotSupportedException e) {
throw new JDOMException(
! displayName + " feature not supported for SAX driver " + parser.getClass().getName());
} catch (SAXNotRecognizedException e) {
throw new JDOMException(
! displayName + " feature not recognized for SAX driver " + parser.getClass().getName());
}
}
***************
*** 652,661 ****
parser.setProperty(property, value);
} catch (SAXNotSupportedException e) {
throw new JDOMException(
! displayName + " property not supported for SAX driver " + saxDriverClass);
} catch (SAXNotRecognizedException e) {
throw new JDOMException(
! displayName + " property not recognized for SAX driver " + saxDriverClass);
}
}
--- 652,661 ----
parser.setProperty(property, value);
} catch (SAXNotSupportedException e) {
throw new JDOMException(
! displayName + " property not supported for SAX driver " + parser.getClass().getName());
} catch (SAXNotRecognizedException e) {
throw new JDOMException(
! displayName + " property not recognized for SAX driver " + parser.getClass().getName());
}
}
From bart at wdi.co.uk Mon Feb 25 09:16:03 2002
From: bart at wdi.co.uk (Bart Read)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] jdom beta 7 xmlOuttputer
References:
Message-ID: <003901c1be20$1bb0b140$dc00a8c0@JOHNNYBRAVO>
Unless I'm very much mistaken I seem to remember some traffic on this topic
some while ago. You should perhaps check out the latest code from CVS for a
fix, or wait for the imminent (?) beta 0.8 release, or you _could_ even fix
the sources yourself. ;-)
Incidentally, and I apologise in advance because I know this has been asked
before, does anybody (I guess this means Brett, Jason, or Alex) know when
beta 0.8 will be available as a milestone build?
With thanks,
Bart
=================================
Bart Read
Senior Developer
Abbotsbury Software Ltd
Abbotsbury, DORSET DT3 4JT
Tel: +44 (0) 1305 871543
E-mail: bart@wdi.co.uk
=================================
----- Original Message -----
From: "Dan Warburton"
To: "Jdom-Intrest"
Cc:
Sent: Monday, February 25, 2002 1:52 PM
Subject: [jdom-interest] jdom beta 7 xmlOuttputer
>
> We are using the xmlOutputter. When we specify "no new lines" it still
puts
> a new line between the
> processing instructions and the root element. I'd like it not to do that.
>
> Thanks.
>
> Dan Warburton FAA/ACT-510
> Work: 609.485.4480
>
---------- Automatically inserted by WDI Mailserver ----------------
This message has been scanned for virus, trojans, illegal relays and
spam. If you have any comments, problems or questions please do not
hesitate to contact:
Abbotsbury Software Ltd
Tel: +44 1305 871543 Fax: +44 1305 871688
Email: postmaster@wdi.co.uk
Web: http://www.wdi.co.uk/virus.phtml
From ADEVASIA at mobius.com Mon Feb 25 11:30:40 2002
From: ADEVASIA at mobius.com (Alex Devasia)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Using Crimson
Message-ID: <89B3700F1199D411A0CB00508BEE227E013C80CD@ryentes1.mobius.com>
Can I use the SAXBuilder(String saxDriverClass) constructor to work with
Crimson directly.
I tried setting saxDriverClass = org.apache.crimson.jaxp.SAXParserImpl but I
had some problems. Any ideas?
Thanks
From PMcFarlane at lendx.com Mon Feb 25 18:23:24 2002
From: PMcFarlane at lendx.com (Patrick McFarlane)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] API enhancement request: Element.removeContent()
Message-ID: <001260FC91ADD511907400D0B79EC1BF0B8A38@CIMAIL>
Not sure if this is in the works or intentionally left out or if
I've missed something, but, it seems that Element removeContent(), which
removes all of the various types of content (CDATA, Comment, Element, etc.)
from an element without passing an Object argument would be very useful.
This would be roughly analogous to the Element removeChildren(). The inverse
Element setContent(List) is available and it seems odd that Element
removeContent() is not. My usage is replacing an existing bit of content
with a revised copy of the content via Jaxen/XPath, keeping the order
intact. I would like to do the following:
Element oldElem = findElementUsingXPath(elementPath);
Element parentElem = oldElem.getParent();
List siblings = parentElem.getContent();
// find the location of the element to update
int location = findEqualElement(siblings, oldElem);
// create a new List with the new element added Before the
addBefore element
List updatedList =
replaceElementInList(siblings,location,newElem);
// remove existing chilren
parentElem.removeContent(); // This method does not
currently exist
// add new list of children to parent
parentElem.setContent(updatedList);
Thanks in advance,
patrick
From bhardy at alodar.com Mon Feb 25 18:40:45 2002
From: bhardy at alodar.com (Bruce A. Hardy)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Question on element ordering in Document Object
Message-ID: <3C7AF5AD.5060104@alodar.com>
Hi,
I'm using JDOM to parse an XML document using the default parser. When
parsed it seems that the elements end up in Alphabetical order when what
I really need is to keep the order they are in in the XML document. Is
there a way I can do this?
Thanks,
Bruce Hardy
From jhunter at acm.org Mon Feb 25 18:50:16 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Question on element ordering in Document Object
References: <3C7AF5AD.5060104@alodar.com>
Message-ID: <3C7AF7E8.7B36AF17@acm.org>
Xerces doesn't alphabetize elements, nor does JDOM. I'd be very
surprised if this was a JDOM issue.
-jh-
"Bruce A. Hardy" wrote:
>
> Hi,
>
> I'm using JDOM to parse an XML document using the default parser. When
> parsed it seems that the elements end up in Alphabetical order when what
> I really need is to keep the order they are in in the XML document. Is
> there a way I can do this?
>
> Thanks,
>
> Bruce Hardy
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From jhunter at acm.org Mon Feb 25 18:53:44 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] API enhancement request: Element.removeContent()
References: <001260FC91ADD511907400D0B79EC1BF0B8A38@CIMAIL>
Message-ID: <3C7AF8B7.342E5F9E@acm.org>
Well, with the present API you can setContent(null) or
getContent().clear(). Do we need another method beyond that?
In your usage would it not suffice to say
parentElem.setContent(updatedList) and skip the removeContent() step?
-jh-
Patrick McFarlane wrote:
>
> Not sure if this is in the works or intentionally left out or if
> I've missed something, but, it seems that Element removeContent(), which
> removes all of the various types of content (CDATA, Comment, Element, etc.)
> from an element without passing an Object argument would be very useful.
> This would be roughly analogous to the Element removeChildren(). The inverse
> Element setContent(List) is available and it seems odd that Element
> removeContent() is not. My usage is replacing an existing bit of content
> with a revised copy of the content via Jaxen/XPath, keeping the order
> intact. I would like to do the following:
>
> Element oldElem = findElementUsingXPath(elementPath);
> Element parentElem = oldElem.getParent();
> List siblings = parentElem.getContent();
> // find the location of the element to update
> int location = findEqualElement(siblings, oldElem);
> // create a new List with the new element added Before the
> addBefore element
> List updatedList =
> replaceElementInList(siblings,location,newElem);
> // remove existing chilren
> parentElem.removeContent(); // This method does not
> currently exist
> // add new list of children to parent
> parentElem.setContent(updatedList);
>
> Thanks in advance,
> patrick
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From jozart at csi.com Mon Feb 25 23:47:54 2002
From: jozart at csi.com (Joseph Bowbeer)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Re: Using Crimson
References: <200202260712.AAA07196@dorothy.denveronline.net>
Message-ID: <007501c1be99$e69235e0$0a0a0a0a@REPLICANT>
The last time I used Crimson directly, I did it this way:
new SAXBuilder("org.apache.crimson.parser.XMLReaderImpl")
--- original message ---
From: Alex Devasia
Date: Mon, 25 Feb 2002 14:30:40 -0500
Subject: [jdom-interest] Using Crimson
Can I use the SAXBuilder(String saxDriverClass) constructor to work with
Crimson directly.
I tried setting saxDriverClass = org.apache.crimson.jaxp.SAXParserImpl
but I had some problems. Any ideas?
From s.mcleish at lse.ac.uk Tue Feb 26 04:29:45 2002
From: s.mcleish at lse.ac.uk (Simon McLeish)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Suggestions for increasing speed of JDOM based app
Message-ID: <3C7B7FB9.5010503@lse.ac.uk>
Hi,
I've recently developed an application which uses JDOM heavily - it
traverses an XML document, matches a search string against certain text
nodes using java.util.regex, and performs an XSL transformation to
display the hit count in a hierarchy matching the original document.
Unfortunately, this turns out to be quite slow as far as users are
concerned (in some documents, there are thousands of nodes to check and
a threaded search across all 30 of them takes about 70 seconds depending
on the complexity of the search query), and I wondered if anyone has any
suggestions which might help speed it up.
One option I've considered is using an ahead of time compiler to create
a machine-specific binary, and any reports on experience with this.
(Looking at the gcj home page makes me think that it's unlikely to be
possible to do this for an app that uses JDOM, however.)
I'm assuming that people are likely to want to send generic responses
rather than wade through the code, but if anyone wants to do that I'll
happily send it to them.
TIA,
Simon
From matthew.preston at knowledgeview.co.uk Tue Feb 26 09:32:20 2002
From: matthew.preston at knowledgeview.co.uk (Matt Preston)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] JDOMResult
Message-ID:
Hi all,
I have been using the JDOMResult for some transformations where I need a
JDOM Document at the end, but have run into a problem. It seems that the
Document produced never has a DocType set, even if my xsl stylesheet creates
one.
e.g. I created a doctype with this xsl
I used this code to do the transformation
JDOMResult _result = new JDOMResult();
StreamSource _source = new StreamSource(anInputStream);
_transformer.transform(_source, _result);
Document _document = _result.getDocument();
_document.getDocType() returns null. If rather than using JDOMResult, I use
a StreamResult and make the Document via a SAXBuilder, the Document has the
correct DocType.
Has anyone else experienced this?
Cheers,
Matt Preston
---
Not dirty!
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.314 / Virus Database: 175 - Release Date: 11/01/2002
---
Not dirty!
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.314 / Virus Database: 175 - Release Date: 11/01/2002
From dms at sosnoski.com Tue Feb 26 09:43:30 2002
From: dms at sosnoski.com (Dennis Sosnoski)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Suggestions for increasing speed of JDOM based app
References: <3C7B7FB9.5010503@lse.ac.uk>
Message-ID: <3C7BC942.2070607@sosnoski.com>
Beta 7 has a known performance problem in that it uses linked lists for
returned lists. If you're iterating through a long list of children the
time required is O(n^2).
I think this has changed in the current CVS version, so you if you've
been using beta 7 you might want to try your program with the current
CVS code before investigating further.
- Dennis
Simon McLeish wrote:
> Hi,
>
> I've recently developed an application which uses JDOM heavily - it
> traverses an XML document, matches a search string against certain
> text nodes using java.util.regex, and performs an XSL transformation
> to display the hit count in a hierarchy matching the original
> document. Unfortunately, this turns out to be quite slow as far as
> users are concerned (in some documents, there are thousands of nodes
> to check and a threaded search across all 30 of them takes about 70
> seconds depending on the complexity of the search query), and I
> wondered if anyone has any suggestions which might help speed it up.
>
> One option I've considered is using an ahead of time compiler to
> create a machine-specific binary, and any reports on experience with
> this. (Looking at the gcj home page makes me think that it's unlikely
> to be possible to do this for an app that uses JDOM, however.)
>
> I'm assuming that people are likely to want to send generic responses
> rather than wade through the code, but if anyone wants to do that I'll
> happily send it to them.
>
> TIA,
>
> Simon
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>
From dms at sosnoski.com Tue Feb 26 10:38:13 2002
From: dms at sosnoski.com (Dennis Sosnoski)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Suggestions for increasing speed of JDOM based app
References: <3C7B7FB9.5010503@lse.ac.uk> <3C7BC942.2070607@sosnoski.com>
Message-ID: <3C7BD615.6020607@sosnoski.com>
Actually I should clarify this - if you're using an Iterator to go
through the list there should not be a problem with the beta 7 code; if
you're using indexing to go through the list then there definitely is.
Your problem is more likely to be with the regex and/or XSLT processing,
though. If you want to check this just disable the regex matching (have
your matching code always return "false") and see how fast your app runs
without either of these steps. Then enable the regex matching but skip
the XSLT output generation, so that you get separate measurements for
each of these.
Assuming these are the problem areas, you can (1) try to get better
matching code (perhaps you don't need full regex, for instance) or use
it more efficiently (make sure you're not rebuilding the patterns for
each match, etc.), and (2) build the output directly rather than using XSLT.
I've not been impressed by the machine-specific compilers for Java.
Modern JVMs get performance reasonably close to what the
machine-specific ones can achieve, without any of the hassle. You're
better off looking for algorithm improvements, as discussed above.
- Dennis
Dennis Sosnoski wrote:
> Beta 7 has a known performance problem in that it uses linked lists
> for returned lists. If you're iterating through a long list of
> children the time required is O(n^2).
>
> I think this has changed in the current CVS version, so you if you've
> been using beta 7 you might want to try your program with the current
> CVS code before investigating further.
>
> - Dennis
>
> Simon McLeish wrote:
>
>> Hi,
>>
>> I've recently developed an application which uses JDOM heavily - it
>> traverses an XML document, matches a search string against certain
>> text nodes using java.util.regex, and performs an XSL transformation
>> to display the hit count in a hierarchy matching the original
>> document. Unfortunately, this turns out to be quite slow as far as
>> users are concerned (in some documents, there are thousands of nodes
>> to check and a threaded search across all 30 of them takes about 70
>> seconds depending on the complexity of the search query), and I
>> wondered if anyone has any suggestions which might help speed it up.
>>
>> One option I've considered is using an ahead of time compiler to
>> create a machine-specific binary, and any reports on experience with
>> this. (Looking at the gcj home page makes me think that it's unlikely
>> to be possible to do this for an app that uses JDOM, however.)
>>
>> I'm assuming that people are likely to want to send generic responses
>> rather than wade through the code, but if anyone wants to do that
>> I'll happily send it to them.
>>
>> TIA,
>>
>> Simon
>>
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>>
>>
>
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>
From arosen at silverstream.com Tue Feb 26 11:06:52 2002
From: arosen at silverstream.com (Alex Rosen)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] Suggestions for increasing speed of JDOM based app
In-Reply-To: <3C7BD615.6020607@sosnoski.com>
Message-ID: <000701c1bef8$c1311230$d26e810a@silverstream.com>
Excellent recommendation. Another thing to try, if you have fixed or at
least repeating searches, is using a compiler for XSLT and/or regexp, which
builds a special-purpose class file for performing the tranformation and or
search. Xalan has XSLTC, I'm sure there's some regexp compiler somewhere.
It sounds like you're using some not-too-speedy technologies (XML, XSL,
regexp) for an app that needs a lot of performance, which may be the root of
your problem. I don't know anything about what you're trying to do, but can
you do something else instead, like store the info in a database?
Alex
> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org]On Behalf Of Dennis Sosnoski
> Sent: Tuesday, February 26, 2002 1:38 PM
> To: Simon McLeish
> Cc: jdom-interest@jdom.org
> Subject: Re: [jdom-interest] Suggestions for increasing speed of JDOM
> based app
>
>
> Actually I should clarify this - if you're using an Iterator to go
> through the list there should not be a problem with the beta
> 7 code; if
> you're using indexing to go through the list then there definitely is.
>
> Your problem is more likely to be with the regex and/or XSLT
> processing,
> though. If you want to check this just disable the regex
> matching (have
> your matching code always return "false") and see how fast
> your app runs
> without either of these steps. Then enable the regex matching
> but skip
> the XSLT output generation, so that you get separate measurements for
> each of these.
>
> Assuming these are the problem areas, you can (1) try to get better
> matching code (perhaps you don't need full regex, for
> instance) or use
> it more efficiently (make sure you're not rebuilding the patterns for
> each match, etc.), and (2) build the output directly rather
> than using XSLT.
>
> I've not been impressed by the machine-specific compilers for Java.
> Modern JVMs get performance reasonably close to what the
> machine-specific ones can achieve, without any of the hassle. You're
> better off looking for algorithm improvements, as discussed above.
>
> - Dennis
>
> Dennis Sosnoski wrote:
>
> > Beta 7 has a known performance problem in that it uses linked lists
> > for returned lists. If you're iterating through a long list of
> > children the time required is O(n^2).
> >
> > I think this has changed in the current CVS version, so you
> if you've
> > been using beta 7 you might want to try your program with
> the current
> > CVS code before investigating further.
> >
> > - Dennis
> >
> > Simon McLeish wrote:
> >
> >> Hi,
> >>
> >> I've recently developed an application which uses JDOM
> heavily - it
> >> traverses an XML document, matches a search string against certain
> >> text nodes using java.util.regex, and performs an XSL
> transformation
> >> to display the hit count in a hierarchy matching the original
> >> document. Unfortunately, this turns out to be quite slow as far as
> >> users are concerned (in some documents, there are
> thousands of nodes
> >> to check and a threaded search across all 30 of them takes
> about 70
> >> seconds depending on the complexity of the search query), and I
> >> wondered if anyone has any suggestions which might help
> speed it up.
> >>
> >> One option I've considered is using an ahead of time compiler to
> >> create a machine-specific binary, and any reports on
> experience with
> >> this. (Looking at the gcj home page makes me think that
> it's unlikely
> >> to be possible to do this for an app that uses JDOM, however.)
> >>
> >> I'm assuming that people are likely to want to send
> generic responses
> >> rather than wade through the code, but if anyone wants to do that
> >> I'll happily send it to them.
> >>
> >> TIA,
> >>
> >> Simon
> >>
> >> _______________________________________________
> >> To control your jdom-interest membership:
> >>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
>>
>>
>
>
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
>
>
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
From matthew at knowledgeview.co.uk Tue Feb 26 09:26:53 2002
From: matthew at knowledgeview.co.uk (Matt Preston)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] JDOMResult
Message-ID:
Hi all,
I have been using the JDOMResult for some transformations where I need a
JDOM Document at the end, but have run into a problem. It seems that the
Document produced never has a DocType set, even if my xsl stylesheet creates
one.
e.g. I created a doctype with this xsl
I used this code to do the transformation
JDOMResult _result = new JDOMResult();
StreamSource _source = new StreamSource(anInputStream);
_transformer.transform(_source, _result);
Document _document = _result.getDocument();
_document.getDocType() returns null. If rather than using JDOMResult, I use
a StreamResult and make the Document via a SAXBuilder, the Document has the
correct DocType.
Has anyone else experienced this?
Cheers,
Matt Preston
---
Not dirty!
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.314 / Virus Database: 175 - Release Date: 11/01/2002
From jhunter at acm.org Tue Feb 26 11:25:38 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] JDOMResult
References:
Message-ID: <3C7BE132.2B5F926F@acm.org>
Are you using the latest code in CVS? As the FAQ says, please everyone
try that before submitting a possible bug report, and state in the
report that you have tried it.
-jh-
Matt Preston wrote:
>
> Hi all,
>
> I have been using the JDOMResult for some transformations where I need a
> JDOM Document at the end, but have run into a problem. It seems that the
> Document produced never has a DocType set, even if my xsl stylesheet creates
> one.
>
> e.g. I created a doctype with this xsl
>
> doctype-public="-//IPTC//NITF DTD 2.0//EN"
> doctype-system="http://www.nitf.org/site/nitf-documentation/nitf-2-5-no-comm
> ents.dtd"/>
>
> I used this code to do the transformation
>
> JDOMResult _result = new JDOMResult();
>
> StreamSource _source = new StreamSource(anInputStream);
>
> _transformer.transform(_source, _result);
>
> Document _document = _result.getDocument();
>
> _document.getDocType() returns null. If rather than using JDOMResult, I use
> a StreamResult and make the Document via a SAXBuilder, the Document has the
> correct DocType.
>
> Has anyone else experienced this?
>
> Cheers,
> Matt Preston
>
> ---
> Not dirty!
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.314 / Virus Database: 175 - Release Date: 11/01/2002
>
> ---
> Not dirty!
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.314 / Virus Database: 175 - Release Date: 11/01/2002
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
From Sullivan.Sean at menlolog.com Tue Feb 26 12:49:22 2002
From: Sullivan.Sean at menlolog.com (Sullivan, Sean C - MLG)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] JDOM Birds-of-Feather (BOF) at JavaOne 2002?
Message-ID: <7B73D5F649D0D311B1E30008C7A4D92A116D7561@cnfqs029.cnf.prod.cnf.com>
Is there going to be a JDOM Birds-of-Feather event
at JavaOne 2002 in San Francisco?
I looked here:
http://servlet.java.sun.com/javaone/sf2002/conf/bofs/all-all-regular.en.jsp
but I did not see JDOM listed.
-Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020226/4af34cf0/attachment.htm
From PMcFarlane at lendx.com Tue Feb 26 13:03:31 2002
From: PMcFarlane at lendx.com (Patrick McFarlane)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] API enhancement request: Element.removeConten
t()
Message-ID: <001260FC91ADD511907400D0B79EC1BF0B8A3A@CIMAIL>
Again maybe I'm missing something, but when I use the setContent(null)
method or getContent().clear() my content still has parent relationships so
that I get an error messages like the following:
org.jdom.IllegalAddException: The comment " Display Element Definitions "
could not be added as content to "localizableDisplay": The comment already
has an existing parent "localizableDisplay"
If I use the Element removeChildren() method, that sets the parent
relationship to null which lets me avoid the problem above. I'm wondering if
a removeContent method could also free the parent relationships of what was
removed.
I'm sure that I can work around this by iterating through my list of content
and doing the equivalent of a detach() for each, but I just thought this
might be a useful method to add.
patrick
-----Original Message-----
From: Jason Hunter [mailto:jhunter@acm.org]
Sent: Monday, February 25, 2002 6:54 PM
To: Patrick McFarlane
Cc: 'jdom-interest@jdom.org'
Subject: Re: [jdom-interest] API enhancement request:
Element.removeContent()
Well, with the present API you can setContent(null) or
getContent().clear(). Do we need another method beyond that?
In your usage would it not suffice to say
parentElem.setContent(updatedList) and skip the removeContent() step?
-jh-
Patrick McFarlane wrote:
>
> Not sure if this is in the works or intentionally left out or if
> I've missed something, but, it seems that Element removeContent(), which
> removes all of the various types of content (CDATA, Comment, Element,
etc.)
> from an element without passing an Object argument would be very useful.
> This would be roughly analogous to the Element removeChildren(). The
inverse
> Element setContent(List) is available and it seems odd that Element
> removeContent() is not. My usage is replacing an existing bit of content
> with a revised copy of the content via Jaxen/XPath, keeping the order
> intact. I would like to do the following:
>
> Element oldElem = findElementUsingXPath(elementPath);
> Element parentElem = oldElem.getParent();
> List siblings = parentElem.getContent();
> // find the location of the element to update
> int location = findEqualElement(siblings, oldElem);
> // create a new List with the new element added Before the
> addBefore element
> List updatedList =
> replaceElementInList(siblings,location,newElem);
> // remove existing chilren
> parentElem.removeContent(); // This method does not
> currently exist
> // add new list of children to parent
> parentElem.setContent(updatedList);
>
> Thanks in advance,
> patrick
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
From jhunter at acm.org Tue Feb 26 13:51:26 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] API enhancement request: Element.removeContent()
References: <001260FC91ADD511907400D0B79EC1BF0B8A3A@CIMAIL>
Message-ID: <3C7C035E.6E441DE3@acm.org>
You're using beta7 I presume. The code in CVS is much, much better, and
includes code that better manages parent relationships.
Yes, we'll be doing a beta8 soon. :-)
-jh-
Patrick McFarlane wrote:
>
> Again maybe I'm missing something, but when I use the setContent(null)
> method or getContent().clear() my content still has parent relationships so
> that I get an error messages like the following:
>
> org.jdom.IllegalAddException: The comment " Display Element Definitions "
> could not be added as content to "localizableDisplay": The comment already
> has an existing parent "localizableDisplay"
>
> If I use the Element removeChildren() method, that sets the parent
> relationship to null which lets me avoid the problem above. I'm wondering if
> a removeContent method could also free the parent relationships of what was
> removed.
>
> I'm sure that I can work around this by iterating through my list of content
> and doing the equivalent of a detach() for each, but I just thought this
> might be a useful method to add.
>
> patrick
>
> -----Original Message-----
> From: Jason Hunter [mailto:jhunter@acm.org]
> Sent: Monday, February 25, 2002 6:54 PM
> To: Patrick McFarlane
> Cc: 'jdom-interest@jdom.org'
> Subject: Re: [jdom-interest] API enhancement request:
> Element.removeContent()
>
> Well, with the present API you can setContent(null) or
> getContent().clear(). Do we need another method beyond that?
>
> In your usage would it not suffice to say
> parentElem.setContent(updatedList) and skip the removeContent() step?
>
> -jh-
>
> Patrick McFarlane wrote:
> >
> > Not sure if this is in the works or intentionally left out or if
> > I've missed something, but, it seems that Element removeContent(), which
> > removes all of the various types of content (CDATA, Comment, Element,
> etc.)
> > from an element without passing an Object argument would be very useful.
> > This would be roughly analogous to the Element removeChildren(). The
> inverse
> > Element setContent(List) is available and it seems odd that Element
> > removeContent() is not. My usage is replacing an existing bit of content
> > with a revised copy of the content via Jaxen/XPath, keeping the order
> > intact. I would like to do the following:
> >
> > Element oldElem = findElementUsingXPath(elementPath);
> > Element parentElem = oldElem.getParent();
> > List siblings = parentElem.getContent();
> > // find the location of the element to update
> > int location = findEqualElement(siblings, oldElem);
> > // create a new List with the new element added Before the
> > addBefore element
> > List updatedList =
> > replaceElementInList(siblings,location,newElem);
> > // remove existing chilren
> > parentElem.removeContent(); // This method does not
> > currently exist
> > // add new list of children to parent
> > parentElem.setContent(updatedList);
> >
> > Thanks in advance,
> > patrick
> > _______________________________________________
> > To control your jdom-interest membership:
> >
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> t.com
From jhunter at acm.org Tue Feb 26 13:48:58 2002
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] JDOM Birds-of-Feather (BOF) at JavaOne 2002?
References: <7B73D5F649D0D311B1E30008C7A4D92A116D7561@cnfqs029.cnf.prod.cnf.com>
Message-ID: <3C7C02CA.409AB466@acm.org>
> Is there going to be a JDOM Birds-of-Feather event
> at JavaOne 2002 in San Francisco?
> I looked here:
> http://servlet.java.sun.com/javaone/sf2002/conf/bofs/all-all-regular.en.jsp
> but I did not see JDOM listed.
No BOF that I know of, but I'm giving a JDOM talk. Usually after JDOM
talks at other conferences those of us who know each other's names from
this list often hang out afterward. I met Phil Nelson that way. Some
guy I knew by email for a year suddenly introduced himself in person! I
hear Jools say he'll be attending this year, and this'll be my first
time to meet the man who runs our cvs. :-)
-jh-
P.S. Please turn off html email. I had to copy-paste to quote, and
many email readers don't display it at all.
From uwaibel at t-online.de Tue Feb 26 13:26:45 2002
From: uwaibel at t-online.de (Uli Waibel)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] XMLOutputter to Sockets
Message-ID:
Hi,
I try to get the following simple client/ server app running, but having
problems.
Any help is really apreciated
Thanks a lot
Uli Waibel
JAVA Developer, Germany
<<< CODE for Server >>>>>
public void server()
{
try
{
ServerSocket srv = new ServerSocket(2222);
SAXBuilder builder = new SAXBuilder(false);
try
{
while( true )
{
System.out.println("Wait for Client");
Socket in = srv.accept();
System.out.println("Client connected");
Document doc = builder.build(new
java.io.BufferedInputStream(in.getInputStream()));
System.out.println( "Document created...");
Element root = doc.getRootElement();
org.jdom.Namespace ns = root.getNamespace();
Element command = root.getChild("Action",ns).getChild("Command",ns);
System.out.println( command.getName()+": "+command.getText() );
List parms =
root.getChild("Action",ns).getChild("Parameter",ns).getChildren();
List retParms =
root.getChild("Action",ns).getChild("Return",ns).getChildren();
Iterator it = parms.iterator();
String user=null;
while( it.hasNext() )
{
Element aParam = (Element)it.next();
if( aParam.getName().compareTo("UserID")== 0 )
user = aParam.getText();
if( aParam.getName().compareTo("Passwd")== 0 )
{
if( aParam.getAttribute("encrypt").getBooleanValue() == true )
System.out.println("Passwort decodieren");
}
//System.out.println( aParam.getName()+": " +aParam.getText());
}
it = retParms.iterator();
while( it.hasNext() )
{
Element aParam = (Element)it.next();
if( aParam.getName().compareTo("Returnmsg")== 0 )
{
aParam.setText("Benutzer " + user + " ist angemeldet");
}
}
org.jdom.output.XMLOutputter printer = new
org.jdom.output.XMLOutputter();
printer.output( doc, in.getOutputStream());
}
}
catch( java.io.IOException e ){e.getMessage();}
}
catch( JDOMException e ){e.printStackTrace();}
catch( java.io.IOException e ){e.printStackTrace();}
}
<<< Client Code >>>>
public static void main(java.lang.String[] args) {
try
{
java.net.Socket tester = new java.net.Socket("localhost", 2222);
SAXBuilder builder = new SAXBuilder(false);
Document doc = builder.build(new File( args[0] ));
System.out.println( "Document created...");
// in reallity I will modifiy the elements of a document here
// .....
// and send to server
XMLOutputter printer = new XMLOutputter();
printer.output(doc, tester.getOutputStream());
doc=builder.build(tester.getInputStream());
printer.output(doc,System.out);
}
catch( java.net.UnknownHostException e ){e.printStackTrace();}
catch( java.io.IOException e){e.printStackTrace();}
catch( JDOMException e ){e.printStackTrace();}
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ulrich Waibel.vcf
Type: text/x-vcard
Size: 519 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20020226/22c02fe6/UlrichWaibel.vcf
From PMcFarlane at lendx.com Tue Feb 26 14:00:05 2002
From: PMcFarlane at lendx.com (Patrick McFarlane)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] API enhancement request: Element.removeConten
t()
Message-ID: <001260FC91ADD511907400D0B79EC1BF0B8A3C@CIMAIL>
Yes, I am using beta7. I very much look forward to beta8. Thanks for the
info.
By the way, thanks for writing such a clean API. It's definitely one of my
favorite Java API to work with. You've made creating and navigating XML
documents easy! :)
patrick
-----Original Message-----
From: Jason Hunter [mailto:jhunter@acm.org]
Sent: Tuesday, February 26, 2002 1:51 PM
To: Patrick McFarlane
Cc: 'jdom-interest@jdom.org'
Subject: Re: [jdom-interest] API enhancement request:
Element.removeContent()
You're using beta7 I presume. The code in CVS is much, much better, and
includes code that better manages parent relationships.
Yes, we'll be doing a beta8 soon. :-)
-jh-
Patrick McFarlane wrote:
>
> Again maybe I'm missing something, but when I use the setContent(null)
> method or getContent().clear() my content still has parent relationships
so
> that I get an error messages like the following:
>
> org.jdom.IllegalAddException: The comment " Display Element Definitions "
> could not be added as content to "localizableDisplay": The comment already
> has an existing parent "localizableDisplay"
>
> If I use the Element removeChildren() method, that sets the parent
> relationship to null which lets me avoid the problem above. I'm wondering
if
> a removeContent method could also free the parent relationships of what
was
> removed.
>
> I'm sure that I can work around this by iterating through my list of
content
> and doing the equivalent of a detach() for each, but I just thought this
> might be a useful method to add.
>
> patrick
>
> -----Original Message-----
> From: Jason Hunter [mailto:jhunter@acm.org]
> Sent: Monday, February 25, 2002 6:54 PM
> To: Patrick McFarlane
> Cc: 'jdom-interest@jdom.org'
> Subject: Re: [jdom-interest] API enhancement request:
> Element.removeContent()
>
> Well, with the present API you can setContent(null) or
> getContent().clear(). Do we need another method beyond that?
>
> In your usage would it not suffice to say
> parentElem.setContent(updatedList) and skip the removeContent() step?
>
> -jh-
>
> Patrick McFarlane wrote:
> >
> > Not sure if this is in the works or intentionally left out or if
> > I've missed something, but, it seems that Element removeContent(), which
> > removes all of the various types of content (CDATA, Comment, Element,
> etc.)
> > from an element without passing an Object argument would be very useful.
> > This would be roughly analogous to the Element removeChildren(). The
> inverse
> > Element setContent(List) is available and it seems odd that Element
> > removeContent() is not. My usage is replacing an existing bit of content
> > with a revised copy of the content via Jaxen/XPath, keeping the order
> > intact. I would like to do the following:
> >
> > Element oldElem = findElementUsingXPath(elementPath);
> > Element parentElem = oldElem.getParent();
> > List siblings = parentElem.getContent();
> > // find the location of the element to update
> > int location = findEqualElement(siblings, oldElem);
> > // create a new List with the new element added Before
the
> > addBefore element
> > List updatedList =
> > replaceElementInList(siblings,location,newElem);
> > // remove existing chilren
> > parentElem.removeContent(); // This method does not
> > currently exist
> > // add new list of children to parent
> > parentElem.setContent(updatedList);
> >
> > Thanks in advance,
> > patrick
> > _______________________________________________
> > To control your jdom-interest membership:
> >
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> t.com
From ddlucas at lse.com Tue Feb 26 15:57:08 2002
From: ddlucas at lse.com (David D. Lucas)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] performance on tonights CVS
References: <001c01c1be08$e84a16f0$6601a8c0@silverstream.com>
Message-ID: <3C7C20D4.1000902@lse.com>
Can you be more specific about what revision the "buffering" was added.
I have been doing diff and I am not sure the DTD buffering is being hit
unless I am receiving DTD events. The XML I am parsing is just well
formed XML with no DTD or Schema in the input.
Also a side note I noticed the use of Stack. Is this being replaced or
staying due to backward compatability?
Thanks in advance,
Dave
Alex Rosen wrote:
> One thing that's been added since beta 7 is the "buffer" code in SAXHandler,
> that tries to preserve the internal subset of the DTD. Try commenting out
> all that code in SAXHandler and see if the speed improves. (I wonder if
> we'll need to add a method to turn off this feature for performance
> reasons...)
>
> Alex
>
>
>>-----Original Message-----
>>From: jdom-interest-admin@jdom.org
>>[mailto:jdom-interest-admin@jdom.org]On Behalf Of David D. Lucas
>>Sent: Sunday, February 24, 2002 4:43 AM
>>To: jdom-interest@jdom.org
>>Subject: [jdom-interest] performance on tonights CVS
>>
>>
>>I pulled down the CVS source tonight and wanted to know how
>>the current
>>JDOM is handling the parsing as compared to JDOM beta 7. I used
>>different SAX parsers and the samples.TestXMLOutput (slightly
>>modified)
>>to run a few repeating tests.
>>
>>What I have found seems to indicate that outputting a JDOM
>>tree to XML
>>for a large file (1.85MB) is about 3 times faster now than
>>JDOM beta 7.
>>Great job!!!
>>
>>However, something in the way SAX is being used has impacted
>>my Builder.
>>build performance which has slipped some 40% in the wrong direction.
>>I have not profiled it yet, but was wanting to know if anyone has a
>>quick explaination or suggestion on how to get it back up to beta 7
>>build speeds.
>>
>>As a side note, it looks like memory usage is a bit better in the
>>current CVS snapshot than beta 7.
>>
>>Any help would be appreciated. I know that 1.85MB XML is a
>>bit large,
>>but that is what my client wants. We are processing some large
>>MQSeries messages and are using JDOM to manipulate the information.
>>
>>Thanks in advance,
>>Dave
>>
>>--
>>
>>+------------------------------------------------------------+
>>| David Lucas mailto:ddlucas@lse.com |
>>| Lucas Software Engineering, Inc. (740) 964-6248 Voice |
>>| Unix,Java,C++,CORBA,XML,EJB (614) 668-4020 Mobile |
>>| Middleware,Frameworks (888) 866-4728 Fax/Msg |
>>+------------------------------------------------------------+
>>| GPS Location: 40.0150 deg Lat, -82.6378 deg Long |
>>| IMHC: "Jesus Christ is the way, the truth, and the life." |
>>| IMHC: "I know where I am; I know where I'm going." <>< |
>>+------------------------------------------------------------+
>>
>>Notes: PGP Key Block=http://www.lse.com/~ddlucas/pgpblock.txt
>>IMHO="in my humble opinion" IMHC="in my humble conviction"
>>All trademarks above are those of their respective owners.
>>
>>
>>_______________________________________________
>>To control your jdom-interest membership:
>>http://lists.denveronline.net/mailman/options/jdom-interest/yo
>>
> uraddr@yourhost.com
>
>
>
--
+------------------------------------------------------------+
| David Lucas mailto:ddlucas@lse.com |
| Lucas Software Engineering, Inc. (740) 964-6248 Voice |
| Unix,Java,C++,CORBA,XML (614) 668-4020 Mobile |
| Middleware,Frameworks (888) 866-4728 Fax |
+------------------------------------------------------------+
| GPS Location: 40 deg 00' 51" N, 82 deg 38' 11" W |
| IMHC: "Jesus Christ is the way, the truth, and the life." |
| IMHC: "I know where I am; I know where I'm going." <>< |
+------------------------------------------------------------+
Notes: PGP Key Block=http://www.lse.com/~ddlucas/pgpblock.txt
IMHO="in my humble opinion" IMHC="in my humble conviction"
All trademarks above are those of their respective owners.
From philip.nelson at omniresources.com Tue Feb 26 18:39:27 2002
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] performance on tonights CVS
Message-ID:
> Can you be more specific about what revision the "buffering"
> was added. I have been doing diff and I am not sure the DTD
> buffering is being hit
> unless I am receiving DTD events. The XML I am parsing is just well
> formed XML with no DTD or Schema in the input.
Right, the use of the buffer for the internal subset shouldn't really affect
you unless you have entity expansion off and therefore use the internal
subset to capture the entity definitions and other dtd information.
There have been some major changes under the covers with JDOM since beta 7.
One of them (Text class and automagic joining of adjacent text nodes) was
done specifically for a performance problem in sax handler which
demonstrated out a worst case situation. Can you give any clues as to where
the slowdown is occurring? Is there something, other than size, that is
unusual about your document, like lots of attributes, lots of mixed
contents, or things like that?
From laurent.bihanic at atosorigin.com Wed Feb 27 04:35:47 2002
From: laurent.bihanic at atosorigin.com (Laurent Bihanic)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] JDOMResult
References:
Message-ID: <3C7CD2A3.60404@atosorigin.com>
Hi Matt,
I'm not sure the directive applies when the result is not a
stream result: the XSLT 1.0 recommendation defines the xsl:output element in
the context of "output the result tree as a sequence of bytes". When
outputting to a JDOMResult, the result is not a sequence of byte but a SAX
event stream.
For example, in your case, none of the "indent", "method" and "encoding" is
relevant when the output is a SAX event stream. So, my guess would be that the
xsl:output is globally ignored when the output is not a StreamResult.
Maybe you could try with another XSLT processor (e.g. SAXON 6.x) to see if
this behaviour is consistent.
Laurent
Matt Preston wrote:
> Hi all,
>
> I have been using the JDOMResult for some transformations where I need a
> JDOM Document at the end, but have run into a problem. It seems that the
> Document produced never has a DocType set, even if my xsl stylesheet creates
> one.
>
> e.g. I created a doctype with this xsl
>
> doctype-public="-//IPTC//NITF DTD 2.0//EN"
> doctype-system="http://www.nitf.org/site/nitf-documentation/nitf-2-5-no-comm
> ents.dtd"/>
>
> I used this code to do the transformation
>
> JDOMResult _result = new JDOMResult();
> StreamSource _source = new StreamSource(anInputStream);
> _transformer.transform(_source, _result);
> Document _document = _result.getDocument();
>
> _document.getDocType() returns null. If rather than using JDOMResult, I use
> a StreamResult and make the Document via a SAXBuilder, the Document has the
> correct DocType.
>
> Has anyone else experienced this?
>
> Cheers,
> Matt Preston
>
From laurent.bihanic at atosorigin.com Wed Feb 27 06:40:32 2002
From: laurent.bihanic at atosorigin.com (Laurent Bihanic)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] JDOM and XSLT
References:
Message-ID: <3C7CEFE0.5080307@atosorigin.com>
Hi,
Mani Doraisamy wrote:
> Hi all,
> What is the fastest XSLT processor available in market. I am
> using JDOM and I would like to do XSLT so that I can present
> it as HTML.
Saxon (http://saxon.sourceforge.net) can be up to 3 times faster than Xalan,
depending on your stylesheet, and is very stable.
> Another question,
> my JDOM structure is huge and the Elements in the structure
> actually gets the value from performance intensive calculations
> and database operations, by overriding getText() method. Now
> when i want to do XSLT i wouldnt want the entire tree for XSLT.
> Although i can pass the whole tree for XSLT, what is the most
> performant way of doing XSLT for the subtree?
XSLT processes an entire document. So the only way to apply a stylesheet to
only a part of a document is to detach that part and make it a standalone
document. You can then apply the stylesheet to this "small" document and
attach the result back to the original document.
Hope this helps,
Laurent
From weigao at hypergrove.com Wed Feb 27 10:04:35 2002
From: weigao at hypergrove.com (W. Gao)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] HTML to XHTML?
Message-ID: <002501c1bfb9$37817310$d77dfea9@anna>
Hi,
Sorry if this is a unrelated question. I want to create a DOM tree from a XHTML file. If I get errors, I want to use a translator or some tools to convert the .html file to XHTML file and parse it again. I want my program to fail only after this attempt fails. Does anyone know where I can find this kind of software? Thanks.
Wei
From MDoraisamy at SELECTICA.com Wed Feb 27 11:36:42 2002
From: MDoraisamy at SELECTICA.com (Mani Doraisamy)
Date: Fri Aug 6 17:07:25 2004
Subject: [jdom-interest] JDOM and XSLT
Message-ID:
thanks. the problem in applying a stylesheet to the sub tree
is that, i might not need the child elements as well. it would
be too much of overhead to loop through the content and detach
the child elements. Also it should be able to specify till what
level i need nested children for XSLT.
I am thinking of creating a dummy Element which gets the actual
node and the number of the neting i need, in the contructor and
recursively loop till the number of nesting.
i am not sure if this would create a problem though.
mani
-----Original Message-----
From: Laurent Bihanic [mailto:laurent.bihanic@atosorigin.com]
Sent: Wednesday, February 27, 2002 8:11 PM
To: Mani Doraisamy
Cc: jdom-interest@jdom.org
Subject: Re: [jdom-interest] JDOM and XSLT
Hi,
Mani Doraisamy wrote:
> Hi all,
> What is the fastest XSLT processor available in market. I am
> using JDOM and I would like to do XSLT so that I can present
> it as HTML.
Saxon (http://saxon.sourceforge.net) can be up to 3 times faster than Xalan,
depending on your stylesheet, and is very stable.
> Another question,
> my JDOM structure is huge and the Elements in the structure
> actually gets the value from performance intensive calculations
> and database operations, by overriding getText() method. Now
> when i want to do XSLT i wouldnt want the entire tree for XSLT.
> Although i can pass the whole tree for XSLT, what is the most
> performant way of doing XSLT for the subtree?
XSLT processes an entire document. So the only way to apply a stylesheet to
only a part of a document is to detach that part and make it a standalone
document. You can then apply the stylesheet to this "small" document and
attach the result back to the original document.
Hope this helps,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020228/f39091ec/attachment.htm
From jmuhlestein at i-link.net Wed Feb 27 13:28:39 2002
From: jmuhlestein at i-link.net (John Muhlestein)
Date: Fri Aug 6 17:07:26 2004
Subject: [jdom-interest] Schema Validation and Windows 98
Message-ID:
I have bumped into a problem attempting to do validation against a schema.
When I parse my documet using SAXBuilder builder = new SAXBuilder(true) I
get an exception stating that my root element must be declared.
Here is where it gets funny. On both Linux and Windows NT the xml document
parses without any problems. When I execute the same program (via ant) on
Windows 98 I get the exception.
-- My schema definition is sitting on one of our intranet servers so the
uri reference is valid.
-- The document parsed just fine against a DTD sitting on the same intranet
server.
-- The schema definition parsed without errors (well formed)
I'm stumped,
Has anyone else run into problems on Win98
The only other differences besides OS is there are different JVM's on each
machine (IBM, whatever comes w/ JBuilder4, and SUN) though all are version
1.3.1
I am including a copy of the xml and xsd (Just made up content for a class
I'm teaching at my work).
Thanks in advance,
John
<> <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: olympicsxsd.xml
Type: application/octet-stream
Size: 3221 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20020227/6d81966a/olympicsxsd.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: olympics.xsd
Type: application/octet-stream
Size: 3349 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20020227/6d81966a/olympics.obj
From ian.lea at blackwell.co.uk Wed Feb 27 13:37:47 2002
From: ian.lea at blackwell.co.uk (Ian Lea)
Date: Fri Aug 6 17:07:26 2004
Subject: [jdom-interest] HTML to XHTML?
References: <002501c1bfb9$37817310$d77dfea9@anna>
Message-ID: <3C7D51AB.58BA6A00@blackwell.co.uk>
JTidy (http://www.google.com/search?hl=en&q=jtidy) does at least
some of this. Possibly all of it.
--
Ian.
"W. Gao" wrote:
>
> Hi,
>
> Sorry if this is a unrelated question. I want to create a DOM tree from a XHTML file. If I get errors, I want to use a translator or some tools to convert the .html file to XHTML file and parse it again. I want my program to fail only after this attempt fails. Does anyone know where I can find this kind of software? Thanks.
>
> Wei
From jmuhlestein at i-link.net Wed Feb 27 14:11:51 2002
From: jmuhlestein at i-link.net (John Muhlestein)
Date: Fri Aug 6 17:07:26 2004
Subject: [jdom-interest] Schema Validation and Windows 98
Message-ID:
I forgot to mention. I am using code from cvs from about 1 week ago.
John
> -----Original Message-----
> From: John Muhlestein [mailto:jmuhlestein@i-link.net]
> Sent: Wednesday, February 27, 2002 2:29 PM
> To: 'jdom-interest@jdom.org'
> Subject: [jdom-interest] Schema Validation and Windows 98
>
>
> I have bumped into a problem attempting to do validation
> against a schema.
>
> When I parse my documet using SAXBuilder builder = new
> SAXBuilder(true) I
> get an exception stating that my root element must be declared.
>
> Here is where it gets funny. On both Linux and Windows NT
> the xml document
> parses without any problems. When I execute the same program
> (via ant) on
> Windows 98 I get the exception.
>
> -- My schema definition is sitting on one of our intranet
> servers so the
> uri reference is valid.
> -- The document parsed just fine against a DTD sitting on
> the same intranet
> server.
> -- The schema definition parsed without errors (well formed)
>
> I'm stumped,
> Has anyone else run into problems on Win98
>
> The only other differences besides OS is there are different
> JVM's on each
> machine (IBM, whatever comes w/ JBuilder4, and SUN) though
> all are version
> 1.3.1
>
> I am including a copy of the xml and xsd (Just made up
> content for a class
> I'm teaching at my work).
>
> Thanks in advance,
>
> John
>
>
> <> < |