Re: Adding EXSLT functions
On 27/02/14 21:47, Christopher Schultz wrote: Has anyone ever manually-plugged an EXSLT function into Xalan? No, I changed the processor to Saxon so I can use XSLT2. The date and time functions there are much better and more extensive, and there is no need for plugins. ///Peter -- Peter Flynn | Electronic Publishing Unit | IT Services | University College Cork | Phone +353 21 490 2609 | Email pfl...@ucc.ie | Web www.ucc.ie - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Getting the value of the browser selector
Does anyone have any more information about the browser selector? Specifically, how to pass its value into a pipeline as a parameter to the XSLT? ///Peter On 19/12/13 15:51, Peter Flynn wrote: On 19/12/13 12:46, Christopher Schultz wrote: Peter, On Dec 19, 2013, at 4:24, Peter Flynn pfl...@ucc.ie wrote: Let me try again in a shorter post :-) 1. Has anyone ever used the browser selector? 2. Can it be used to pass the *value* to a transformation as a parameter without resorting to map:when, instead of just doing selection? Isn't the value of the browser selector the same as the user-agent header value? I don't think so. http://cocoon.apache.org/2.1/userdocs/browser-selector.html says: map:select type=browser map:when test=netscape /map:when map:when test=explorer ... /map:when ... map:otherwise ... /map:otherwise /map:select In other words you can take alternate action based on the test=... value, but you cannot pass that actual value into the XSLT as a parameter. You can just pass-in the header to the transformation... No need for the browser selector. But then I'd have to parse the user-agent string in my XSLT. The whole point of the browser selector is that it's done for you in the sitemap. ///Peter ///Peter -- Peter Flynn | Electronic Publishing Unit | IT Services | University College Cork | Phone +353 21 490 2609 | Email pfl...@ucc.ie | Web www.ucc.ie - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Getting the value of the browser selector
Let me try again in a shorter post :-) 1. Has anyone ever used the browser selector? 2. Can it be used to pass the *value* to a transformation as a parameter without resorting to map:when, instead of just doing selection? ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Getting the value of the browser selector
On 19/12/13 12:46, Christopher Schultz wrote: Peter, On Dec 19, 2013, at 4:24, Peter Flynn pfl...@ucc.ie wrote: Let me try again in a shorter post :-) 1. Has anyone ever used the browser selector? 2. Can it be used to pass the *value* to a transformation as a parameter without resorting to map:when, instead of just doing selection? Isn't the value of the browser selector the same as the user-agent header value? I don't think so. http://cocoon.apache.org/2.1/userdocs/browser-selector.html says: map:select type=browser map:when test=netscape /map:when map:when test=explorer ... /map:when ... map:otherwise ... /map:otherwise /map:select In other words you can take alternate action based on the test=... value, but you cannot pass that actual value into the XSLT as a parameter. You can just pass-in the header to the transformation... No need for the browser selector. But then I'd have to parse the user-agent string in my XSLT. The whole point of the browser selector is that it's done for you in the sitemap. ///Peter -- Peter Flynn | Electronic Publishing Unit | IT Services | University College Cork | Phone +353 21 490 2609 | Email pfl...@ucc.ie | Web www.ucc.ie - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Switching to Saxon
On 17/12/10 08:43, Johan Cwiklinski wrote: Hello, [...] Here is our configuration: [...] Hope that could help you :) Thanks very much, that did it. It was unclear from the docs where you put the name of the .jar file (saxon9) and where you just put the name saxon. One thing that switching to Saxon has done is reveal the holes in my XSLT :-) a. If a URI call to Cocoon to retrieve a web page through a Tidy pipeline (to make it XML) returns an empty file (really null, not even an empty root element), Xalan treats the statement xsl:variable name=foo select=document($uri)/ as a non-event, and $foo is unset (that is, a binary test for if=$foo returns false). Saxon, on the other hand, emits a Java error message about a null pointer; technically correct, except that it makes it untestable because the error occurs before the document() call completes, so its status is inaccessible in the XSLT. b. Any ambiguity in template selection (normally a recoverable warning if you run Saxon from the command line) returns the Ambiguous... message as an error. Is this configurable? (ie get Saxon to not pass an error status to Cocoon, but just log a warning, and continue recoverably as it does in commandline mode?). Obviously writing better XSLT is the answer...I should have paid closer attention to Mike and Jeni's sessions on testing at the XML Summerschool... ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Too many open files
On 16/12/10 16:49, john muth wrote: I hit this problem not too long ago and decided the o/s default limit of 1024 was too low for what we were trying to do. For me, on Redhat, the solution was to edit /etc/security/limits.conf tomcatuser hard nofile 65535 tomcatuser soft nofile 65535 On 17/12/10 08:41, Laurent Medioni wrote: Yes, had that too in the past, ulimit -H -n 65535 cured the issue. Thanks, I'll try. And presumably reboot the server. ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Encoding
I restored the Xalan settings after (failing to) add Saxon by copying
Emacs' ~ backup copies of cocoon.xconf and sitemap.xmap, but now
suddenly there are Unicode replacement characters (U+FFFD) appearing for
accents in pages which were working before.
The data is taken from a feed from an Oracle Application Server giving a
HTML table fragment, eg
http://rss.ucc.ie/live/w_rms_profile_list.show?p_school_id=A005
which dog and wget identify in the headers as
Content-Type: text/html; charset=WINDOWS-1252
(yes, I know, yuck...not my server)
[That URI may not be accessible off-campus]
This is processed by a pipeline to ensure it is XML:
map:match pattern=people-in-schools/*
map:generate type=html
src=http://rss.ucc.ie/dev/w_rms_profile_list.show?p_school_id={1}/
map:serialize type=xml/
/map:match
so that
http://publish.ucc.ie/researchprofiles/people-in-schools/A005
produces XML I can consume in my XSLT. However, this is appearing as:
?xml version=1.0 encoding=ISO-8859-1?html...etc
depite the fact that the sitemap.xmap says very clearly:
map:serializer logger=sitemap.serializer.xml
mime-type=application/xml name=xml
src=org.apache.cocoon.serialization.XMLSerializer
encodingUTF-8/encoding
/map:serializer
The result is that the output at
http://publish.ucc.ie/researchprofiles/A005
has Unicode replacement characters instead of accents.
I thought it should enforce translation to UTF-8 but obviously I have
missed somethingbut what?
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Switching to Saxon
On 16/12/10 16:23, Schmitz, Jeffrey A wrote: Taking a quick look, that looks like the same as I did, although I'm using a saxon9he.jar file. To ask maybe a dumb question, did you restart Cocoon after adding the jar? No, I assumed any change would force Tomcat to reread it all. I can restart Tomcat but I'm not aware of how to restart Cocoon itself. ///Peter -Original Message- From: Peter Flynn [mailto:pfl...@ucc.ie] Sent: Thursday, December 16, 2010 9:58 AM To: users@cocoon.apache.org Subject: Switching to Saxon I just tried this, but there seems to be a lack of up-to-date details on doing this in Cocoon 2.1.11 with saxon9. Following the assorted web pages for earlier versions, I got as far as adding saxon9.jar to Cocoon's WEB-INF/lib and editing the two files (commenting out the Xalan entries): - cocoon.xconf: component logger=core.xslt role=org.apache.excalibur.xml.xslt.XSLTProcessor/saxon class=org.apache.cocoon.components.xslt.TraxProcessor parameter name=use-store value=true/ parameter name=transformer-factory value=net.sf.saxon.TransformerFactoryImpl/ /component - sitemap.xmap: map:transformer name=xslt pool-grow=2 pool-max=32 pool-min=8 logger=sitemap.transformer.xslt src=org.apache.cocoon.transformation.TraxTransformer use-request-parametersfalse/use-request-parameters use-browser-capabilities-dbfalse/use-browser-capabilities-db use-session-parametersfalse/use-session-parameters use-cookie-parametersfalse/use-cookie-parameters xslt-processor-rolesaxon/xslt-processor-role check-includestrue/check-includes /map:transformer But then Cocoon spits out: Internal Server Error Message: Could not find component (key [org.apache.excalibur.xml.xslt.XSLTProcessor/saxon]) Description: org.apache.cocoon.ProcessingException: Lookup of transformer 'xslt' failed at map:transform - file:///usr/share/tomcat5/webapps/ROOT/sitemap.xmap:1174:71 Sender: org.apache.cocoon.servlet.CocoonServlet Source: Cocoon Servlet cause org.apache.avalon.framework.component.ComponentException: Could not find component (key [org.apache.excalibur.xml.xslt.XSLTProcessor/saxon]) full exception chain stacktrace org.apache.cocoon.ProcessingException: Lookup of transformer 'xslt' failed at map:transform - file:///usr/share/tomcat5/webapps/ROOT/sitemap.xmap:1174:71 at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException. java:113) What is it actually looking for when it says org.apache.excalibur.xml.xslt.XSLTProcessor/saxon? I have no idea what or where org.apache.excalibur.xml.xslt.XSLTProcessor points to (I'm sure it's possible to find out, but I'm not a Java programmer :-) ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Encoding
On 17/12/10 15:06, Peter Flynn wrote: [...] The result is that the output at http://publish.ucc.ie/researchprofiles/A005 has Unicode replacement characters instead of accents. Curiouser and curiouser, that page serves as UTF-8 but lower down it says: !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; html xmlns=http://www.w3.org/1999/xhtml; lang=en-ie head xmlns= xmlns:h=http://www.w3.org/1999/xhtml; meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1 !--School: A005; Researcher-in-School: ; Real School: -- meta content=no-cache http-equiv=Pragma That is generated by xsl:template match=h:head head xsl:comment xsl:textSchool: /xsl:text xsl:value-of select=$school/ xsl:text; Researcher-in-School: /xsl:text xsl:value-of select=$researcher-in-school/ xsl:text; Real School: /xsl:text xsl:value-of select=$real-school/ /xsl:comment meta http-equiv=Pragma content=no-cache/ so WTF is that meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1 coming from? Is Cocoon sticking it in by itself? The page template which I take for the framework is http://www.ucc.ie/en/old-design-base/ and that says quite clearly meta http-equiv=Content-Type content=text/html; charset=UTF-8 / Something, somewhere is sticking a bogus encoding in the works. ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Encoding
On 17/12/10 15:37, Laurent Medioni wrote:
What is your
init-param
param-namecontainer-encoding/param-name
param-valueUTF-8/param-value
/init-param
In web.xml ?
Interesting. ISO-8859-1, because
!--
Set encoding used by the container. If not set the ISO-8859-1 encoding
will be assumed.
Since the servlet specification requires that the ISO-8859-1 encoding
is used (by default), you should never change this value unless
you have a buggy servlet container.
--
I wouldn't call Tomcat buggy, exactly, but the servlet spec made a poor
choice in making ISO-8859-1 the default, given that the rest of the
planet is going down the UTF-{8|16|32|64} road :-)
Certainly fixes the problem though...very many thanks.
///Peter
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Too many open files
I'm getting this error in apparently random circumstances on http://publish.ucc.ie/researchprofiles/ using Cocoon 2.1.11 under Tomcat5 on RHEL5. This application is reprocessing some HTML feeds from another server in order to present the information in a different layout, and do some extensive cleaning-up of the data. Most of the time it works just fine. The full stacktrace says: org.apache.cocoon.ProcessingException: Failed to process pipeline at map:serialize - file:///var/www/xml/profiles/sitemap.xmap:74:18 at map:transform - file:///var/www/xml/profiles/sitemap.xmap:69:36 at map:generate type=html - file:///var/www/xml/profiles/sitemap.xmap:68:17 The line numbers vary according to the page type (and thus which piece of the pipeline). All the templates generate the page layout by retrieving a HTML page via Tidy, and slotting different pieces of data into different places: a fairly typical mashup. In the process, the XSLT will open five internal pipelines via document() calls to retrieve data, each of which opens one or two other document()s and two local (static) XML lookup tables (very small). at map:mount - file:///usr/share/tomcat5/webapps/ROOT/sitemap.xmap:1115:57 at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:145) Further down the stacktrace, it says: Caused by: java.net.SocketException: Too many open files at java.net.Socket.createImpl(Socket.java:388) at java.net.Socket.connect(Socket.java:517) at java.net.Socket.connect(Socket.java:469) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.www.http.HttpClient.openServer(HttpClient.java:394) In my ignorance of the internals of Cocoon and Tomcat and Java, is it running out of file handles when making a HTTP call? The server is lightly loaded, but each page does open a significant number of document()s: is there a setting that will increase the number of open files allowed? Is there any way to get it to report *what* it was trying to open (the URI) when it failed? ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Too many open files
On 16/12/10 13:03, Johan Cwiklinski wrote: Hello, Le 16/12/2010 13:58, Peter Flynn a écrit : Caused by: java.net.SocketException: Too many open files at java.net.Socket.createImpl(Socket.java:388) at java.net.Socket.connect(Socket.java:517) at java.net.Socket.connect(Socket.java:469) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.www.http.HttpClient.openServer(HttpClient.java:394) In my ignorance of the internals of Cocoon and Tomcat and Java, is it running out of file handles when making a HTTP call? The server is lightly loaded, but each page does open a significant number of document()s: is there a setting that will increase the number of open files allowed? We already have seen this issue on some cocoon applications ; most of the time, that was due to intensive use of xpath document function with. We observe that using saxon as xslt processor genrerally solved that issue. I have had that on my TODO list for some time. About time to do it...thanks. ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Switching to Saxon
I just tried this, but there seems to be a lack of up-to-date details on doing this in Cocoon 2.1.11 with saxon9. Following the assorted web pages for earlier versions, I got as far as adding saxon9.jar to Cocoon's WEB-INF/lib and editing the two files (commenting out the Xalan entries): - cocoon.xconf: component logger=core.xslt role=org.apache.excalibur.xml.xslt.XSLTProcessor/saxon class=org.apache.cocoon.components.xslt.TraxProcessor parameter name=use-store value=true/ parameter name=transformer-factory value=net.sf.saxon.TransformerFactoryImpl/ /component - sitemap.xmap: map:transformer name=xslt pool-grow=2 pool-max=32 pool-min=8 logger=sitemap.transformer.xslt src=org.apache.cocoon.transformation.TraxTransformer use-request-parametersfalse/use-request-parameters use-browser-capabilities-dbfalse/use-browser-capabilities-db use-session-parametersfalse/use-session-parameters use-cookie-parametersfalse/use-cookie-parameters xslt-processor-rolesaxon/xslt-processor-role check-includestrue/check-includes /map:transformer But then Cocoon spits out: Internal Server Error Message: Could not find component (key [org.apache.excalibur.xml.xslt.XSLTProcessor/saxon]) Description: org.apache.cocoon.ProcessingException: Lookup of transformer 'xslt' failed at map:transform - file:///usr/share/tomcat5/webapps/ROOT/sitemap.xmap:1174:71 Sender: org.apache.cocoon.servlet.CocoonServlet Source: Cocoon Servlet cause org.apache.avalon.framework.component.ComponentException: Could not find component (key [org.apache.excalibur.xml.xslt.XSLTProcessor/saxon]) full exception chain stacktrace org.apache.cocoon.ProcessingException: Lookup of transformer 'xslt' failed at map:transform - file:///usr/share/tomcat5/webapps/ROOT/sitemap.xmap:1174:71 at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:113) What is it actually looking for when it says org.apache.excalibur.xml.xslt.XSLTProcessor/saxon? I have no idea what or where org.apache.excalibur.xml.xslt.XSLTProcessor points to (I'm sure it's possible to find out, but I'm not a Java programmer :-) ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Too many open files
On 16/12/10 14:39, Andreas Kuehne wrote: Hi all, if you're in a Cocoon environment, it's always a good idea to avoid the document function. Cocoon offers so many better ways like map:aggregate or the CInclude transformer preserving the cache functionalities. Thank you, that sounds like a useful tip, although I wasn't aware of either of them. The problem is that the XSLT I am using also needs to run standalone (ie outside Cocoon) for other reasons, so I was trying to avoid too much Cocoon dependency. ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Calling LaTeX from within Cocoon
A common solution to the requirement to generate publication-quality PDF is to use XSLT to create LaTeX code and rely on LaTeX's understanding of documents and library of pre-written packages to create the PDF. For real-time web applications it would be very useful to be able to drive this from within Cocoon rather than having to call out to a CGI script. As Cocoon can only call Java resources, and can only accept XML return, would it be possible to write a small Java stub whose classes can be added to Cocoon, that would do the business of running LaTeX over the XSLT output in the pipeline and returning the PDF? I don't do Java, so I would be interested to know if this is even possible. ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
XHTML via Tidy not making it into XSLT
I have a resource in my sitemap which makes a web page available as XHTML:
map:match pattern=fetch/**
map:generate src=http://{1}; type=html/
map:transform src=xsl/as-is.xsl/
map:serialize type=xhtml/
/map:match
I call this from within another XSLT file so that I can screenscrape the
document for a specific element type by ensuring that it is Tidy'd to
XHTML first. The as-is.xsl is a plain identity transform to match *.
Ugly, but useful (there must be a more elegant way but I haven't found
it). In the second XSLT file I have a match for an element type which
holds the desired URI in an attribute:
xsl:apply-templates
select=document(concat('http://myserver/fetch/',@site))//
descendant::html:d...@class='foo']/
Constructing the URI and issuing it by hand from the terminal with curl,
wget, dog, etc works fine, and the resulting XHTML file works (tested
with lxgrep to ensure that the XPath extracts the right element), so I
know that bit works.
When accessed from within the second stylesheet, the cocoon.log shows
Tidy successfully converting the remote page to XHTML, the same as when
tested from the terminal, but the data never makes it through to the
template for html:div (the namespace *is* specified in the stylesheet
:-) In cocoon.log there's a warning:
WARN (2009-10-23) 11:34.02:162 [sitemap.transformer.xslt] (/doc/test)
TP-Processor9/TraxErrorListener: file:///xsl/tools.xsl:7:138
but it doesn't say what it found wrong (not very helpful). Line 7 of
tools.xsl is the apply-templates shown above, char 138 is the end of
that line.
Testing it from the command line with Saxon, I get this:
Recoverable error on line 7 of file:/xsl/tools.xsl:
FODC0005: java.io.IOException: Server returned HTTP response code: 503 for
URL:
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
503 is a temporary overload, but that URI is retrievable with curl the
instant before and after using Saxon. And in any case, when going via
Cocoon it would cache the DTD (wouldn't it? to avoid overloading the W3C
with a gazillion requests for the DTD URI?)
I'm missing a trick here, but I can't see what.
///Peter
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
User file uploads
I have a requirement for some of my users to upload documents to a Cocoon server. The files need to be managed by Apache and Tomcat afterwards, so using FTP/sftp won't work because those files will be owned by the user's userid, and I'd prefer not to start messing with the groups. There are a gazillion upload scripts in PHP, Java, Flash, Perl, etc, but before I reinvent any wheels, does anyone know of an upload facility written for a Cocoon server? ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Restricting access by IP address
Thomas Markus wrote:
try a generic RegexMatcher (all untested :) )
I solved it temporarily by simply passing the IP address into the XSLT
stylesheet and doing the substringing there: that also let me output a
suitably-formatted eror message for off-siters. Thanks for your help.
///Peter
in your sitemap add this to components with your pattern:
map:matchers default=wildcard
map:matcher name=regular src=test.RegexMatcher
pattern^192\.168\.\d+\.\d+/pattern
/map:matcher
/map:matchers
and in your pipeline:
map:match pattern={request:remoteAddr} type=regular
!-- matched content, access regex groups with {0} or {1} ... --
/map:match
!-- unmatched content --
package test;
import java.util.HashMap;
import java.util.Map;
import java.util.regex.Pattern;
import org.apache.avalon.framework.configuration.Configurable;
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.ConfigurationException;
import org.apache.avalon.framework.logger.AbstractLogEnabled;
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.avalon.framework.thread.ThreadSafe;
import org.apache.cocoon.matching.Matcher;
import org.apache.cocoon.sitemap.PatternException;
public class RegexMatcher extends AbstractLogEnabled implements Matcher,
Configurable, ThreadSafe {
private Patternregexpattern;
public void configure(Configuration configuration) throws
ConfigurationException {
regexpattern =
Pattern.compile(configuration.getChild(pattern).getValue().trim());
}
public Map match(String pattern, Map objectModel, Parameters
parameters) throws PatternException {
java.util.regex.Matcher m = regexpattern.matcher(pattern);
if (m.matches()) {
HashMapString, String h = new HashMapString, String();
for (int i = 0, j = m.groupCount(); i = j; i++)
h.put(String.valueOf(i), m.group(i));
return h;
}
return null;
}
}
Peter Flynn schrieb:
Peter Flynn wrote:
Thomas Markus wrote:
hi,
look at http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#access
or use a matcher/selector in your sitemap
map:select type=parameter
map:parameter name=parameter-selector-test
value={request:remoteAddr} /
map:when test=127.0.0.1
!-- actions for this ip --
/map:when
map:otherwise
!-- --
/map:otherwise
/map:select
That look like the right approach...except I can't find any
documentation at
http://cocoon.apache.org/2.2/core-modules/core/2.2/840_1_1.html on
the syntax of the test attribute.
I found some under the entry for Parameter Selector but it appears
that the test will only perform a plain equality. Is there a way to
perform a substring operation; when testing an IP address for access
permission I want to allow all xxx.yyy.*.* and prohibit everything else.
///Peter
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Restricting access by IP address
Thomas Markus wrote:
hi,
look at http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#access
or use a matcher/selector in your sitemap
map:select type=parameter
map:parameter name=parameter-selector-test
value={request:remoteAddr} /
map:when test=127.0.0.1
!-- actions for this ip --
/map:when
map:otherwise
!-- --
/map:otherwise
/map:select
That look like the right approach...except I can't find any
documentation at
http://cocoon.apache.org/2.2/core-modules/core/2.2/840_1_1.html on the
syntax of the test attribute.
What I'm looking for is something like
test=substring($parameter-selector-test,1,7)='xxx.yyy'
Your example looks as if test is a binary operator implying equality,
but the documentation is blank about this.
///Peter
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Restricting access by IP address
Peter Flynn wrote:
Thomas Markus wrote:
hi,
look at http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#access
or use a matcher/selector in your sitemap
map:select type=parameter
map:parameter name=parameter-selector-test
value={request:remoteAddr} /
map:when test=127.0.0.1
!-- actions for this ip --
/map:when
map:otherwise
!-- --
/map:otherwise
/map:select
That look like the right approach...except I can't find any
documentation at
http://cocoon.apache.org/2.2/core-modules/core/2.2/840_1_1.html on the
syntax of the test attribute.
I found some under the entry for Parameter Selector but it appears that
the test will only perform a plain equality. Is there a way to perform a
substring operation; when testing an IP address for access permission I
want to allow all xxx.yyy.*.* and prohibit everything else.
///Peter
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Restricting access by IP address
I have developed an RSS feed summarising posts to an internal mailing list, but I need to restrict access to it by IP address so that it is usable only internally to the organisation. I can't see any way to do this using the authentication framework. Are there other ways to implement IP address checks within (eg) the sitemap? ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Restricting access by IP address
Jeroen Reijn wrote: Hi Peter, have you also considered doing this with a webserver in front of your cocoon application? Yes, we currently front Tomcat with Apache httpd as a virtual host, but it's at the top level, eg VirtualHost *:80 ServerAdmin pfl...@ucc.ie ProxyPreserveHost On ProxyPass / ajp://localhost:8009/ ProxyPassReverse / ajp://localhost:8009/ ServerName foobar.ucc.ie ErrorLog logs/foobar.ucc.ie-error_log CustomLog logs/foobar.ucc.ie-access_log combined /VirtualHost I can't seem to find any information about how to refine this so that access to the specific URI for the feed gets checked, and all other accesses get allowed, unless I create a separate VH for that feed only. ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: XSLT is Dead ?!
Stephen Winnall wrote: I think a lot of the anti-XSLT sentiment comes from people who don't see the point of XML. Yes, there are many of these. XML and its philosophy are far too complicated for the average designer-cum-website-hacker. This is neither a criticism of XML nor of the d-c-w-h. XML and tools which make use of it and fairly advanced IT, and enable complicated integration projects (such as one might conduct with Cocoon). If you don't have a training in IT and don't share a broader vision like the semantic web, you may crave simpler tools for simple websites. And if you think you don't need XML, you certainly won't think you need XSLT or any other XML-based technology. This is the approach which enables us to publish e-journals with the author's/editors' only concern being to create an ODT or OOXML document with the relevant stylesheet. The ability of Cocoon (and related technologies) to hide the bumpy bits us a huge advantage. I agree with the point in previous posts about Cocoon's learning curve being too daunting. I wonder if it would be easier if we had more XML-based tools which hid XML itself from the user. For example, graphical tools for the sitemap or for generating XSLT which hide the grisly XML bits from the user. Speaking personally, I don't feel that XML is a thing of beauty on the surface: but it certainly has deeper virtues! IMHE the attempts to create a purely visual d'n'd XSLT-generating interface are only useful at the upper levels (eg positioning a heading, formatting a list). I'm not sure it would provide any advantage when it comes to the lower levels where you need to combine logic and layout, such as conditionally enabling a portlet fragment inside a banner component which itself is subject to several layers of conditionality. But someone may yet crack that one. I've been using Cocoon almost since the start, and although there are bits I haven't grokked yet, I find it one of the most productive tools around. There are aspects of its design I disagree with (the removal of DTD-detected pipelines from v1.*, the lack of interface to the system like directory listing or date/time awareness, and the inability to execute an external program even when the program generates XML, unless you fake it via a web script), but it's flexible enough to work around most of these. Reports of XSLT's demise are much exaggerated :-) ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Unexpected encoding in output
Petteri Sulonen wrote: (1) Check your web.xml. You should have the init-param form-encoding set to UTF-8. (It's set by default to ISO-8859-1 on at least some versions of Cocoon.) /var/lib/tomcat5/webapps/cocoon/WEB-INF/web.xml says: !-- Set encoding used by the container. If not set the ISO-8859-1 encoding will be assumed. Since the servlet specification requires that the ISO-8859-1 encoding is used (by default), you should never change this value unless you have a buggy servlet container. -- init-param param-namecontainer-encoding/param-name param-valueISO-8859-1/param-value /init-param !-- Set form encoding. This will be the character set used to decode request parameters. If not set the ISO-8859-1 encoding will be assumed. -- init-param param-nameform-encoding/param-name param-valueISO-8859-1/param-value /init-param I changed both to UTF-8. No effect. Incidentally, why is 8859-1 the default when XML's default is UTF-8? This seems deeply suboptimal. (2) Check your sitemaps, starting from the Cocoon root sitemap. You can set the encoding of your serializers there, for example map:serializer logger=sitemap.serializer.xml mime-type=text/xml name=xml src=org.apache.cocoon.serialization.XMLSerializer encodingUTF-8/encoding /map:serializer ...under /map:sitemap/map:components/map:serializers. That did it. Very many thanks. There was no encoding element type in there, so it would have been inheriting the default. Is there some problem in making UTF-8 the default in the distro? ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Unexpected encoding in output
I have an RSS feed from our home page which is being generated by pulling in the HTML and Tidying it: map:match pattern=ucc map:generate src=http://www.ucc.ie/en/; type=html/ map:transform src=xsl/ucc.xsl/ map:serialize type=xml/ /map:match This works, except that the output starts with the XML Declaration claiming ?xml version=1.0 encoding=ISO-8859-1? But the home page is UTF-8, the ucc.xsl file is UTF-8, the xsl:output inside it specifies UTF-8, and tidy.properties specifies char-encoding=UTF-8. Something, somewhere is interfering, and adding this encoding=ISO-8859-1, but I'm at a loss where to look. I also notice that all my generated HTML from Cocoon is being labelled with META http-equiv=Content-Type content=text/html; charset=ISO-8859-1 but I can't find where to turn this off. ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Email connector
David Legg wrote: Hi Peter, In effect it needs to parse the RFC822 headers to get the subject and origin and date, and then reproduce the text-body untouched (replacing and with character entity references), and drop all attachments on the floor. I thought I saw a reference to a component that did this a couple of years ago, but I can't find it again. You may like to take a look at the Mime4j code which is a subproject of the James Apache mail server [1] That looks very useful. Unfortunately I'm not a Java programmer, so I have no idea how to add this to Cocoon so that I can call on it from within XSLT (giving the name of the local mailbox as the argument). ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
mime-type oddity
In my sitemap I have:
map:match pattern=*/*/*/*/*/*.mov
map:read mime-type=video/quicktime
src=docs/{1}-{2}/{4}-{3}-{1}-{2}-{5}/{6}.mov/
/map:match
map:match pattern=*/*/*/*/*/*.pdf
map:read mime-type=application/pdf
src=docs/{1}-{2}/{4}-{3}-{1}-{2}-{5}/{6}.pdf/
/map:match
This serves additional files related to a specific document in the
specified folder, and it works perfectly for MOVs, serving them as
video/quicktime.
But the PDFs are being served as text/html with a length of 1, for no
reason that I can understand. There is no match pattern for PDFs in any
sitemap in higher directories. The mime.types file entries for PDF in
the Cocoon build (and in the /etc/mime.types) are all correct. The PDF
file exists, in the correct location (same as the MOV files earlier in
the document), and opens in Acrobat Reader correctly.
There is an example at
http://publish.ucc.ie/journals/scenario/2008/01/retzlaff/04/en#I-4 (link
Fit for Duty I've obviously missed something, but what?
///Peter
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Email connector
Is there an email connector for Cocoon? I am currently using my .procmailrc to grab some messages of interest to a research community and stick them in a mailbox file. I'd like to expose the n most recent (say 10) in a corner of a web page which is being generated by Cocoon. In effect it needs to parse the RFC822 headers to get the subject and origin and date, and then reproduce the text-body untouched (replacing and with character entity references), and drop all attachments on the floor. I thought I saw a reference to a component that did this a couple of years ago, but I can't find it again. ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
RE: generate pdf from xml with embedded image?
On Tue, December 23, 2008 7:01 pm, Marten van der Honing wrote:
Peter: Did you write a preprocessor in cocoon? Where can i find more info
on
that?
No, the preprocessor that sets it up is run separately through a CGI
script, using XSLT routines processed with Saxon. I can send you details
separately after the holidays.
I'd do it using Cocoon if I could grok Cocoon forms, but this has so far
eluded me.
///Peter
Meanwhile i tried another approach:
xsl:variable name=image-base64 select=.//IMAGE/
fo:external-graphic
src=url('data:image/gif;base64,{$image-base64}')
height=3cm width=3cm /
But now i get an error in html instead of an pdf file:
java.lang.NullPointerException:
Cocoon stacktrace[hide]
java.lang.NullPointerException cocoon://fop_post/xsl - 4:14
Exception in StreamGenerator.generate() cocoon://fop_post/xsl - 4:14
[TransformerException]
context://fop_post/sitemap.xmap - 11:32 map:serialize type=xml
context://fop_post/sitemap.xmap - 7:33 map:generate type=stream
context://fop_post/sitemap.xmap - 44:37 map:serialize type=fo2pdf
context://fop_post/sitemap.xmap - 43:42 map:transform
context://fop_post/sitemap.xmap - 32:38 map:generate
context://sitemap.xmap - 1034:92 map:mount
Maybe i should try to show the base64 as text in the pdf first to see if
it
still there.
-Oorspronkelijk bericht-
Van: Peter Flynn [mailto:pfl...@ucc.ie]
Verzonden: donderdag 18 december 2008 10:24
Aan: users@cocoon.apache.org
Onderwerp: Re: generate pdf from xml with embedded image?
Ken Starks wrote:
[...]
I did have a few images that were stored also in a database, but I
would pre-process them in a seperate stage, generating a local copy,
and populating a table of the database with the path. This was a batch
process, not an interactive one, and it used python rather than
cocoon. (Actually, it could do a minor amount of image-processing as
well, such as cropping, changing contrast, creating thumbnails,
changing to a different format, Etc and used Image magick as well as
python).
I do something very similar, taking in Word XML documents. The
preprocessor extracts any encoded image data, converts them back to
image format, creates thumbnails and web-res versions, and adds details
of them to an XML file in their directory, rather than using a database.
The XSL[T] processes then reference them externally as images, which is
probably faster than doing database extraction and image conversion in
real time.
I suppose it depends on the amount of storage you have, and how
important it is to you to store your images on a database.
In this case there are typically only a handful of images, so a database
would be overkill: YMMV.
///Peter
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Configuration oddity
Luca Morandini wrote: Peter Flynn wrote: Whereabouts in the pipeline is that /cocoon veing inserted, and why? I've clearly misunderstood something vital here, but I can't see what. Just one question: do you use Apache HTTPd's mod_proxy or mod_rewrite as a front-ent to Tomcat ? Both are loaded, and AFAIK the proxy is used only once in httpd.conf, and rewrite not at all: VirtualHost *:80 ServerAdmin webmas...@ucc.ie DocumentRoot /var/www/xml ProxyPreserveHost On ProxyPass / ajp://localhost:8009/cocoon/ ProxyPassReverse / ajp://localhost:8009/cocoon/ ServerName publish.ucc.ie ErrorLog logs/publish.ucc.ie-error_log CustomLog logs/publish.ucc.ie-access_log common /VirtualHost ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: generate pdf from xml with embedded image?
Ken Starks wrote: [...] I did have a few images that were stored also in a database, but I would pre-process them in a seperate stage, generating a local copy, and populating a table of the database with the path. This was a batch process, not an interactive one, and it used python rather than cocoon. (Actually, it could do a minor amount of image-processing as well, such as cropping, changing contrast, creating thumbnails, changing to a different format, Etc and used Image magick as well as python). I do something very similar, taking in Word XML documents. The preprocessor extracts any encoded image data, converts them back to image format, creates thumbnails and web-res versions, and adds details of them to an XML file in their directory, rather than using a database. The XSL[T] processes then reference them externally as images, which is probably faster than doing database extraction and image conversion in real time. I suppose it depends on the amount of storage you have, and how important it is to you to store your images on a database. In this case there are typically only a handful of images, so a database would be overkill: YMMV. ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Configuration oddity
I have a new installation of Cocoon on a new server, so I am slowly configuring it and moving apps across from the old machine. In the process I am trying to rationalise where stuff goes, as the old system was partly experimental and grew organically with very little planning. In Tomcat's server.xml I specify my virtual hostname in Host/@name and the default directory in Context/docBase as /var/www/xml, which is where I want all document-based stuff to reside. In the Cocoon mount-table.xml I give the name of a top-level directory: mount uri-prefix=doc/ src=/var/www/xml/doc/ / And in the sitemap.xmap for that directory I have map:match pattern= map:redirect-to uri=index/ /map:match and a map pattern for index. So far so good: if I hit up the URI http://publish.ucc.ie/doc/index I get the test page. However, if I try http://publish.ucc.ie/doc/ it brings up the page, but the displayed URI says http://publish.ucc.ie/cocoon/doc/index Whereabouts in the pipeline is that /cocoon veing inserted, and why? I've clearly misunderstood something vital here, but I can't see what. ///Peter - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
New server recommendations?
After much waiting I am now in a position to install a new Cocoon server for use by several document-serving projects (yay), with Lucene and eXist. I've been running Cocoon for years on antiquated hardware so this is an opportunity to Do It Right and demonstrate to people that this is the One True Path :-) The platform is RHEL5 running Apache 2 to front-end port 80 so that we can host a few unmigrated HTML/PHP sites and virtual hosts as well. I think the last time I asked, the recommendation was to make httpd proxy Tomcat (I trawled the logs but failed to find my message), but I do remember that last time I installed Tomcat from Red Hat's RPMs it was a total mess and I went back to a source install. Using RPMs via yum is a great convenience, but not if Red Hat breaks the config. a) Are Red Hat's RPMs now usable as a Tomcat installation for running Cocoon? If so, which bits do I need (servlet, webapps, jasper, jsp...)? Or should I install from source again? b) Does anyone have any specific Dos or Donts about this platform or configuration? c) When I installed Apache from the RH distro RPMs, I got what looked like an Apache 1.x setup, with a httpd.conf in /etc/httpd/conf, instead of the expected multi-file Apache 2 setup that I got on my Ubuntu box. But this httpd.conf does refer to http://httpd.apache.org/docs/2.2 as the source for docs. Is this really Apache 2, and have RH gone and screwed with the setup again and should I wipe it and install from source? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New server recommendations?
After much waiting I am now in a position to install a new Cocoon server for use by several document-serving projects (yay), with Lucene and eXist. I've been running Cocoon for years on antiquated hardware so this is an opportunity to Do It Right and demonstrate to people that this is the One True Path :-) The platform is RHEL5 running Apache 2 to front-end port 80 so that we can host a few unmigrated HTML/PHP sites and virtual hosts as well. I think the last time I asked, the recommendation was to make httpd proxy Tomcat (I trawled the logs but failed to find my message), but I do remember that last time I installed Tomcat from Red Hat's RPMs it was a total mess and I went back to a source install. Using RPMs via yum is a great convenience, but not if Red Hat breaks the config. a) Are Red Hat's RPMs now usable as a Tomcat installation for running Cocoon? If so, which bits do I need (servlet, webapps, jasper, jsp...)? Or should I install from source again? b) Does anyone have any specific Dos or Donts about this platform or configuration? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: re-design of sitemaps
Stephen Winnall wrote: validation is off by default but can be activated, again only in Cocoon 2.2 Correct me if I am wrong, but I thought that it was impossible to write a complete XML schema for the current version of the sitemap. I thought all attempts hitherto were only approximations. One of the major problems is that any extensions a user writes (actions, transformations, etc.) might introduce new elements and attributes into the sitemap which the schema cannot know about a priori. I was looking for a solution where any valid sitemap could be validated against the schema, which seems to me to imply a change in the structure of sitemaps. This is perhaps one of those occasions when a modular DTD might make more sense than a Schema, because local changes can be implemented and tested in the internal subset without the need to coordinate global changes to the distribution. What you lose in data content validation is probably compensated for in additional flexibility. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logs
Grzegorz Kossakowski wrote: Peter Flynn pisze: But none of those files have any information about where the request has come from (eg IP address), which makes them virtually useless. AFAIR, they should contain information you need. Nope. There is no trace of IP addresses anywhere in the Cocoon or Tomcat logs. Unless this is a configuration issue which I have missed, there seems to be a major deficiency in the logging. Nevertheless, you should always use httpd configured as proxy for this purpose. As I explained in the original post, I will be doing this on the production machine once development is finished. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logs
Jason Johnston wrote: Since you're using Tomcat you can configure it to create an access log; see http://tomcat.apache.org/tomcat-5.0-doc/config/valve.html for details. I imagine the reason it is not configured to create one out of the box is that usually Tomcat is behind an Apache reverse proxy which does the logging, so it would be redundant to do it in both places. Several people pointed me at this...I should have guessed. Thanks for the help. It's logging away happily now. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logs
Sebastian Wenzky wrote: Peter Flynn wrote: In my webapps/ROOT there's a logs directory, but none of the logs contain any information about who has visited the site. How do I turn on access logging? Or is it already on but hidden somewhere I don't know about? This is an experimental site, so it's running as root. When I switch it over to run proxy to port 80 httpd, will the regular access_log provide the data, or can Cocoon continue to be made to log its own stuff? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Go into your personally webroot context of cocoon (webapps). Then you have to go to the WEB-INF/logs folder and within this folder you find all logs belongs to your cocoon application as well as your access log for your site. But none of those files have any information about where the request has come from (eg IP address), which makes them virtually useless. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Logs
In my webapps/ROOT there's a logs directory, but none of the logs contain any information about who has visited the site. How do I turn on access logging? Or is it already on but hidden somewhere I don't know about? This is an experimental site, so it's running as root. When I switch it over to run proxy to port 80 httpd, will the regular access_log provide the data, or can Cocoon continue to be made to log its own stuff? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sitemap schema (Re: [contrib] Cocoon editor)
Mark Lundquist wrote: On Jan 24, 2007, at 2:17 AM, Peter Flynn wrote: I couldn't find a DTD or Schema anywhere though: I'm sure there's one around -- it's just not obvious. The link to sitemap-2.1-draft.xsd on http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html is broken, and all the mentions seem to point at drafts. It looks as if it was just made up as things developed, so what needs doing is retro-fitting it properly, which will be made harder if the development process has not documented the various values or data models that are allowed or disallowed for (eg) attribute values. Just created last week: http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/src/sitemap-1.0.xsd?view=markup Excellent, very many thanks. ///Peter -- Peter Flynn Electronic Publishing Unit, UCC Computer Centre +353 21 490 2609University College Cork, Ireland. [EMAIL PROTECTED] Please use plain text: I'll never see HTML email or attachments /sig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [contrib] Cocoon editor
Grzegorz Kossakowski wrote: Olivier napisał(a): Hi all happy new year, I' ve started few months ago to build a sitemap cocoon editor as an eclipse plugin. My first goal was to play with eclipse plugins, EMF, WSTTranslator and more ... I think that the proof of concept is done. Is there anybody in there that would be interested in contributing : - code, - code, - icons, - ideas There was Lepido project at one time but unfortunately it died :( Have you looked at it? What functionality your editor covers? Is there any place we can see it? I was thinking about developing plug-in for Eclipse's Test and Performance Tools Platform, but I have no time for this interesting kind of activity, now. Also, higher place on my priority list takes writing some tutorials about incoming C2.2. I could help but not sooner than in a month. Is there any guarantee that you will have enough time to guide the effort? If there was a DTD or Schema for sitemap.xmap files, then you could use any normal XML editor, or make a stylesheet or customisation layer for a selection of editors. I couldn't find a DTD or Schema anywhere though: I'm sure there's one around -- it's just not obvious. The link to sitemap-2.1-draft.xsd on http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html is broken, and all the mentions seem to point at drafts. It looks as if it was just made up as things developed, so what needs doing is retro-fitting it properly, which will be made harder if the development process has not documented the various values or data models that are allowed or disallowed for (eg) attribute values. Until that's done, it's pretty pointless trying to make an editor. I did make up a DTD for sitemaps, but without proper documentation it's not reliable. Generating documentation from a Schema is a singularly pointless exercise. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication puzzle
Steven D. Majewski wrote: My understanding is that the Authentication Framework is just a framework -- it doesn't itself do any authentication or encryption/decryption of passwords. I understand that it doesn't do any authentication: that's what I wrote the little XML and XSLT files for: to output the format specified in the doc at http://cocoon.apache.org/2.1/developing/webapps/authentication.html I did, however, expect it to pass the password in crypt(3) form, but that's not important for now. It manages protected resources and restricts them to authenticated users. ( Because typically sites will want to plug in different authentication mechanisms. ) Yes, that much I'm happy with. I'll eventually want this to authenticate against Active Directory or an LDAP server. I'm not clear on what you're trying to do. Are you doing trying to do HTTP Basic Authentication ? For now I just want to authenticate using the little file I posted, which provides a username and password per user that I can match against locally. I'm not sure what HTTP Basic Authentication is (unless it's like the method used by regular Apache httpd for web passwords -- but that *does* use crypt(3)). I'm using the file system: my auth.xml and auth.xsl with the parameter_username and parameter_password as per the document image in http://cocoon.apache.org/2.1/developing/webapps/authentication.html map:match pattern=login map:generate src=auth.xml/ map:transform src=auth.xsl type=xslt map:parameter name=use-request-parameters value=true/ /map:transform map:serialize type=xml/ /map:match And I'm not sure what you mean by required crypt(3) - required by whom ? Me. I assumed (obviously wrongly) that Cocoon would handle the encryption of the password. No matter -- for the moment I don't care; but the problem still stands in that it isn't coming back with authentication when I provide the right userid/password pair in Cocoon, but it *does* provide the specified output if I perform the same action from the shell commandline using Saxon. HTTP Basic Authentication sends the bas64 encoding of user:password They aren't encrypted. Base64? Ewww. So if I store the userid and password in my XML disk file in base64 encoding they should be matched? ( But if you're trying to port users from an Apache .htpasswd file , then THOSE entries are encrypted with crypt(3). That was my problem and I found and adapted a javascript version of crypt. ) No, I wasn't trying to use those: I just assumed the concept would be the same, only performed by my XML file and its XSLT procedure. The documentation is missing this vital information in that case. Has anyone ever implemented a small test case where authentication is performed by a component which just runs XSLT over XML and matches the passed userid/password parameters with values in the XML file, and returns the format specified in the Cocoon doc at http://cocoon.apache.org/2.1/developing/webapps/authentication.html ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication puzzle
Armaz Mellati wrote: May I ask you what version of Cocoon you are using? 2.1.8 I ask because the documentation you are refering to is somewhat outdated if you are using 1.2.10 (may be even for 1.2.9). I was going to upgrade to the latest stable (2.1.10?) when I move this from the pilot machine to the production machine. I found out that in version 1.2.10 Cocoon is set up to use the new CoWarp authentication framwork (Which is a better one). I haven't looked at this. If that's where the future lies, I should move, but I'd be concerned if it's going to change again and again with every version. But things are different when using that. If you look at your cocoon.xconf, I thought I read somewhere that that file was obsolete and only retained for backward compatibility. you can find the following : If you want to use the authentication framework, comment out the above line and uncomment the following line: Aha. Excellent. Very many thanks, I'll try it. But if people recommend using CoWarp instead, I'll use it. However, I don't see any documentation at cocoon.apache.org. Is it still experimental or is anyone using it in production? Looking at the introduction at cowarp.sourceforge.net, it claims If you look at the usual Cocoon configuration, the sitemaps, you will not see that your pipelines are only accessible for authenticated users. This is absolutely not true: the map:act type=auth-protect makes it abundantly clear that my pipeline *is* subject to authentication. Perhaps the author meant something else. Part of the difficulty is that it keeps on talking about an application. I don't have any (yet) -- I just want to protect a single document, nothing else. Later on I'll want to extend that to whole applications, but to get it working and understand the mechanism, I need some *much* more explanatory documentation (like a worked example). Does anyone know if such a thing exists? I'm happy to do it and write the doc if I can find out how to make it work. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Aggregate fields
Mark Lundquist wrote: On Jan 8, 2007, at 5:44 AM, Peter Flynn wrote: [..snip] it understandably complains that there is no widget organiser. What have I misunderstood? Do this: ft:aggregate-widget id=organiser ft:widget id=forename/ ft:widget id=surname/ /ft:aggregate-widget Thanks very much. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Authentication puzzle
I am trying to get simple authentication to work for a single document, using local files for the authentication step, but I can't get it to return an authentication success. The following works fine when run using Saxon from the commandline, with userid=peter and password=GHYTFVN.map4h (ie it returns the expected authentication XML: authenticationIDabcd/IDrole*/roledataauthok:peter/data/authentication and when run with other data it returns the failure: authenticationdataauthfail:peter/data/authentication as described in http://cocoon.apache.org/2.1/developing/webapps/authentication.html But run via Cocoon it only fails. Does Cocoon automatically perform the required crypt(3) on the password string from the form before passing the parameter_password into the handler authentication URI? ///Peter XML: users user id=peter authority=abcd namePeter Flynn/name branchuri*/branchuri cryptGHYTFVN.map4h/crypt /user /users XSLT: ?xml version=1.0? xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0 xsl:output method=xml/ xsl:param name=userid/ xsl:param name=password/ xsl:template match=/ authentication xsl:choose xsl:when test=users/user/@id=$userid and users/[EMAIL PROTECTED]/crypt=$password ID xsl:value-of select=users/[EMAIL PROTECTED]/@authority/ /ID role xsl:value-of select=users/[EMAIL PROTECTED]/branchuri /role data xsl:textauthok:/xsl:text xsl:value-of select=users/[EMAIL PROTECTED]/@id/ /data /xsl:when xsl:otherwise data xsl:textauthfail:/xsl:text xsl:value-of select=users/[EMAIL PROTECTED]/@id/ /data /xsl:otherwise /xsl:choose /authentication /xsl:template /xsl:stylesheet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Writing form data to an XML file
Ard Schrijvers wrote: Obviously it's a trace from somewhere...but where? My registration_success.jx says: You just need an xsl transformation after the writing of the source. You are now just showing the result of the source writer What markup format is returned by the writing of the source (ie what element types do I have to provide for in my transformation)? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Writing form data to an XML file
Ard Schrijvers wrote: Just change your serializer to xml (or add a cocoon view) Duh. I knew this of course. Thanks...it's a Monday morning...:-( ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Running cocoon as tomcat user on port 80
I've been running Cocoon as root while testing but I clearly don't want to do this for an open production server which will be writing to the server disk. How do I allow running it as the tomcat user but still binding to port 80? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Aggregate fields
I'd like to be able to present a single form field (HTML input) for the gathering of a user's full name, but be able to split it into forename and surname. The aggregatefield appears to be designed for this, but the documentation provides no details on templating it. fd:aggregatefield id=organiser required=true fd:widgets fd:field id=forename required=true fd:labelForename/fd:label fd:datatype base=string/ /fd:field fd:field id=surname required=true fd:labelSurname/fd:label fd:datatype base=string/ /fd:field /fd:widgets fd:split pattern=\([^\ ]*\)\ \([^\ ]*\) fd:map group=1 field=forename/ fd:map group=1 field=surname/ /fd:split fd:combine expression=forename surname/ /fd:aggregatefield However, in the form template, if I say tr tdft:widget-label id=organiser//td tdft:widget id=organiser//td /tr it understandably complains that there is no widget organiser. What have I misunderstood? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Syntax of registration.js
I'm trying to get the Cforms demo to pass all the form field values to
the success pipeline, but I don't know the syntax of the registration.js
file. I have added what is intended to be a second definition to the var
viewData command, but it has no effect, and I don't know what delimiter
should be used between definitions, or if the command should be
constructed differently if you want more than one definition:
--
cocoon.load(resource://org/apache/cocoon/forms/flow/javascript/Form.js);
function registration() {
var form = new Form(registration_definition.xml);
form.showForm(registration-display-pipeline);
var viewData = { username : form.getChild(name).getValue()
date : form.getChild(date).getValue() }
cocoon.sendPage(registration-success-pipeline, viewData);
}
--
Incidentally, the original var viewData line did not end with a
semicolon. Should it?
///Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Syntax of registration.js
Peter Flynn wrote: I'm trying to get the Cforms demo to pass all the form field values to the success pipeline, but I don't know the syntax of the registration.js file. Cancel that...sorry for the bandwidth. Turns out it's a comma; and no, there is no need for a semicolon at the end of the var viewData command (at least, it works without it). ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Writing form data to an XML file
I'm passing the results of the form demo into some code in
registration_success.jx
to write the form data to an XML file. Having got it working, I now need
to find
out how to get rid of the text which appears in the browser after the
success message:
success entire source overwritten write overwritten
file:/usr/local/apache-tomcat-5.5.12/webapps/ROOT/myformtest/abc.xml xml
Obviously it's a trace from somewhere...but where? My
registration_success.jx says:
?xml version=1.0?
html
head
titleRegistration successful/title
/head
body
pRegistration was successful for ${username} on ${date}!/p
source:write xmlns:source=http://apache.org/cocoon/source/1.0;
source:sourcecontext://myformtest/${username}.xml/source:source
source:fragment
data
date -mm-dd=${date}/
/data
/source:fragment
/source:write
/body
/html
///Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
unparsed-entity-uri()
Does anyone know when or if the unparsed-entity-uri() function will be implemented in distributions of Cocoon? It's becoming very hard to do serious document publishing without proper entity resolution. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: use-request-parameters with checkboxes
Fred Vos wrote: Hello Peter, On Mon, Oct 02, 2006 at 04:19:44PM +0100, Peter Flynn wrote: Jeroen Reijn wrote: Hi Peter, splitting values based on #'s isn't the best solution imho. I agree, but for a very simple application it's easy enough using contains($ref,@id) to identify the elements needed. If you can use another separator, like comma, But that's not possible: the # is the standard checkbox multi-value separator inserted by browsers when forming the URI response to a form-fill. ///Peter Cocoon will handle all values as a single request parameter. Using the str:tokenize function (see http://www.exslt.org/str/functions/tokenize/index.html) you can split the values from within xsl. Fred - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
use-request-parameters with checkboxes
I'm trying to handle form data from a plain HTML form which is normally (outside Cocoon) returned in the format http://foo.bar/cgi-bin?field=valuestuff=abc#def#ghimore=bar where the values of selected checkboxes are concatenated with # to separate the values. If I change the action attribute of the form element to point to my Cocoon (using a URI defined in my sitemap.xmap with use-request-parameters), it appears that Cocoon silently munges these into the format http://foo.bar/cgi-bin?field=valuestuff=abcstuff=defstuff=ghimore=bar This makes the data unusable, as the XSLT receives only one value for the parameter stuff (the first) and drops the othes on the floor. Is there a switch which will make the request parameters behave normally? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: use-request-parameters with checkboxes
Jeroen Reijn wrote: Hi Peter, splitting values based on #'s isn't the best solution imho. I agree, but for a very simple application it's easy enough using contains($ref,@id) to identify the elements needed. I guess that you could use the request generator for your purpose. It should give you the values based on the uri you provide. Ah...I'm missing something there. Is there an example I can see? ///Peter -Original Message- From: Peter Flynn [mailto:[EMAIL PROTECTED] Posted At: maandag 2 oktober 2006 16:48 Posted To: Cocoon User List Conversation: use-request-parameters with checkboxes Subject: use-request-parameters with checkboxes I'm trying to handle form data from a plain HTML form which is normally (outside Cocoon) returned in the format http://foo.bar/cgi-bin?field=valuestuff=abc#def#ghimore=bar where the values of selected checkboxes are concatenated with # to separate the values. If I change the action attribute of the form element to point to my Cocoon (using a URI defined in my sitemap.xmap with use-request-parameters), it appears that Cocoon silently munges these into the format http://foo.bar/cgi-bin?field=valuestuff=abcstuff=defstuff=ghimore=bar This makes the data unusable, as the XSLT receives only one value for the parameter stuff (the first) and drops the othes on the floor. Is there a switch which will make the request parameters behave normally? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: use-request-parameters with checkboxes
Jeroen Reijn wrote: Yes you can take a look in the documentation: http://cocoon.apache.org/2.1/userdocs/request-generator.html Thanks you, that looks ideal. I have no idea how I have managed to use Cocoon for so long without knowing about it (although not knowing it exists, and therefore not knowing to look for it) is always a good excuse :-) ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Cforms dates and data destinations
Christofer Dutz wrote: a: The samples-styling xslt looks for a head-tag to insert the javascript. When starting to use CForms I missed that at first. Either change the xslt or add a dummy head element somewhere. You can move the stuff in another transformation ;) Changing the XSLT is easy, but this sounds like I have to know what Javascript it wants, and I wouldn't know where to start looking. b: As far as I understood everything you can either use W3C DOM Objects or java Beans with all get and set methods implemented. In flowscript you can do whatever you like with them. If you need some assistance, just mail me which form you prefer to store your data and I will send you some sample code. DOM Objects would be preferable, but I haven't started learning flowscript yet. I was just curious to see how Cocoon would be expected to handle writing to the server disk, given that its principal mode of operation is to read from disk and write down the wire to the user. Thanks very much for your offer, I'll mail separately about this. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
unparsed-entity-uri
Does anyone have any information on when the unparsed-entity-uri() function is likely to be supported in distributions of Cocoon (eg in whatever parser is distributed by default)? Its absence is a significant problem for text document publishing applications, where it offers a solution to effectivities not easily obtained otherwise. Is there a workaround (like installing a parser which does support it)? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
unparsed-entity-uri
Does anyone have any information on when the unparsed-entity-uri function is likely to be supported in distributions of Cocoon (eg in whatever parser is distributed by default)? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: auth-protect not defined for act
Andrew Stevens wrote: [me] I did the default build, so I had assumed Yes. How would I recognise it? Well, for starters, there'll be a cocoon-authentication-fw-block.jar in build/webapp/WEB-INF/lib... That's there: $ locate cocoon-authentication-fw-block.jar /usr/src/cocoon-2.1.8/build/webapp/WEB-INF/lib/cocoon-authentication-fw-block.jar /usr/local/apache-tomcat-5.5.12/webapps/ROOT/WEB-INF/lib/cocoon-authentication-fw-block.jar $ So the authentication-fw block must have been selected for inclusion. Unfortunately it doesn't mean anything to me as I don't speak Java. But presumably it means that the relevant bits and pieces *are* present in the build, so I can use them, if I can find some document which tells me which ones are needed and what they're called, right? And Bruno Dumon wrote: [me] I tried map:action name=auth-protect src=org.apache.cocoon.webapps.authentication.acting.ProtectAction/ [...] Just guessing class names isn't very effective indeed ;-) No, alas. Naming them after the action they perform would be far too easy :-) One way to know what exists is of course to check the source code. Only relevant, alas, if you speak Java. Another way is to go to here: http://cocoon.zones.apache.org/daisy/documentation/facetedBrowser/default and choose authentication-fw for CocoonBlock and Action for CocoonComponentReference, and this should show you a list of all actions in the authentication framework. Which unfortunately confirms my suspicion that there is no definition for auth-protect [yet]. If you do as above, the only four listed are AuthAction, LoggedInAction, LoginAction, and LogoutAction. The doc at http://cocoon.apache.org/2.1/developing/webapps/authentication.html describes very clearly the existence of a map:act type=auth-protect which appears to be fundamental to the authentication framework, but which causes a fatal error if you try to use it. Does anyone have a workaround for implementing simple sitemap auth? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
auth-protect not defined for act
Andrew Stevens wrote: From: Peter Flynn [EMAIL PROTECTED] Date: Tue, 04 Apr 2006 20:03:56 +0100 I added map:action name=auth-login src=org.apache.cocoon.webapps.authentication.acting.LoginAction/ to the map:components section of my sitemap Inside the map:actions, right? Yes. But -- g -- I has pasted it inside the LocaleAction definition, which in the sample sitemap is the only non-empty element there. Must have been late at night. So now that works, many thanks, but I now get the same class of error saying that auth-protect isn't defined. So taking a guess I tried map:action name=auth-protect src=org.apache.cocoon.webapps.authentication.acting.ProtectAction/ not expecting it to work, and I wasn't disappointed :-) How many more of these are there, and where are they documented? There's no mention of them in the pages about Authentication. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: auth-protect not defined for act
[EMAIL PROTECTED] wrote: Peter, I apologize if this has been asked before (I admit to coming somewhat late to this thread). When you built Cocoon, was the authentication-fw block selected for inclusion? I did the default build, so I had assumed Yes. How would I recognise it? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: auth-login not defined for act
I added
map:action name=auth-login
src=org.apache.cocoon.webapps.authentication.acting.LoginAction/
to the map:components section of my sitemap but I'm still getting the
same error:
Message: Type 'auth-login' is not defined for 'act' at
file:/home/peter/tomcat/webapps/ROOT/sitemap.xmap:554:29
where the relevant lines say:
553: map:match pattern=authtest
554:map:act type=auth-login
555: map:parameter name=handler value=epuauth/
556: map:parameter name=parameter_username
557:value={request-param:username}/
558: map:parameter name=parameter_password
559:value={request-param:password}/
560: map:redirect-to uri=doc/webmaster/
561:/map:act
562:map:generate src=welcome.xml/
563:map:transform src=webpages.xsl/
564:map:serialize type=xhtml/
566: /map:match
Why isn't the token auth-login being recognised?
///Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: auth-login not defined for act
Andrew Stevens wrote:
Do you have a corresponding
map:action name=auth-login
src=org.apache.cocoon.webapps.authentication.acting.LoginAction/
definition in the map:components section of your sitemap?
I didn't but I do now...but the result is unchanged: the same error.
Where else should I be looking?
///Peter
From: peter [EMAIL PROTECTED]
Date: Tue, 28 Mar 2006 08:28:17 +
I'm getting the following error:
Internal Server Error
Message: Type 'auth-login' is not defined for 'act' at
file:/home/peter/tomcat/webapps/ROOT/sitemap.xmap:554:29
where the relevant lines say:
553: map:match pattern=authtest
554:map:act type=auth-login
555: map:parameter name=handler value=epuauth/
556: map:parameter name=parameter_username
557:value={request-param:username}/
558: map:parameter name=parameter_password
559:value={request-param:password}/
560: map:redirect-to uri=doc/webmaster/
561:/map:act
562:map:generate src=welcome.xml/
563:map:transform src=webpages.xsl/
564:map:serialize type=xhtml/
566: /map:match
Why isn't the token auth-login being recognised?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
wikis
What Cocoon-based wikis are recommended (if any)? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: auth-login not defined for act
Andrew Stevens wrote:
From: peter [EMAIL PROTECTED]
Date: Tue, 28 Mar 2006 08:28:17 +
I'm getting the following error:
Internal Server Error
Message: Type 'auth-login' is not defined for 'act' at
file:/home/peter/tomcat/webapps/ROOT/sitemap.xmap:554:29
where the relevant lines say:
553: map:match pattern=authtest
554:map:act type=auth-login
555: map:parameter name=handler value=epuauth/
556: map:parameter name=parameter_username
557:value={request-param:username}/
558: map:parameter name=parameter_password
559:value={request-param:password}/
560: map:redirect-to uri=doc/webmaster/
561:/map:act
562:map:generate src=welcome.xml/
563:map:transform src=webpages.xsl/
564:map:serialize type=xhtml/
566: /map:match
Why isn't the token auth-login being recognised?
Do you have a corresponding
map:action name=auth-login
src=org.apache.cocoon.webapps.authentication.acting.LoginAction/
definition in the map:components section of your sitemap?
Aha. Probably not...I was just following the documentation and it
doesn't mention that. I'll go check (away from site right now).
Many thanks.
///Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Authentication via sitemap
I'm just starting to look at very simple authentication, using http://cocoon.apache.org/2.1/developing/webapps/authentication/authenticating_user.html as a guide. It looks straightforward enough, but there's one missing item of information. For Using a URI as the authentication resource it gives sample code for autentication-manager handlers !-- Now follows the handlers configuration -- handler name=portalhandler !-- The login resource -- redirect-to uri=cocoon:/sunspotdemoportal/ authentication uri=cocoon:raw:/sunrise-authuser/ /handler /handlers /autentication-manager but it doesn't say where in the sitemap.xmap you put this, and I can't see anywhere obvious that it should go. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML-Serializer encoding
On Tue, 2006-01-17 at 12:40, christian bindeballe wrote: Edwin Kapauni schrieb: Also http://de.wikipedia.org/wiki/UTF-8 and http://de.wikipedia.org/wiki/Unicode are good references in German. cheers, I looked here: http://en.wikipedia.org/wiki/Character_encoding ;) it mentions the difficulty between distinguishing character sets and character encoding. See also the XML FAQ at http://xml.silmaril.ie/authors/characters/ ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XCSS?
On Thu, 2006-01-12 at 18:37, Stephen Winnall wrote: I am setting up a website using Cocoon and want to generate XHTML and use CSS to handle the presentation. Like everyone else I am being bitten by the fact that 90% of all browsers conform to the CSS standard, but the browser that 90% of the users use does not :-( grin http://explorerdestroyer.com/ /grin Does anyone know of a way of writing something that could be called XCSS, i.e. CSS written in an XML syntax, which can be transformed/serialised into proper CSS? This would be a useful project: to codify all known differences in CSS support and behaviour between the browsers. DocBook already has the structure needed to support effectivities and it would be fairly easy to add or modify (eg making the vendor attribute IDREFS so you can make robust references to the browser versions funcsynopsis id=attr conformance=css2 vendor=ff1.5 ff1.4 funcprototype funcdefattr/funcdef paramdefattribute name/paramdef /funcprototype funcsynopsisinfoReturns the value of the named attribute for the currently-selected element type./funcsynopsisinfo /funcsynopsis ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cocoon and eXist
[My apologies for crossposting, but I don't know which community is best placed to answer this one.] I am going to be using Cocoon to serve a large and varied collection of XML documents and I'd like to use eXist as the search system. Cocoon is running happily within Tomcat on port 80 as the default application (by moving ROOT out of the way and renaming cocoon to ROOT within webapps) because I don't want users confused with :8080/cocoon in the URIs. 1. Where do I put the exist directory? (It was unwrapped from the .war file earlier when I tested it, before I moved ROOT). I've tried it in the Ccocoon directory, but that seems to create problems finding the classes (see http://minerva.ucc.ie/exist/). 2. The eXist documentation seems to imply that eXist comes with its own copy of Cocoon. Is this true, and if so, when I start writing queries, how will I make it use my existing Cocoon (or do I need to)? 3. Is all this even possible, or do I have to go back to keeping cocoon and exist as siblings within the original ROOT? If so, how can I still get rid of the /cocoon token from the default URIs? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Exist-open] Re: Cocoon and eXist
On Thu, 2006-01-05 at 11:48, Jonas Lundberg wrote: Peter, I think you might want to integrate eXist with your existing Cocoon installation: http://wiki.exist-db.org/comments/CocoonInstall Thanks, I'd somehow missed that page. I'll give it a try. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Cocoon and eXist
On Thu, 2006-01-05 at 12:00, Christian Barth wrote: I think it should work, when you putt the directory in the Wepapps folder of Tomcat. You can then access the Admin-Page over http://localhost:8080/exist It shouldn't matter if you put Cocoon as ROOT-Folder or in a separate Folder under Webapps. No, that cannot work. If I replace ROOT with cocoon, then all requests (eg localhost/exist) will seek exist in the ROOT (=cocoon) directory. ///Peter -Ursprüngliche Nachricht- Von: Peter Flynn [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 5. Januar 2006 12:34 An: users@cocoon.apache.org Cc: [EMAIL PROTECTED] Betreff: Cocoon and eXist [My apologies for crossposting, but I don't know which community is best placed to answer this one.] I am going to be using Cocoon to serve a large and varied collection of XML documents and I'd like to use eXist as the search system. Cocoon is running happily within Tomcat on port 80 as the default application (by moving ROOT out of the way and renaming cocoon to ROOT within webapps) because I don't want users confused with :8080/cocoon in the URIs. 1. Where do I put the exist directory? (It was unwrapped from the .war file earlier when I tested it, before I moved ROOT). I've tried it in the Ccocoon directory, but that seems to create problems finding the classes (see http://minerva.ucc.ie/exist/). 2. The eXist documentation seems to imply that eXist comes with its own copy of Cocoon. Is this true, and if so, when I start writing queries, how will I make it use my existing Cocoon (or do I need to)? 3. Is all this even possible, or do I have to go back to keeping cocoon and exist as siblings within the original ROOT? If so, how can I still get rid of the /cocoon token from the default URIs? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Exist-open] Re: Cocoon and eXist
On Thu, 2006-01-05 at 12:31, Huib Verweij wrote: Peter Flynn wrote: On Thu, 2006-01-05 at 11:48, Jonas Lundberg wrote: Peter, I think you might want to integrate eXist with your existing Cocoon installation: http://wiki.exist-db.org/comments/CocoonInstall Thanks, I'd somehow missed that page. I'll give it a try. Hi, maybe I'm missing something, but if you integrate eXist with Cocoon, don't you exclude the possibility beforehand of moving eXist out to it's own server when the going get's rough? I have installed eXist on a separate machine and use XML-RPC to access it from cocoon. That way it doesn't matter where eXist is installed anymore, local and remote are the same (except for the initialisation of course). Isn't it also easier that way to upgrade eXist or cocoon independently? I'm sure that is ideal if you can afford to buy a new machine for each application. Unfortunately this is a university, so both cocoon and exist must run on this PIII. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OT: Signature brands
Sorry, I couldn't resist this one: http://www.newtree.be/en/choco_cocoon.php ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cforms basics
I'm just starting to look at using Cforms and there are a few things that I don't find obvious (and I'm an XML document-head, not a Java programmer :-) I think I've grokked definitions and templates, and the flowscript and pipelines seem do-able. The application will need to gather new data from a user. Some of the values will need to be written to new XML instances on the server; other values will need to update existing XML files on the server, either by changing existing element data content or attributes within the file, or by inserting a new element with several subelements at the end of the file (ie immediately before the end-tag of the root element. The simple XML binding seems to be the obvious one, but the section labelled Usage http://cocoon.apache.org/2.1/userdocs/xmlbinding.html is completely opaque to me and I can't find an example to refer to. The standard binding makes more sense to me, as it's all XML, but I don't see where you specify *what* files to output the data to. Is there an example anywhere of a simple (1-variable) form which (a) writes its data to a new XML file and (b) inserts an element in an existing file? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running a shell script from Cocoon
On Mon, 2005-12-12 at 11:37, Jorg Heymans wrote: Peter Flynn wrote: On Sun, 2005-12-11 at 11:03, Jorg Heymans wrote: i'm sure you could use Runtime.exec() just about anyware you like to call your shellscript. If you need the output of the shell script then i'ld put this call in a generator for example. Could you give an example of the syntax for doing this? (untested, and evilness of runtime.exec ignored ) Process p = Runtime.getRuntime().exec(cat myfile.xml); SAXParserFactory factory = SAXParserFactory.newInstance(); factory.newSAXParser().parse(p.getInputStream(), contenthandler); Sorry, what I meant was how do I get my sitemap.xmap to call this? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running a shell script from Cocoon
On Sun, 2005-12-11 at 11:03, Jorg Heymans wrote: i'm sure you could use Runtime.exec() just about anyware you like to call your shellscript. If you need the output of the shell script then i'ld put this call in a generator for example. Could you give an example of the syntax for doing this? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Cocoon the default
On Thu, 2005-12-08 at 12:59, Edwin Kapauni wrote: Peter Flynn wrote: The FAQ about making Cocoon the default app doesn't seem to have a look at http://wiki.apache.org/cocoon/CocoonEasyInstallation If you don't want to default http://cocoon:8080/ then simply replace $tomcat_home/webapps/ROOT/ and rename your new default webapp to become ROOT. Thank you! I knew there had to be an easy way. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
unparsed-entity-uri
Could someone in the know please post the status of this function in Cocoon? Searching turns up numerous posts about it not being available because some parser feature is not implemented, but no information about when or if this is likely to be fixed. Currently it's a major factor in preventing Cocoon being used more heavily for text document serving. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing classes building 2.1.7
Mark Lundquist wrote: It's cocoon.sh servlet. My fault. I keep forgetting to add the .sh to all the script calls... OK Cocoon runs fine at port . Now to find the tomcat logs. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing classes building 2.1.7
Joerg Heinicke wrote: description The requested resource (Servlet Cocoon is not available) is not available. Apache Tomcat/5.0 Hmm, strange. You probably have to look into the log files of Tomcat now (if Cocoon has not been started there should not be Cocoon logs). Having tracked down the tomcat logs to /var/log/tomcat5 (thank you Red Hat), we see: (this was the day before, when I did a build webapp) INFO: Installing web application at context path /cocoon from URL file:/var/lib/tomcat5/webapps/cocoon - Reading standard config net/sourceforge/myfaces/resource/standard-faces-config.xml - Reading config jar:file:/tmp/myfacesnsph7s.jar!/META-INF/faces-config.xml - Reading config jar:file:/tmp/myfacesnsph7t.jar!/META-INF/faces-config.xml - Error initializing ServletContext javax.faces.FacesException: java.io.IOException: Stream closed. at net.sourceforge.myfaces.config.FacesConfigurator.feedJarConfig(java.lang.String) (Unknown Source) [snip] - ServletContext '/var/lib/tomcat5/webapps/cocoon' initialized. - The database 'db' root directory has been set to /var/lib/tomcat5/webapps/cocoon/WEB-INF/db. Keep in mind that if a war upgrade will take place the database will be lost. - Database points to /var/lib/tomcat5/webapps/cocoon/WEB-INF/db - Filer 'org.apache.xindice.core.filer.BTreeFiler' is not available org.apache.xindice.core.filer.FilerException: Error creating SysSymbols.tbl [snip] Caused by: java.io.FileNotFoundException: /var/lib/tomcat5/webapps/cocoon/WEB-INF/db/system/SysSymbols/SysSymbols.tbl (No such file or directory) And then yesterday when I did a build war: INFO: Installing web application at context path /cocoon from URL file:/var/lib/tomcat5/webapps/cocoon - Reading standard config net/sourceforge/myfaces/resource/standard-faces-config.xml - Reading config jar:file:/tmp/myfacesihu7z0.jar!/META-INF/faces-config.xml - Reading config jar:file:/tmp/myfacesihu7z1.jar!/META-INF/faces-config.xml - Error initializing ServletContext javax.faces.FacesException: java.io.IOException: Stream closed. [snip] 29 Aug 2005 23:40:04 - org.apache.slide.common.Namespace - INFO - Loading namespace cocoon configuration 29 Aug 2005 23:40:04 - org.apache.slide.common.Domain - ERROR - org.apache.slide.structure.ObjectNotFoundException: No object found at /actions/read org.apache.slide.structure.ObjectNotFoundException: No object found at /actions/read at org.apache.slide.store.txfile.AbstractXMLResourceDescriptor.retrieveObject() (Unknown Source) etc etc da capo ad nauseam. Something's missing but I don't know if it's Red Hat's kludge of tomcat5 or Java. Or Cocoon. Or a mixture :-) ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing classes building 2.1.7
Joerg Heinicke wrote: Sorry, but I don't know any of these errors, so I can't help you with them directly. Only the suggestion to build a Cocoon with the offending blocks (looks like xmldb and slide) excluded. Nope...I just downloaded a fresh Tomcat 5.5.9 from Apache and installed that. Cocoon worked straight off. Answer: it won't work with the preinstalled tomcat5 that comes with FC4. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing classes building 2.1.7
Joerg Heinicke wrote: On 29.08.2005 01:12, Peter Flynn wrote: Umm...now that it's built OK, I moved webapps to tomcat/webapps/cocoon and copied the xalan etc, and restarted tomcat, but tomcat says Servlet Cocoon is not available. sigh/ It was sooo much easier with a .war file. (Actually I meant, when the .war file was distributed ducking :-) Why don't you do it that way then? ;-) build war creates a WAR file for you. Just did that. I was hoping it would work when I hit up localhost:8080 for the tomcat home page prior to trying localhost:8080/cocoon and the disk light went on solid and I could hear the disk furiously working :-) Tomcat unpacked the war file OK, but it still says HTTP Status 404 - Servlet Cocoon is not available type Status report message Servlet Cocoon is not available description The requested resource (Servlet Cocoon is not available) is not available. Apache Tomcat/5.0 Pity. Another possibility - at least for introductory tests - is to use Jetty: cocoon servlet on the command line. There doesn't appear to be any command jetty nor any command cocoon. # jetty cocoon servlet bash: jetty: command not found # cocoon servlet bash: cocoon: command not found # I'm sure I saw an explicit command to do this, in the docs or the wiki, but I can't find it. I didn't try it before, because I'm fairly confident that Cocoon itself works once it's running :-) I've been using it since Cocoon-1, and my problems have mostly been with getting it installed, not with running it once it's in. And it's usually been my own ignorance that's to blame: the docs are written for the Java expert, rather than the XML user. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Missing classes building 2.1.7
I downloaded 2.1.7 on a fresh installation of FC4 with the Tomcat 5.0 RPM and Sun's JDK 1.5.0_04. When I tried ./build.sh it went through the motions, but came up with two errors: java.lang.ClassNotFoundException: org.apache.tools.ant.taskdefs.optional.XslpLiaison java.lang.ClassNotFoundException: org.apache.tools.ant.taskdefs.optional.TraXLiaison Where can I get the missing classes? Ant 1.6.2 is preinstalled on FC4 but build.sh clearly disables it in order to use its own copy, so I'm puzzled as to why it can't find these classes. There are a few mentions of this problem on the Web (eg PlanetCocoon) but nothing that I can find in the Wiki, and the FAQ page at http://cocoon.apache.org/2.1/faq/faq-install.html is empty (dead? or just no-one has posted to it yet? or am I in the wrong place?) ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing classes building 2.1.7
Joerg Heinicke wrote:
On 28.08.2005 21:54, Peter Flynn wrote:
Where can I get the missing classes? Ant 1.6.2 is preinstalled on FC4
That's the problem.
I thought it might be. The ghost of Red Hat strikes again...
but build.sh clearly disables it in order to use its own copy,
Unfortunately not:
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=112474471307581w=4
Aha. Grrr. Thank you...OK, soft links to their binaries removed, and
I updated the Wiki page at http://wiki.apache.org/cocoon/Installing
to reflect the changes for FC4.
so I'm puzzled as to why it can't find these classes.
I wasn't seeing the Could not create task or type of type: if. error
so I hadn't found the page.
It seems to like building now, but it comes up with a different error:
package net.php does not exist
public class PhpServlet extends net.php.servlet implements Runnable {
^
and then dozens of warnings that @something cannot be used, or can't be
found, or the reference isn't found.
///Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing classes building 2.1.7
Joerg Heinicke wrote:
package net.php does not exist
public class PhpServlet extends net.php.servlet implements Runnable {
Also strange. Cocoon comes with mock objects for the case you have not
put a php jar into your setup. Normally this works fine. For the case
you don't need the php block you should simply exclude it from your
build (see blocks.properties for more information). Otherwise put a php
jar into lin/local.
I won't be wanting PHP anyway so it'll get excluded eventually.
and then dozens of warnings that @something cannot be used, or can't
be found, or the reference isn't found.
This is no problem I think. It's just Javadoc claiming about unknown tags.
grrJavadoc/grr
Umm...now that it's built OK, I moved webapps to tomcat/webapps/cocoon
and copied the xalan etc, and restarted tomcat, but tomcat says Servlet
Cocoon is not available.
sigh/ It was sooo much easier with a .war file.
///Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Cocoon 2.0.4 still failing
My newly-installed http://localhost/cocoon (Tomcat 4.1.30 and Cocoon 2.0.4 under Java 1.4.2_05 on FC2) still fails with Cocoon 2 - Internal server error type fatal message Failed to generate program code (this may happen if you use Xalan in incremental processing mode). Please check log file and/or console for errors. description org.apache.cocoon.ProcessingException: Failed to generate program code (this may happen if you use Xalan in incremental processing mode). Please check log file and/or console for errors. sender org.apache.cocoon.servlet.CocoonServlet The error.log file says ERROR (2004-09-09) 11:27.09:378 [sitemap] (/cocoon/) http80-Processor3/Handler: Error compiling sitemap org.apache.cocoon.ProcessingException: Failed to generate program code (this may happen if you use Xalan in incremental processing mode). Please check log file and/or console for errors. and ERROR (2004-09-09) 11:27.09:380 [access] (/cocoon/) http80-Processor3/CocoonServlet: Problem with Cocoon servlet Can anyone shed any light on why this should be happening with a virgin installation? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.0.4 still failing
On Thu, 2004-09-09 at 11:48, Jorg Heymans wrote: did you check the endorsed lib problem? Search the wiki for a howto. Hah! That definitely looks like it. Unfortunately, the Wiki page doesn't say *what* files need to be copied to the endorsed directory: it just says the libraries; and it refers to a jre/lib/endorsed directory which doesn't exist in my /usr/java/j2sdk1.4.2_05 directory (do I create it?). Any particular reason why you decided on an old cocoon version? Yes, Cocoon 2.1.5.1 won't compile because ant is apparently being picked up wrongly from FC2, despite what the docs say; and Tomcat 5.5 has issues running under Java 1.5.0 unless you start adding patches. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.0.4 still failing
On Thu, 2004-09-09 at 11:48, Jorg Heymans wrote: did you check the endorsed lib problem? Search the wiki for a howto. That seems to work, after a bit of experimenting. Thanks very much. For the record, with Tomcat 4.1.30 and Cocoon 2.0.4 with Java 1.4.2_05 under FC2 you need to copy xalan-2.3.1.jar (only) from /opt/tomcat/jakarta-tomcat-4.1.30/webapps/cocoon/WEB-INF/lib (where it was put when Tomcat expanded cocoon.war) to /opt/tomcat/jakarta-tomcat-4.1.30/common/endorsed Copying xalan-2.3.1.jar to /usr/java/j2sdk1.4.2_05/jre/lib/endorsed as suggested in the Wiki does *not* work. Copying xercesImpl-2.0.0.jar in the same manner seems to be unnecessary, as /opt/tomcat/jakarta-tomcat-4.1.30/common/endorsed already has a file xercesImpl.jar. I have not tried removing this and replaing it with the 2.0.0 file. The Wiki EndorsedLibsProblem is immutable, so I'll leave it to someone else to update. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.0.4 still failing
On Thu, 2004-09-09 at 13:25, Jorg Heymans wrote: Any particular reason why you decided on an old cocoon version? Yes, Cocoon 2.1.5.1 won't compile because ant is apparently being picked up wrongly from FC2, despite what the docs say; and Tomcat 5.5 has issues running under Java 1.5.0 unless you start adding patches. If you're looking to use cocoon professionally, you should seriously consider using 2.1.5.1 - the 2.0.x branch is not actively maintained anymore (for over a year). Java 1.5 is not yet supported by cocoon so don't worry about tomcat just yet. I've tried and tried, but 2.1.5.1 build.sh simply doesn't work. I removed the ant distributed with FC2 from RPM, despite the fact that it's clear from build.sh that it never goes anywhere near it, but uses the ant distributed with Cocoon 2.1.5.1 instead. Now I get ./build.sh java.lang.InstantiationException: org.apache.tools.ant.Main at java.lang.Class.newInstance0(Class.java:293) at java.lang.Class.newInstance(Class.java:261) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:196) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:56) How do I make 2.1.5.1 build the default target set? The wiki explanation on the endorsed lib prob is indeed a bit strange. Note that if you use Jetty you won't have this problem. I'd settle for being able to build 2.1.5.1 first. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.0.4 still failing
On Thu, 2004-09-09 at 15:43, Jorg Heymans wrote: try build webapp as target. Same result. But how on earth you're getting the instantiationexception i don't know... Now you know why I'm using 2.0.4 :-) ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1.5.1 build oddity, 2.0.4 war fails
On Tue, 2004-09-07 at 19:38, Antonio Gallardo wrote: Hi Peter: I use Fedora Core 2 with tomcat 5.0.28, j2sdk 1.4.2_05 and that work OK with Cocoon 2.1.5.1 and cvs version. If you are a new in Cocoon, please try first tomcat 4.1.x with j2sdk 1.4.2_x. This configuration works on Fedora. I'm not new to Cocoon (been using it since v1) but I don't reinstall it that often :-) and I'm not a developer, so I don't track the code. Using 4.x sounds sensible; I was just trying to keep up to date :-) Else, try to search another ant.jar and java libraries in your Fedora Core installation. I have very bad experiences with ant (basically it appears to be non-functional anywhere I've tried it). I didn't even know it was included in FC2. I wouldn't know what to do with ant.jar anyway (there appear to be two on the machine, in /usr/share/java/ant.jar and /usr/share/ant/lib/ant.jar). Do I copy one of them into the Cocoon distribution directory, overwriting the one in /opt/cocoon/cocoon-2.1.5.1/tools/lib/ant.jar ? Hmm. I just did. Same error: Exception in thread main java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher Grrr. Why O why is Java stuff always broken? If you are interested, here are some bugzilla reports related to j2sdk 1.5 (aka. java 5.0): Thanks but no thanks. Bugzilla is impenetrably user-hostile. But, I think we could avoid j2sdk 5.0 until the stable (final) version. Good idea. But unfortunately the Tomcat site says it is a requirement for tomcat 5.5 Unfortunately, I had no time to test if Cocoon run on the new tomcat 5.5. Maybe someone else can confirm that. I can confirm that it doesn't, and it seems to be the Launcher missing from the ant distributed with Cocoon, not anything to do with Tomcat, because you can't even build Cocoon 2.1.5.1 as it stands: it's broken as distributed. So it cannot be tested with Tomcat 5.5 yet. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1.5.1 build oddity, 2.0.4 war fails
On Wed, 2004-09-08 at 09:57, Ugo Cei wrote: Since Cocoon works fine with JDK 1.4, I guess it's unfair to say that Cocoon is broken. If there's something that's broken is the degree of backward-compatibility offered by Java5 and you can hardly blame anyone for not delivering a release that runs on an undelivered platform. True. Sorry, it's my ignorance. I assumed that the error message Exception in thread main java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher meant that some routine called Launcher was missing from the Cocoon ant distribution, not that there was something wrong with the Java that was looking for it. This is Open Source software, so if you have a need to run Cocoon on Java5, you are free to provide the necessary patches. If they solve the problem, they will surely be included in a future release. Absolutely. If I knew enough Java, I would. But I misinterpreted the error message to mean Cocoon was at fault. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1.5.1 build oddity, 2.0.4 war fails
On Wed, 2004-09-08 at 16:03, Carlos Chávez wrote: I had the same problem and was because Fedora Core 2 had installed another versión of Ant, i dont remember which is, i uninstall that version and install Ant 1.6.2. Thanks. That's odd: the docs say that Cocoon ignores any setting of $ANT_HOME, so it shouldn't be using the copy of ant that came with FC2 at all, should it? Well i have cocoon-2.1.6-dev, but the error message was the same. you try rpm -q ant to see the Ant installed. Anyway I changed back to Java 1.4.2_05 and Tomcat 4.1.30 and Cocoon 2.0.4. Now Java and Tomcat work fine but when I copy the cocoon.war file into Tomcat's webapps directory and open http://localhost/cocoon in my browser, I get a Cocoon error message: Cocoon 2 - Internal server error type fatal message Failed to generate program code (this may happen if you use Xalan in incremental processing mode). Please check log file and/or console for errors. description org.apache.cocoon.ProcessingException: Failed to generate program code (this may happen if you use Xalan in incremental processing mode). Please check log file and/or console for errors. Well, at least it's an error from Cocoon, so *something* is running. Has anyone any idea why it doesn't bring up the Cocoon install page. I've installed several Cocoon before and never hit this kind of error. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
2.1.5.1 build oddity, 2.0.4 war fails
I just installed a fresh tomcat 5.5.0 on Fedora Core 2, with jdk1.5.0, and that works fine (edited server.xml to make it the default port 80 server). Then I unwrapped Cocoon 2.1.5.1 and typed ./build to get the default set of targets. I immediately get the error: # cd /opt/cocoon/cocoon-2.1.5.1/ # ./build.sh Exception in thread main java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher Is something (ant) missing from 2.1.5.1? The docs at http://cocoon.apache.org/2.1/installing/index.html#Building%2BCocoon say The build script overrides the existing ANT_HOME variable. In fact I do have ant installed, but I deliberately held back from exporting ANT_HOME as I assumed Cocoon came with its own built-in ant. OK, so backpedal...I unwrapped a copy of Cocoon 2.0.4 and copied the cocoon.war file into the tomcat webapps directory. Tomcat picked it up and expanded it, apparently correctly, but http://localhost/cocoon just gives me the error message (yes I *am* using port 80, not 8080): HTTP Status 404 - /cocoon type Status report message /cocoon description The requested resource (/cocoon) is not available. Apache Tomcat/5.5.0 What have I done wrong? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Caching ancillary file content
On Fri, 2004-06-04 at 12:02, Joerg Heinicke wrote:
On 03.06.2004 14:55, Peter Flynn wrote:
[caching]
http://issues.apache.org/bugzilla/show_bug.cgi?id=10203
From the bug date you will also see, that there will probably be no
short-term fix.
That's actually the reverse of this problem: the OP seems
to be complaining that ancillary data retrieved from a call
to the document() function is *not* being cached, whereas
in fact it *is* (and shouldn't be) -- and the waters were
muddied by the problem being confused with the behaviour of
xsl:include.
Not important now: I coded around it. But it would be a big
benefit to the behaviour of Cocoon if this was fixed: it is
*not*, as Carsten suggests, a feature request: it's a bug.
If I write
xsl:value-of select=document('foo.xml')/bar/@blort/
and it emits the string xyz because foo.xml contains
bar blort=xyz/
and then an external system changes foo.xml so that it now
contains
bar blort=abc/
and I reload the URI of the pipeline in my browser, I still
get xyz because the content of the file was cached.
Whatever code in Cocoon that is performing this caching
simply needs to be removed.
///Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Caching ancillary file content
In my XSLT I extract values from some ancillary files using
the document('foo.xml') function. This works fine, but when
the foo.xml file is changed (eg by some external agency like a timed
script), its old content continues to be served by
Cocoon. Eventually it starts to serve the new content (but
I haven't been able to time it so I don't know what the lag
is).
The archives have many comments on caching, but they appear
to refer mostly to custom apps, JSP routines, etc, none of
which seem apply to this situation, which is an XML document
being transformed to HTML by an XSLT script. I've trawled
the docs for caching, but it only mentions the caching of
the primary content (the src value of map:generate), not any
additional files opened from within the XSLT.
Ideally I'd like all caching of secondary content to be
turned off permanently, so that Cocoon would physically open every file
that the XSLT expects to use, every time the primary content is
served, and not cache anything from
previous hits. This is a low-volume app, so I am prepared
to suffer any I/O penalty in doing so.
Is this possible? I'm running jakarta-tomcat-4.1.18 with
cocoon 2.0.4 under j2sdk1.4.1_01 on RH9. I'll upgrade if
necessary, but the machine will eventually be wiped and
reinstalled with RHE, which will mean a new version of
everything, so if this caching is a bug, I'm interested in
a short-term fix :-)
///Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
