Basic authentication
I have failed to find anything in the docs about implementing crude Apache-style authentication (eg equivalent to .htaccess). We don't have any global auth framework yet, so the more sophisticated methods won't be applicable. The user requirement is simply to restrict some directories to user/psw pairs like we did before :-) Can someone point me at what I must have missed? I guess I could fake it up (although I don't know how to call crypt() from within an XSLT script) but I felt there is probably a better way... ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Basic authentication
On Mon, 2003-06-16 at 22:11, Nathaniel Alfred wrote: This sort of thing is usually done by an upstream Apache or in the servlet engine (Tomcat) configuration. Ah, OK. Thanks. I thought Cocoon had something built in. Dunno where I got that idea... There isn't an upstream Apache (well, we have it on port 80, with Cocoon on 8080, but the two run independently: Cocoon is serviced by its own Tomcat). Now to find out where to do this in Tomcat... ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TeX to PDF serializator
On Tue, 2003-06-10 at 23:03, Alexander Schatten wrote: Andreas Kuckartz wrote: I think it's not in the the cocoon project's goals. Why not? A good reason which I can see for such a component is that you could use the features of TeX to automatically create printable pages with high quality. This has come up several times before. I agree completely: many people want to use LaTeX to create PDF because it does a vastly better job than any of the FOP systems. I cant get the point. Cocoon is an XML publishing tool. The central idea is the XML based pipeline. Sure. So why not let external processors into the pipeline? Other systems do (eg PropelX). You seem to have missed the point that at *some* stage, your text *has* to cease being XML and become pixels if you want it read. It's just a case of when that happens: normally we want to keep it in XML as long as possible, because Cocoon and other XML systems provide better control than non-XML systems. But only up to a point: I would argue that because LaTeX does a better job of formatting than anything else, *that* is the point when my text should leave XML and start the journey to pixels. Why should Cocoon now be responsible for a hodgepodge of other publication tasks? how does TEX fit into the pipeline? not at all. Very easily. It's almost trivial to write text-mode XSLT which will output LaTeX source code. All that is needed is to spawn a task which runs LaTeX on that code (and can subspawn BIBTeX and makeindex). only if (what I would *really* appreciate) someone would generate an TeX generator, that creates XML out of tex; this would seamless integrate also TeX ressources. This is really a bad idea, I'm afraid, and the very last thing we actually want or need. TeX systems are for formatting: you use them to typeset something which was created/edited/stored/manipulated in (for example) XML. Because of the way history happened, TeX preceded XML, so we have a lot of legacy TeX. Sure it would be nice to have a tex2xml which would do the job (actually there are a few attempts) but if you stop for a moment to think of the ghastly mess which most authors make of TeX, you'll realise why there is no such animal right now. Yes, you could write a conversion from well-formed LaTeX to XML (I actually did one a long time ago, for SGML) but the instant an author starts to write her own macros or mess manually with the formatting, the model breaks and translation becomes virtually impossible. To effect it fully you'd need to rewrite TeX the program to output XML instead of DVI or PDF, and you'd *still* be in trouble because most of what TeX formats carries nothing with it which can be used to indicate markup, unless you want to go back to the days of b, i, and u. but TeX processing is obviously no Cocoon purpose. On the contrary, it's badly needed. Even more so is a latex-mode for XSLT (but that's a different thing). The next one will ask, why Cocoon cannot create WML from powerpoint or SVG from Postscript. Because PowerPoint is not (yet) an XML format, nor is PostScript. What we need to to be able to go from XML to PDF via LaTeX. In any case, it shouldn't be specific to LaTeX. All we need is an ability of Cocoon to spawn an external process and serve the result back to the user with a defined media type. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TeX to PDF serializator
On Tue, 2003-06-10 at 23:57, Andre Thenot wrote: On Tuesday, June 10, 2003, at 06:37 PM, Peter Flynn wrote: In any case, it shouldn't be specific to LaTeX. All we need is an ability of Cocoon to spawn an external process and serve the result back to the user with a defined media type. There's a _big_ problem with this: how do I apply a transformer on an external process? I cant! You don't, and you don't need to. All you need to do is transform the XML using an XSLT text-mode stylesheet and feed the *output* to LaTeX, then pass the resulting PDF back to the user. This is the same concept as transforming XML to FO and passing the result through a FO processor and passing the resulting PDF back to the user. For your use (reading and serving), you could write a servlet (or even use a plain web server, for that matter). I'd rather use Cocoon to manage the process. Cocoon is an *XML* publishing framework. Except for the initial input and final output, everything MUST be XML. I think this is more of a religious argument than a practical one. The problem is that the typographic quality of FO processors is extremely poor compared with LaTeX, and there seems little point in constantly reinventing the wheel by writing vastly complex XSL to output PDF when the job can be done more simply and accurately and efficiently by outputting LaTeX from XSLT. I'm astonished that the authors of FO processors have not learned from 25 years of automated typesetting using LaTeX. I remember reading about TeXML a little while ago; I don't know how broad it is or even if it's still alive. When it's better developed that would answer the case, as it would accept XML as input and emit PDF as output, same as FOP. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: newbies documentation - yet another wiki?
Manos wrote: No, I was talking about Microsoft Office XP not 2k; it does have native XML support. For example You can save Microsoft Excel 2002 spreadsheets and Microsoft Access 2002 database tables, queries, and views as XML.[1]. Please not that I'm *not* an M$ fun ;-) Office-11 will have native XML support (ie it will be able to edit an XML document according to a Schema (not a DTD) you provide, not just its own internal one). ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Running command-line programs in a pipeline
Is it possible to specify a pipeline which instantiates a non-SAX transformation (eg running some arbitrary commandline program on the pipeline content or a generated file and serving the result)? An example would be to transform XML to LaTeX with XSLT and then run LaTeX in order to serve DVI instead of PDF. ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
testing error
I've added the following lines to the distribution sitemap.xmap (using the jakarta-tomcat-4.0.4-b2-01-LE-jdk14 distribution), immediately before the section commented Sites: map:match pattern=cc map:generate src=cc/homepage.xml/ map:transform src=cc/styles/homepage.xsl/ map:serialize type=html/ /map:match map:match pattern=cc/objectives map:generate src=cc/info/objectives.xml/ map:transform src=cc/styles/information.xsl/ map:serialize type=html/ /map:match map:match pattern=information.css map:read mime-type=text/css src=cc/styles/information.css/ /map:match !-- Sites === -- The files are all in place as given within the cocoon directory: $ ls -lR cc cc: total 16 drwxrwxr-x2 peterpeter4096 Jul 15 12:24 dtds -rw-rw-r--1 peterpeter 403 Jul 11 11:27 homepage.xml drwxrwxr-x2 peterpeter4096 Jul 15 11:44 info drwxrwxr-x2 peterpeter4096 Jul 15 12:25 styles cc/dtds: total 4 -rw-rw-r--1 peterpeter 962 Jul 11 09:13 website.dtd cc/info: total 4 -rw-rw-r--1 peterpeter3568 Jul 12 14:59 objectives.xml cc/styles: total 16 -rw-rw-r--1 peterpeter 331 Jul 11 09:16 homepage.xsl -rw-rw-r--1 peterpeter 155 Jul 12 14:57 information.css -rw-rw-r--1 peterpeter4996 Jul 12 14:59 information.xsl $ and both XML files have been validated with nsgmls and they both transform correctly with xt and their relevant XSL files, so I'm satisfied the documents are syntactically correct. When I request cc in a browser (ie http://localhost:8080/cocoon/cc) it works perfectly (as do all the distro examples). But when I try http://localhost:8080/cc/objectives I get The org.apache.cocoon.www.sitemap_xmap notifies that org.apache.cocoon.ProcessingException says: Exception in creating Transform Handler More precisely: org.apache.cocoon.ProcessingException: Exception in creating Transform Handler: java.lang.NullPointerException This sounds as if it cannot fire up the transformer. I've obviously made some error, but I can't see where. This is under RHL 7.2 with j2sdk1.4.0 on a 500MHz Pentium with 128Mb memory and several Gb of spare disk. I can't work out why it would have such a problem. The trace says (to start with) Original exception : java.lang.NullPointerException at org.apache.xalan.processor.StylesheetHandler.startElement(StylesheetHandler.java:656) at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:445) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:216) at org.apache.xerces.impl.XMLNamespaceBinder.handleStartElement(XMLNamespaceBinder.java:829) at org.apache.xerces.impl.XMLNamespaceBinder.emptyElement(XMLNamespaceBinder.java:590) at org.apache.xerces.impl.dtd.XMLDTDValidator.emptyElement(XMLDTDValidator.java:829) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:748) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1454) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:333) at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:525) at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:581) Is there any way of making it turn off the Java stuff and turn on proper reporting, so I can see the line number and character offset in the XML or XSL document where the error was thrown? The Java trace is fine for tracking bugs in the Java code, but where the error is the likely to be the user's (ie, mine) rather than Cocoon's authors' (yours :-) we do need user-document error reporting, if only to ascertain if the bug really is in the user document and not in the Java code. ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Still nothing served
I'm still having no luck getting Cocoon to serve me a file of my own.
It's working fine for the distro files, docs, etc.
I added this to sitemap.xmap:
map:match pattern=foo/**
map:generate src=foo/foo.xml/
map:transform src=foo/foo.xsl/
map:serialize type=html/
/map:match
(in the space just above the example map:match pattern=**/)
The intention is to test if Cocon will serve a request for
localhost:8080/coocon/foo/{anything} by responding with the
transformed result of a single named XML file through a single named
XSL file and nothing else (this being the simplest possible static
case).
I created a directory foo in the installation directory
jakarta-tomcat-4.0.4-b2-01-LE-jdk14/webapps/cocoon
I put in there a 2-line foo.xml:
?xml version=1.0?
foobar/foo
and a short foo.xsl to transform it to HTML:
?xml version=1.0 encoding=utf-8?
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0
xsl:output method=html/
xsl:template match=/
html
body bgcolor=#FF
xsl:apply-templates/
/body
/html
/xsl:template
xsl:template match=foo
h1
xsl:apply-templates/
/h1
/xsl:template
/xsl:stylesheet
(which all works: you can see it in Cocoon-1 at http://www.ucc.ie/tmp/foo.xml)
When I load the URL http://oimelc.ucc.ie:8080/cocoon/foo/ I get
nothing at all: the browser (Moz 1.0) spins its wheels and waits and
waits and waits and nothing happens. The log file says:
143.239.128.48 - - [05/Jun/2002:14:49:33 00] GET /cocoon/foo/foo.xml HTTP/1.1 200
3854
so something is happening...but what? And why no response?
a. Do I have to shutdown and startup Cocoon every time I change
sitemap.xmap? I've tried with and without and it seems to have
no effect.
b. What directory is the match pattern relative to? This is not
specified in the docs, so I'm guessing the directory within
webapps where Tomcat created cocoon/ from coocon.war when it
was installed (the one quoted above).
c. There is clearly something wrong with my syntax or assumptions
but it is not clear what.
///Peter
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fw: Serving static XML files a la Cocoon-1
Sometimes you need to use unique XSL file for several XML files,
but this is also solved by the sitemap in a varios ways, e.g.:
map:match pattern=3D*.xml
map:generate src=3D{1}.xml/
map:transform src=3D{1}.xsl/
map:serialize /
/map:match
That 1:1 kind of match is very rare. Much more importantly, there
seems to be no provision in sitemap.xmap for binding a stylesheet to a
DTD. Let's suppose I have 3,000 DocBook article documents in many
many directories, but these directories also contain many other .xml
files (related to the articles in many different ways) which require
different stylesheets, according to their DTD.
I want all *.xml files which use DocBook article to be served into
HTML using foo.xsl; all *.xml which use (say) TEI-Lite to be served
using another stylesheet, etc etc. Can this be done?
///Peter
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serving static XML files a la Cocoon-1
Key distinction: DTDs are used to *VALIDATE*, not render. That's one reason. The other is to allow the document to be edited in a structured editor. Our documents are all created by humans, so we need to use a system which guides creation and editing. The Document Type Declaration is therefore present in the XML file so that the type of document can be detected by software (whether or not the DTD is used). The root element type name is insufficient for this (too many DTDs for articles use the root element type article already :-) True, but it is not uncomon to have a working stylsheet in applications, and before release the web monkeys are let loose to make it look nice. Of course both these developments can be happening simultaneously. THe doc writer should not care how the info is presented, that isn't their concern. This is a contentious point. Frequently the doc writer is the only one who knows how the information should be presented: document stylists are notoriously ignorant of technical matters, just as authors are notoriously ignorant of typographic matters. The sample sitemap bundled with Cocoon offers these 'defaults' already. If that is so, why does it not transform my sample XML document with its accompanying XSL stylesheet? Are you volunteering to write something that reacts to PIs? :-) Done too many of them already. It's not really a trivial task, and considering the amount of work involved in it, for something we really don't want to encourage, its not a likely thing to happen soon. No, I don't want to if I can avoid it. PIs should be kept for their real task: affecting processing *outside* the domain of the processor (think TeX/dvi \specials). Basically tweaks. Going back to your associated XSL document, and distributing the files w/o a server: you can still do that with your PIs. A browser that knows how to treat the PIs will do so correctly. However, for serving up to older browsers, you should use the preferred method. Your Sitemap won't change much. You stated something like every few years. When you change your site, you only need to update the sitemap to point to the new stylesheet--even if you have hundreds of documents by then. I still need to bind a stylesheet to the documents. The Document Type is the obvious key, but I can't see how to achieve this in sitemap.xmap ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serving static XML files a la Cocoon-1
Key distinction: DTDs are used to *VALIDATE*, not render. This is a common fallacy, fast attaining status of an Urban Myth. DTDs may also be required at the rendering stage if they contain default or fixed attribute values, declarations of external entities, notations, or id/idref attributes. DTDs are also required by some editors, as mentioned earlier, not because they perform validation (which is useful) but because they are used to guide or prompt (and sometimes force :-) the author while writing (a form of validation, but not the act of validation). ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serving static XML files a la Cocoon-1
=?ISO-8859-1?Q?C=E9dric_Damioli?= [EMAIL PROTECTED] writes:
Of course you don't have to put an entry for each new doc : you simply
need the most common C2 pipeline:
map:match pattern=**.xml
map:generate src={1}.xml/
map:generate src=stylesheet.xsl/
map:serialize/
/map:match
This pipeline will process all the .xml files on your server. Does it
match your needs?
This assumes that all documents are processable using the same
stylesheet, which is not the case:
1. Documents of different types often require different stylesheets
because that is their nature: they describe different things, and
styling is a convenient way of communicating this to a reader.
2. Documents of different types may reside in the same directory, and
their filenames cannot be used to identify the document type (nor
should they be, they're already abused to carry way too much
information :-).
3. The document type is identified in the Document Type Declaration
in each file. This is what it's for.
4. Different document types can have a root element type name which is
the same (cf. ISO 12083 book vs. DocBook's book).
Am I right in assuming that Cocoon-2 is based on the premise that
all distinction between document files can be done only on the basis
of directory/file names (and REs matching them)?
The DocType Declaration is the only authoritative statement of the
document type. That is why is exists. If the PI has (rightly) been
retired as Cocoon's flag mechanism, something needs to be introduced
to replace it.
I realise this borders on heresy for some people, because it smacks of
using DTDs, which are anathema to many. But I'm afraid it's the
reality of publishing: not all documents are the same, and directory
and file names are not always [ab]usable as discriminators.
In another project, the opposite is true: documents are submitted for
inclusion in a huge range of document types (read: DTDs) but they
are required to look the same when viewed. Hence one stylesheet per
DTD, implementing lots of ways of getting a consistent look.
Maybe Cocoon can't be used for this any more, in which case I
apologise for wasting your time.
///Peter
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serving static XML files a la Cocoon-1
Bertrand writes:
Hey that's an easy one - allow me to quote Vadim's previous answer:
Read concept docs and sitemap docs on Cocoon site. Sitemap is
the only way to tell Cocoon what it needs to do. You should
spend some time to get it - once you get it, chances are, you
will love it.
Don't get me wrong, I love the idea of Cocoon. It was just an error
to distribute it without the previous default (Cocoon 1) already
enabled, ie any XML files already on disk should be processed with
their XSL[T] files and served up as HTML/PDF by default.
Something like
map:match pattern=3Drtfm/*.xml
map:generate src=3Dsomewhere/{1}.xml/
But I don't want to *generate* any XML. I already have XML documents.
map:transform src=3Dxslt-stuff/transform.xsl/
map:serialize type=3Dxml/
/map:match
///Peter
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serving static XML files a la Cocoon-1
Of course you don't have to put an entry for each new doc :
That is not at all obvious from the doc.
you simpl=
y=20
need the most common C2 pipeline:
map:match pattern=3D**.xml
map:generate src=3D{1}.xml/
map:generate src=3Dstylesheet.xsl/
map:serialize/
/map:match
This pipeline will process all the .xml files on your server. Does it=
=20
match your needs?
Very close, except that all the XML files already identify their
stylesheet in an xml-stylesheet PI, so Cocoon would need to honor
this.
///Peter
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serving static XML files a la Cocoon-1
!-- it's a customary to have welcome.xml instead of index.xml ;) -- Better. Index.* has historical implications :-) PS I /believe/ you can get all this from the reading docs. I'm sure you can, but it's very non-obvious *where*, and there's a vast amount about SQL, scripting, forms and other (doubtless important) stuff which very much gets in the way of someone trying to move existing vanilla XML/XSLT functionality from Cocoon 1 to Cocoon 2 before starting to implement the new features. I'm documenting as I go: there will be a Beginners' Guide (*has* to be: I have users who want to do this stuff and they certainly don't want to know about SQL :-) ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serving static XML files a la Cocoon-1
Not necessarily. PIs are nice, but they are not standard accross all files. One thing that PIs don't allow is to easily retheme the entire site without changing the existing template. Absolutely. They're document-centric. And in any case, the xml-stylesheet PI isn't a real PI. A real PI starts with the name of the program it is intended to be honored by (*ducking* :-) But it provides a useful in-document reminder of at least one possible stylesheet which will at least render *something* if the document is encountered in isolation: a very important safety-catch for a site full of research documents which academics may download at will. In the headlong panic to dress XML up in a business suit, it's sometimes forgotten that one principal function of markup is to identify textual information for use (mostly rendering) in a publishing context. No databases, no scripts, no SQL, no generators, just a large number of authors turning out XML. ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serving static XML files a la Cocoon-1
You don't understand the Cocoon2 concepts at all. I think you are deeply mistaken :-) It is nonsense to serve XML files with their XSL files : This is rubbish. Leave aside non-valid XML, as I don't use it. All valid XML documents adhere to a DTD by definition (omit Schemas, they're not relevant here). Each DTD has a stylesheet to render documents of its class. I require to serve the XML documents processed with the relevant XSL stylesheet into HTML. Each XSL stylesheet belongs to a DTD: that is, it is written to render documents written to that DTD. the principle is to separe data and presentation, ie XML source and XSL. Absolutely correct. This is what I do. I have a large number of XML files and a very small number of XSL files (one stylesheet per document type, modulo development). Each document type (in effect, DTD) has one stylesheet at any given point in time, so that all documents written to that DTD are served in a uniform format. Over time, a new format may be developed, at which stage it will be useful to be able to edit the sitemap to make all XML documents of a given type to use a new stylesheet. But this is a once-every-few-years task, not something I change every five minutes. So you have to write a pipeline (or to copy/paste one from an existing sitemap) to generate HTML stuff from XML by transforming it through XSL. The sample sitemap bundled with Cocoon offers these 'defaults' already. If that is so, why does it not transform my sample XML document with its accompanying XSL stylesheet? Please read the docs and reffer to the samples. They will learn you much. I have. I learned a lot, but nothing that I wanted. But I don't want to *generate* any XML. I already have XML documents. Yes, you want In Cocoon2 terminology, generate means you generate SAX events from a source. Ah. That's useful to know. Doubtless this is documented somewhere. But a quick scan of the docs shows generat[a-z]* is used with no explanation. In your case, the source is an XML document. So you have to use : map:generate src=XXX.xml/ No problem there. Thanks. ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: special characters for i18n
Really stupid question: How do you guys enter the special characters in utf-8 files? a) which special characters? XML is Unicode, there are thousands. b) if you're using a western european language, maybe use iso-8859-1 instead of utf-8. Do I need a special editor, how do I find out what (code?) to enter? If the character you want is one your operating system can display, and you've got a keyboard character or short cut for it, just type it. Example: a-with-umlaut, รค Linux: type AltGr-[ a Windows: type Alt-0-2-2-8 Mac: (some Mac user please suggest) If your editor won't accept these characters, trash it and get one that does. If the character is one your screen cannot display, or your keyboard cannot generate, type the numeric character entity (you need a table of Unicode characters to look it up, see www.unicode.org) Example: a-with-umlaut (again), type #x00E4; w-with-circumflex (Welsh), type #x0175; If you get black or open squares or other non-character symbols when you expect a printable character, it means your editor does not have a font which it can use for this character. In this case: * either get a font from someone in the community which uses these characters, * or test the file to make sure it really has stored the character (save it and check it via a browser or some system that displays the character), and then ignore it. ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serving static XML files a la Cocoon-1
Vadim writes: contain the ?cocoon-process type=xslt? Processing Instruction. This instruction is not working anymore. OK. The documentation does not mention this method of working. Has it been scrapped? Yes. Would be nice if there was a doc for Cocoon-1 users which explained this. Read concept docs and sitemap docs on Cocoon site. Sitemap is the only way to tell Cocoon what it needs to do. You should spend some time to get it - once you get it, chances are, you will love it. You must be kidding. Every time a user wants to put a new doc on the server, the administrator has to manually add an entry to the sitemap? This is the height of lunacy, and a surefire way to kill Cocoon stone dead. Requirement: an XML/XSL[T] server that simply recognises .xml, performs the relevant conversion, and ships out the result. Cocoon-1 did this fine: why break a perfectly good piece of software? ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Serving static XML files a la Cocoon-1
I finally got Cocoon running (scrapped everything, installed the Tomcat 4.0.4-b2-01-LE-jdk14 and went on from there and it worked fine). Initially I need urgently to get back to the stage I was at before with Cocoon 1, serving from XML files with XSLT stylesheets outputting HTML. However, Cocoon2 now being separate from my regular port-80 Apache server won't recognise XML files or process them even though they contain the ?cocoon-process type=xslt? Processing Instruction. The documentation does not mention this method of working. Has it been scrapped? All I can see are predefined conversions in the sitemaps: that won't work at all, as the whole objective is to server the texts direct from arbitrary XML files, just like Cocoon-1 did. Anyone got a pointer? ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stuck setting up Cocoon 2.0.1 with Tomcat 4.0.2
Marcelo F. Ochoa wrote: Dirk Louwers Copy xml-apis.jar, xalan.jar and batik.jar from Cocoon Home lib directory to Tomcat Home common/lib directory. ./tools/lib/xml-apis.jar OK No such file as xalan.jar, should I use ./tools/lib/xalan-2.2.0.jar No such file as batik.jar, should I use ./lib/optional/batik-libs-1.1.1.jar Aha! Yes! Restarting Apache *and* tomcat suddenly causes the .war file to be unwrapped. Excellent. This needs to be documented. But now http://localhost:8180/cocoon at least produces something, although it's the error message Cocoon 2 - Internal server error: type fatal message Language Exception description org.apache.cocoon.ProcessingException: Language Exception: org.apache.cocoon.components.language.LanguageException: Error compiling sitemap_xmap: Line 0, column 0: could not parse error message: error: Invalid class file format in /usr/java/j2sdk1.4.0/jre/lib/rt.jar(java/io/OutputStream.class). The major.minor version '48.0' is too recent for this tool to understand. /var/tomcat4/work/localhost/cocoon/cocoon-files/org/apache/cocoon/www/sitemap_xmap.java:12: Class java.io.OutputStream not found in import. import java.io.OutputStream; ^ Line 0, column 0: could not parse error message: error: Invalid class file format in /usr/java/j2sdk1.4.0/jre/lib/rt.jar(java/io/IOException.class). The major.minor version '48.0' is too recent for this tool to understand. What is this tool? Cocoon? Java1.4.0? Tomcat4.0.1? ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stuck setting up Cocoon 2.0.1 with Tomcat 4.0.2
Dirk Louwers writes: I've set up all the env variables. I've copied the cocoon.war file to = the webapps directory and tomcat unpacked the file and created a cocoon = directory structure, but when I try to access = http://localhost:8080/cocoon I get an error page. Can anybody help me = solve this problem? I get the same. No-one has suggested anything to do yet. It appears that Apache + tomcat + cocoon simply doesn't work at the moment: tomcat just fails to recognise cocoon.war ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Cocoon 2.0.1 + Tomcat 4.0 + JDK 1.4
Peter Baer writes: Dear Daniel, thank you for making this info public. Especially your hints about what versions to use helped me to finally get C2 working. The combination that works for us here is: - Java: Sun J2SDK 1.4.0 - Cocoon: Development snapshot xml-cocoon2_20020219112118.tar.gz, built with JNDI using Java 1.4 from Sun I just tried to build the only snapshot available in the CVS directory close to this date (xml-cocoon2_20020219172103.tar.gz) and it doesn't produce a cocoon.war file. It produces a cocoon.jar file instead. What should I do with it? Have you got a copy of the snapshot you used that I can download? My problem is that under no circumstances will tomcat do anything with cocoon.war. It just sits there in /var/tomcat/webapps. Is something supposed to happen when I restart tomcat? I'm still getting a 404 for my http://localhost:8180/cocoon - Tomcat: Jakarta-Tomcat 4.0.1 binary release - SuSE Linux 7.3 With all other combinations we got one of the well-known errors: Sitemap not available, major minor version number 48.0 etc. Eg, it *has not worked* with the Tomcat 4.0.2 binary release. And it *does not work* with C2 release version 2.0.1. So, please, folks on this list who have trouble to get C2 running: Your *best chance* appears to be to try a *C2 development snapshot* with *Tomcat 4.0.1* binary release! And thanks again, Daniel! Your XML page is of great value! Could you please repost this URL? ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stuck setting up Cocoon 2.0.1 with Tomcat 4.0.2
Marcelo F. Ochoa wrote: [blah] message: error: Invalid class file format in /usr/java/j2sdk1.4.0/jre/lib/rt.jar(java/io/IOException.class). The major.minor version '48.0' is too recent for this tool to understand. What is this tool? Cocoon? Java1.4.0? Tomcat4.0.1? Humm, seem to be a problem of jdk1.4.0, replace cocoon and tomcat's tools.jar by the jdk1.4.0 version of this jar. But neither cocoon nor tomcat has any tools.jar file! # cd cocoon-2.0.1 # find . -name 'tools*' ./tools # find /var/tomcat4 -name 'tools*' # These are both full, fresh distros downloaded the other day. Should I be looking for a hidden file or a file called something other than tools.jar? I can copy Sun's jdk tools.jar but that seems a little pointless as it's presumably the one being used anyway. ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Newbie FAQ (was Re: Just starting COCOON
Peter Schwenke writes: There has been discussions on the list that it is better to stick with Tomcat 4.0.2 for now. (http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=101363193404329w=2) But that's what I'm trying to install. Is the war file OK - Can you do a jar tvf on it? Permissions OK etc Yep. -rw-r--r--1 tomcat4 tomcat4 12052601 Feb 15 16:12 cocoon.war I and some co-workers have also been trying to get Cocoon running. I was recently put on a different project, but my co-workers report that downgrading to Tomcat 4.0.1 made things work. You might try that. Ah. Should that have read 4.0.1 above? Many thanks, I'll try. ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Newbie FAQ (was Re: Just starting COCOON
Found it. 4.0.1 only delivers and init.d script, no link. Started up fine, but it still ignores cocoon.war What *is* the trick to make tomcat recognise cocoon.war? Why the mystery? ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Newbie FAQ (was Re: Just starting COCOON
I'm trying to fill in the gaps in the documentation of the procedure for bringing up Cocoon. I'm doing this under a virgin installation of Red Hat 7.2 (enigma) with Apache 1.3, IBM Java2, and Tomcat4 (4.0.2). I'm sticking with RPMs as far as possible for the underlying support. (I previously had Cocoon 1 running very happily under RH6.2/Apache/JServ/Xerces/Xalan for about a year, and I have brought up Cocoon 1 under W2K for a client on several machines, so I hadn't reckoned on this being as difficult as it turns out.) It's not clear if this is a tomcat or a cocoon problem, or a bit of both, but it's obviously fairly major, so I'm posting to both user lists. On Wed, 23 Jan 2002 18:21:21 -0800, Vadim Gritsenko wrote Some more comments to follow Roger's email: I tried Cocoon binary download ... and it worked. Assuming that you have: 1. Servlet engine - Tomcat 4.0, Tomcat 3.3, or Resin 2.0.4 2. Windows machine or *NIX with X running (it is the case for the development machine, isn't it?) OK, both of these are fine, but the Tomcat default is port 8180 (undocumented). I installed (in order): IBMJava2-SDK-1.3-10.0 regexp-1.2-1 servletapi4-4.0.2-1 xerces-j-1.4.4-1 xerces-j-demo-1.4.4-1 tomcat4-4.0.2-1 tomcat4-webapps-4.0.2-1 and edited the /etc/tomcat4/conf/tomcat4.conf for the location of IBM's Java (didn't need changing). Also undocumented is the fact that the RPMs omit the startup.sh script and the tomcat4 binary by that name, and instead include /etc/rc.d/rc5.d/S80tomcat4 and /bin/dtomcat4. But it appears to start up without error, and the tomcat page appears at http://localhost:8180 just fine. So I unwrapped cocoon-2.0.1-bin.tar.gz and copied cocoon.war to /var/tomcat4/webapps, and stopped and restarted tomcat4. You have to just drop pre-compiled cocoon.war, and it will work out of the box as soon as container recognizes it (usually, restart is required). This is the problem. It's unrecognised. Trying to access http://localhost:8180/cocoon gets me: Apache Tomcat/4.0.2 - HTTP Status 404 - /cocoon type Status report message /cocoon description The requested resource (/cocoon) is not available. Cocoon.war is still sitting there in /var/tomcat4/webapps and nothing I can find to do will persuade tomcat to recognise it or do anything with it. From what I can glean from the docs, something (tomcat?) is supposed to open up cocoon.war and compile something out of it the first time tomcat is restarted. Presumably this means the simple presence of cocoon.war in /var/tomcat4/webapps is supposed to be enough to trigger tomcat into doing something with it? If so, something looks to be broken or hasn't been adequately documented. But: You may run into a problem if: 1. You do not have X (or never heard of it ;) XFree86 is running. 2. You do not have Xvfb (or never heard of it) I didn't have it, but I do now (XFree86-Xvfb-4.1.0-3). Stopped and restarted tomcat4 but cocoon still inactive as before. 3. You never heard of PJA and you do not know how to install it. Certainly, but it gets no mention in the docs. But it seems to be for headless systems, and I'm running X. 4. You run Cocoon 2-nd, 3-rd, n-th time and see exception thrown by HSQLDB (which was not there at the first run) Can't run cocoon because tomcat says it doesn't know about it (as above). 5. You want to remove SVG stuff completely SVG? What's SVG got to do with it? (Yes I know what SVG is, but I don't see its relevance here.) 6. You upgraded Cocoon and it stopped working Nope, fresh install. Some of these situations are covered in the installation doc and in the FAQ, others I will try to cover here: 3: PJA installation instructions (as it was reported by some users) have flaws; it was recommended to use installation instructions provided on PJA site. There are no installation instruction on http://www.eteks.com/pja/en/ but I'm assuming that I don't need it as I run X. I hope I covered here 80 to 90% of the newbie problems here. Mine is obviously one of the 10-20% but it seems more critical. An earlier user (Roger?) wrote: how to use it, all in one huge example webapp (much beyond a typical Hello World! example). Your starting point is getting this one huge example web app to deploy once or twice on tomcat by placing the cocoon.war file in the webapps folder of tomcat. Once or twice? Getting it to run once would be nice :-) The as is Cocoon installation either works or it doesn't. There is nothing you can do right or wrong. This needs some expansion. If it's shipped wrongly configured, perhaps it would be better not to ship it at all, but make people build it. Just copy the cocoon.war to the %TOMCAT_HOME%\webapps yourself. Fire tomcat up. It either works or you got a bum revision or copy :-) Won't be the first time... of Cocoon.war. If it doesn't work the second time you fire it up, delete the generated
