DO NOT REPLY [Bug 20445] New: - i18n transformer does not recognize 2.0 namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20445. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20445 i18n transformer does not recognize 2.0 namespace Summary: i18n transformer does not recognize 2.0 namespace Product: Cocoon 2 Version: 2.1m2 Platform: Sun OS/Version: Solaris Status: NEW Severity: Major Priority: Other Component: sitemap components AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The i18n transformer is not backwards-compatible. It only accepts the 2.1 namespace.
Re: [CLI] Breaking CocoonBean Interface
Vadim, ... uri type=append src-prefix=documents/ src=index.html dest=build/dest// uri type=replace src-prefix=documents/ src=index.html dest=build/dest/docs.html/ uri type=insert src-prefix=documents/ src=index.html dest=zip://*.zip/page.html/ It took me some time to understand meaning of append, replace, insert. Can we choose some other names for this, and/or combine append and replace types together? (What would happen in replace type while processing more than one page?) Also, what goes instead of '*' in insert? Append sticks the uri of the generated page onto the end of the dest uri. Replace just uses the dest uri, ignoring the uri of the generated page. Insert lets you put the uri of the generated page into the middle of the dest uri. Is that any clearer? I can't see how they can be merged, as they do very different things. However, I'm quite open to better names, although I suspect that better explanations might work just as well. When posted, I'll publish docs on the Wiki. I'm happy to create xdocs too, if you can point me in the right direction. And one more question... Can you remind me why src-prefix attribute is necessary? My guess is that it specifies base directory, and no crawling happens above it. If my guess is right, attribute can be named src-base... The src-prefix is the part of the uri of the generated page that isn't used when building the destination uri. So if you have src-prefix=documents/ and src=index.html and dest=site/, your final uri would be site/index.html. If you skipped the src-prefix, you'd need src=documents/index.html instead, which would result in site/documents/index.html. It will then be impossible to get rid of the 'documents' from the URI without creating an entirely new webapp. It is this that breaks the interface to the CocoonBean. Now, instead of passing a Map of destinations, or a single destination, you call addTarget(). There are a number of versions of this method, with increasing functionality: CocoonBean cocoon = new CocoonBean(); // Functionality most like before: cocoon.setDestDir(built/dest/); CocoonBean was introduced just recently and we had no single beta release yet, so I think it's ok to break this interface. If method setDestDir is not necessary anymore, feel free to remove it. It is particularly the removal of the Destination interface that breaks the interface. However, removing the setDestDir will certainly make a cleaner interface. I'll do that. Thanks for your comments. Upayavira
DO NOT REPLY [Bug 20446] New: - using get-string for an oracle output parameter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20446.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20446
using get-string for an oracle output parameter
Summary: using get-string for an oracle output parameter
Product: Cocoon 2
Version: 2.0
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Major
Priority: Other
Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I am calling an oracle stored proc, which works in SQL PLUS. It has many output
parameters and when I try to retrieve the numeric output parameters from the
stored proc via XSL, everything works fine, however when I try to retrieve an
output parameter, which is defined as a varachr2 in oracle and defined as a
string in XSL, everything stops working: The following is a sample of the code,
note when I leave the call out for getting the output parameter, which is a
string everything works as normal (I have added a note as to where the code
stops working, look for parameter advanceAA. All suggestions are welcome.
Thanks
Martina
I have used the following code:
xsl:template match=letterslib:get-advance-for-loan-type
xsp:logic
errorMessage=;
advanceDate=;
templateName=letterslib:get-advance-for-loan-type;
iPurchasePrice = 0;
iPropertyInsurance = 0;
iPropertyInsPremium = 0;
iASUInsurance = 0;
iASUInsPremium = 0;
iIndemnity = 0;
iArrangement = 0;
advanceType = ;
basisType = ;
advanceAA=;
String test=;
/xsp:logic
esql:execute-query
esql:call{call
lg_pk_get_loan_details.p_get_advance_particulars(
esql:parameter direction=in
type=Stringxsp:expruser_id/xsp:expr/esql:parameter,
esql:parameter direction=in
type=Stringxsp:exprloan_type/xsp:expr/esql:parameter,
esql:parameter direction=in
type=Stringxsp:expragreement_id/xsp:expr/esql:parameter,
esql:parameter direction=out
type=Double/esql:parameter,
esql:parameter direction=out
type=Double/esql:parameter,
esql:parameter direction=out
type=Double/esql:parameter,
esql:parameter direction=out
type=Double/esql:parameter,
esql:parameter direction=out
type=Double/esql:parameter,
esql:parameter direction=out
type=Double/esql:parameter,
esql:parameter direction=out
type=Double/esql:parameter,
esql:parameter direction=out
type=String/esql:parameter,
esql:parameter direction=out
type=String/esql:parameter)
}
/esql:call
esql:call-results
xsp:logic
iPurchasePrice=esql:get-double column=4 from-call=yes/;
iPropertyInsurance=esql:get-double column=5 from-call=yes/;
iPropertyInsPremium=esql:get-double column=6 from-call=yes/;
iASUInsurance=esql:get-double column=7 from-call=yes/;
iASUInsPremium=esql:get-double column=8 from-call=yes/;
iIndemnity=esql:get-double column=9 from-call=yes/;
iArrangement=esql:get-double column=10 from-call=yes/;
advanceAA=esql:get-string column =11 from-call=yes/; --Note this is the
line which prevents the URI from working plus I get no meaningful error
message, without this line everything works fine
/xsp:logic
/esql:call-results
PurchasePricexsp:expriPurchasePrice/xsp:expr/PurchasePrice
PropertyInsurancexsp:expriPropertyInsurance/xsp:expr/PropertyInsu
rance
PropertyInsPremiumxsp:expriPropertyInsPremium/xsp:expr/PropertyIn
sPremium
ASUInsurancexsp:expr
iASUInsurance/xsp:expr/ASUInsurance
ASUInsurancePremiumxsp:expr
iASUInsPremium/xsp:expr/ASUInsurancePremium
Indemnityxsp:expr iIndemnity/xsp:expr/Indemnity
Arrangementxsp:expr
iArrangement/xsp:expr/Arrangement
Advancexsp:expradvanceAA/xsp:expr /Advance
esql:error-results
xsp:logic
errorMessage=esql:get-message/;
/xsp:logic
xsl:call-template name=write-error/
/esql:error-results
/esql:execute-query
/xsl:template
Re: C2.0.4: Strange XSLT behaviour in logicsheet when matching text() nodes (resent)
Sylvain Wallez wrote: IIRC (but don't ask me why), the XSP engine wraps every text node from the XSP file into xsp:text elements. In the original implementation text nodes were preprocessed and escaped as string constants in accordance to the rules of the target programming language. This took place prior to applying the core logicsheet, where xsp:text nodes were to be transparently output as quoted string constants. An alternative to this was using XSLT extension functions to perform string escaping inside the core logicsheet itself. This was rejected at the time because not all XSLT processors supported extensions and they were considered not portable. Along the way, the XSPMarkupLanguage class was rewritten as a SAX processor and the language-specific escaping was dropped in favor of... XSLT extensions inside the core logicsheet :-) So xsp:text is probably a venerable fossil today. That said, if it ain't broken... Ricardo
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/servlet BootstrapServlet.java CocoonServlet.java ParanoidClassLoader.java ParanoidCocoonServlet.java
sylvain 2003/06/03 06:25:43
Modified:src/java/org/apache/cocoon/servlet BootstrapServlet.java
CocoonServlet.java ParanoidClassLoader.java
ParanoidCocoonServlet.java
Log:
ParanoidCocoonServlet is now really paranoid
Revision ChangesPath
1.2 +53 -139
cocoon-2.1/src/java/org/apache/cocoon/servlet/BootstrapServlet.java
Index: BootstrapServlet.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/servlet/BootstrapServlet.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- BootstrapServlet.java 9 Mar 2003 00:09:37 - 1.1
+++ BootstrapServlet.java 3 Jun 2003 13:25:42 - 1.2
@@ -50,19 +50,19 @@
*/
package org.apache.cocoon.servlet;
-import javax.servlet.*;
-import javax.servlet.http.HttpServlet;
-
import java.io.File;
-import java.io.IOException;
import java.io.InputStream;
import java.net.MalformedURLException;
import java.net.URL;
-import java.util.ArrayList;
import java.util.Enumeration;
-import java.util.List;
import java.util.Set;
+import javax.servlet.RequestDispatcher;
+import javax.servlet.Servlet;
+import javax.servlet.ServletConfig;
+import javax.servlet.ServletContext;
+import javax.servlet.ServletException;
+
/**
* A bootstrap servlet to allow Cocoon to run in servlet engines that aren't fully
* compliant with the servlet 2.2 spec.
@@ -81,141 +81,55 @@
* @version CVS $Id$
*/
-public class BootstrapServlet extends HttpServlet {
-
-/**
- * The name of the actual servlet class.
- */
-public static final String SERVLET_CLASS =
org.apache.cocoon.servlet.CocoonServlet;
+public class BootstrapServlet extends ParanoidCocoonServlet {
-protected Servlet servlet;
+private File contextDir;
-protected ClassLoader classloader;
-
-protected ServletContext context;
-
-public void init(ServletConfig config) throws ServletException {
-this.context = config.getServletContext();
-
-this.context.log(getRealPath(\/\) = + context.getRealPath(/));
-
-String contextDirParam = config.getInitParameter(context-directory);
-if (contextDirParam == null) {
-// Check old form, not consistent with other parameter names
-contextDirParam = config.getInitParameter(context-dir);
-if (contextDirParam == null) {
-String msg = The 'context-directory' parameter must be set to the
root of the servlet context;
-this.context.log(msg);
-throw new ServletException(msg);
-} else {
-this.context.log(Parameter 'context-dir' is deprecated - use
'context-directory');
-}
-}
-
-// Ensure context dir doesn't end with a / (servlet spec says that paths
for
-// getResource() should start by a /)
-if (contextDirParam.endsWith(/)) {
-contextDirParam = contextDirParam.substring(0, contextDirParam.length()
- 1);
-}
-
-// Ensure context dir exists and is a directory
-File contextDir = new File(contextDirParam);
-if (!contextDir.exists()) {
-String msg = Context dir ' + contextDir + ' doesn't exist;
-this.context.log(msg);
-throw new ServletException(msg);
-}
+ protected File getContextDir() throws ServletException {
+
+ ServletContext context = getServletContext();
+ ServletConfig config = getServletConfig();
+
+ log(getRealPath(\/\) = + context.getRealPath(/));
+
+ String contextDirParam = config.getInitParameter(context-directory);
+
+ if (contextDirParam == null) {
+ throw new ServletException(The 'context-directory'
parameter must be set to the root of the servlet context);
+ }
+
+ // Ensure context dir doesn't end with a / (servlet spec says that
paths for
+ // getResource() should start by a /)
+ if (contextDirParam.endsWith(/)) {
+ contextDirParam = contextDirParam.substring(0,
contextDirParam.length() - 1);
+ }
+
+ // Ensure context dir exists and is a directory
+ this.contextDir = new File(contextDirParam);
+ if (!this.contextDir.exists()) {
+ String msg = Context dir ' + this.contextDir + ' doesn't
exist;
+ log(msg);
+ throw new ServletException(msg);
+ }
+
+ if
cvs commit: cocoon-2.1 status.xml
sylvain 2003/06/03 06:28:26 Modified:.status.xml Log: ParanoidCocoonServlet is now really paranoid Revision ChangesPath 1.50 +5 -0 cocoon-2.1/status.xml Index: status.xml === RCS file: /home/cvs/cocoon-2.1/status.xml,v retrieving revision 1.49 retrieving revision 1.50 diff -u -r1.49 -r1.50 --- status.xml3 Jun 2003 07:50:33 - 1.49 +++ status.xml3 Jun 2003 13:28:26 - 1.50 @@ -181,6 +181,11 @@ changes release version=@version@ date=@date@ + action dev=SW type=update +Updated ParanoidCocoonServlet, which is now an easy solution to the +well-known endorsed library problem (incompatible version of Xalan in +Cocoon and in JDK 1.4+). + /action action dev=DC type=fix fixes-bug=14327 Encoding-related change to the JSP engine: the response charset is now retrieved from the Content-Type, and if not found ISO-8859-1 is used as
The end of the infamous endorsed libs problem : ParanoidCocoonServletnow really paranoid
Hi all,
Short story : once again, I've hit the famous endorsed library problem.
So as usual I copied Cocoon's Xalan and Xerces to
tomcat/common/endorsed, but unfortunately this broke another application
that was running in the same Tomcat.
Damn. How to solve this ? Install another Tomcat ? Yeah, it will work,
but will add yet-another-JVM to the server, which I wanted to avoid. So,
I decided to use ParanoidCocoonServlet, and discovered that it was
actually not paranoid at all because it was not using the
ParanoidClassLoader it was supposed to use :-(
So I refactored a bit all our servlets and now ParanoidCocoonServlet is
_really_ paranoid. This means, that its classloader will _always_ try to
load classes and resources first from WEB-INF/lib and WEB-INF/classes,
ignoring any similar classes existing in the parent classloader. Xalan,
Xerces, etc are now really immune to whatever version of the same
library can exist either in the JDK or in the servlet engine.
Such a strong shielding can have some drawbacks, however : if a class is
given by the servlet engine (e.g. a JNDI context) and the same class
exists in the webapp libs (e.g. in jndi.jar), then you're very likely to
get a ClassCastException. This is likely to happen mostly with standard
APIs, and the solution is then to remove the offending library from your
WEB-INF/lib.
Enjoy,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: TidySerializer
On Tuesday 03 June 2003 09:38, Bruno Dumon wrote: BD TK We have a current problem, that cocoon is not useable in many cases, BD TK because it's nearly impossible to create valid (x)html. BD And again I'm wondering why? Of the tree reasons given earlier: BD AC 1) As a fix for the the namespace problem BD AC 2) When human-readable HTML output is needed BD AC 3) To validate the output to a dtd BD only number 1 really causes problems, the others are merely BD conveniences. Those are important too, but don't make it impossible to BD create valid (x)html. The second is helpful to debug your output and the last is helpful to ensure you output valid code. Would be nice to ensure valid output, before sending out code which has the w3c compliance logo. I can do all this with a script called after cocoon (which I still have to do for non-html output). But TidySerializer is a cleaner solution. BD TK There is also HTMLGenerator using jtidy and noone says, we wait for BD TK the web pages to have valid (X)HTML. BD While I do find this a false comparison (we don't control webpages, but BD we do control what we generate in our pipelines), please understand that Both is for tweaking external problems or failures. HTMLGenerator is for webpages which haven't xhtml, TidySerializer is for HTMLSerializer's which don't ignore, what's not interesting for them. BD I'm not opposed to a tidyserializer. I'm just figuring out why I would BD use it. To make it affordable to have valid html output. Problem is, you can do it actually, but it's to much work. You have to use a xml formatter, to read the output and see whats wrong. You have to validate the output to see if it's valid. You have to do xalan tricks to remove unneeded namespaces. ... Tidy is a temporary (I hope that xalan does the job some time, because I'd like to have it for wml and others too) solution for these problems. For me it works much better than the existing HTMLSerializer, that's why I sent it to the BTS. When you don't have these problems so far, or have another way or a better way to solve them, you don't need it. Indeed it's better not to use it, as it eats performance. Regards Torsten -- Domain in provider transition, hope for smoothness. Planed date is 1.7.2003.
Re: C2.0.4: Strange XSLT behaviour in logicsheet when matching text() nodes (resent)
Ricardo Rocha wrote:
Sylvain Wallez wrote:
IIRC (but don't ask me why), the XSP engine wraps every text node
from the XSP file into xsp:text elements.
In the original implementation text nodes were preprocessed and
escaped as string constants in accordance to the rules of the target
programming language. This took place prior to applying the core
logicsheet, where xsp:text nodes were to be transparently output as
quoted string constants.
An alternative to this was using XSLT extension functions to perform
string escaping inside the core logicsheet itself. This was rejected
at the time because not all XSLT processors supported extensions and
they were considered not portable.
Along the way, the XSPMarkupLanguage class was rewritten as a SAX
processor and the language-specific escaping was dropped in favor
of... XSLT extensions inside the core logicsheet :-)
So xsp:text is probably a venerable fossil today. That said, if it
ain't broken...
Ah yes, I remember that, now. Gosh, the ancient times of Cocoon 1.x...
Thanks for refreshing our memory, Ricardo.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: TidySerializer
Torsten Knodt wrote: On Tuesday 03 June 2003 09:38, Bruno Dumon wrote: TK We have a current problem, that cocoon is not useable in many cases, TK because it's nearly impossible to create valid (x)html. And again I'm wondering why? Of the tree reasons given earlier: AC 1) As a fix for the the namespace problem AC 2) When human-readable HTML output is needed AC 3) To validate the output to a dtd only number 1 really causes problems, the others are merely conveniences. Those are important too, but don't make it impossible to create valid (x)html. The second is helpful to debug your output and the last is helpful to ensure you output valid code. Would be nice to ensure valid output, before sending out code which has the w3c compliance logo. I can do all this with a script called after cocoon (which I still have to do for non-html output). But TidySerializer is a cleaner solution. snip/ Torsten, *Please* put a blank line after the text you are quoting, before your reply. It makes it *so* much easier to read :) Thanks, J. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
Re: Unresolved bugs with patches
On Tuesday 03 June 2003 11:33, Steven Noels wrote: SN 20185 [PATCH] TidySerializer SN - ongoing discussion: I'm -0 as well due to implementation choices SN (don't expect others to come clean up your work) Don't know if you really ment me for the last part. But to be sure: I don't think TidySerializer needs clean up any more. JTidy needs clean up. But that's not my work and also I haven't time for it currently. I see TidySerializer as something between hack and solution as long as HTMLSerializer doesn't do the job on his own. The last would be something I could think about, when I find the time (nice dream). SN 20296 [PATCH] Modularized DirectoryGenerator's SN - needs further review It needs also people testing it. I already have more ideas for it. But for this, this part has to be in. Perhaps a commiter could put it in scratchpad. SN 20297 [PATCH] Added RequestURI in addition to SitemapURI to BaseLi SN - no opinion: Christian? If someone has questions for inclusion or something else, I'm open. But would be nice to have an answer. SN 20298 [PATCH] ExtendedXLinkPipe support for multiple XLinks per el SN - fine with me Someone tested it? I already have some extensions for the namespace/ attributes map in my internal patch queue, which could collide with this patch. Regards Torsten -- Domain in provider transition, hope for smoothness. Planed date is 1.7.2003.
DO NOT REPLY [Bug 20298] - [PATCH] ExtendedXLinkPipe support for multiple XLinks per element
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20298. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20298 [PATCH] ExtendedXLinkPipe support for multiple XLinks per element --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 13:44 --- Yesterday I updated to current cvs. Some changes there, seem to colide with this patch. As I filed it, building the cocoon docs worked with it, now they don't build any more. Without this patch, it works.
Re: The end of the infamous endorsed libs problem : ParanoidCocoonServletnow really paranoid
Sylvain Wallez wrote: Hi all, Short story : once again, I've hit the famous endorsed library problem. So as usual I copied Cocoon's Xalan and Xerces to tomcat/common/endorsed, but unfortunately this broke another application that was running in the same Tomcat. Damn. How to solve this ? Install another Tomcat ? Yeah, it will work, but will add yet-another-JVM to the server, which I wanted to avoid. So, I decided to use ParanoidCocoonServlet, and discovered that it was actually not paranoid at all because it was not using the ParanoidClassLoader it was supposed to use :-( So I refactored a bit all our servlets and now ParanoidCocoonServlet is _really_ paranoid. This means, that its classloader will _always_ try to load classes and resources first from WEB-INF/lib and WEB-INF/classes, ignoring any similar classes existing in the parent classloader. Xalan, Xerces, etc are now really immune to whatever version of the same library can exist either in the JDK or in the servlet engine. Such a strong shielding can have some drawbacks, however : if a class is given by the servlet engine (e.g. a JNDI context) and the same class exists in the webapp libs (e.g. in jndi.jar), then you're very likely to get a ClassCastException. This is likely to happen mostly with standard APIs, and the solution is then to remove the offending library from your WEB-INF/lib. Good explanation. Any chance it will get into Javadoc and wiki? ;-) Vadim
[VOTE] Release Excalibur Phase III RC 4 (with Fortress)
I think Fortress is finally Good Enough (TM) There are some issues to be sure, but they can be worked out with a Fortress 1.1 on a short release cycle. Everyone place your votes for a release on Friday (6/6). +1 from me. PS On a sick humor note, it's a pity that we aren't in 2006 yet, then the release could come on 6/6/06 o)...
Re: C2.0.4: Strange XSLT behaviour in logicsheet when matching text() nodes (resent)
Sylvain Wallez wrote: Ricardo Rocha wrote: snip/ So xsp:text is probably a venerable fossil today. That said, if it ain't broken... Ah yes, I remember that, now. Gosh, the ancient times of Cocoon 1.x... Thanks for refreshing our memory, Ricardo. In fact, I was refering to the first Cocoon *2* XSP implementation. But, yes, this is reminiscent of good ole' Cocoon 1...
Re: The end of the infamous endorsed libs problem : ParanoidCocoonServlet now really paranoid
Le Mardi, 3 juin 2003, à 15:42 Europe/Zurich, Vadim Gritsenko a écrit : ... Good explanation. Any chance it will get into Javadoc and wiki? ;-) I'm just wikifying it as we speak.. -Bertrand
Re: The end of the infamous endorsed libs problem : ParanoidCocoonServletnow really paranoid
Vadim Gritsenko wrote: Sylvain Wallez wrote: Hi all, Short story : once again, I've hit the famous endorsed library problem. So as usual I copied Cocoon's Xalan and Xerces to tomcat/common/endorsed, but unfortunately this broke another application that was running in the same Tomcat. Damn. How to solve this ? Install another Tomcat ? Yeah, it will work, but will add yet-another-JVM to the server, which I wanted to avoid. So, I decided to use ParanoidCocoonServlet, and discovered that it was actually not paranoid at all because it was not using the ParanoidClassLoader it was supposed to use :-( So I refactored a bit all our servlets and now ParanoidCocoonServlet is _really_ paranoid. This means, that its classloader will _always_ try to load classes and resources first from WEB-INF/lib and WEB-INF/classes, ignoring any similar classes existing in the parent classloader. Xalan, Xerces, etc are now really immune to whatever version of the same library can exist either in the JDK or in the servlet engine. Such a strong shielding can have some drawbacks, however : if a class is given by the servlet engine (e.g. a JNDI context) and the same class exists in the webapp libs (e.g. in jndi.jar), then you're very likely to get a ClassCastException. This is likely to happen mostly with standard APIs, and the solution is then to remove the offending library from your WEB-INF/lib. Oh good. You fixed all the problems I was having. -- You know the world is going crazy when the best rapper is a white guy, the best golfer is a black guy, The Swiss hold the America's Cup, France is accusing the US of arrogance, and Germany doesn't want to go to war. And the 3 most powerful men in America are named 'Bush', 'Dick', and 'Colon' (sic). -Chris Rock
Re: The end of the infamous endorsed libs problem : ParanoidCocoonServlet now really paranoid
At 09:42 AM 6/3/2003, you wrote: Sylvain Wallez wrote: Such a strong shielding can have some drawbacks, however : if a class is given by the servlet engine (e.g. a JNDI context) and the same class exists in the webapp libs (e.g. in jndi.jar), then you're very likely to get a ClassCastException. This is likely to happen mostly with standard APIs, and the solution is then to remove the offending library from your WEB-INF/lib. Good explanation. Any chance it will get into Javadoc and wiki? ;-) Can you give a little more info on when we could expect this to happen? Why would I get a class cast exception? Geoff
Re: The end of the infamous endorsed libs problem : ParanoidCocoonServlet now really paranoid
Le Mardi, 3 juin 2003, à 15:28 Europe/Zurich, Sylvain Wallez a écrit : ...Damn. How to solve this ? Install another Tomcat ? Yeah, it will work, but will add yet-another-JVM to the server, which I wanted to avoid. So, I decided to use ParanoidCocoonServlet, and discovered that it was actually not paranoid at all because it was not using the ParanoidClassLoader it was supposed to use :-( Great, thanks! More signal, less noise ;-) You've been wikified for posterity at http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem -Bertrand
FOM and stateful components
As originally proposed by Stefano, the FOM exposes a getComponent(id) method but not a corresponding releaseComponent(component), as Sylvain was quick to point out. I agree with Sylvain that releaseComponent() is indeed needed for stateful, pooled components. Btw, I'm sure when Stefano mentioned stateful components being questioned he referred to *EJB* stateful session beans that keep state on behalf of a remote client. In this arena, it's felt that keeping session state is best done at the webapp layer rather than inside the EJB container. But that's another matter... *Avalon* stateful, pooled components, OTH, _require_ to be released after use. That said, using try/catch blocks in Javascript to ensure proper stateful component release looks anti-scripting to me. In an ideal world, the flow implementation should take care of this aspect for the flow developer. Of course, I do see such a guarantee is easier hoped for than implemented. Because of continuations, automatically releasing components at the end of request processing is clearly not appropriate. Things are further complicated by the fact that continuations can be abandoned. How should we deal with active stateful components in this case? Even if we hook into continuation expiration, this could still lead to excesive tying up of pooled heavy-weight components. Should we reclaim components at the end of sitemap-invoked function execution? This makes more sense because function completion can span across requests. Performing component auto-releasing at the end of sitemap-invoked function completion (whether because of return or exception) seems a reasonable thing to do because, typically, such function call will embody a complete interaction between the user and the application. If any components were needed during that process it's ok to relase them at use-case completion. However, it would preclude keeping components in use across flow functions. Would this truly limit flow usability? What about specifying a retention policy (session, function) upon acquiring components? getComponent(id[, scope]) What do you guys think?
DO NOT REPLY [Bug 20138] - [PATCH] AntBuildGenerator
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20138. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20138 [PATCH] AntBuildGenerator [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED
DO NOT REPLY [Bug 20138] - [PATCH] AntBuildGenerator
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20138. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20138 [PATCH] AntBuildGenerator [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED
cvs commit: cocoon-2.1/src/scratchpad/webapp/samples/ant/stylesheets - New directory
cziegeler2003/06/03 07:19:50 cocoon-2.1/src/scratchpad/webapp/samples/ant/stylesheets - New directory
cvs commit: cocoon-2.1/src/scratchpad/webapp/samples/ant - New directory
cziegeler2003/06/03 07:19:50 cocoon-2.1/src/scratchpad/webapp/samples/ant - New directory
cvs commit: cocoon-2.1/src/scratchpad/webapp/samples/ant/stylesheets antbuildgenerator2html.xsl
cziegeler2003/06/03 07:19:56 Added: src/scratchpad/src/org/apache/cocoon/ant AntBuildGenerator.java src/scratchpad/webapp/samples/ant/stylesheets antbuildgenerator2html.xsl Log: Applying patch 20138 - AntBuildGenerator Revision ChangesPath 1.1 cocoon-2.1/src/scratchpad/src/org/apache/cocoon/ant/AntBuildGenerator.java Index: AntBuildGenerator.java === /* The Apache Software License, Version 1.1 Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved. Redistribution and use in source and binary forms, with or without modifica- tion, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: This product includes software developed by the Apache Software Foundation (http://www.apache.org/). Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear. 4. The names Apache Cocoon and Apache Software Foundation must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [EMAIL PROTECTED] 5. Products derived from this software may not be called Apache, nor may Apache appear in their name, without prior written permission of the Apache Software Foundation. THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the Apache Software Foundation and was originally created by Stefano Mazzocchi [EMAIL PROTECTED]. For more information on the Apache Software Foundation, please see http://www.apache.org/. */ package org.apache.cocoon.ant; import java.io.File; import java.io.IOException; import java.util.Map; import java.util.Stack; import org.apache.avalon.framework.activity.Initializable; import org.apache.avalon.framework.context.Context; import org.apache.avalon.framework.context.ContextException; import org.apache.avalon.framework.context.Contextualizable; import org.apache.avalon.framework.logger.AbstractLogEnabled; import org.apache.avalon.framework.parameters.ParameterException; import org.apache.avalon.framework.parameters.Parameterizable; import org.apache.avalon.framework.parameters.Parameters; import org.apache.avalon.framework.thread.ThreadSafe; import org.apache.cocoon.Constants; import org.apache.cocoon.ProcessingException; import org.apache.cocoon.environment.ObjectModelHelper; import org.apache.cocoon.environment.SourceResolver; import org.apache.cocoon.environment.http.HttpContext; import org.apache.cocoon.generation.Generator; import org.apache.cocoon.xml.XMLConsumer; import org.apache.tools.ant.BuildEvent; import org.apache.tools.ant.BuildListener; import org.apache.tools.ant.Project; import org.apache.tools.ant.ProjectHelper; import org.xml.sax.SAXException; import org.xml.sax.helpers.AttributesImpl; /** * A Cocoon Generator that runs an Ant build file * * @author a href=mailto:[EMAIL PROTECTED]Charles Yates/a * @version CVS $Id: AntBuildGenerator.java,v 1.1 2003/06/03 14:19:56 cziegeler Exp $ */ public class AntBuildGenerator extends AbstractLogEnabled implements Generator, BuildListener, Parameterizable,
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/language/markup/xsp/java util.xsl
haul2003/06/03 07:34:30 Modified:src/java/org/apache/cocoon/components/language/markup/xsp/java util.xsl Log: make util:include-expr expr=foo/ treat foo as java expression, not as string literal make util:include-exprutil:exprfoo/util:expr/util:include-expr sufficient, ie. no need to write xsp:exprfoo/xsp:expr Revision ChangesPath 1.4 +4 -4 cocoon-2.1/src/java/org/apache/cocoon/components/language/markup/xsp/java/util.xsl Index: util.xsl === RCS file: /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/language/markup/xsp/java/util.xsl,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- util.xsl 13 Mar 2003 14:13:08 - 1.3 +++ util.xsl 3 Jun 2003 14:34:29 - 1.4 @@ -194,9 +194,9 @@ xsl:template match=util:include-expr xsl:variable name=expr xsl:choose -xsl:when test=@exprxsl:value-of select=@expr//xsl:when +xsl:when test=@exprxsl:value-of select=@expr//xsl:when xsl:when test=util:expr - xsl:apply-templates select=util:expr/*|util:expr/text()/ + xsp:exprxsl:apply-templates select=util:expr/*|util:expr/text()//xsp:expr /xsl:when /xsl:choose /xsl:variable
DO NOT REPLY [Bug 15005] - [PATCH] Extension to sendmail.xsp: lists for sendmail:cc
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15005. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15005 [PATCH] Extension to sendmail.xsp: lists for sendmail:cc [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED
DO NOT REPLY [Bug 20297] - [PATCH] Added RequestURI in addition to SitemapURI to BaseLinkModule
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20297. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20297 [PATCH] Added RequestURI in addition to SitemapURI to BaseLinkModule --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 14:46 --- Please use the request InputModule instead.
DO NOT REPLY [Bug 20297] - [PATCH] Added RequestURI in addition to SitemapURI to BaseLinkModule
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20297. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20297 [PATCH] Added RequestURI in addition to SitemapURI to BaseLinkModule [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 14:46 --- (see previous comment)
Re: Unresolved bugs with patches
On 03.Jun.2003 -- 11:33 AM, Steven Noels wrote: 12173 [PATCH] SQLTransformer Query object prematurely closes conne - no opinion - someone should check 15005 [PATCH] Extension to sendmail.xsp: lists for sendmail:cc - comments by Christian - no reply Forgot to close this bug -- have been communicating with Frank directly which led to an overhaul of the logicsheet and actions in 2.1-dev. 16718 [PATCH] Using only one connection in SQLTransformer - someone should check (Torsten (or Christian), maybe you guys could have a look at outstanding SQL/ESQL/DB-related patches?) 19138 [Contrib]/[Patch] Made SQLTransformer paginatable. - someone should look into this one 19702 [PATCH] esql:call needs-query=true generate an invalid x - see comment on 16718 20297 [PATCH] Added RequestURI in addition to SitemapURI to BaseLi - no opinion: Christian? won't fix -- module is deprecated and duplicates functionality of the RequestInputModule Will try to look into outstanding bugs / patches but am currently very short on cocoon time. Things might look different shortly (hopefully) but then they might look even worse. Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: Unresolved bugs with patches
At 05:33 AM 6/3/2003, you wrote: On 3/06/2003 8:57 Carsten Ziegeler wrote: My point is, sending every three days an email to the list, saying there are too many open patches/bugs doesn't really help or motivate. Exactly. When I read these mails, I always end up with this vision of people trying to 'corporatize' open source projects, in the genuine belief injecting such corporate project artefacts will help. Other than OSS projects 'owned' by a single company (which Cocoon luckily is not), I don't think this approach works out. If people need food for discussion, here's my utterly uninformed and out-of-the-head opinion on these patches: === 6879 [PATCH] Cache improvement using ESI invalidation protocol - one man show - and too specialized towards a certain specific goal I agree, but as a newcomer haven't wanted to mark things WONTFIX because hey, someone else MIGHTFIX! There are some technical problems with the ESI solution IMVHO - it requires the back end system to know what urls are associate with each record in the database. I'm working on a similar capability though for externally invalidated cache items. I'm not far enough in, but what I'm looking at could provide hooks for an updated version of this ESI scheme as an alternative to JMS (which I see as a better solution) as a means for contacting cocoon about the external events. If someone with more authority wants to mark it WONTFIX go ahead but if not, I can. Geoff
Re: Unresolved bugs with patches
Now - only about 20 hours later - only 26 entries with patches are left and the total number of open issues is 103. That is not bad considering the fact that a few new bugs were filed at the same time. Andreas - Original Message - From: Andreas Kuckartz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 02, 2003 8:46 PM Subject: Unresolved bugs with patches Here is a list of the 31 unresolved bugs for which patches have been created. Only one bug is owned by a person. The others are owned by the developers list.
DO NOT REPLY [Bug 20297] - [PATCH] Added RequestURI in addition to SitemapURI to BaseLinkModule
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20297. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20297 [PATCH] Added RequestURI in addition to SitemapURI to BaseLinkModule --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 16:48 --- No it doesn't. Tell me how you can create backticks (../../) for the sitemap and request URI with the RequestModule. Would be nice when yes, but I don't know how. Pleas reopen and apply, if you agree.
Re: Unresolved bugs with patches
CH 20297 [PATCH] Added RequestURI in addition to SitemapURI to BaseLi CH - no opinion: Christian? CH won't fix -- module is deprecated and duplicates functionality of the CH RequestInputModule Sure? BaseLink returnes something like ../../ to have a link back to the base. Where is this stored in the request? I created this module, because I couldn't find it in the request. It only calculates it's values based on values from the request. Regards Torsten -- Domain in provider transition, hope for smoothness. Planed date is 1.7.2003.
DO NOT REPLY [Bug 12158] - some improvements to Main.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12158. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12158 some improvements to Main.java --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 17:34 --- I did not follow the latest dev with CocoonBean but if I call cocoon.sh cli my_url Main.java is used. And it runs into the cocoon.xconf not found because it was shifted to WEB-INF and the others is valid too.
DO NOT REPLY [Bug 20298] - [PATCH] ExtendedXLinkPipe support for multiple XLinks per element
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20298. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20298 [PATCH] ExtendedXLinkPipe support for multiple XLinks per element --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 17:44 --- OK, I found the problem. I'd like to know, what change made the bug show up. But here are the new patcheS.
DO NOT REPLY [Bug 20298] - [PATCH] ExtendedXLinkPipe support for multiple XLinks per element
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20298. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20298 [PATCH] ExtendedXLinkPipe support for multiple XLinks per element --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 17:48 --- Created an attachment (id=6615) LinkSerializer has to call the super functions in ExtendedXLinkPipe and ExtendedXLinkPipe got some clean up (superflous warning removed, ...)
Re: TidySerializer
On Tue, 2003-06-03 at 15:28, Torsten Knodt wrote: On Tuesday 03 June 2003 09:38, Bruno Dumon wrote: BD TK We have a current problem, that cocoon is not useable in many cases, BD TK because it's nearly impossible to create valid (x)html. BD And again I'm wondering why? Of the tree reasons given earlier: BD AC 1) As a fix for the the namespace problem BD AC 2) When human-readable HTML output is needed BD AC 3) To validate the output to a dtd BD only number 1 really causes problems, the others are merely BD conveniences. Those are important too, but don't make it impossible to BD create valid (x)html. The second is helpful to debug your output and the last is helpful to ensure you output valid code. yeah yeah, I agree with that, and for that purpose the tidyserializer is very valuable. I was only wondering if there were any blocking bugs in the normal htmlserializer that make it impossible to generate valid html (next to the namespace problem). (I'll look into applying the tidyserializer.) BD I'm not opposed to a tidyserializer. I'm just figuring out why I would BD use it. To make it affordable to have valid html output. Problem is, you can do it actually, but it's to much work. You have to use a xml formatter, to read the output and see whats wrong. You have to validate the output to see if it's valid. Is there any other way to validate the output then by validating it? You have to do xalan tricks to remove unneeded namespaces. ... Tidy is a temporary (I hope that xalan does the job some time, because I'd like to have it for wml and others too) If the job means that Xalan should validate the serialized xml against the DTD it references, then I think it's a pretty save bet to say that will never ever happen. solution for these problems. For me it works much better than the existing HTMLSerializer, that's why I sent it to the BTS. When you don't have these problems so far, or have another way or a better way to solve them, you don't need it. Indeed it's better not to use it, as it eats performance. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
DO NOT REPLY [Bug 20443] - util:include-expr does not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20443. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20443 util:include-expr does not work [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 20:01 --- From these both messages the bug seems to be fixed: http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=105465140919873w=2 http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=105465130219728w=2
DO NOT REPLY [Bug 20443] - util:include-expr does not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20443. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20443 util:include-expr does not work [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED
Re: Unresolved bugs with patches
Torsten Knodt wrote: CH 20297 [PATCH] Added RequestURI in addition to SitemapURI to BaseLi CH - no opinion: Christian? CH won't fix -- module is deprecated and duplicates functionality of the CH RequestInputModule Sure? BaseLink returnes something like ../../ to have a link back to the base. Where is this stored in the request? I created this module, because I couldn't find it in the request. It only calculates it's values based on values from the request. Torsten, I'm sorry :-( I have only skimmed over your patch and have missed the loop constructing the String. Although I would personally use absolute links in those cases I accept that in some situations relative links are preferable. So I appologize for misjudging the patch. Will accept the patch tomorrow. Thanks for spotting the mistake! Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: TidySerializer
On Tuesday 03 June 2003 21:46, Bruno Dumon wrote: BD yeah yeah, I agree with that, and for that purpose the tidyserializer is BD very valuable. I was only wondering if there were any blocking bugs in BD the normal htmlserializer that make it impossible to generate valid html BD (next to the namespace problem). No real blocking. For most problems, there is a simple workaround. BD (I'll look into applying the tidyserializer.) When you or someone else wants to apply it, I'll provide xdocs for it, including all supported parameter by tidy. BD TK You have to validate the output to see if it's valid. BD Is there any other way to validate the output then by validating it? Was written bad. You have to validate the output with an external program to see if it is valid. That's what I meat. BD If the job means that Xalan should validate the serialized xml against BD the DTD it references, then I think it's a pretty save bet to say that BD will never ever happen. I hope it removes not allowed and not needed namespaces. For deciding what namespaces are allowed, it has to do validation. But I also don't think that chances for this aren't very good. I think this is a item for my long getting todo. Regards Torsten -- Domain in provider transition, hope for smoothness. Planed date is 1.7.2003.
Re: TidySerializer
AC 1) As a fix for the the namespace problem AC 2) When human-readable HTML output is needed AC 3) To validate the output to a dtd Hmm, all 3 reasons are not strong enough for adding a further serializer with almost the same functionality IMHO. 1: A solution for the HTMLSerializer was discussed (startPrefixMapping(), endPrefixMapping()). Maybe TidySerializer provides a better solution, but I guess this can be adapted too. 2: Human readability is as you say for debugging reasons. This needs not to be done on live systems. We use IMO a better way: on the last transformer step we add a label=format. We access a page in debugging mode via test.html?cocoon-view=format. The view format is simply a further transformer step using format.xsl and the XMLSerializer. The different between live and debugging mode is the URL, not the sitemap. And there is no need for second component. 3: Also only for debugging, isn't it? Validating every request on live systems is too much resource consuming. And what do you want to do on live systems when a validation error occurs? A message We can't deliver the page, because it's not valid HTML? But you have other possibilities, e.g. using http://validator.w3.org/ or a mix of Jakarta commons httpclient with Tidy as we did. If you integrate this in a test system you can validate your pages automatically. Joerg
Re: TidySerializer
On Tuesday 03 June 2003 22:29, Joerg Heinicke wrote: JH 1: A solution for the HTMLSerializer was discussed JH (startPrefixMapping(), endPrefixMapping()). Maybe TidySerializer JH provides a better solution, but I guess this can be adapted too. A little more would be nercessary. You would have to map all xhtml namespace to default prefix and remove the declaration. All other namespaces would have to generate an error. When I know someone will commit it, I can make this patch for HTMLSerializer. JH 2: Human readability is as you say for debugging reasons. This needs not JH to be done on live systems. We use IMO a better way: on the last JH transformer step we add a label=format. We access a page in debugging JH mode via test.html?cocoon-view=format. The view format is simply a JH further transformer step using format.xsl and the XMLSerializer. The JH different between live and debugging mode is the URL, not the sitemap. JH And there is no need for second component. You can use tidyserializer for the same via views. For this purpose, a stylesheet would also be OK. But it wouldn't be simply indenting. You have to check for xml:strip-space and friends. That's why I haven't done it so far. JH 3: Also only for debugging, isn't it? Yesno. I want it as part of quality assurance. JH Validating every request on live systems is too much resource consuming. Not that real, when it (hopefully) is integrated in xalan some time. For xslt 2.0 type handling, there has to be (IMHO) validation inside. It only has to be forceable for output. JH And what do you want to do on JH live systems when a validation error occurs? A message We can't deliver JH the page, because it's not valid HTML? Redirecting to a internal error page, like with other errors to. JH But you have other JH possibilities, e.g. using http://validator.w3.org/ or a mix of Jakarta JH commons httpclient with Tidy as we did. If you integrate this in a test JH system you can validate your pages automatically. That's what I actually do more or less. I validate all generated files via xmllint. I am looking for a cleaner solution which enforces this already in cocoon. When this is a parameter or a view, even better. Regards Torsten -- Domain in provider transition, hope for smoothness. Planed date is 1.7.2003.
Re: DO NOT REPLY [Bug 20445] New: - i18n transformer does notrecognize 2.0 namespace
I guess, legacy support won't be readded, so this is a WONTFIX? Joerg [EMAIL PROTECTED] wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20445 i18n transformer does not recognize 2.0 namespace Summary: i18n transformer does not recognize 2.0 namespace Product: Cocoon 2 Version: 2.1m2 Platform: Sun OS/Version: Solaris Status: NEW Severity: Major Priority: Other Component: sitemap components AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The i18n transformer is not backwards-compatible. It only accepts the 2.1 namespace.
Re: The end of the infamous endorsed libs problem : ParanoidCocoonServletnow really paranoid
Bertrand Delacretaz wrote:
Le Mardi, 3 juin 2003, à 15:28 Europe/Zurich, Sylvain Wallez a écrit :
...Damn. How to solve this ? Install another Tomcat ? Yeah, it will
work, but will add yet-another-JVM to the server, which I wanted to
avoid. So, I decided to use ParanoidCocoonServlet, and discovered
that it was actually not paranoid at all because it was not using the
ParanoidClassLoader it was supposed to use :-(
Great, thanks! More signal, less noise ;-)
You've been wikified for posterity at
http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem
Thanks Bertrand the wikifier !
However, I do not consider my initial post as some ultimate literature
that should go to posterity, and rewrote the whole thing with much more
details and explanations. I don't know if it's perfect, but at least
it's better ;-)
I also included some explanations for Geoff about the ClassCastException.
Comments updates welcome !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: DO NOT REPLY [Bug 20445] New: - i18n transformer does notrecognize 2.0 namespace
On Tue, 2003-06-03 at 23:12, Joerg Heinicke wrote: I guess, legacy support won't be readded, so this is a WONTFIX? yes, I agree. A bit of a problem though is that upon encountering the old namespace, the I18nTransformer nicely logs a warning, however the log level is error by default. Maybe we should lower it to warn instead? (there are other components also logging deprecation warnings not visible by default) -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: TidySerializer
On Tue, 2003-06-03 at 22:29, Joerg Heinicke wrote: AC 1) As a fix for the the namespace problem AC 2) When human-readable HTML output is needed AC 3) To validate the output to a dtd Hmm, all 3 reasons are not strong enough for adding a further serializer with almost the same functionality IMHO. 1: A solution for the HTMLSerializer was discussed (startPrefixMapping(), endPrefixMapping()). Maybe TidySerializer provides a better solution, but I guess this can be adapted too. I agree that this should be fixed in the htmlserializer. Dropping startPrefixMapping and endPrefixMapping is a rather dirty solution though. 2: Human readability is as you say for debugging reasons. This needs not to be done on live systems. We use IMO a better way: on the last transformer step we add a label=format. We access a page in debugging mode via test.html?cocoon-view=format. The view format is simply a further transformer step using format.xsl and the XMLSerializer. The different between live and debugging mode is the URL, not the sitemap. And there is no need for second component. 3: Also only for debugging, isn't it? Validating every request on live systems is too much resource consuming. And what do you want to do on live systems when a validation error occurs? A message We can't deliver the page, because it's not valid HTML? But you have other possibilities, e.g. using http://validator.w3.org/ or a mix of Jakarta commons httpclient with Tidy as we did. If you integrate this in a test system you can validate your pages automatically. The above two reasons still make it valuable, even if only for debugging purposes? I think that if we make this purpose clear in the documentation, then there's no problem. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: TidySerializer
Torsten Knodt wrote: On Tuesday 03 June 2003 22:29, Joerg Heinicke wrote: JH 1: A solution for the HTMLSerializer was discussed JH (startPrefixMapping(), endPrefixMapping()). Maybe TidySerializer JH provides a better solution, but I guess this can be adapted too. A little more would be nercessary. You would have to map all xhtml namespace to default prefix and remove the declaration. All other namespaces would have to generate an error. When I know someone will commit it, I can make this patch for HTMLSerializer. IMO this (a patch to HTMLSerializer) is the best option we have and I'm sure it will be applied. JH 2: Human readability is as you say for debugging reasons. This needs not JH to be done on live systems. We use IMO a better way: on the last JH transformer step we add a label=format. We access a page in debugging JH mode via test.html?cocoon-view=format. The view format is simply a JH further transformer step using format.xsl and the XMLSerializer. The JH different between live and debugging mode is the URL, not the sitemap. JH And there is no need for second component. You can use tidyserializer for the same via views. For this purpose, a stylesheet would also be OK. But it wouldn't be simply indenting. You have to check for xml:strip-space and friends. That's why I haven't done it so far. For debug output I normalize-space every text node and simply indent them by counting the ancestor nodes. This has no influence for HTML, because HTML normalizes text nodes too (exception: pre/). JH 3: Also only for debugging, isn't it? Yesno. I want it as part of quality assurance. Understandable ... JH Validating every request on live systems is too much resource consuming. Not that real, when it (hopefully) is integrated in xalan some time. For xslt 2.0 type handling, there has to be (IMHO) validation inside. It only has to be forceable for output. But it's also resource consuming if it's integrated in Xalan :) JH And what do you want to do on JH live systems when a validation error occurs? A message We can't deliver JH the page, because it's not valid HTML? Redirecting to a internal error page, like with other errors to. What's the advantage for the user? Who cares about invalid HTML pages? It's only important for development, must no be running on live systems. JH But you have other JH possibilities, e.g. using http://validator.w3.org/ or a mix of Jakarta JH commons httpclient with Tidy as we did. If you integrate this in a test JH system you can validate your pages automatically. That's what I actually do more or less. I validate all generated files via xmllint. I am looking for a cleaner solution which enforces this already in cocoon. When this is a parameter or a view, even better. Ok, reason accepted :) But what about an extra validating transformer as last pipeline step? Seems to make more sense IMO. Joerg
Re: TidySerializer
On Tue, 2003-06-03 at 22:19, Torsten Knodt wrote: On Tuesday 03 June 2003 21:46, Bruno Dumon wrote: BD yeah yeah, I agree with that, and for that purpose the tidyserializer is BD very valuable. I was only wondering if there were any blocking bugs in BD the normal htmlserializer that make it impossible to generate valid html BD (next to the namespace problem). No real blocking. For most problems, there is a simple workaround. BD (I'll look into applying the tidyserializer.) When you or someone else wants to apply it, I'll provide xdocs for it, including all supported parameter by tidy. great. BD TK You have to validate the output to see if it's valid. BD Is there any other way to validate the output then by validating it? Was written bad. You have to validate the output with an external program to see if it is valid. That's what I meat. ok. BD If the job means that Xalan should validate the serialized xml against BD the DTD it references, then I think it's a pretty save bet to say that BD will never ever happen. I hope it removes not allowed and not needed namespaces. but that is quite a heavy process if only for aesthetic purposes. For deciding what namespaces are allowed, it has to do validation. true, but only if you are still living in the DTD-area. And since in DTD's you shouldn't be using namespaces in the first place, maybe it is easier to simply make a transformer which drops all namespaces? -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: TidySerializer
-Original Message- From: Torsten Knodt [mailto:[EMAIL PROTECTED] Subject: Re: TidySerializer On Tuesday 03 June 2003 22:29, Joerg Heinicke wrote: JH 1: A solution for the HTMLSerializer was discussed JH (startPrefixMapping(), endPrefixMapping()). Maybe TidySerializer JH provides a better solution, but I guess this can be adapted too. A little more would be nercessary. You would have to map all xhtml namespace to default prefix and remove the declaration. All other namespaces would have to generate an error. When I know someone will commit it, I can make this patch for HTMLSerializer. Send a patch that does that and I'll commit it. Domain in provider transition, hope for smoothness. Planed date is 1.7.2003. Is that done yet? ;) Geoff Howard
Re: DO NOT REPLY [Bug 20445] New: - i18n transformer does notrecognize 2.0 namespace
Bruno Dumon wrote: I guess, legacy support won't be readded, so this is a WONTFIX? yes, I agree. A bit of a problem though is that upon encountering the old namespace, the I18nTransformer nicely logs a warning, however the log level is error by default. Maybe we should lower it to warn instead? (there are other components also logging deprecation warnings not visible by default) + 0.5
DO NOT REPLY [Bug 20096] - Build fails if deprecated classes are excluded.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20096. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20096 Build fails if deprecated classes are excluded. --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 22:22 --- I stumpled across it as well. Easy to work around by the user but defies the just-use-what-you-need spirit of the new build system. I'd call it a must to fix it for 2.1final.
ValidatingTransformer (WAS RE: TidySerializer)
Joerg Heinicke wrote: Ok, reason accepted :) But what about an extra validating transformer as last pipeline step? Seems to make more sense IMO. YES! This could be VERY useful: a transfomer that could validate the output of some pipeline stage against a DTD or other schema could be a great help for debugging. You wouldn't have to download the file and validate it with an external tool. It might even have a role in production systems for validating input from forms, web services etc? map:transform type=dtd-validator map:parameter name=dtd value=dtd/stage-1.dtd/ /map:transform
Re: TidySerializer
On Tuesday 03 June 2003 23:48, Bruno Dumon wrote: BD TK BD If the job means that Xalan should validate the serialized xml BD TK BD against the DTD it references, then I think it's a pretty save bet BD TK BD to say that will never ever happen. BD TK I hope it removes not allowed and not needed namespaces. BD but that is quite a heavy process if only for aesthetic purposes. Problem is, without proper cleanup, you output invalid XML for some DTD's. Namespace tricks with DTD's are used to often to ignore it. Think about docbook+mathml+svg. BTW: Does someone have numbers how much performance validation at output takes, when implemented right (means, not reparse the output stream after generating, but validating during generation)? BD TK For deciding what namespaces are allowed, it has to do validation. BD true, but only if you are still living in the DTD-area. When a DTD is given, I can't use XML Schema. And often there is only a DTD. BD And since in BD DTD's you shouldn't be using namespaces in the first place, maybe it is BD easier to simply make a transformer which drops all namespaces? Shouldn't, but it's possible. Read the modularized SVG and XHTML DTD's? And as I want to be open to all XML output, I need a good way to support it. Regards Torsten -- Domain in provider transition, hope for smoothness. Planed date is 1.7.2003.
Re: TidySerializer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 04 June 2003 00:09, Geoff Howard wrote: GH TK JH 1: A solution for the HTMLSerializer was discussed GH TK JH (startPrefixMapping(), endPrefixMapping()). Maybe TidySerializer GH TK JH provides a better solution, but I guess this can be adapted too. GH TK A little more would be nercessary. You would have to map all GH TK xhtml namespace GH TK to default prefix and remove the declaration. All other GH TK namespaces would have GH TK to generate an error. When I know someone will commit it, I can make GH TK this patch for HTMLSerializer. GH Send a patch that does that and I'll commit it. Already written. I'll test it tomorrow and send it to the BTS. GH Domain in provider transition, hope for smoothness. Planed date GH is 1.7.2003. GH Is that done yet? ;) No. I have the warning there, as changing from strato is often a pain. - -- Domain in provider transition, hope for smoothness. Planed date is 1.7.2003. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+3S1hvxZktkzSmiwRAt7JAJ0ZDbjm6Jb+OQf5HlF3UxtnvaFIBwCfdf12 fqJrrK5pgWIfkPFHOAo1M+w= =nWD/ -END PGP SIGNATURE-
RE: Cocoon developers on the east coast of the US
Hi I've done some cocoon. If you have an interesting project for remote development, I'd consider. my home page is at members.cox.net/akuketayev Thanks for the info. I will keep you posted. Thanks Michael I also know other cocoon folks in DC metro area. Argyn -Original Message- From: Michael Wechner [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 6:10 PM To: [EMAIL PROTECTED] Subject: Cocoon developers on the east coast of the US Hello all I am looking for Cocoon developers on the east coast of the US (preferably Boston/Cambridge and NYC). If you are interested to work on an exciting project (which probably everyone would say , please contact me off the list. Thanks Michael
DO NOT REPLY [Bug 16958] - caching pipeline serves wrong content
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16958. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16958 caching pipeline serves wrong content [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|ASSIGNED|NEW
Log level, compatibility (was: Re: DO NOT REPLY [Bug 20445] New: - i18n transformer does notrecognize 2.0 namespace)
From: Bruno Dumon [EMAIL PROTECTED] On Tue, 2003-06-03 at 23:12, Joerg Heinicke wrote: I guess, legacy support won't be readded, so this is a WONTFIX? yes, I agree. A bit of a problem though is that upon encountering the old namespace, the I18nTransformer nicely logs a warning, however the log level is error by default. Maybe we should lower it to warn instead? Btw, the WARNING text in 2.1 states: ... Until then, there will be no warranty that newer versions will maintain backward compatibility for such parts, even in the most simple cases. Of course Cocoon will be compatible to latest release, 2.0.x release. ... Somewhat contradicting statements, arent they? Should the version 2.1 be backward compatible with 2.0.x releases? (there are other components also logging deprecation warnings not visible by default) +1 for lowering the log level to WARN. But it'd be much better to provide two (or more) typical configurations, e.g.: - development: log level - DEBUG, development cache settings, etc. - testing: log level - WARN, etc. - production: log level - ERROR, etc. What do you think? -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
DO NOT REPLY [Bug 20033] - [PATCH]LDAPTransformer patch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20033. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20033 [PATCH]LDAPTransformer patch --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 07:58 --- Created an attachment (id=6620) implement the add/replace value of attributes
DO NOT REPLY [Bug 19104] - [PATCH] SchematronValidator incorrectly creates JXPath contexts which breaks tests in schemas
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19104. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19104 [PATCH] SchematronValidator incorrectly creates JXPath contexts which breaks tests in schemas [EMAIL PROTECTED] changed: What|Removed |Added Summary|SchematronValidator |[PATCH] SchematronValidator |incorrectly creates JXPath |incorrectly creates JXPath |contexts which breaks tests |contexts which breaks tests |in schemas |in schemas --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 08:10 --- Changed summary to include '[PATCH]'.
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/bean/destination Destination.java DestinationNotFoundException.java FileDestination.java NullDestination.java ThreadedDestination.java
upayavira2003/06/04 02:25:53
Modified:.cli.xconf
src/java/org/apache/cocoon Cocoon.java Constants.java
Main.java
src/java/org/apache/cocoon/bean CocoonBean.java
src/java/org/apache/cocoon/environment/commandline
AbstractCommandLineEnvironment.java
Added: src/java/org/apache/cocoon/bean/helpers
DelayedOutputStream.java
Removed: src/java/org/apache/cocoon/bean/destination Destination.java
DestinationNotFoundException.java
FileDestination.java NullDestination.java
ThreadedDestination.java
Log:
Added broken link functionality
Replaced Destination object with ModifiableSources in CLI
Moved CLI constants into CocoonBean class (as suggested by GP)
Reworked getConfigurationFile and made it also look into WEB-INF for the config file
(see bug 12158)
Revision ChangesPath
1.2 +139 -8cocoon-2.1/cli.xconf
Index: cli.xconf
===
RCS file: /home/cvs/cocoon-2.1/cli.xconf,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- cli.xconf 18 Mar 2003 15:23:28 - 1.1
+++ cli.xconf 4 Jun 2003 09:25:52 - 1.2
@@ -1,22 +1,153 @@
?xml version=1.0?
-!-- all links here are relative to the build context dir, that
- in the build.xml file is set to ${build.context} --
+!--+
+| This is the Apache Cocoon command line configuration file.
+| Here you give the command line interface details of where
+| to find various aspects of your Cocoon installation.
+|
+| If you wish, you can also use this file to specify the URIs
+| that you wish to generate.
+|
+| The current configuration information in this file is for
+| building the Cocoon documentation. Therefore, all links here
+| are relative to the build context dir, which, in the build.xml
+| file, is set to ${build.context}
+|
+| Options:
+|verbose:increase amount of information presented
+|to standard output (default: false)
+|follow-links: whether linked pages should also be
+|generated (default: true)
+|precompile-only:precompile sitemaps and XSP pages, but
+|do not generate any pages (default: false)
+|confirm-extensions: check the mime type for the generated page
+|and adjust filename and links extensions
+|to match the mime type
+|(e.g. text/html-.html)
++--
+
cocoon verbose=true
follow-links=true
precompile-only=false
-confirm-extensions=true
+confirm-extensions=false
- broken-link-file../brokenlinks.txt/broken-link-file
-!--load-classorg.firebirdsql.jdbc.Driver/load-class--
+ !--+
+ | Broken link reporting options:
+ | Report into a text file, one link per line:
+ | broken-links type=text report=filename/
+ | Report into an XML file:
+ | broken-links type=xml report=filename/
+ | Ignore broken links (default):
+ | broken-links type=none/
+ | When a page includes an error, should a page be generated?
+ |
+ | Two attributes to this node specify whether a page should
+ | be generated when an error occured. 'generate' specifies
+ | whether a page should be generated (default: true) and
+ | extension specifies an extension that should be appended
+ | to the generated page's filename (default: none)
+ | broken-links generate=true extension=.error.txt/
+ |
+ +--
+ broken-links type=xml
+ file=../brokenlinks.xml
+ generate=false
+ extension=.error/
+
+ !--+
+ | Load classes at startup. This is necessary for generating
+ | from sites that use SQL databases and JDBC.
+ | The load-class element can be repeated if multiple classes
+ | are needed.
+ +--
+ !--
+ load-classorg.firebirdsql.jdbc.Driver/load-class
+ --
+
+ !--+
+ |
+ +--
logging log-kit=./logkit.xconf logger=cli level=ERROR /
+
+ !--+
+ | The context directory is usually the webapp directory
+ | containing the sitemap.xmap file.
+ |
+ | The config file is the cocoon.xconf file.
+ |
+ | The work directory is used by Cocoon to store temporary
+ | files and cache files.
+ |
+ | The destination directory is where generated pages will
+ |
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/bean/helpers - New directory
upayavira2003/06/04 02:23:03 cocoon-2.1/src/java/org/apache/cocoon/bean/helpers - New directory
DO NOT REPLY [Bug 12158] - some improvements to Main.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12158. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12158 some improvements to Main.java [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 10:19 --- 1) Makes sense. I've made the CLI now look into WEB-INF for the cocoon.xconf file. 2) No longer relevant as the command line handling now uses the commons CLI jar. 3) Because, if you are following links, you do not want to follow a link twice. However, if you are not following links, there might be situations in which you want a page to be generated multiple times. See new code in HEAD which allows you to specify a URI 'target', in which you specify not just the source URI, but also what should happen to the page once generated. If the same page goes to the same destination, it is not scanned twice. If it goes somewhere else, it will be generated again. Does this resolve your issue? Is the issue still current? These changes only apply to the 2.1 HEAD. Upayavira
DO NOT REPLY [Bug 18679] - [PATCH] CLI Broken Links Improvements
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18679. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18679 [PATCH] CLI Broken Links Improvements [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 10:20 --- Patch commited.
DO NOT REPLY [Bug 18679] - [PATCH] CLI Broken Links Improvements
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18679. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18679 [PATCH] CLI Broken Links Improvements [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED
Re: ValidatingTransformer (WAS RE: TidySerializer)
On 4 Jun 2003 at 10:28, Conal Tuohy wrote: Joerg Heinicke wrote: Ok, reason accepted :) But what about an extra validating transformer as last pipeline step? Seems to make more sense IMO. YES! This could be VERY useful: a transfomer that could validate the output of some pipeline stage against a DTD or other schema could be a great help for debugging. You wouldn't have to download the file and validate it with an external tool. It might even have a role in production systems for validating input from forms, web services etc? map:transform type=dtd-validator map:parameter name=dtd value=dtd/stage-1.dtd/ /map:transform And then you add that transformer into a view, so you can access page.html?cocoon-view=validate to find out whether the page validates. That'd be neat. Upayavira
RE: TidySerializer
BD TK We have a current problem, that cocoon is not useable in many cases, I think I just changed my opinion. I don't need a TidySerializer as desperately as I thought I did. What I need is HTML-valid (whatever that may be) output from Cocoon. I saw Jeorg rescue someone on the users list who's script tag got messed up. This issue has been going on for a long long time.. And I have the feeling a lot of users really don't understand this behauviour. I know it is fixed now - but it's not clear enough for users. It's probably a matter of time, but some Wikifying could speed the process [note to myself]. So that's done. Another inventory. 1) script tags are messed up 2) style tags are messed up 3) textarea tags are messed up 4) namespaces stick in the final HTML 5) dtd validity (for debugging purposes?) 6) human readibility These could all by done by Tidy; but with the extra overhead, and we shouldn't encourage this. ad. 1, 2, 3: [Joerg Heinicke] 2.0.5-dev and 2.1M3-dev: With both versions script/ and style/ are serialized to script/script and style/style. (same goes for textarea, right?). [NTM: Wikify] ad. 4: fix in the HTMLSerializer: TK A little more would be necessary. You would have to map TK all xhtml namespace to default prefix and remove the declaration. TK All other namespaces would have to generate an error. I agree with this completely. But is this the same thing that you discussed with Vadim in august last year? (http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=102865880018966w=2). What was the final outcome back then? ad. 5: ... [Conal Tuohy] ValidatingTransformer? ad. 6: ... HumanReadableSerializer? - oops sorry; I meant TidySerializer :) So only the last point could be used as an argument for the TidySerializer? Sorry for this long post... But I need some clarity.. Arje BD TK because it's nearly impossible to create valid (x)html. BD And again I'm wondering why? Of the tree reasons given earlier: BD AC 1) As a fix for the the namespace problem BD AC 2) When human-readable HTML output is needed BD AC 3) To validate the output to a dtd BD only number 1 really causes problems, the others are merely BD conveniences. Those are important too, but don't make it impossible to BD create valid (x)html. The second is helpful to debug your output and the last is helpful to ensure you output valid code. yeah yeah, I agree with that, and for that purpose the tidyserializer is very valuable. I was only wondering if there were any blocking bugs in the normal htmlserializer that make it impossible to generate valid html (next to the namespace problem). (I'll look into applying the tidyserializer.) BD I'm not opposed to a tidyserializer. I'm just figuring out why I would BD use it. To make it affordable to have valid html output. Problem is, you can do it actually, but it's to much work. You have to use a xml formatter, to read the output and see whats wrong. You have to validate the output to see if it's valid. Is there any other way to validate the output then by validating it? You have to do xalan tricks to remove unneeded namespaces. ... Tidy is a temporary (I hope that xalan does the job some time, because I'd like to have it for wml and others too) If the job means that Xalan should validate the serialized xml against the DTD it references, then I think it's a pretty save bet to say that will never ever happen. solution for these problems. For me it works much better than the existing HTMLSerializer, that's why I sent it to the BTS. When you don't have these problems so far, or have another way or a better way to solve them, you don't need it. Indeed it's better not to use it, as it eats performance. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: FOM and stateful components
Ricardo Rocha wrote:
As originally proposed by Stefano, the FOM exposes a getComponent(id)
method but not a corresponding releaseComponent(component), as Sylvain
was quick to point out.
:-)
I agree with Sylvain that releaseComponent() is indeed needed for
stateful, pooled components.
Btw, I'm sure when Stefano mentioned stateful components being
questioned he referred to *EJB* stateful session beans that keep state
on behalf of a remote client. In this arena, it's felt that keeping
session state is best done at the webapp layer rather than inside the
EJB container. But that's another matter...
*Avalon* stateful, pooled components, OTH, _require_ to be released
after use.
That said, using try/catch blocks in Javascript to ensure proper
stateful component release looks anti-scripting to me. In an ideal
world, the flow implementation should take care of this aspect for the
flow developer. Of course, I do see such a guarantee is easier hoped
for than implemented.
Agree, both with the anti-scripting look and difficult implementation.
Because of continuations, automatically releasing components at the
end of request processing is clearly not appropriate.
Things are further complicated by the fact that continuations can be
abandoned. How should we deal with active stateful components in this
case? Even if we hook into continuation expiration, this could still
lead to excesive tying up of pooled heavy-weight components.
Should we reclaim components at the end of sitemap-invoked function
execution? This makes more sense because function completion can span
across requests.
This won't work, since when a continuation path reaches the end of a
function, other paths in the same tree can still need these components.
Performing component auto-releasing at the end of sitemap-invoked
function completion (whether because of return or exception) seems a
reasonable thing to do because, typically, such function call will
embody a complete interaction between the user and the application. If
any components were needed during that process it's ok to relase them
at use-case completion.
Again, the notion of use-case completion is intimately tied to the
various branches that exist on the continuation tree. Some use cases,
such as a shopping cart, will want to ensure that no other branch still
exists when the end of the function is reached (i.e. the order is
placed). To achieve this, the solution is to create a continuation at
the start of the function, and invalidate it when one of the branches
reaches the end of the function. The whole continuation tree is then
invalidated.
However, it would preclude keeping components in use across flow
functions. Would this truly limit flow usability?
What about specifying a retention policy (session, function) upon
acquiring components? getComponent(id[, scope])
What do you guys think?
I think there are only two reliable ways to manage stateful components :
1/ raise an error if there are some unreleased stateful components when
a continuation is created.
2/ tie releasing of a component to the death of the continuation to
which it belongs.
Solution 1/ solves the problem by suppressing its cause. Although it
seems very strict, we can also consider that application state should be
kept by script variables and and not state of components. This is
similar to your remark about EJB statefull session beans : keep state in
the webapp an not in the container.
Solution 2/ can answer transparently to your function policy. If the
whole continuation tree is invalidated at function completion on one of
the branches, all components looked up since the function started are
automatically released.
Although solution 2 seems nice, I still find it dangerous to allow
heavyweight resources to float around between requests. This is an open
door to many memory and performance problems if this feature is abused.
Also, it strongly prevents session serialization and thus the use of
flowscript on failsafe servers. So I would go for solution 1, which
enforces careful state management.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: ValidatingTransformer (WAS RE: TidySerializer)
map:transform type=dtd-validator map:parameter name=dtd value=dtd/stage-1.dtd/ /map:transform Or, perhaps map:transform type=dtd-validator src=dtd/stage-1.dtd/ /Adrian Any e-mail message from the European Central Bank (ECB) is sent in good faith but shall neither be binding nor construed as constituting a commitment by the ECB except where provided for in a written agreement. This e-mail is intended only for the use of the recipient(s) named above. Any unauthorised disclosure, use or dissemination, either in whole or in part, is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and delete this e-mail from your system.
multiple catalogue search
Hello, Continuing with my work on customization, I'd like to be able to search multiple catalogs, so if the customized web name is foo I'd like to be able to do: 1. search translation in appropriate file of messages_foo catalog hierarchy 2. If no entry is found, search translation in appropriate file of messages catalog hierarchy Even more than two catalogs hierarchies could be used, to accomodate for domain-specific jargon, eg: 1. search messages_novartis hierarchy 2. search messages_biochemical hierarchy 3. search messages hierarchy -- Fernando D. Mato Mira [EMAIL PROTECTED] Thomson Dialog www.dialog.com E-MAIL NOTICE: This message (plus any attachments) is confidential and may be subject to lawyer-client privilege. Use without permission is strictly prohibited.
Re: Log level, compatibility (was: Re: DO NOT REPLY [Bug 20445] New: - i18n transformer does notrecognize 2.0 namespace)
At 02:14 AM 6/4/2003, Konstantin wrote: +1 for lowering the log level to WARN. But it'd be much better to provide two (or more) typical configurations, e.g.: - development: log level - DEBUG, development cache settings, etc. - testing: log level - WARN, etc. - production: log level - ERROR, etc. What do you think? This could be done now with the new custom-config build target I've been working on which uses xpatch. Currently, the only way to do this would be to provide multiple patch files for the log xconf which rely on different build properties (like config.loglevel.warn=true) because no variable expansion is done on the contents of the xpatch. (see: http://wiki.cocoondev.org/Wiki.jsp?page=XPatchTaskUsage http://wiki.cocoondev.org/Wiki.jsp?page=YourCocoonBasedProject (my comment at the end) http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=105440069221225w=2 It would be nice to enable variable substitution though. I looked at the ant docs but 1) saw a warning of API instability in the package/class that looked like what I'd need to do the expansion 2) only saw methods to operate on strings, but didn't see a clean way to do so for xml being parsed in. Any takers to help me out? Geoff
Re: [Bug 20445] New: - i18n transformer does not recognize 2.0 namespace
Bruno Dumon wrote:
On Tue, 2003-06-03 at 23:12, Joerg Heinicke wrote:
I guess, legacy support won't be readded, so this is a WONTFIX?
yes, I agree. A bit of a problem though is that upon encountering the
old namespace, the I18nTransformer nicely logs a warning, however the
log level is error by default. Maybe we should lower it to warn instead?
(there are other components also logging deprecation warnings not
visible by default)
We should make a difference between deprecation (still works, but likely
to disappear in the future), and detection of abandoned features.
So IMO, if the old i18n namespace is detected but not supported, then
the message should be an error, since the feature is no longer provided.
But this leads to another question : why did we loose backwards
compatibility ? I'm a bit ignorant about the evolutions that led to
change the namespace, but why haven't we kept the old transformer beside
a new one handling the new namespace ?
This would have allowed a smooth migration path by not breaking existing
applications. Of course, the old transformer should log a deprecation
warning encouraging users to migrate to the new one.
So what about renaming the new transformer to I18nTransformer2 and
re-adding the old I18nTransformer ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
DO NOT REPLY [Bug 20297] - [PATCH] Added RequestURI in addition to SitemapURI to BaseLinkModule
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20297. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20297 [PATCH] Added RequestURI in addition to SitemapURI to BaseLinkModule [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 12:38 --- Sorry, my fault. Will accept patch.
DO NOT REPLY [Bug 20297] - [PATCH] Added RequestURI in addition to SitemapURI to BaseLinkModule
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20297. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20297 [PATCH] Added RequestURI in addition to SitemapURI to BaseLinkModule [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/bean/helpers - New directory
On 04.Jun.2003 -- 09:23 AM, [EMAIL PROTECTED] wrote: upayavira2003/06/04 02:23:03 cocoon-2.1/src/java/org/apache/cocoon/bean/helpers - New directory Would CocoonBean.INDEX_URI be the same as Constants.INDEX_URI? CocoonProcessorDelegate in scratchpad seems to miss this constant Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
cvs commit: cocoon-2.1/tools/src/anttasks XConfToolTask.java
ghoward 2003/06/04 19:55:51
Modified:tools/src/anttasks XConfToolTask.java
Log:
Add unless-path. Functionally identical but clearer name than unless.
For back compat, unless is used when unless-path is not specified.
Revision ChangesPath
1.6 +9 -4 cocoon-2.1/tools/src/anttasks/XConfToolTask.java
Index: XConfToolTask.java
===
RCS file: /home/cvs/cocoon-2.1/tools/src/anttasks/XConfToolTask.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- XConfToolTask.java23 May 2003 02:48:03 - 1.5
+++ XConfToolTask.java5 Jun 2003 02:55:51 - 1.6
@@ -247,15 +247,20 @@
Node root = nodes.item(0);
// Test that 'root' node satisfies 'component' insertion criteria
-String test = component.getDocumentElement().getAttribute(unless);
+String testPath =
component.getDocumentElement().getAttribute(unless-path);
+if (testPath == null) {
+// only look for old unless attr if unless-path is not present
+testPath = component.getDocumentElement().getAttribute(unless);
+}
+// Is if-path needed?
String ifProp = component.getDocumentElement().getAttribute(if-prop);
boolean ifValue =
Boolean.valueOf(project.getProperty(ifProp)).booleanValue();
if (ifProp != null (ifProp.length()0) !ifValue ) {
log(Skipping: + file, Project.MSG_DEBUG);
return false;
-} else if ((test!=null) (test.length()0)
-(XPathAPI.selectNodeList(root, test).getLength()!=0)) {
+} else if ((testPath!=null) (testPath.length()0)
+(XPathAPI.selectNodeList(root, testPath).getLength()!=0)) {
log(Skipping: + file, Project.MSG_DEBUG);
return false;
} else {
cvs commit: cocoon-2.1/src/targets webapp-build.xml
ghoward 2003/06/04 20:02:45
Modified:src/targets webapp-build.xml
Log:
one path was still hardcoded from testing.
Revision ChangesPath
1.19 +1 -1 cocoon-2.1/src/targets/webapp-build.xml
Index: webapp-build.xml
===
RCS file: /home/cvs/cocoon-2.1/src/targets/webapp-build.xml,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- webapp-build.xml 31 May 2003 17:04:46 - 1.18
+++ webapp-build.xml 5 Jun 2003 03:02:45 - 1.19
@@ -164,7 +164,7 @@
target name=custom-conf depends=init-tasks description=Uses Cocoon's xpatch
task to customize runtime configuration
xpatch file=${build.webapp}/sitemap.xmap srcdir=
include name=${customconf}/*.xmap /
- include name=src/confpatch/*.xpipe /
+ include name=${customconf}/*.xpipe /
/xpatch
xpatch file=${build.webapp}/WEB-INF/cocoon.xconf srcdir=
include name=${customconf}/*.xconf /
Re: [CLI] Breaking CocoonBean Interface
Upayavira wrote: ... It is particularly the removal of the Destination interface that breaks the interface. However, removing the setDestDir will certainly make a cleaner interface. I'll do that. Thanks. Sorry for me being slow. Vadim
RE: Log level, compatibility
-Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Geoff Howard wrote: At 02:14 AM 6/4/2003, Konstantin wrote: +1 for lowering the log level to WARN. But it'd be much better to provide two (or more) typical configurations, e.g.: - development: log level - DEBUG, development cache settings, etc. - testing: log level - WARN, etc. INFO should be even better. ... Any takers to help me out? Why not simply error.level in build.properties and ant filtering of logkit.xconf? Simple, and no additional code. Vadim That would work for this case but the build is not currently filtering logkit.xconf is it? In general people have asked for this ability, and I'd find it useful. Doesn't need to be tied to any log level change though, just fishing. ;) As an update, I tried using org.apache.tools.ant.filters.ExpandProperties which extends java.io.Reader to wrap the File object on the way in to the DocumentBuilder, but was getting errors. Geoff
