You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Donald Ball <ba...@webslingerZ.com> on 2000/05/23 08:27:27 UTC
XInclude Processor should be fixed now
grab it out of CVS if you've a notion and try it out
apache->cocoon not tomcat->cocoon
Posted by Kenwrick Chan <kc...@hawaii.edu>.
Folks,
I'm running Apache 1.3.12, tomcat 3.1, and cocoon 1.7.4 on solaris 2.6. I've added
the following to my httpd.conf file.
AddType text/xml .xml
AddHandler jserv-servlet .xml
Apache forwards any .xml extension files off to tomcat/cocoon if I have a symbolic
link from the .xml files in my apache htdocs directory to .xml files in my tomcat
directory (or vice versa). Is there a way to set this up such that the .xml files
only need to exist in the apache htdocs directory? I'm working on a project with a
short time frame so I may not be able to impliment the whole project with cocoon.
I'd like to be able to mix and match cocoon and php pages, but not have users
access my files via the tomcat directory tree.
Thanks,
Kenwrick
Re: XInclude Processor should be fixed now
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 5 Jun 2000, Daniel Schneider wrote:
> > On Sat, 3 Jun 2000, Daniel Schneider wrote:
> >
> > > > On Fri, 2 Jun 2000, Daniel Schneider wrote:
> > > >
> .......
> > > // (3) then catch the special node
> > > // loop
> > > node = children.item(i)
> > > int type = node.getNodeType();
> > > switch ( type ) {
> > > case Node.DOCUMENT_TYPE_NODE: {
> > > // NOW KILL THE THING :)
> > > doc.removeChild(node);
> > > // exit loop
> >
> > You sure got the right idea. I just checked in a patch based on this,
> > check it out and see if it helps your problem.
> >
> Hi thanx a lot for looking into this, ..... but no, it does not help :(
>
> In my uneducated guess there is a problem with the parser. I don't
> have any clue what that might be. I looked at
> org.apache.cocoon.parser.XercesParser and its code does not seem to
> ask for any validation entailing that the external DTD must be read
> (Anyhow the question WHY xerces can not find a simple relative DTD
> declaration remains is another thing to look at ....)
>
> I diversified a bit your error catching and sent messages to the log file.
> So basically the thing breaks BEFORE your stripDocumentTypeNodes fix:
>
> [05/06/2000 20:37:52:046 CEST] +++ processXIncludeElement +++ SAX exception found
> [05/06/2000 20:37:52:047 CEST] File "file:/hello.dtd" not found. [FATAL ERROR] [File:
> "null" Line: -1 Column: -1]
> [05/06/2000 20:37:52:047 CEST] *** Other exception found:
> java.lang.NullPointerException
>
> Code snippet:
>
> try {
> included_document = parser.parse(input,false);
> stripDocumentTypeNodes(included_document.getDocumentElement());
> // stripDocumentTypeNodes(included_document);
> }
> catch (SAXParseException e) {
> logger.log("+++ processXIncludeElement +++ The File is not well formed.", 1);
> logger.log(e.getMessage()
> + " at line " + e.getLineNumber()
> + ", column " + e.getColumnNumber(), 1);
> }
> catch (SAXException e) {
> logger.log("+++ processXIncludeElement +++ SAX exception found", 1);
> logger.log(e.getMessage(), 1);
> // e.printStackTrace(logger);
> }
> .... and so forth
>
> If I am right you can't do anything about this and I don't know who's problem
> this might be. Just in case Stefano is listening in: My main
> motivation for wanting xincluded files to have DTD declarations is that I believe
> that even "sloppy" Web sites have to make sure that XML is somewhat valid .. but
> unfourtunately it is difficult for some persons to remember removing the DTD,
> especically if the WWW tree is mounted on all local file systems
> (got empirical proof for that)... and finally the tools we are using can't
> read DTDs over HTTP (so absolute URLs are out too).
Actually, I reckon that if I called setSystemId on the InputSource I'm
passing to Xerces, it should be able to resolve the relative link to the
DTD with no trouble. Question is, what parameter to I use when calling
setSystemId...? Anyone have a clue for me?
- donald
Re: XInclude Processor should be fixed now
Posted by Daniel Schneider <Da...@tecfa.unige.ch>.
Donald Ball wrote:
>
> On Sat, 3 Jun 2000, Daniel Schneider wrote:
>
> > > On Fri, 2 Jun 2000, Daniel Schneider wrote:
> > >
.......
> > // (3) then catch the special node
> > // loop
> > node = children.item(i)
> > int type = node.getNodeType();
> > switch ( type ) {
> > case Node.DOCUMENT_TYPE_NODE: {
> > // NOW KILL THE THING :)
> > doc.removeChild(node);
> > // exit loop
>
> You sure got the right idea. I just checked in a patch based on this,
> check it out and see if it helps your problem.
>
Hi thanx a lot for looking into this, ..... but no, it does not help :(
In my uneducated guess there is a problem with the parser. I don't have
any clue what that might be. I looked at org.apache.cocoon.parser.XercesParser
and its code does not seem to ask for any validation entailing that the
external DTD must be read (Anyhow the question WHY xerces can not find
a simple relative DTD declaration remains is another thing to look at ....)
I diversified a bit your error catching and sent messages to the log file.
So basically the thing breaks BEFORE your stripDocumentTypeNodes fix:
[05/06/2000 20:37:52:046 CEST] +++ processXIncludeElement +++ SAX exception found
[05/06/2000 20:37:52:047 CEST] File "file:/hello.dtd" not found. [FATAL ERROR] [File:
"null" Line: -1 Column: -1]
[05/06/2000 20:37:52:047 CEST] *** Other exception found:
java.lang.NullPointerException
Code snippet:
try {
included_document = parser.parse(input,false);
stripDocumentTypeNodes(included_document.getDocumentElement());
// stripDocumentTypeNodes(included_document);
}
catch (SAXParseException e) {
logger.log("+++ processXIncludeElement +++ The File is not well formed.", 1);
logger.log(e.getMessage()
+ " at line " + e.getLineNumber()
+ ", column " + e.getColumnNumber(), 1);
}
catch (SAXException e) {
logger.log("+++ processXIncludeElement +++ SAX exception found", 1);
logger.log(e.getMessage(), 1);
// e.printStackTrace(logger);
}
.... and so forth
If I am right you can't do anything about this and I don't know who's problem
this might be. Just in case Stefano is listening in: My main
motivation for wanting xincluded files to have DTD declarations is that I believe
that even "sloppy" Web sites have to make sure that XML is somewhat valid .. but
unfourtunately it is difficult for some persons to remember removing the DTD,
especically if the WWW tree is mounted on all local file systems
(got empirical proof for that)... and finally the tools we are using can't
read DTDs over HTTP (so absolute URLs are out too).
- Daniel
PS: The examples on my site (previous postings) won't break now, but are empty because
of my error catching.
Re: XInclude Processor should be fixed now
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sat, 3 Jun 2000, Daniel Schneider wrote:
> > On Fri, 2 Jun 2000, Daniel Schneider wrote:
> >
> Since I hardly can be called a programmer and since I never did any
> serious Java & XML it took me few hours to find an idea (don't know if
> it's the best way).
>
> // (1) When you have
> doc = parser.getDocument();
> // (2) DO NOT doc.getDocumentElement();
> // but look at the children
> children = node.getChildNodes();
> // (3) then catch the special node
> // loop
> node = children.item(i)
> int type = node.getNodeType();
> switch ( type ) {
> case Node.DOCUMENT_TYPE_NODE: {
> // NOW KILL THE THING :)
> doc.removeChild(node);
> // exit loop
You sure got the right idea. I just checked in a patch based on this,
check it out and see if it helps your problem.
- donald
Re: XInclude Processor should be fixed now
Posted by Daniel Schneider <Da...@tecfa.unige.ch>.
Hi and thanks for your interest :)
-> anwser below
Donald Ball wrote:
>
> On Fri, 2 Jun 2000, Daniel Schneider wrote:
>
> > I don't know if anybody cares listening talking to myself, but including files
> > within files has become an obsession of mine in the last days, that is maybe
> > shared by other folks :)
> > Anyhow, I have a correction to make, should have thought of it before :(
> >
> > OK no DTD in included file
> > OK <!DOCTYPE hello SYSTEM
> > "http://tecfa2.unige.ch/guides/xml/cocoon/includes/hello.dtd">
> > BAD: <!DOCTYPE hello SYSTEM "hello.dtd">
>
> I suppose the proper and simple solution would be to remove the DOCTYPE
> declaration from the included document. Do you know how to strip that from
> a DOM?
>
> - donald
Since I hardly can be called a programmer and since I never did any
serious Java & XML it took me few hours to find an idea (don't know if
it's the best way).
// (1) When you have
doc = parser.getDocument();
// (2) DO NOT doc.getDocumentElement();
// but look at the children
children = node.getChildNodes();
// (3) then catch the special node
// loop
node = children.item(i)
int type = node.getNodeType();
switch ( type ) {
case Node.DOCUMENT_TYPE_NODE: {
// NOW KILL THE THING :)
doc.removeChild(node);
// exit loop
To demo this I wrote a servlet (adapted from some code in the xerces samples)
It prints the tree of an XML file ... plus tells what special nodes
it finds (like document_type or comments).
Directory with source: http://tecfa2.unige.ch/guides/java/staf2x/ex/xml/dom-tree/
Servlet running: http://tecfa2.unige.ch/servlet/DomTreeWriteServlet2?url=.....
e.g.
http://tecfa2.unige.ch/servlet/DomTreeWriteServlet2?url=http://tecfa.unige.ch/guides/xml/cocoon/includes/hello-with-url-dtd.xml
I don't know if this helps you fixing something and I certainly don't
know enough to discuss whether ripping this node away is the good solution.
- Greetings ! - Daniel
PS: I looked at XIncludeProcessor and don't understand where you read
this special node and therefore why your code should choke on "my
problem", but then again I am not good at programming and in addition
it's after mid-night ... and I need some sleep (else I would have
tried a few hours on XIncludeProcessor). Back on Monday :)
Re: XInclude Processor should be fixed now
Posted by Donald Ball <ba...@webslingerZ.com>.
On Fri, 2 Jun 2000, Daniel Schneider wrote:
> I don't know if anybody cares listening talking to myself, but including files
> within files has become an obsession of mine in the last days, that is maybe
> shared by other folks :)
> Anyhow, I have a correction to make, should have thought of it before :(
>
> OK no DTD in included file
> OK <!DOCTYPE hello SYSTEM
> "http://tecfa2.unige.ch/guides/xml/cocoon/includes/hello.dtd">
> BAD: <!DOCTYPE hello SYSTEM "hello.dtd">
I suppose the proper and simple solution would be to remove the DOCTYPE
declaration from the included document. Do you know how to strip that from
a DOM?
- donald
Re: XInclude Processor should be fixed now
Posted by Daniel Schneider <Da...@tecfa.unige.ch>.
I don't know if anybody cares listening talking to myself, but including files
within files has become an obsession of mine in the last days, that is maybe
shared by other folks :)
Anyhow, I have a correction to make, should have thought of it before :(
OK no DTD in included file
OK <!DOCTYPE hello SYSTEM
"http://tecfa2.unige.ch/guides/xml/cocoon/includes/hello.dtd">
BAD: <!DOCTYPE hello SYSTEM "hello.dtd">
So xinclude:include (and other mechanisms I tried) freak out when
- there is an external DTD declaration
- this declaration points to a simple file (or relative URL as I'd prefer calling it)
- it does work if the DTD declaration points to an URL !
(did not realize that in my previous posting)
So the situation is not as bad, it's just that my xemacs/psgml
(and other tools) do not want to read DTDs from URLs
(tho if I were an emacs hacker that certainly could be fixed ...).
Uuh, if any knowledgeable person replies to this, a hint about whether
Cocoon (or is it Xerces ?) ought to produce an error would be nice !
thanx & greetings - Daniel (with the usual disclaimers)
PS: Again, my quick and dirty test suite + a little comments is here:
http://tecfa2.unige.ch/guides/xml/cocoon/includes/ (cocoon 1.7.5 dev ??)
http://tecfa.unige.ch/guides/xml/cocoon/includes/ (cocoon 1.7.4)
ALSO PLEASE note that the source does not display with IE as it should.
(*.text are symbolic links to orginals and IE does not believe my server
that these are text/plain ...)
Finally, patching the cocoon 1.7.4 official jar file with just the xinclude
processor works :)
http://tecfa2.unige.ch/guides/xml/cocoon/includes/cocoon-fix.text
Re: XInclude Processor should be fixed now
Posted by Daniel Schneider <Da...@tecfa.unige.ch>.
Ian Abbott wrote:
>
> Daniel Schneider wrote:
.......
>
> Why not just download the 1.7.5-dev tarball from
> http://xml.apache.org/from-cvs/ and build using Ant (i.e. chmod ugo+x
> build.sh lib/bin/antRun; build.sh dist-tgz)? Maybe 1.7.5-dev has been
> patched in other places to XInclude better? Seems a lot easier than
> going through patching the 1.7.4 codebase with bits from 1.7.5-dev
> CVS...
>
Well I did not patch the codebase but I just switched 2 files into the
official 1.7.4 *.jar distribution.,... but anyhow you are right: it has
become very easy to compile a dev version now, so just did exactly what you
you suggested .... :)
Now, the problem remains the same and it would be cool if Donald Ball
could look at it when he is back. So again the problem is that
Cocoon breaks when I try to include a file that has a DTD declaration inside:
File http://tecfa2.unige.ch/guides/xml/cocoon/includes/include-include-dtd.sxml
(source is in include-entity.dtd.sxml.text)
----- begin
<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet href="style.xsl" type="text/xsl"?>
<?cocoon-process type="xinclude"?>
<?cocoon-process type="xslt"?>
<?cocoon-format type="text/xml"?>
<page xmlns:xinclude="http://www.w3.org/1999/XML/xinclude">
<xinclude:include parse="xml" href="hello-with-dtd3.xml"/>
</page>
---- end
File hello-with-dtd3.xml:
--- begin
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE hello SYSTEM "hello.dtd">
<hello>
Hello XML !
(xml has DTD)
</hello>
---- end
This might be totally illegal (to have a DTD within an imported file).
But as far as goes my vague understanding of the philosophy of XML
one ought to be able to build a pig piece of xml by combining various
small and valid XML files ... of course I may be wrong :)
Btw doing the same thing with the XSL document() function works, except
that the Cocoon's cache doesn't see the change. XML file remains the
same for Cocoon because it's the XSL inside some dummy stable XML file
that includes the XML file(s),
My Setup:
Directory: http://tecfa2.unige.ch/guides/xml/cocoon/includes/
With:xml-cocoon_20000526101502.tar.gz, ApacheJServ/1.1 and java 1.2
http://tecfa2.unige.ch/servlet/Cocoon.sxml
- thanx and greetings !
Dr Daniel K.Schneider, TECFA (Educational Technologies and Learning)
Faculte de Psychologie et des Sciences de l'Education, University of Geneva,
email: Daniel.Schneider@tecfa.unige.ch
www: http://tecfa.unige.ch/tecfa-people/schneider.html
MOO: tecfamoo.unige.ch 7777
TECFA - FPSE - Université de Genève
40, Bd. du Pont d'Arve, 1205 Genève
Tel: 41 22 705 9377 - Fax: 41 22 705 9379 - Office#: 6359
Re: XInclude Processor should be fixed now
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 25/5/00 at 10:20 am, iana@cinesite.co.uk (Ian Abbott) wrote:
>Why not just download the 1.7.5-dev tarball from
>http://xml.apache.org/from-cvs/ and build using Ant (i.e. chmod ugo+x
>build.sh lib/bin/antRun; build.sh dist-tgz)? Maybe 1.7.5-dev has been
>patched in other places to XInclude better? Seems a lot easier than
>going through patching the 1.7.4 codebase with bits from 1.7.5-dev
>CVS...
I am still confused about the compilation issue.
Do I need Java 1.2 to compile Cocoon 1.x?
thanks Jeremy
____________________________________________________________________
Jeremy Quinn media.demon
webSpace Design
<ma...@media.demon.co.uk> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: XInclude Processor should be fixed now
Posted by Ian Abbott <ia...@cinesite.co.uk>.
Daniel Schneider wrote:
>
> I got XIncludeProcessor from CVS on May 24, did ONLY add these classes
> to cocoon.jar as it was distributed. So Cocoon is standard 1.7.4 except
> the XIncludeProcessor classes.
>
Why not just download the 1.7.5-dev tarball from
http://xml.apache.org/from-cvs/ and build using Ant (i.e. chmod ugo+x
build.sh lib/bin/antRun; build.sh dist-tgz)? Maybe 1.7.5-dev has been
patched in other places to XInclude better? Seems a lot easier than
going through patching the 1.7.4 codebase with bits from 1.7.5-dev
CVS...
Ian
--
ian abbott: www programmer/designer, cinesite visual effects eur
@work: iana@cinesite.co.uk t +44 20 7973 4344 f +44 20 7973 4040
cinesite europe - 9/12 carlisle street, soho, london, uk w1v 5rg
kb{ the longeared ones are coming. run run run for your lives. }
Re: XInclude Processor should be fixed now
Posted by Daniel Schneider <Da...@tecfa.unige.ch>.
Hello,
I don't know if this is a bug or a feature or whatever. When I
include files that have a DTD declaration like
<!DOCTYPE hello SYSTEM "hello.dtd">
something breaks:
java.lang.NullPointerException at
org.apache.cocoon.processor.xinclude.XIncludeProcessor$XIncludeProcessorWorker.processXIncludeElement(Compiled
Code)
I got XIncludeProcessor from CVS on May 24, did ONLY add these classes
to cocoon.jar as it was distributed. So Cocoon is standard 1.7.4 except
the XIncludeProcessor classes.
The full example is available at:
http://tecfa2.unige.ch/guides/xml/cocoon/includes/
Compare the files:
include-include.sxml alias include-include.sxml.text (works)
include-include-dtd.sxml alias include-include-dtd.sxml.text (BREAKS)
*.xsml files are Cocoon processed. *.xml and *.text files are not
Note:
Something similar happens when I try to include files using entities
(examples in the same directory) This does NOT happen when I use the
XSL document() function.
- greetings ! Daniel
PS: Why would I want to have a DTD in "production" files ? Makes work
much simpler. It is a pain if you have to add/remove DTD declaration
all the time you just edit a file. In my environment you just go
"edit the file", "save the file", reload and see what happens instead
of carefully preparing some sort of distribution ...
In chapter 9 "Viewing XML converted to HTML" McLaughlin says that one
should remove DTDs. I really don't see why ... I wish he could expand
a bit. I don't buy his explanation :)
I am also aware that I may have to add/remove processing declarations to
my examples with DTDs, that I might not use
<xinclude:include parse="xml" href="hello3.xml"/> correctly etc.
I tried a few variants .... anyhow
any help/comments on my problems would be appreciated.
--
Dr Daniel K.Schneider, TECFA (Educational Technologies and Learning)
Faculte de Psychologie et des Sciences de l'Education, University of Geneva,
email: Daniel.Schneider@tecfa.unige.ch
www: http://tecfa.unige.ch/tecfa-people/schneider.html
MOO: tecfamoo.unige.ch 7777
TECFA - FPSE - Université de Genève
40, Bd. du Pont d'Arve, 1205 Genève
Tel: 41 22 705 9377 - Fax: 41 22 705 9379 - Office#: 6359
Re: XInclude Processor should be fixed now
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 23 May 2000, Antonio Cabezuelo Vivo wrote:
> It seems to work fine.
>
> Thanks a lot Donald.
And thanks to you for finding this bug! I look forward to the next one(s).
- donald
Re: XInclude Processor should be fixed now
Posted by Antonio Cabezuelo Vivo <an...@eresmas.com>.
It seems to work fine.
Thanks a lot Donald.
Regards,
___
Antonio Cabezuelo
----- Original Message -----
From: Donald Ball <ba...@webslingerZ.com>
To: <co...@xml.apache.org>
Sent: Tuesday, May 23, 2000 8:27 AM
Subject: XInclude Processor should be fixed now
> grab it out of CVS if you've a notion and try it out
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org