Re: [Proposal] Include Jetty in Cocoon CVS
On Tuesday, December 3, 2002, at 01:14 AM, Nicola Ken Barozzi wrote: Yes, it's very nice for testing and embedding, like in this case. mapping the cocoon's webapp to uri / gives some weird link problems. the cocoon webapplication seems to prefer to be mapped to /cocoon, or at least to some other none / only servlet uri. Would be worth fixing this (when?) jetty is part of the release... other than in tomcat you need a / as second Argument Call name=addWebApplication Argcocoon.host.tld/Arg Arg//Arg Arg/home/www/serv/webapps/cocoon204//Arg /Call the second (little) problem I had when I switched to Jetty concerned paths in the sitemap: I had to change all redirects like map:match pattern= map:redirect-to uri=start.html/ /map:match by adding a / map:match pattern= map:redirect-to uri=/start.html/ /map:match I'm still not sure who handles this correctly. Tomcat does the same thing, if there is a / or not. This makes me think that tomcat is less precise. If I was eligible for voting it would be +1. Jetty saved me days with the short restating time. /Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Designing Dialogs in XML
Hi,
Since cocoon is moving to Relax NG schemas, why not build your forms from that?
For example:
rng:define name=page
rng:element name=page
rng:ref name=page.attrlist/
rng:zeroOrMore
rng:ref name=col/
/rng:zeroOrMore
/rng:element
/rng:define
rng:define name=page.attrlist
rng:attribute name=print_friendly
a:attr label=Print friendly dflt=false
a:descriptionIndicates whether a print friendly page should be
generated/a:description
/a:attr
rng:data type=boolean/
/rng:attribute
rng:ref name=title.attr/
rng:ref name=xsl_fileref.attr/
/rng:define
rng:define name=title.attr
rng:attribute name=title
a:attr label=Title dflt=
a:descriptionA text title/a:description
/a:attr
rng:data type=token/
/rng:attribute
/rng:define
rng:define name=xsl_fileref.attr
rng:attribute name=xsl_fileref
a:attr label=XSL ref dflt=default
a:descriptionA name of the primary XSL template to be
used/a:description
/a:attr
rng:choice
rng:value type=NMTOKENdefault/rng:value
rng:value type=NMTOKENsomething-else/rng:value
/rng:choice
/rng:attribute
/rng:define
I am taking some liberties with the annotation in the schema as it is currently
defined, but it still validates (both the schema and the XML instance).
Transform this into your form using the annotations to fill out whatever else
needs to be in the form. Perhaps cocoon devs could come up with an altered RNG
Schema (the one that validates the RNG schema itself) for these additional
annotations. By the way it is pretty easy to transform this into a set of JS
objects (client - or server side, if necessary). Note: the //a:attr/@dflt is
spelled the way it is so it can work in JS.
best,
-Rob
-Original Message-
From: Ovidiu Predescu [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 02, 2002 11:42 PM
To: [EMAIL PROTECTED]
Subject: Re: Designing Dialogs in XML
Matthew,
I was talking to Stefan Sofariu at GetTogether and he mentioned XUL
from Mozilla in the same context of an XML language to define controls
which are independent of HTML. The event and object model is a bit
different though, but nevertheless XUL would be a great markup to use
to define controls on a page.
One nice thing about XUL's event model, which is heavily based on
JavaScript, is that it could translate to the control flow quite easy.
This would be a real killer app for the control flow, since a XUL
application for Mozilla could run within Cocoon as well! There would be
a lot of plumbing required to emulate the object model available in
XUL, but it would be really interesting.
Regards,
Ovidiu
On Monday, Dec 2, 2002, at 00:27 US/Pacific, Matthew Langham wrote:
Hi,
thanks for the pointers. Yes this is roughly what I had in mind. I was
however surprised that I couldn't find anything standardized.
But this morning Carsten pointed me to XFrames
(http://www.w3.org/TR/2002/WD-xframes-20020806/) and together with the
XMLForm stuff, I think that is what we are looking for.
Matthew
--
Open Source Group Cocoon { Consulting, Training, Projects }
=
Matthew Langham, SN AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 [EMAIL PROTECTED] - http://www.s-und-n.de
-
Cocoon book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
Weblog:
http://radio.weblogs.com/0103021/
=
-Original Message-
From: Ivelin Ivanov [mailto:[EMAIL PROTECTED]]
Sent: Saturday, November 30, 2002 4:55 PM
To: [EMAIL PROTECTED]
Subject: Re: Designing Dialogs in XML
If I understand correctly, the thing you're looking for exists.
Look at the WebServiceProxyGenerator demos.
One of them uses only the XMLForm stylesheet which simple transforms a
XMLForm markup into HTML markup,
without using any of the other XMLForm components (action, transformer,
validator).
The other one (cocoonhive mini-portal) is using a page markup very
similar
to the one in your example.
I guess the src=/resources/header part can be conveniently replaced
with a
CInclude or an XInclude
(again look at the cocoonhive main document).
Let me know if this helped any.
Ivelin
[1] WSPG demo
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/webapp/samples/
webservicep
roxy/
[2] Cocoonhive demo portal main doc
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/webapp/samples/
webservicep
roxy/cocoonhive/portal/
[3] XMLForm to HTML without any validation overhead, etc.
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/webapp/samples/
webservicep
roxy/sitemap.xmap?rev=HEADcontent-type=text/vnd.viewcvs-markup
- Original Message
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/serialization ZipArchiveSerializer.java
cziegeler2002/12/03 02:20:02
Modified:src/java/org/apache/cocoon/serialization
ZipArchiveSerializer.java
Log:
Avoid private internal calls and use the allowed api instead
Revision ChangesPath
1.3 +64 -44
xml-cocoon2/src/java/org/apache/cocoon/serialization/ZipArchiveSerializer.java
Index: ZipArchiveSerializer.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/serialization/ZipArchiveSerializer.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ZipArchiveSerializer.java 31 Oct 2002 16:48:55 - 1.2
+++ ZipArchiveSerializer.java 3 Dec 2002 10:20:01 - 1.3
@@ -51,12 +51,11 @@
package org.apache.cocoon.serialization;
-import org.apache.cocoon.caching.CacheValidity;
-import org.apache.cocoon.caching.Cacheable;
-import org.apache.cocoon.components.CocoonComponentManager;
-import org.apache.cocoon.environment.Source;
-import org.apache.cocoon.environment.SourceResolver;
-
+import org.apache.avalon.framework.component.ComponentException;
+import org.apache.avalon.framework.component.ComponentManager;
+import org.apache.avalon.framework.component.Composable;
+import org.apache.excalibur.source.Source;
+import org.apache.excalibur.source.SourceResolver;
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
@@ -96,63 +95,70 @@
// svg.../svg
///entry
-public class ZipArchiveSerializer extends AbstractSerializer
-{
+public class ZipArchiveSerializer
+extends AbstractSerializer
+implements Composable {
/**
* The namespace for elements handled by this serializer,
* http://apache.org/cocoon/zip-archive/1.0;.
*/
-public static final String ZIP_NAMESPACE =
http://apache.org/cocoon/zip-archive/1.0;;
-
+public static final String ZIP_NAMESPACE =
+http://apache.org/cocoon/zip-archive/1.0;;
+
/** The Zip stream where entries will be written */
protected ZipOutputStream zipOutput;
-
+
/** Have we encountered the toplevel zip element ? */
protected boolean inZip = false;
-
-/** The resolver to get sources */
-protected SourceResolver resolver;
-
+
/** Temporary byte buffer to read source data */
protected byte[] buffer = new byte[1024];
-
+
+protected ComponentManager manager;
+
/**
* Always return application/x-zip which is the default for Zip archives.
*/
-public String getMimeType()
-{
+public String getMimeType() {
return application/x-zip;
}
/**
* @see org.xml.sax.ContentHandler#startDocument()
*/
-public void startDocument() throws SAXException
-{
+public void startDocument() throws SAXException {
this.zipOutput = new ZipOutputStream(this.output);
this.inZip = false;
-this.resolver = CocoonComponentManager.getCurrentEnvironment();
}
/**
* @see org.xml.sax.ContentHandler#startElement(String, String, String,
Attributes)
*/
-public void startElement(String namespaceURI, String localName, String qName,
Attributes atts) throws SAXException
-{
+public void startElement(String namespaceURI,
+String localName,
+String qName,
+Attributes atts)
+throws SAXException {
if (!inZip) {
// expecting zip as the first element
-if (namespaceURI.equals(ZIP_NAMESPACE) localName.equals(archive)) {
+if (namespaceURI.equals(ZIP_NAMESPACE)
+ localName.equals(archive)) {
this.inZip = true;
} else {
-throw new SAXException(Expecting 'archive' root element (got ' +
localName + '));
+throw new SAXException(
+Expecting 'archive' root element (got '
++ localName
++ '));
}
} else {
// expecting entry element
-if (namespaceURI.equals(ZIP_NAMESPACE) localName.equals(entry)) {
+if (namespaceURI.equals(ZIP_NAMESPACE)
+ localName.equals(entry)) {
// Get the source
addEntry(atts);
} else {
-throw new SAXException(Expecting 'entry' element (got ' +
localName + '));
+throw new SAXException(
+Expecting 'entry' element (got ' + localName + '));
}
}
}
@@ -161,56 +167,70 @@
* Add an entry in the archive.
* @param atts the attributes that describe the entry
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components CocoonComponentManager.java
cziegeler2002/12/03 02:21:57
Modified:src/java/org/apache/cocoon/components
CocoonComponentManager.java
Log:
Add warning comment
Revision ChangesPath
1.43 +5 -2
xml-cocoon2/src/java/org/apache/cocoon/components/CocoonComponentManager.java
Index: CocoonComponentManager.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/CocoonComponentManager.java,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- CocoonComponentManager.java 2 Dec 2002 08:39:17 - 1.42
+++ CocoonComponentManager.java 3 Dec 2002 10:21:57 - 1.43
@@ -78,7 +78,10 @@
* Cocoon Component Manager.
* This manager extends the {@link ExcaliburComponentManager}
* by a special lifecycle handling for a {@link RequestLifecycleComponent}
- * and by handling the lookup of the codeSourceResolver/code
+ * and by handling the lookup of the {@link SourceResolver}.
+ * WARNING: This is a private Cocoon core class - do NOT use this class
+ * directly - and do not assume that a {@link ComponentManager} you get
+ * via the compose() method is an instance of CocoonComponentManager.
*
* @author a href=mailto:[EMAIL PROTECTED];Carsten Ziegeler/a
* @version CVS $Id$
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: PATCH QUEUE... downsizing...?
Yes, we should :) (perhaps after the 2.0.4 release) So any volunteers? Thanks Carsten -Original Message- From: Morrison, John [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 1:32 PM To: '[EMAIL PROTECTED]' Subject: PATCH QUEUE... downsizing...? Should we try and either apply or discard some of these? J. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Important] Any showstopper for 2.0.4 release? [was:Looking for help in the upcomming release]
Hi Cocooners, first of all many thanks to all who helped and gave feedback in the last days for finalizing the upcomming 2.0.4. As far as I see it, there are no showstoppers. There were some installation problems, so perhaps updating the docs would help here. Am I right? If there are no real showstoppers, I will release 2.0.4 on thursday. Carsten Carsten Ziegeler Chief Architect Open Source Group, SN AG -- Open Source in Commerce -- mailto:[EMAIL PROTECTED] http://www.s-und-n.de http://ziegeler.bei.t-online.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important] Any showstopper for 2.0.4 release? [was:Looking forhelp in the upcomming release]
Hi Carsten, On Tue, 3 Dec 2002, Carsten Ziegeler wrote: As far as I see it, there are no showstoppers. Am I right? Yup, looks ok to me. Except, of course, for one small thing ;-) http://localhost:8080/cocoon/samples/welcome has the wrong href for the slides link, should be ../slides/slides. Recenctly the text has been updated but not the link. If there are no real showstoppers, I will release 2.0.4 on thursday. Cool! Andrew. -- Andrew SavoryEmail: [EMAIL PROTECTED] Managing Director Tel: +44 (0)870 741 6658 Luminas Internet Applications Fax: +44 (0)700 598 1135 This is not an official statement or order.Web:www.luminas.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/webapp/samples samples.xml
cziegeler2002/12/03 03:52:57 Modified:src/webapp/samples Tag: cocoon_2_0_3_branch samples.xml Log: Fixing link. Reported by Andrew Savory [[EMAIL PROTECTED]] Revision ChangesPath No revision No revision 1.3.2.5 +2 -2 xml-cocoon2/src/webapp/samples/samples.xml Index: samples.xml === RCS file: /home/cvs/xml-cocoon2/src/webapp/samples/samples.xml,v retrieving revision 1.3.2.4 retrieving revision 1.3.2.5 diff -u -r1.3.2.4 -r1.3.2.5 --- samples.xml 1 Dec 2002 04:01:47 - 1.3.2.4 +++ samples.xml 3 Dec 2002 11:52:57 - 1.3.2.5 @@ -91,7 +91,7 @@ sample name=List of docs href=../documents/doclist.html Generated list of all documentation (aggregates each book.xml) /sample - sample name=Slides href=slides/slides + sample name=Slides href=../slides/slides An old, but still relevant, presentation of Cocoon 1 shown at ApacheCon 2000 (an example of complex XSLT usage). /sample -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Important] Any showstopper for 2.0.4 release? [was:Looking for help in the upcomming release]
Andrew Savory wrote: Hi Carsten, On Tue, 3 Dec 2002, Carsten Ziegeler wrote: As far as I see it, there are no showstoppers. Am I right? Yup, looks ok to me. Except, of course, for one small thing ;-) http://localhost:8080/cocoon/samples/welcome has the wrong href for the slides link, should be ../slides/slides. Recenctly the text has been updated but not the link. Thanks for reporting, Andrew. It's fixed now :) Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Fwd: Re: Sendmail serial email]
Something is wrong with the user-mailing list! ---BeginMessage--- Dear Ray, dear all, thanks for the reply! Ray Martin wrote: Sir, I too experienced that no one would give any answers. But, i am wondering if the cocoon-users mail list server is always behaving correctly. i am subscribed to the cocoon-users list, but this is the first time that i have seen your message. i did not receive any of your previous postings on this question. ...and I have posted a lot. i too got sendmail to work for me slightly. however, i was never able to get sendmail to authenticate or to attach a file. i gave up on sendmail. Instead i use an action in which i have some JAVA mail client code. Now i can control the code exactly to meet my requirements. i am no longer dependent on code that has no documentation beyond a simple tutorial - which in its own self was very interesting - just no clues as to how to proceed with such things as authentication and file attachment. if i can help in any way - a code snippet? - let me know. if you are going to continue with sendmail, i cannot help. YES PLEASE LET ME KNOW HOW YOU DID IT. I am not married to sendmail. You are right in saying the tutorial is not enough, because to attach something to mail is quite basic stuff you want to do with mail. authentication is no point at the moment but it should be possible. another subject - i know that you are talking about attaching a file to an email. but, while we are on the subject of attaching files. if there is ever a time when you want to attach a file to an HTTP request (file uploading) - cocoon does this automatically. i was going crazy trying to figure out how to do it - i accidentally looked in the cocoon upload directory and there the file was - sitting right there as nice as could be - kinda like magic. i would like to know more about the class that was used to parse the multipart form, but i have not been able to fidn it just yet. good luck with sending emails, Ray -Original Message- From: Scherler, Thorsten [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 9:49 AM To: [EMAIL PROTECTED] Subject: AW: Sendmail serial email Hello group, I don't know why I don't get any answers on that topic, but it is quit frustrating. http://www.javaworld.com/javaworld/jw-09-2002/jw-0920-cocoon-p2.ht ml#sidebar1 There you can find how to nested a esql with sendmail. It is working! Now I just suffering how to attach a pdf. ...but I don't think I will get any answers on that,or? :-( -Ursprüngliche Nachricht- Von: Scherler, Thorsten Gesendet: Montag, 2. Dezember 2002 13:58 An: Cocoon-Dev (E-Mail); Cocoon-Users (E-Mail) Betreff: Sendmail serial email Hello group, I am still trying to send a serial email with cocoon ... and I am stucked big time I got the sendmail logic sheet runnig (without the possiblity to attach a file or a URL). I have my query (with esql) running. Now I want to do the following: The query looks for the date on which information has to be send (info.xsp:) xsp:page language=java xmlns:xsp=http://apache.org/xsp; xmlns:esql=http://apache.org/cocoon/SQL/v2; xmlns:xsp-request=http://apache.org/xsp/request/2.0; dataset esql:connection esql:poolIDC2/esql:pool esql:execute-query esql:query select * from info where Info_datum = #xsp-request:get-parameter name=date/# address bname1 esql:get-string column=business_name/ /bname1 bname2 esql:get-string column=business_name_2/ /bname2 bname3 esql:get-string column=business_name_3/ /bname3 street esql:get-string column=address/ /street ZIP esql:get-string column=zip_code/ /ZIP City esql:get-string column=city/ /City country esql:get-string column=country/ /country telephone_number esql:get-string column=telephone_number/ /telephone_number /address aktion Info_datum esql:get-date column=Info_datum/ /Info_datum /aktion WD district esql:get-string column=district/ /district ADM name esql:get-string column=ADM/ /name email esql:get-string column=ADM_email/ /email /ADM /WD /client /esql:row-results /esql:results esql:no-results/ esql:error-results/ /esql:execute-query /esql:connection /dataset /xsp:page Now I want to send each ADM an eMail. I have the following sendmail.xsp. I have to replace empfaenger with the emailesql:get-string column=ADM_email//email : ?xml version=1.0 encoding=UTF-8? xsp:page language=java xmlns:xsp=http://apache.org/xsp; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xmlns:sendmail=http://apache.org/cocoon/sendmail/1.0; page xsp:expr xsp-request:get-parameter name=./ADM/email/ /xsp:expr xsp:logic String empfaenger = [EMAIL PROTECTED]\n; /xsp:logic xsp:logic String text = \n+ something\n+ \n+ more:\n+ empfaenger; /xsp:logic xsp-request:get-parameter name=date/ sendmail:send-mail sendmail:charsetISO-8859-1/sendmail:charset sendmail:from[EMAIL PROTECTED]/sendmail:from sendmail:to xsp:exprempfaenger/xsp:expr /sendmail:to sendmail:cc xsp:exprempfaenger/xsp:expr /sendmail:cc
cvs commit: xml-cocoon2/src/blocks/session-fw/java/org/apache/cocoon/webapps/session/acting SessionFormAction.java
cziegeler2002/12/03 04:31:35
Modified:src/blocks/session-fw/conf session-act.xmap
src/blocks/session-fw/java/org/apache/cocoon/webapps/session/transformation
SessionPostTransformer.java
Added: src/blocks/session-fw/java/org/apache/cocoon/webapps/session/acting
SessionFormAction.java
Log:
Adding simple validation. Submitted by Guido Casper ([EMAIL PROTECTED])
Revision ChangesPath
1.2 +2 -0 xml-cocoon2/src/blocks/session-fw/conf/session-act.xmap
Index: session-act.xmap
===
RCS file: /home/cvs/xml-cocoon2/src/blocks/session-fw/conf/session-act.xmap,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- session-act.xmap 27 Sep 2002 09:05:11 - 1.1
+++ session-act.xmap 3 Dec 2002 12:31:35 - 1.2
@@ -6,4 +6,6 @@
map:action name=session
src=org.apache.cocoon.webapps.session.acting.SessionAction/
+map:action name=session-form
+src=org.apache.cocoon.webapps.session.acting.SessionFormAction/
/xmap
1.3 +119 -10
xml-cocoon2/src/blocks/session-fw/java/org/apache/cocoon/webapps/session/transformation/SessionPostTransformer.java
Index: SessionPostTransformer.java
===
RCS file:
/home/cvs/xml-cocoon2/src/blocks/session-fw/java/org/apache/cocoon/webapps/session/transformation/SessionPostTransformer.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SessionPostTransformer.java 8 Oct 2002 14:43:19 - 1.2
+++ SessionPostTransformer.java 3 Dec 2002 12:31:35 - 1.3
@@ -51,17 +51,28 @@
package org.apache.cocoon.webapps.session.transformation;
import java.io.IOException;
+import java.io.StringBufferInputStream;
import java.util.Map;
+import org.apache.excalibur.source.Source;
import org.apache.excalibur.source.SourceParameters;
+import org.apache.excalibur.source.SourceException;
import org.apache.avalon.framework.parameters.Parameters;
+import org.apache.avalon.framework.configuration.Configuration;
+import org.apache.avalon.framework.configuration.DefaultConfigurationBuilder;
+import org.apache.avalon.framework.configuration.SAXConfigurationHandler;
+import org.apache.avalon.framework.configuration.ConfigurationException;
import org.apache.cocoon.ProcessingException;
+import org.apache.cocoon.xml.XMLUtils;
+import org.apache.cocoon.environment.Session;
import org.apache.cocoon.webapps.session.SessionConstants;
+import org.apache.cocoon.acting.ValidatorActionResult;
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.AttributesImpl;
import org.w3c.dom.DocumentFragment;
+import org.w3c.dom.Node;
/**
* This is the session post transformer. It does all the setting and
@@ -105,6 +116,7 @@
public static final String INPUTXML_PATH_ATTRIBUTE = path;
public static final String INPUTXML_NAME_ATTRIBUTE = name;
public static final String INPUTXML_TYPE_ATTRIBUTE = type; // optional
+public static final String INPUTXML_VALIDATIONRESULT_ATTRIBUTE = valresult;
/** The form element */
public static final String FORM_ELEMENT = form;
@@ -115,6 +127,11 @@
/** The form content element */
public static final String FORM_CONTENT_ELEMENT = content;
+/** The form validation rules */
+public static final String FORM_VALIDATION_ELEMENT = validate;
+public static final String FORM_VALIDATION_SOURCE_ATTRIBUTE = src;
+public static final String FORM_VALIDATESET_ELEMENT = validate-set;
+
/** State: no element parsed */
private static final int STATE_OUTSIDE = 0;
/** State: form element */
@@ -126,8 +143,8 @@
/** The current form name */
private String formName;
-/** The unique form number */
-private static int currentFormNumber = 0;
+/** The validation results */
+private Map validationResultMap;
public void setupTransforming()
throws ProcessingException, SAXException, IOException {
@@ -202,6 +219,15 @@
CDATA,
attr.getValue(INPUTXML_TYPE_ATTRIBUTE));
}
+ValidatorActionResult validationResult = null;
+if (validationResultMap != null validationResultMap.get(fieldname)
!= null) {
+validationResult =
(ValidatorActionResult)validationResultMap.get(fieldname);
+newattr.addAttribute(,
+ INPUTXML_VALIDATIONRESULT_ATTRIBUTE,
+ INPUTXML_VALIDATIONRESULT_ATTRIBUTE,
+ CDATA,
DO NOT REPLY [Bug 14991] - [PATCH] Missing monitor role in cocoon.roles
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=14991. 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=14991 [PATCH] Missing monitor role in cocoon.roles [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 12:48 --- Currently looking at this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon cocoon.roles
crafterm2002/12/03 04:57:37 Modified:src/java/org/apache/cocoon cocoon.roles Log: Added role definition for Excalibur monitor. PR: BZ#14991 Submitted by: Unico Hommes [EMAIL PROTECTED] Revision ChangesPath 1.37 +5 -0 xml-cocoon2/src/java/org/apache/cocoon/cocoon.roles Index: cocoon.roles === RCS file: /home/cvs/xml-cocoon2/src/java/org/apache/cocoon/cocoon.roles,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- cocoon.roles 13 Nov 2002 22:09:43 - 1.36 +++ cocoon.roles 3 Dec 2002 12:57:37 - 1.37 @@ -112,6 +112,11 @@ shorthand=xmlizer default-class=org.apache.excalibur.xmlizer.impl.XMLizerImpl/ + role name=org.apache.avalon.excalibur.monitor.Monitor +shorthand=monitor +default-class=org.apache.avalon.excalibur.monitor.ActiveMonitor + /role + role name=org.apache.cocoon.components.sax.XMLSerializer shorthand=xml-serializer default-class=org.apache.cocoon.components.sax.XMLByteStreamCompiler/ -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14991] - [PATCH] Missing monitor role in cocoon.roles
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=14991. 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=14991 [PATCH] Missing monitor role in cocoon.roles [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 13:04 --- Patch applied, Thanks! :) Please cross check and close. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[IMPORTANT] Code Freeze for 2.0.3 branch
Hi, as 2.0.4 will be released soon (thursday), we are now entering CODE FREEZE for the 2.0.3_branch, which means that only bug-fixing and doc updates are allowed. Carsten Carsten Ziegeler Open Source Group, SN AG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Expire Continuations
On Mon, Dec 02, 2002 at 10:38:33PM -0800, Ovidiu Predescu wrote: Hi Michael, OK, I'm back from a longer absence due to the Thanksgiving vacation. Cool, I hope you didnt think about cocoon too much during your vaction!! On Thursday, Nov 28, 2002, at 10:28 US/Pacific, Michael Melhem wrote: Hi Ovidiu!! How are you mate, I guess you are not coming to the Frankfurt Stammtisch :-P Wait a second, I want to come! ;) Dont worry, we wont start eating until you arrive ;) I was thinking about how to Expire Continuations and have come up with the following: We know from the bus discussion that placing every wk (WebContinuation) into the expirations Sorted TreeSet is a problematic solution. So how about placing only the leaf nodes in this set for each tree? The bus discussion should be placed in the references section of the documentation and in the comments in the source code ;) Hmmm... I think the next Cocoon getTogether should be held in a bus, because its seems thats where we had our most productive conversations! :-P This can be done by: for each new wk (if wk.getparent().numChildren() 2) expirations.remove(wk.getparent()); expirations.add(wk); This could be an expensive operation especially if the set of wk's is very large although.. the treeSet guarantees log(n) time cost for basic operations. What do you think ? Given that we have a sorted set of leaf nodes (from all continuation trees) we need to excute the following algorithm to rid the system of expired wk's For each leaf node in the set which is expired: delete it, and recursively delete its parent only if its parent has also expired *and* has no (other) children. We could make the ContinuationsManager an avlaon monitored Resource, so that we can periodically trigger continuations clean ups. This implies the max life of an wk after lastAcceesTime equals timeToLive + cleanUp_period. What do you think?? I think the TreeSet is definitely the way to go, as it is a sorted collection and accesses and removals from it are very fast. Yes, I agree that the Sorted TreeSet is a good idea. One observation related to your algorithm, which is an idea I had when we got off The Bus, is that we don't need to handle children continuations of a given continuation. This is because each and every continuation will appear in the sorted tree, and we can expire individual continuations separate from their children. Expiring individual continuations separate from their children would be the simplest and most efficient algorithm. However this would result in holes being punched in the countinuatioons tree(s). o o | | o o o \ becomes / \becomes / o o o o | | o o o This is not necessarily problematic in itself but we need decide whether a subtree or an individual continuation should be considered atomic. I would lean towards the notion of atomic subtrees. By that I mean, we either set the whole subtree as expired (and deleted) or the whole the subtree as not-expired (and available). Otherwise, a user traversing backwards from a a vaild continuation might be suprised that the parent continuation is no longer there, especially if you consider that these continuations are part of the same flow function. Does it make sense to only have half a flow function expired? The expiration algorithm will then simply iterate over the tree set until a continuation whose access time + expiration time is greater than the current time. All the continuations encountered before that are simply removed from the global hash set. Yes, I think we agree on this. This is independent of how we derive the expirations set. What do you think? The algorithm I suggested would treat continuation subtrees as atomic and maintain valid trees. The only question is whether this is worth the slight performance hit??? What do you think? thanks, Michael Melhem Ovidiu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14991] - [PATCH] Missing monitor role in cocoon.roles
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=14991. 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=14991 [PATCH] Missing monitor role in cocoon.roles [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/serialization XMLSerializer.java HTMLSerializer.java TextSerializer.java AbstractTextSerializer.java
cziegeler2002/12/03 05:30:34
Modified:src/java/org/apache/cocoon/serialization XMLSerializer.java
HTMLSerializer.java TextSerializer.java
AbstractTextSerializer.java
Log:
Hopefully fixing bug 11935 format properties for Text/XMLSerializer not working
Revision ChangesPath
1.9 +14 -3
xml-cocoon2/src/java/org/apache/cocoon/serialization/XMLSerializer.java
Index: XMLSerializer.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/serialization/XMLSerializer.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- XMLSerializer.java27 Nov 2002 23:58:10 - 1.8
+++ XMLSerializer.java3 Dec 2002 13:30:34 - 1.9
@@ -53,6 +53,9 @@
import javax.xml.transform.OutputKeys;
import javax.xml.transform.sax.TransformerHandler;
import javax.xml.transform.stream.StreamResult;
+
+import org.apache.avalon.framework.configuration.Configuration;
+import org.apache.avalon.framework.configuration.ConfigurationException;
import org.apache.cocoon.CascadingIOException;
import java.io.IOException;
@@ -70,13 +73,21 @@
public XMLSerializer() {
}
+/**
+ * Set the configurations for this serializer.
+ */
+public void configure(Configuration conf)
+throws ConfigurationException {
+super.configure( conf );
+this.format.put(OutputKeys.METHOD,xml);
+}
+
public void setOutputStream(OutputStream out) throws IOException {
try {
super.setOutputStream(out);
this.handler = this.getTransformerHandler();
-format.put(OutputKeys.METHOD,xml);
-handler.setResult(new StreamResult(this.output));
handler.getTransformer().setOutputProperties(format);
+handler.setResult(new StreamResult(this.output));
this.setContentHandler(handler);
this.setLexicalHandler(handler);
} catch (Exception e) {
1.11 +2 -2
xml-cocoon2/src/java/org/apache/cocoon/serialization/HTMLSerializer.java
Index: HTMLSerializer.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/serialization/HTMLSerializer.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- HTMLSerializer.java 13 Sep 2002 07:30:50 - 1.10
+++ HTMLSerializer.java 3 Dec 2002 13:30:34 - 1.11
@@ -91,8 +91,8 @@
try {
super.setOutputStream(out);
TransformerHandler handler = this.getTransformerHandler();
-handler.getTransformer().setOutputProperties(this.format);
handler.setResult(new StreamResult(this.output));
+handler.getTransformer().setOutputProperties(this.format);
this.setContentHandler(handler);
this.setLexicalHandler(handler);
} catch (Exception e) {
1.9 +14 -3
xml-cocoon2/src/java/org/apache/cocoon/serialization/TextSerializer.java
Index: TextSerializer.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/serialization/TextSerializer.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- TextSerializer.java 27 Nov 2002 23:58:10 - 1.8
+++ TextSerializer.java 3 Dec 2002 13:30:34 - 1.9
@@ -53,6 +53,9 @@
import javax.xml.transform.OutputKeys;
import javax.xml.transform.sax.TransformerHandler;
import javax.xml.transform.stream.StreamResult;
+
+import org.apache.avalon.framework.configuration.Configuration;
+import org.apache.avalon.framework.configuration.ConfigurationException;
import org.apache.cocoon.CascadingIOException;
import java.io.IOException;
@@ -71,13 +74,21 @@
public TextSerializer() {
}
+/**
+ * Set the configurations for this serializer.
+ */
+public void configure(Configuration conf)
+throws ConfigurationException {
+super.configure( conf );
+this.format.put(OutputKeys.METHOD,text);
+}
+
public void setOutputStream(OutputStream out) throws IOException {
try {
super.setOutputStream(out);
handler = this.getTransformerHandler();
-format.put(OutputKeys.METHOD,text);
-handler.setResult(new StreamResult(this.output));
handler.getTransformer().setOutputProperties(format);
+handler.setResult(new StreamResult(this.output));
this.setContentHandler(handler);
this.setLexicalHandler(handler);
} catch (Exception e) {
DO NOT REPLY [Bug 11935] - format properties for Text/XMLSerializer not working
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=11935. 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=11935 format properties for Text/XMLSerializer not working --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 13:33 --- I just checked-in some changes to the abstract text serializer (those Christoph) mentiones and now everything works fine for me. Can someone confirm this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon cocoon.roles
crafterm2002/12/03 05:32:19 Modified:src/java/org/apache/cocoon Tag: cocoon_2_0_3_branch cocoon.roles Log: Applied Monitor role definition fix from HEAD. PR: BZ#14991 Submitted by: Unico Hommes [EMAIL PROTECTED] Revision ChangesPath No revision No revision 1.18.2.5 +5 -0 xml-cocoon2/src/java/org/apache/cocoon/cocoon.roles Index: cocoon.roles === RCS file: /home/cvs/xml-cocoon2/src/java/org/apache/cocoon/cocoon.roles,v retrieving revision 1.18.2.4 retrieving revision 1.18.2.5 diff -u -r1.18.2.4 -r1.18.2.5 --- cocoon.roles 13 Aug 2002 08:30:23 - 1.18.2.4 +++ cocoon.roles 3 Dec 2002 13:32:19 - 1.18.2.5 @@ -33,6 +33,11 @@ shorthand=browser default-class=org.apache.cocoon.components.browser.BrowserImpl/ + role name=org.apache.avalon.excalibur.monitor.Monitor +shorthand=monitor +default-class=org.apache.avalon.excalibur.monitor.ActiveMonitor + /role + !-- For backwards compatibility, the shorthand for this role is sitemap role name=org.apache.cocoon.Processor shorthand=processor/ -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: Announcement: Cocoon Stammtisch @ Frankfurt
On Mon, Dec 02, 2002 at 06:52:44PM +0100, Michael Hartle wrote: Hello all, FYI, the Cocoon Stammtisch @ Frankfurt now has a reservation for a location in downtown Frankfurt on Monday, December 9th for 25-30 people Oh, thats great, downtown Frankfurt would make it easier for all involved! :) Regards, Michael Melhem - currently I have 21 people by name who are probably going to visit the Stammtisch, so there still are some spare seats left. You will find all the details at http://outerthought.net/wiki/Wiki.jsp?page=FrankfurtherStammtisch Hope to see you all at Frankfurt, Best regards, Michael Hartle, Hartle Klug Consulting GmbH - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/webapp sitemap.xmap
crafterm2002/12/03 05:37:26 Modified:src/webapp sitemap.xmap Log: Added new jpath transformer to webapp root sitemap. Revision ChangesPath 1.85 +1 -0 xml-cocoon2/src/webapp/sitemap.xmap Index: sitemap.xmap === RCS file: /home/cvs/xml-cocoon2/src/webapp/sitemap.xmap,v retrieving revision 1.84 retrieving revision 1.85 diff -u -r1.84 -r1.85 --- sitemap.xmap 16 Nov 2002 18:58:29 - 1.84 +++ sitemap.xmap 3 Dec 2002 13:37:26 - 1.85 @@ -113,6 +113,7 @@ map:transformer logger=sitemap.transformer.xinclude name=xinclude pool-grow=2 pool-max=16 pool-min=2 src=org.apache.cocoon.transformation.XIncludeTransformer/ map:transformer logger=sitemap.transformer.cinclude name=cinclude pool-grow=2 pool-max=16 pool-min=2 src=org.apache.cocoon.transformation.CIncludeTransformer/ +map:transformer logger=sitemap.transformer.jpath name=jpath src=org.apache.cocoon.transformation.JPathTransformer/ map:transformer logger=sitemap.transformer.extractor name=extractor src=org.apache.cocoon.transformation.FragmentExtractorTransformer/ -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/session-fw/java/org/apache/cocoon/webapps/session SessionConstants.java
cziegeler2002/12/03 05:43:40 Modified:src/blocks/session-fw/java/org/apache/cocoon/webapps/session SessionConstants.java Log: Renaming context Revision ChangesPath 1.2 +1 -1 xml-cocoon2/src/blocks/session-fw/java/org/apache/cocoon/webapps/session/SessionConstants.java Index: SessionConstants.java === RCS file: /home/cvs/xml-cocoon2/src/blocks/session-fw/java/org/apache/cocoon/webapps/session/SessionConstants.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- SessionConstants.java 27 Sep 2002 09:05:17 - 1.1 +++ SessionConstants.java 3 Dec 2002 13:43:40 - 1.2 @@ -68,7 +68,7 @@ String RESPONSE_CONTEXT= response; /** Reserved Context: Temp */ -String TEMPORARY_CONTEXT = temp; +String TEMPORARY_CONTEXT = temporary; /** The request parameter name for the form handling */ String SESSION_FORM_PARAMETER = sessionform; -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/session-fw/java/org/apache/cocoon/webapps/session/components SessionManager.java
cziegeler2002/12/03 05:52:14
Modified:src/blocks/portal-fw/java/org/apache/cocoon/webapps/portal/components
PortalManager.java
src/blocks/session-fw/java/org/apache/cocoon/webapps/session/components
SessionManager.java
Log:
Changing Exception type
Revision ChangesPath
1.5 +5 -5
xml-cocoon2/src/blocks/portal-fw/java/org/apache/cocoon/webapps/portal/components/PortalManager.java
Index: PortalManager.java
===
RCS file:
/home/cvs/xml-cocoon2/src/blocks/portal-fw/java/org/apache/cocoon/webapps/portal/components/PortalManager.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- PortalManager.java21 Nov 2002 18:18:48 - 1.4
+++ PortalManager.java3 Dec 2002 13:52:13 - 1.5
@@ -1145,24 +1145,24 @@
try {
// check parameter
if (type == null) {
-throw new IllegalArgumentException(buildProfile: Type is
required);
+throw new ProcessingException(buildProfile: Type is required);
}
if (type.equals(PortalManager.BUILDTYPE_VALUE_GLOBAL) == true ||
type.equals(PortalManager.BUILDTYPE_VALUE_BASIC) == true) {
// nothing to do here
} else if (type.equals(PortalManager.BUILDTYPE_VALUE_ROLE) == true) {
if (role == null) {
-throw new IllegalArgumentException(buildProfile: Role is
required);
+throw new ProcessingException(buildProfile: Role is required);
}
} else if (type.equals(PortalManager.BUILDTYPE_VALUE_ID) == true) {
if (role == null) {
-throw new IllegalArgumentException(buildProfile: Role is
required);
+throw new ProcessingException(buildProfile: Role is required);
}
if (id == null) {
-throw new IllegalArgumentException(buildProfile: ID is
required);
+throw new ProcessingException(buildProfile: ID is required);
}
} else {
-throw new IllegalArgumentException(buildProfile: Type unknown: +
type);
+throw new ProcessingException(buildProfile: Type unknown: +
type);
}
SessionContext context = this.getContext(true);
1.4 +35 -32
xml-cocoon2/src/blocks/session-fw/java/org/apache/cocoon/webapps/session/components/SessionManager.java
Index: SessionManager.java
===
RCS file:
/home/cvs/xml-cocoon2/src/blocks/session-fw/java/org/apache/cocoon/webapps/session/components/SessionManager.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SessionManager.java 21 Nov 2002 18:18:48 - 1.3
+++ SessionManager.java 3 Dec 2002 13:52:14 - 1.4
@@ -369,7 +369,8 @@
* it is set to false, the session is only terminated
* if no session context is available.
*/
-public void terminateSession(boolean force) {
+public void terminateSession(boolean force)
+throws ProcessingException {
// synchronized
if (this.getLogger().isDebugEnabled() == true) {
this.getLogger().debug(BEGIN terminateSession force=+force);
@@ -406,10 +407,10 @@
// test arguments
Session session = this.getSession(false);
if (session == null) {
-throw new IllegalArgumentException(CreateContext: Session is
required);
+throw new ProcessingException(CreateContext: Session is required);
}
if (name == null) {
-throw new IllegalArgumentException(CreateContext: Name is required);
+throw new ProcessingException(CreateContext: Name is required);
}
SessionContext context;
@@ -451,14 +452,14 @@
// test arguments
if (name == null) {
-throw new IllegalArgumentException(SessionManager.deleteContext: Name
is required);
+throw new ProcessingException(SessionManager.deleteContext: Name is
required);
}
if (SessionManager.isReservedContextName(name) == true) {
throw new ProcessingException(SessionContext with name + name + is
reserved and cannot be deleted manually.);
}
Session session = this.getSession(false);
if (session == null) {
-throw new IllegalArgumentException(SessionManager.deleteContext:
Session is required);
+throw new ProcessingException(SessionManager.deleteContext: Session is
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/serialization HTMLSerializer.java
cziegeler2002/12/03 06:44:12
Modified:src/java/org/apache/cocoon/serialization HTMLSerializer.java
Log:
This one didn't make it in the last commit...
Revision ChangesPath
1.12 +2 -2
xml-cocoon2/src/java/org/apache/cocoon/serialization/HTMLSerializer.java
Index: HTMLSerializer.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/serialization/HTMLSerializer.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- HTMLSerializer.java 3 Dec 2002 13:30:34 - 1.11
+++ HTMLSerializer.java 3 Dec 2002 14:44:12 - 1.12
@@ -91,8 +91,8 @@
try {
super.setOutputStream(out);
TransformerHandler handler = this.getTransformerHandler();
-handler.setResult(new StreamResult(this.output));
handler.getTransformer().setOutputProperties(this.format);
+handler.setResult(new StreamResult(this.output));
this.setContentHandler(handler);
this.setLexicalHandler(handler);
} catch (Exception e) {
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp XSPModuleHelper.java
haul2002/12/03 07:07:11
Modified:src/java/org/apache/cocoon/components/language/markup/xsp
Tag: cocoon_2_0_3_branch XSPModuleHelper.java
Log:
Typo
Revision ChangesPath
No revision
No revision
1.1.2.2 +2 -2
xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp/Attic/XSPModuleHelper.java
Index: XSPModuleHelper.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp/Attic/XSPModuleHelper.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- XSPModuleHelper.java 30 Nov 2002 10:20:44 - 1.1.2.1
+++ XSPModuleHelper.java 3 Dec 2002 15:07:10 - 1.1.2.2
@@ -309,7 +309,7 @@
}
Iterator iter = this.inputModules.keySet().iterator();
while (iter.hasNext()) {
-this.manager.release((InputModule)
this.inputModules.get(iter.next()));
+this.inputSelector.release((InputModule)
this.inputModules.get(iter.next()));
}
this.inputModules = null;
this.manager.release(this.inputSelector);
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
SourceWritingTransformer Bug?
I tried to get someone on the users list to verify
this, but I'm pretty confident this is in fact a
problem. I've looked into fixing it, with no success.
The short description is: source:write fails unless
you specify a source:path, even if the fragment is
valid as a top level node. In other words,
source:write create=true
xmlns:source=http://apache.org/cocoon/source/1.0;
source:sourcefoo.xml/source:source
source:path/source:path
source:fragmentfootest/foo/source:fragment
/source:write
gives a DOM hierarchy exception at
SourceWritingTransformer line 709. (more detailed info
below)
Can anyone confirm this as a problem or have I missed
something?
Geoff Howard
-
SourceWritingTransformer fails in source:write with
empty path
This xml:
source:write create=true
xmlns:source=http://apache.org/cocoon/source/1.0;
source:sourceanyExistingFile.xml/source:source
source:path/source:path
source:fragmentcontent
nodeWell formed xml with only one top-level
node/node
othernodefor example/othernode
/content/source:fragment
/source:write
produces:
?xml version=1.0 encoding=UTF-8?
sourceResult
xmlns:source=http://apache.org/cocoon/source/1.0;
executionfailed/executionmessageThere was a
problem manipulating your document:
org.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An
attempt was made to insert a node where it is not
permitted./message
behaviourwrite/behaviouractionnone/actionsourcefile:/accurate/path/to/file/anyExistingFile.xml/source
/sourceResult
Removing the source:path element has no effect, but
specifying a path causes the document to be written
successfully. According to the design, comments in
the code and the docs, the correct behaviour is to
allow replacing the root node as long as the fragment
has only one top-level node.
The logs show:
DEBUG (2002-12-02) 16:46.57:647 [sitemap]
(/admin/content/save) HttpProcesso
r[8080][3]/SourceWritingTransformer: FAIL exception:
org.w3c.dom.DOMException: H
IERARCHY_REQUEST_ERR: An attempt was made to insert a
node where it is not permi
tted.
org.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An
attempt was made to insert a
node where it is not permitted.
at
org.apache.xerces.dom.ParentNode.internalInsertBefore(ParentNode.java
:356)
at
org.apache.xerces.dom.ParentNode.insertBefore(ParentNode.java:320)
at
org.apache.xerces.dom.CoreDocumentImpl.insertBefore(CoreDocumentImpl.
java:444)
at
org.apache.xerces.dom.NodeImpl.appendChild(NodeImpl.java:267)
at
org.apache.cocoon.transformation.SourceWritingTransformer.insertFragm
ent(SourceWritingTransformer.java:709)
Note I'm using version 1.9 of this file, even though
the current cvs is 1.10. The
diff is here:
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/java/org/apache/cocoon/transformation/SourceWritingTransformer.java.diff?r1=1.9r2=1.10diff_format=h
I don't see anything there that could fix the problem,
though perhaps the new DOMUtil
if used in this section would help. I looked at
DOMUtil and was fairly certain it was
the same code as XMLUtil, moved and renamed.
The source is :
Line 641:
if ( exists == true this.state == STATE_INSERT ) {
...
Condition for source:insert with pre-existing file -
not relevant
...
From Line 699:
} else if (create == true) {
Parser parser =
(Parser)this.manager.lookup(Parser.ROLE);
try {
resource = parser.createDocument();
} finally {
this.manager.release( parser );
}
// import the fragment
Node importNode = resource.importNode(fragment,
true);
if ( path.equals() ) { // this is allowed in
write
resource.appendChild(importNode); // --- The
failing statement, line 709
message = entire source overwritten;
} else {
// get the node
Node parent =
XMLUtil.selectSingleNode(resource, path);
// add fragment
parent.appendChild(importNode);
message = content appended to: + path;
}
There are a couple weird things (mostly unrelated I
think) here
that are either wrong or I don't fully understand
what's going on.
1) the else if (create == true) in line 699
excludes the condition
that source:write is acting on an existing file -
seems like it should be
create == true || (exists == true state ==
STATE_WRITE) or something to
that effect.
2) I'm not clear why parser.createDocument() is used
instead of
XMLUtil.createDocument(), (now
DOMUtil.createDocument() ) though replacing it
didn't seem to help. (it may have caused a different
problem with less feedback).
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Flow wishlist :)
(Someone has also remarked
that this sounded somewhat like a capability that was in C1.)
yeah, you could implement what you want using dynamically added PI
(processing instructions) for the C1 reactor, but it would
end up being
very messy anyway.
When it was described to me it didn't really sound like what I
wanted...
I think Stefano is on the right track with this dynamic PI pattern ... but
since I never
used C1 I've only got a theoretical notion of the C1 reactor. But I've
used a similar
pattern in C2, I think. You can use a pipeline (or a small number of
pipelines)
containing an XSLT transformer followed by an include transformer. The
XSLT transform can
make your decision, and insert elements like this: xi:include
href=cocoon://{$result-
of-some-complex-functional-logic}/
Then the include transformer resolves the url and recursively calls the
sitemap. The URL
could resolve to a database query result, or an error 500 page. This gives
you quite a
functional style where you need it. One issue I'm aware of here is the
cacheability
of the include transformer, but this may not be an issue which your search
results
anyway.
This does indeed match up functionally with part of what I want. It seems
that the caching will eventually get sorted out but even when it is I wonder
about the performance of such an approach? This may in fact work to
experiment with the approach I want to use, if it does I'll let everyone
know (though it will be a while). If we end up liking this we'll likely end
up submitting some patches for the caching if the problems aren't fixed in
the mean time
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Flow wishlist :)
If you ask me, you should never use the sitemap to describe any processing other than page generation. That is one of our goals and my main rational for looking what ways we can do that. I think I've stated this several times in this thread, but given how long it's been going on (and the amount of snipping I've been doing to try and keep the message size reasonable) I wouldn't be surprised if that's been lost. For everything else, just use the flow layer to describe the interactions between pages, and business logic you express in Java or a functional language (like Scheme) implemented in Java if you really want to. Trying to put the rules that describe your application in the sitemap is more cumbersome than the approach I suggested above. I implemented an earlier version of the control flow layer in Scheme, to take advantage of the continuations concept this language supports. The current control flow layer is designed to support other languages as well, so if you're interested, you can add support for Scheme. But again, you should keep in mind the control flow layer is designed to write your application logic elsewhere than in the sitemap. The language I want for the flow layer happens to be XSLT...??? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [IMPORTANT] Code Freeze for 2.0.3 branch
There are quite few NEW bugs agains 2.0.3, only couple ASSIGNED and there also still some NEW Patches. Are there any show stoppers that need to be fixed by Thursday, if so which ones? Artur... -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] Sent: December 3, 2002 8:11 AM To: Cocoon-Dev Subject: [IMPORTANT] Code Freeze for 2.0.3 branch Hi, as 2.0.4 will be released soon (thursday), we are now entering CODE FREEZE for the 2.0.3_branch, which means that only bug-fixing and doc updates are allowed. Carsten Carsten Ziegeler Open Source Group, SN AG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [IMPORTANT] Code Freeze for 2.0.3 branch
Artur Bialecki wrote: There are quite few NEW bugs agains 2.0.3, only couple ASSIGNED and there also still some NEW Patches. Are there any show stoppers that need to be fixed by Thursday, if so which ones? Do you have list handy with the NEW bugs/patches? Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 11935] - format properties for Text/XMLSerializernot working
--- Additional Comments From [EMAIL PROTECTED] 2002-12-03 13:33 --- I just checked-in some changes to the abstract text serializer (those Christoph) mentiones and now everything works fine for me. Can someone confirm this? Now it looks like ALL pages are serialized as XML with UTF-8 encoding, even though the default serializer is html :(. This is from a freshly updated 2.1-dev CVS, unless I'm making some major mistake here. Ugo -- Ugo Cei - Consorzio di Bioingegneria e Informatica Medica P.le Volontari del Sangue, 2 - 27100 Pavia - Italy Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 11935] - format properties for Text/XMLSerializer not working
Hi Ugo, I checked-in a fix for this 30minutes ago (more or less). Carsten -Original Message- From: Ugo Cei [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 03, 2002 4:27 PM To: [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 11935] - format properties for Text/XMLSerializer not working --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 13:33 --- I just checked-in some changes to the abstract text serializer (those Christoph) mentiones and now everything works fine for me. Can someone confirm this? Now it looks like ALL pages are serialized as XML with UTF-8 encoding, even though the default serializer is html :(. This is from a freshly updated 2.1-dev CVS, unless I'm making some major mistake here. Ugo -- Ugo Cei - Consorzio di Bioingegneria e Informatica Medica P.le Volontari del Sangue, 2 - 27100 Pavia - Italy Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [IMPORTANT] Code Freeze for 2.0.3 branch
Here is a list of bugs agains version 2.0.3 of Cocoon from Bugzilla Bug List Tue Dec 3 07:14:15 PST 200228 bugs found. ID Sev Pri Plt Owner State Result Summary 7952 Nor Oth All [EMAIL PROTECTED] NEW No 'Last-Modified' header in the HTTP response 8734 Maj Oth PC [EMAIL PROTECTED] NEW ESQL Error in Cocoon 2.0.3-branch 10203 Nor Oth Oth [EMAIL PROTECTED] NEW Docs referenced by XSLT's document() are not included in cac 10242 Nor Oth Oth [EMAIL PROTECTED] NEW [DOC] Text serializer is not documented 10277 Nor Oth Oth [EMAIL PROTECTED] ASSI Cannot set MIME type for ResourceReader 11001 Nor Oth Oth [EMAIL PROTECTED] NEW ResorceReader and internal redirection fails sometimes 11611 Nor Oth PC [EMAIL PROTECTED] NEW Escaping error with alpha site editor 11669 Nor Oth PC [EMAIL PROTECTED] NEW Documentation for creating new actions is incomplete. 11702 Nor Oth PC [EMAIL PROTECTED] NEW SiLLy logicsheet tags don't seem to work well 11716 Nor Oth Sun [EMAIL PROTECTED] NEW util:include-expr is formatting sensitive 11861 Enh Oth All [EMAIL PROTECTED] NEW Patch to extend castortransformer to handle collections 12173 Nor Oth All [EMAIL PROTECTED] NEW SQLTransformer Query object prematurely closes connection ca 12291 Cri Oth All [EMAIL PROTECTED] NEW JispStore does not implement keys() 12327 Nor Oth All [EMAIL PROTECTED] NEW XIncludeTransformer doesn't include required namespaces decl 12932 Min Oth All [EMAIL PROTECTED] NEW util:parameter should be util:param 12949 Nor Oth All [EMAIL PROTECTED] NEW Cocoon silently fails for long XSPs (java.lang.ClassFormatEr 13186 Maj Oth PC [EMAIL PROTECTED] NEW after java exception in XSP, Cocoon continues with pipeline 13344 Nor Oth PC [EMAIL PROTECTED] NEW SQLTransformer: syntax error when submitting Oracle Stored P 13479 Maj Oth All [EMAIL PROTECTED] NEW Cocoon fails to compile sitemap and XSP in JBoss 3.0.3 with 13668 Nor Oth PC [EMAIL PROTECTED] NEW Problem adding listener to Cocoon's web.xml 13855 Maj Oth All [EMAIL PROTECTED] ASSI EncodeURLTransformer fails to rewrite URLs on initial reques 13904 Nor Oth PC [EMAIL PROTECTED] NEW FilterTransformer: ArrayIndexOutOfBounds exception when coun 14048 Enh Oth Oth [EMAIL PROTECTED] NEW [PATCH] No-cache enhancement for ResourceReader component 14074 Nor Oth Sun [EMAIL PROTECTED] NEW Previously reported tar bug - isn't (well, it is but..) 14247 Blo Oth PC [EMAIL PROTECTED] NEW login in demo-site Portal Authentication failed 14564 Nor Oth All [EMAIL PROTECTED] NEW JspEngineImpl causes NullPointerException 14835 Nor Oth All [EMAIL PROTECTED] NEW [PATCH] Added container/form-encoding init-params to web.x 14905 Maj Oth All [EMAIL PROTECTED] NEW [PATCH] HttpRequest.getParameterValues() broken when form_en 28 bugs found. -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] Sent: December 3, 2002 10:25 AM To: [EMAIL PROTECTED] Subject: RE: [IMPORTANT] Code Freeze for 2.0.3 branch Artur Bialecki wrote: There are quite few NEW bugs agains 2.0.3, only couple ASSIGNED and there also still some NEW Patches. Are there any show stoppers that need to be fixed by Thursday, if so which ones? Do you have list handy with the NEW bugs/patches? Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/tools/jetty/conf jettyconf.xml
nicolaken2002/12/03 07:44:44
Modified:.build.xml
tools/jetty/conf jettyconf.xml
Log:
Added a jetty.home env variable to pass webapp location from the buildfile, and
set it as an absolute path with a trailing slash as suggested by
leo leonid [EMAIL PROTECTED] .
Still doesn't fix the redirect bug :-(
Revision ChangesPath
1.289 +7 -3 xml-cocoon2/build.xml
Index: build.xml
===
RCS file: /home/cvs/xml-cocoon2/build.xml,v
retrieving revision 1.288
retrieving revision 1.289
diff -u -r1.288 -r1.289
--- build.xml 3 Dec 2002 00:05:43 - 1.288
+++ build.xml 3 Dec 2002 15:44:44 - 1.289
@@ -208,6 +208,8 @@
!-- Properties --
!-- === --
+dirname property=antfile.dir file=${ant.file}/
+
!-- Get the properties from the properties.xml file --
xmlproperty file=properties.xml
keeproot=false
@@ -2363,6 +2365,7 @@
!-- * --
!-- * --
+
target name=run
description=Run Jetty with configuration set by the jetty.run property
depends=webapp-local
@@ -2373,7 +2376,7 @@
copy file=${tools.dir}/jetty/conf/jettyconf.xml
todir=${build.war} filtering=on/
-
+
java classname=org.mortbay.jetty.Server
dir=${build.war}
fork=yes
@@ -2387,8 +2390,9 @@
include name=*.ZIP/
/fileset
/classpath
- jvmarg
-
value=-Djava.endorsed.dirs=${java.endorsed.dirs}${path.separator}${endorsed.dir}/
+
+ jvmarg
value=-Djava.endorsed.dirs=${java.endorsed.dirs}${path.separator}${endorsed.dir}/
+ sysproperty key=jetty.home value=${antfile.dir}/build/cocoon/webapp//
arg line=jettyconf.xml /
/java
/target
1.2 +1 -1 xml-cocoon2/tools/jetty/conf/jettyconf.xml
Index: jettyconf.xml
===
RCS file: /home/cvs/xml-cocoon2/tools/jetty/conf/jettyconf.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- jettyconf.xml 3 Dec 2002 00:11:24 - 1.1
+++ jettyconf.xml 3 Dec 2002 15:44:44 - 1.2
@@ -49,7 +49,7 @@
Call name=addWebApplication
Arg//Arg
-Arg./Arg
+ArgSystemProperty name=jetty.home default=.//Arg
/Call
/Configure
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Board Resolution for the creation of Cocoon PMC
On Tue, 26 Nov 2002, Stefano Mazzocchi wrote: Here is the proposal so far. snip/ Two things to define: 1) the text for the cocoon PMC intentions Can't we start using existing charters (i.e. http://xml.apache.org/mission.html or ttp://jakarta.apache.org/site/guidelines.html) as a base for discussion? 2) the person for the chair. I volunteer for the chair. Big +1 Giacomo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication AuthenticationConstants.java
cziegeler2002/12/03 08:04:44
Modified:src/java/org/apache/cocoon/environment/wrapper
EnvironmentWrapper.java
src/blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication/acting
AuthAction.java LogoutAction.java
src/blocks/portal-fw/java/org/apache/cocoon/webapps/portal/components
PortalManager.java
src/blocks/portal-fw/java/org/apache/cocoon/webapps/portal/context
SessionContextImpl.java
SessionContextProviderImpl.java
src/blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication/context
SessionContextProviderImpl.java
src/blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication/components
AuthenticationManager.java
src/blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication
AuthenticationConstants.java
Log:
Removing internal hacks for authentication
Revision ChangesPath
1.23 +1 -3
xml-cocoon2/src/java/org/apache/cocoon/environment/wrapper/EnvironmentWrapper.java
Index: EnvironmentWrapper.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/environment/wrapper/EnvironmentWrapper.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- EnvironmentWrapper.java 2 Dec 2002 08:39:17 - 1.22
+++ EnvironmentWrapper.java 3 Dec 2002 16:04:44 - 1.23
@@ -173,8 +173,6 @@
this,
rawMode);
this.objectModel.put(ObjectModelHelper.REQUEST_OBJECT, this.request);
-
-this.objectModel.put(Internal-Request, true);
}
/**
1.2 +4 -20
xml-cocoon2/src/blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication/acting/AuthAction.java
Index: AuthAction.java
===
RCS file:
/home/cvs/xml-cocoon2/src/blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication/acting/AuthAction.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AuthAction.java 27 Sep 2002 09:05:06 - 1.1
+++ AuthAction.java 3 Dec 2002 16:04:44 - 1.2
@@ -95,36 +95,20 @@
AuthenticationManager authManager = null;
Map map = null;
-boolean initialized;
-
try {
final Request request = ObjectModelHelper.getRequest( objectModel );
-// Are we called as an internal resource?
-if ( objectModel.get(Internal-Request) != null ) {
-handlerName =
(String)request.getAttribute(AuthenticationConstants.REQUEST_ATTRIBUTE_HANDLER_NAME);
-applicationName =
(String)request.getAttribute(AuthenticationConstants.REQUEST_ATTRIBUTE_APPLICATION_NAME);
-initialized = true;
-} else {
-handlerName = par.getParameter(handler, null);
-applicationName = par.getParameter(application, null);
-if (handlerName != null)
request.setAttribute(AuthenticationConstants.REQUEST_ATTRIBUTE_HANDLER_NAME,
handlerName);
-if (applicationName != null)
request.setAttribute(AuthenticationConstants.REQUEST_ATTRIBUTE_APPLICATION_NAME,
applicationName);
-initialized = false;
-}
+handlerName = par.getParameter(handler, null);
+applicationName = par.getParameter(application, null);
authManager = (AuthenticationManager) this.manager.lookup(
AuthenticationManager.ROLE );
// do authentication
-if (authManager.checkAuthentication(redirector, !initialized) == false)
{
+if ( !authManager.checkAuthentication(redirector, handlerName,
applicationName) ) {
// All events are ignored
// the sitemap.xsl ensures that only the redirect is processed
} else {
-if (initialized == false) {
-map = authManager.createMap();
-} else {
-map = EMPTY_MAP;
-}
+map = authManager.createMap();
}
} finally {
this.manager.release( authManager );
1.2 +9 -12
xml-cocoon2/src/blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication/acting/LogoutAction.java
Index: LogoutAction.java
===
RCS file:
Re: [proposal] Board Resolution for the creation of Cocoon PMC(Matthew as a PMC member?)
On Wed, 27 Nov 2002, Bertrand Delacretaz wrote: On Wednesday 27 November 2002 15:18, Steven Noels wrote: . . . I'm all +millions to propose and vote non-code contributing members of this community as 'committers honoris causa'. . . . Thanks for being with me! (despite the fact that Matthew was joking ;-). I think this needs to be discussed at some point, maybe not right now in the middle of the PMC move, but still. I'm not sure the ASF board needs a fixed list of PMC members that take the responsability. I'm also in favor of having *all* active committer in the PMC. We can simply use a list in CVS xdoc where each committer can be part of the PMC by mention her/his name into that list (or remove it if she/he likes to get off) to make it a bit more formal if needed. Giacomo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 11935] - format properties for Text/XMLSerializernot working
Carsten Ziegeler wrote: I checked-in a fix for this 30minutes ago (more or less). Carsten BIG THUMBS UP! ;-) Ugo -- Ugo Cei - Consorzio di Bioingegneria e Informatica Medica P.le Volontari del Sangue, 2 - 27100 Pavia - Italy Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[BUG] XSP dependency tracking broken with cocoon:/ protocol
Bug in both Cocoon-2.0.4dev and Cocoon-2.1:
Dependency tracking does not happen with XSP's when the source
is cocoon:/ instead of file://. In the following sitemap fragment,
changes to thefile.xsp and/or to thefile.xsl do NOT cause the java
source or class files to be updated.
map:match pattern=testfile.xsp
map:generate src=thefile.xsp/
map:transform src=thefile.xsl/
map:serialize/
/map:match
map:match pattern=somefile.xml
map:generate src=cocoon:/testfile.xsp type=serverpages/
map:serialize/
/map:match
For Cocoon-2.1, I tracked the problem down to this file:
xml-cocoon2\src\java\org\apache\cocoon\components\source\impl\SitemapSource.java
In this fragment, you can see the last modification date is not being tracked:
/**
* Get the last modification date.
* @return The last modification in milliseconds since January 1, 1970 GMT
* or 0 if it is unknown
*/
public long getLastModified() {
return 0;
}
Can anyone help me fix this in either or both Cocoon versions?
Thanks,
Tim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [proposal] board resolution version 1.1
On Wed, 27 Nov 2002, Stefano Mazzocchi wrote: Things to be decided: 1) the PMC chair. so far I'm the only person who volunteered. I'd be happy to accept that job. (hey, that would turn me into a vice-president of the foundation, wow :-) Congratulations ;) - o - 2) the list of PMC members. My intention is to have a large PMC. Every active cocoon committer will have the chance to be in that PMC without requiring an election. +1 At the same time, I'd ask you people to consider partecipation at the PMC as a serious thing and step out *NOW* if you don't feel like you should be there. A PMC is the Project Management Commitee. As for ASF bylaws, the PMC is legally responsible of the oversight of the project and reports directly to the ASF board via its chair. The PMC is responsible for *all* the codebases that it will host. Note that if the Cocoon PMC will host more codebases, *all* committers from all hosted codebases will be treated equal, this (and other ASF-wide communities) will hopefully avoid the jakarta-effect of internal fragmentation. This is the list of the current active committers Nicola Ken Barozzi ([EMAIL PROTECTED]) Marcus Crafter ([EMAIL PROTECTED]) David Crossley ([EMAIL PROTECTED]) Torsten Curdt ([EMAIL PROTECTED]) Bertrand Delacr#233;taz ([EMAIL PROTECTED]) Vadim Gritsenko ([EMAIL PROTECTED]) Christian Haul ([EMAIL PROTECTED]) Ivelin Ivanov ([EMAIL PROTECTED]) Stefano Mazzocchi ([EMAIL PROTECTED]) Stephan Michels ([EMAIL PROTECTED]) John Morrison ([EMAIL PROTECTED]) Steven Noels ([EMAIL PROTECTED]) Andrew Oliver ([EMAIL PROTECTED]) Giacomo Pati ([EMAIL PROTECTED]) Konstantin Piroumian ([EMAIL PROTECTED]) Ovidiu Predescu ([EMAIL PROTECTED]) Jeremy Quinn ([EMAIL PROTECTED]) Gianugo Rabellino ([EMAIL PROTECTED]) Peter Royal ([EMAIL PROTECTED]) Diana Shannon ([EMAIL PROTECTED]) Davanum Srinivas ([EMAIL PROTECTED]) Sylvain Wallez ([EMAIL PROTECTED]) Carsten Ziegeler ([EMAIL PROTECTED]) If you think you should be there but you are not listed, please speak up now. If you don't want to sit in the PMC, please speak up now. [matthew has been proposed and will be added to the list if accepted] +1 - o - 3) the scope of the Cocoon PMC well, this is not easy, I'll try to come up with something soon and a vision to share. Try using examples like the http guildline or the xml charter I've mentioned in an earlier mail. Giacomo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [proposal] board resolution version 1.1
On 28 Nov 2002, David Crossley wrote: Stefano Mazzocchi wrote: Things to be decided: 1) the PMC chair. so far I'm the only person who volunteered. I'd be happy to accept that job. (hey, that would turn me into a vice-president of the foundation, wow :-) +1 from me for Stefano to be chair, because he is deserving and it is appropriate. - o - 2) the list of PMC members. My intention is to have a large PMC. Every active cocoon committer will have the chance to be in that PMC without requiring an election. The last time i heard, the intention was to start the Cocoon PMC with *all* Cocoon committers. Why the sudden change to active committers only? If we follow that route, then Stefano, you would not be on the PMC, because by the definition of CVS xml-cocoon/xdocs/who.xml and the history at http://marc.theaimsgroup.com/?l=xml-cocoon-cvsr=4s=stefanoq=b you actually belong in the Inactive Committers section and are close to being Emeritus. You are not the only one in that situation. How would you define 'active committer'? By CVS commit rates? By RTs? By mail posts/replies? ATM I don't fall in none of these categories but still like to be in the PMC. So, we need to define very carefully what constitutes a PMC member and how/when PMC members are considered to be retired. We must get this whole PMC setup correct from the beginning. I have the impression you'd like to exclude volunteers if they don't have a measurable weight (which ever this might be)? Why so, or did I misunderstud your concerns by 'We must get this whole PMC setup correct from the beginning'? At the same time, I'd ask you people to consider partecipation at the PMC as a serious thing and step out *NOW* if you don't feel like you should be there. A PMC is the Project Management Commitee. As for ASF bylaws, the PMC is legally responsible of the oversight of the project and reports directly to the ASF board via its chair. The PMC is responsible for *all* the codebases that it will host. Note that if the Cocoon PMC will host more codebases, *all* committers from all hosted codebases will be treated equal, this (and other ASF-wide communities) will hopefully avoid the jakarta-effect of internal fragmentation. This is the list of the current active committers Nicola Ken Barozzi ([EMAIL PROTECTED]) Marcus Crafter ([EMAIL PROTECTED]) David Crossley ([EMAIL PROTECTED]) Torsten Curdt ([EMAIL PROTECTED]) Bertrand Delacr#233;taz ([EMAIL PROTECTED]) Vadim Gritsenko ([EMAIL PROTECTED]) Christian Haul ([EMAIL PROTECTED]) Ivelin Ivanov ([EMAIL PROTECTED]) Stefano Mazzocchi ([EMAIL PROTECTED]) Stephan Michels ([EMAIL PROTECTED]) John Morrison ([EMAIL PROTECTED]) Steven Noels ([EMAIL PROTECTED]) Andrew Oliver ([EMAIL PROTECTED]) Giacomo Pati ([EMAIL PROTECTED]) Konstantin Piroumian ([EMAIL PROTECTED]) Ovidiu Predescu ([EMAIL PROTECTED]) Jeremy Quinn ([EMAIL PROTECTED]) Gianugo Rabellino ([EMAIL PROTECTED]) Peter Royal ([EMAIL PROTECTED]) Diana Shannon ([EMAIL PROTECTED]) Davanum Srinivas ([EMAIL PROTECTED]) Sylvain Wallez ([EMAIL PROTECTED]) Carsten Ziegeler ([EMAIL PROTECTED]) If you think you should be there but you are not listed, please speak up now. If you don't want to sit in the PMC, please speak up now. [matthew has been proposed and will be added to the list if accepted] - o - 3) the scope of the Cocoon PMC well, this is not easy, I'll try to come up with something soon and a vision to share. Just get started and we will all help to develop the vision. We should start with building a simple list of dot-points. Shall we do it on the Cocoon Wiki or on cocoon-dev ? I'd prefer cocoon-dev. Giacomo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [proposal] board resolution version 1.1
On Sat, 30 Nov 2002, Steven Noels wrote: David Crossley wrote: Earlier in this thread i alerted the list to what i see as a major flaw. I think that the answer is simple: The initial PMC is formed from all committers - the whole list at xml-cocoon2/who.xml no matter what their status. They can take themselves off the PMC if they wish. No distinction is the best way. To be really correct, I assume we need use the avail list: bash-2.04$ cat /home/cvs/CVSROOT/avail | grep xml-cocoon2 avail| twl,stefano,balld,ricardo,rubys,ben,zvia,giacomo,gears,bmclaugh, bloritsch,rossb,jeremy,greenrd,dims,ssahuc,prussell,cziegeler,donaldp, mman,sylvain,vgritsenko,haul,morrijr,crossley,ovidiu,tcurdt,gianugo, froehlich,huber,dirkx,butlermh,nicolaken,ivelin,kpiroumian,shannon, proyal,stephan,coliver,crafterm,acoliver,stevenn,bdelacretaz |xml-cocoon,xml-cocoon2,xml-cocoon2-apps,xml-site,xml-commons ... and invite all people explicitely. People who have lost interest in Cocoon won't answer the invitation then. IMHO this is a more suitable list than the who.xml file. Giacomo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [proposal] board resolution version 1.1
On Sun, 1 Dec 2002, Stefano Mazzocchi wrote: ... and invite all people explicitely. People who have lost interest in Cocoon won't answer the invitation then. I like this. I also agree with David that 'active committer' is not exactly easy to define (also, that's right, from that standard I'm not that 'active' code-wise) So, what about doing this: 1) I write email to everyone listed there (and will copy this mail list) 2) they have 72 hours to reply to that email indicating their interest in partecipating (replying privately to me or publicly as they wish) 3) at the end, I'll post here the list of people that replied and we'll include them in the proposal. [if they take longer to reply, we'll add them anyway, we don't need to be that strict] NOTE: the message will contain a description of what does it mean to be part of a PMC. What do you think? +1 Giacomo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/documentation/xdocs/userdocs/generators search-generator.xml
vgritsenko2002/12/03 08:39:25 Modified:src/documentation/xdocs/userdocs/generators Tag: cocoon_2_0_3_branch search-generator.xml Log: minor update to the DTD Revision ChangesPath No revision No revision 1.1.2.2 +1 -1 xml-cocoon2/src/documentation/xdocs/userdocs/generators/search-generator.xml Index: search-generator.xml === RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/userdocs/generators/search-generator.xml,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- search-generator.xml 6 Sep 2002 03:35:33 - 1.1.2.1 +++ search-generator.xml 3 Dec 2002 16:39:25 - 1.1.2.2 @@ -206,7 +206,7 @@ count-of-pages CDATA #IMPLIED -!ELEMENT hit (#PCDATA) +!ELEMENT hit (field)* !ATTLIST hit rank CDATA #REQUIRED score CDATA #IMPLIED -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/documentation/xdocs/userdocs/concepts modules.xml
haul2002/12/03 08:44:09
Modified:src/webapp/WEB-INF cocoon.xconf
src/java/org/apache/cocoon/components/modules/input
AbstractJXPathModule.java
src/java/org/apache/cocoon/components/language/markup/xsp/java
xsp.xsl
src/documentation/xdocs/userdocs/concepts modules.xml
Added: src/java/org/apache/cocoon/components/modules/input
SimpleMappingMetaModule.java XMLFileModule.java
src/java/org/apache/cocoon/components/language/markup/xsp
XSPModuleHelper.java
src/java/org/apache/cocoon/components/language/markup/xsp/java
input.xsl
Log:
action dev=CH type=fix
New Logicsheet for use with InputModules.
/action
action dev=CH type=add
xsp.xsl now includes all xsp:init-page tags. Additional xsp:exit-page tag for
cleanup operations.
/action
action dev=CH type=add
New InputModule to map parameter names to / from another name. Uses translation
table and additional prefix / suffix. New InputModule to access contents of
an XMLFile using JXPath, based on patch from Jeff Turner ([EMAIL PROTECTED]).
/action
Revision ChangesPath
1.44 +7 -0 xml-cocoon2/src/webapp/WEB-INF/cocoon.xconf
Index: cocoon.xconf
===
RCS file: /home/cvs/xml-cocoon2/src/webapp/WEB-INF/cocoon.xconf,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- cocoon.xconf 13 Nov 2002 22:09:43 - 1.43
+++ cocoon.xconf 3 Dec 2002 16:44:08 - 1.44
@@ -355,6 +355,13 @@
parameter name=href
value=resource://org/apache/cocoon/components/language/markup/xsp/java/jpath.xsl/
/builtin-logicsheet
+!-- The input logicsheet allows easy access to InputModules --
+builtin-logicsheet
+ parameter name=prefix value=input/
+ parameter name=uri value=http://apache.org/cocoon/xsp/input/1.0/
+ parameter name=href
value=resource://org/apache/cocoon/components/language/markup/xsp/java/input.xsl/
+/builtin-logicsheet
+
/target-language
!-- XSP in Javascript --
1.4 +4 -4
xml-cocoon2/src/java/org/apache/cocoon/components/modules/input/AbstractJXPathModule.java
Index: AbstractJXPathModule.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/modules/input/AbstractJXPathModule.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AbstractJXPathModule.java 17 Nov 2002 18:00:03 - 1.3
+++ AbstractJXPathModule.java 3 Dec 2002 16:44:08 - 1.4
@@ -220,8 +220,8 @@
Map objectModel)
throws ConfigurationException {
+Object contextObj = getContextObject(modeConf, objectModel);
try {
-Object contextObj = getContextObject(modeConf, objectModel);
JXPathContext jxContext = JXPathContext.newContext(contextObj);
setupExtensions(jxContext, modeConf);
return jxContext.getValue(name);
@@ -259,8 +259,8 @@
public Object[] getAttributeValues(String name, Configuration modeConf, Map
objectModel)
throws ConfigurationException {
+Object contextObj = getContextObject(modeConf, objectModel);
try {
-Object contextObj = getContextObject(modeConf, objectModel);
JXPathContext jxContext = JXPathContext.newContext(contextObj);
List values = new LinkedList();
setupExtensions(jxContext, modeConf);
@@ -284,5 +284,5 @@
* Examples are: request, session and application context objects.
*/
protected abstract Object getContextObject(Configuration modeConf,
- Map objectModel);
+ Map objectModel) throws
ConfigurationException;
}
1.2 +306 -0
xml-cocoon2/src/java/org/apache/cocoon/components/modules/input/SimpleMappingMetaModule.java
1.1
xml-cocoon2/src/java/org/apache/cocoon/components/modules/input/XMLFileModule.java
Index: XMLFileModule.java
===
/*
The Apache Software License, Version 1.1
Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or without modifica-
tion, are
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/transformation SimpleFormTransformer.java
haul2002/12/03 08:44:34
Modified:src/java/org/apache/cocoon/transformation
SimpleFormTransformer.java
Log:
action dev=CH type=fix fixes-bug=14739
Fixed SimpleFormTransformer: Malformed XML with textarea elements.
/action
Revision ChangesPath
1.3 +15 -8
xml-cocoon2/src/java/org/apache/cocoon/transformation/SimpleFormTransformer.java
Index: SimpleFormTransformer.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/transformation/SimpleFormTransformer.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SimpleFormTransformer.java17 Nov 2002 18:00:02 - 1.2
+++ SimpleFormTransformer.java3 Dec 2002 16:44:34 - 1.3
@@ -121,7 +121,7 @@
* table
* trtdfixed/tdtd(boolean) Do not change values/td/tr
* trtdprefix/tdtd(String) Added to the input element's name/td/tr
- * trtdpostfix/tdtd(String) Added to the input element's name/td/tr
+ * trtdsuffix/tdtd(String) Added to the input element's name/td/tr
* trtdinput/tdtd(String) InputModule name/td/tr
* /table
* /p
@@ -215,6 +215,9 @@
/** nesting level of ignored elements */
protected int ignoreCount;
+/** ignored element needs closing tag */
+protected boolean ignoreThis = false;
+
/** stack of ignored element names */
protected Stack stack = new Stack();
@@ -237,7 +240,7 @@
private boolean fixed = false;
private String prefix = null;
-private String postfix = null;
+private String suffix = null;
private String defaultInput = request-param;
private Configuration defaultInputConf = null;
@@ -303,7 +306,7 @@
this.parameters = par;
this.fixed = par.getParameterAsBoolean(fixed,false);
this.prefix = par.getParameter(prefix,null);
-this.postfix = par.getParameter(postfix,null);
+this.suffix = par.getParameter(suffix,null);
this.inputName = par.getParameter(input,null);
this.inputConf = null;
this.validationResults = XSPFormValidatorHelper.getResults(objectModel);
@@ -456,7 +459,7 @@
getLogger().debug(replacing);
if (this.prefix != null) aName = this.prefix + aName;
-if (this.postfix != null) aName = aName + this.postfix;
+if (this.suffix != null) aName = aName + this.suffix;
this.values = this.getValues(aName);
AttributesImpl attributes = null;
@@ -496,7 +499,7 @@
getLogger().debug(startSelectElement +name+ attributes
+this.printAttributes(attr));
if (aName != null !(this.fixed || (fixed != null
parseBoolean(fixed {
if (this.prefix != null) aName = this.prefix + aName;
-if (this.postfix != null) aName = aName + this.postfix;
+if (this.suffix != null) aName = aName + this.suffix;
this.values = this.getValues(aName);
}
super.startElement(uri, name, raw, attr);
@@ -561,7 +564,7 @@
getLogger().debug(startTextareaElement +name+ attributes
+this.printAttributes(attributes));
if (aName != null) {
if (this.prefix != null) aName = this.prefix + aName;
-if (this.postfix != null) aName = aName + this.postfix;
+if (this.suffix != null) aName = aName + this.suffix;
value = this.getValues(aName);
}
if (value == null || this.fixed || (fixed != null parseBoolean(fixed))) {
@@ -599,7 +602,7 @@
super.startElement(uri, name, raw, attr);
} else {
if (this.prefix != null) aName = this.prefix + aName;
-if (this.postfix != null) aName = aName + this.postfix;
+if (this.suffix != null) aName = aName + this.suffix;
ValidatorActionResult validation =
XSPFormValidatorHelper.getParamResult(this.objectModel, aName);
String when = attr.getValue(when);
String when_ge = attr.getValue(when-ge);
@@ -622,6 +625,7 @@
} else {
this.ignoreCount++;
this.stack.push(name);
+this.ignoreThis = true;
};
}
}
@@ -695,6 +699,9 @@
this.stack.pop();
this.ignoreCount--;
}
+}
+if (this.ignoreCount 0 || (this.ignoreCount == 0 this.ignoreThis))
{
+this.ignoreThis = false;
} else {
switch
(((Integer)elementNames.get(name,defaultElement)).intValue()) {
case ELEMENT_INPUT:
cvs commit: xml-cocoon2 changes.xml
haul2002/12/03 08:44:50 Modified:.changes.xml Log: Revision ChangesPath 1.297 +16 -1 xml-cocoon2/changes.xml Index: changes.xml === RCS file: /home/cvs/xml-cocoon2/changes.xml,v retrieving revision 1.296 retrieving revision 1.297 diff -u -r1.296 -r1.297 --- changes.xml 3 Dec 2002 00:11:23 - 1.296 +++ changes.xml 3 Dec 2002 16:44:50 - 1.297 @@ -40,6 +40,21 @@ /devs release version=@version@ date=@date@ + action dev=CH type=fix + New Logicsheet for use with InputModules. + /action + action dev=CH type=add + xsp.xsl now includes all xsp:init-page tags. Additional xsp:exit-page tag for + cleanup operations. + /action + action dev=CH type=add + New InputModule to map parameter names to / from another name. Uses translation + table and additional prefix / suffix. New InputModule to access contents of + an XMLFile using JXPath, based on patch from Jeff Turner ([EMAIL PROTECTED]). + /action + action dev=CH type=fix fixes-bug=14739 + Fixed SimpleFormTransformer: Malformed XML with textarea elements. + /action action dev=NKB type=update Moved endorsed libs in ./lib/endorsed, so that they can be added in the build file easily as java jvm args, or in the future copied to the webserver or Java endorsed dir. -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/tools/src blocks-build.xsl
nicolaken2002/12/03 08:54:00
Modified:tools/src blocks-build.xsl
Log:
action dev=NKB type=update
Updated block build system to compile and use mock objects in
the mocks subdir of the blocks if present.
/action
Revision ChangesPath
1.12 +79 -2 xml-cocoon2/tools/src/blocks-build.xsl
Index: blocks-build.xsl
===
RCS file: /home/cvs/xml-cocoon2/tools/src/blocks-build.xsl,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- blocks-build.xsl 29 Oct 2002 15:52:56 - 1.11
+++ blocks-build.xsl 3 Dec 2002 16:54:00 - 1.12
@@ -62,8 +62,8 @@
/fileset
/copy
/target
-
- target name=-single-project
depends=-single-project-samples,prepare-jdbc,prepare-database-connection
+
+ target name=-single-project-mocks if=currentblock.has.mocks
path id=currentblock.classpath
fileset
xsl:attribute name=dir${lib.dir}/xsl:attribute
@@ -79,6 +79,40 @@
/include
/fileset
/path
+
+ property name=currentblock.dir
+xsl:attribute
name=value${blocks.dir}/${currentblock.name}/xsl:attribute
+ /property
+
+ property name=currentblock.mocks.dir
+xsl:attribute name=value${currentblock.dir}/mocks/xsl:attribute
+ /property
+
+ property name=build.currentblock.mocks.dir
+xsl:attribute
name=value${build.blocks.root}/${currentblock.name}/mocks/xsl:attribute
+ /property
+
+ mkdir
+xsl:attribute
name=dir${build.currentblock.mocks.dir}/xsl:attribute
+ /mkdir
+
+ javac
+xsl:attribute name=srcdir${currentblock.mocks.dir}/xsl:attribute
+xsl:attribute
name=destdir${build.currentblock.mocks.dir}/xsl:attribute
+xsl:attribute name=debug${debug}/xsl:attribute
+xsl:attribute name=optimize${optimize}/xsl:attribute
+xsl:attribute name=deprecation${deprecation}/xsl:attribute
+xsl:attribute name=target${target.vm}/xsl:attribute
+xsl:attribute name=nowarn${nowarn}/xsl:attribute
+
+classpath refid=currentblock.classpath /
+ /javac
+
+
+ /target
+
+
+ target name=-single-project
depends=-single-project-mocks,-single-project-samples,prepare-jdbc,prepare-database-connection
property name=currentblock.dir
xsl:attribute
name=value${blocks.dir}/${currentblock.name}/xsl:attribute
@@ -116,6 +150,44 @@
xsl:attribute name=dir${build.currentblock.dest}/xsl:attribute
/mkdir
+
+
+ property name=currentblock.mocks.dir
+xsl:attribute name=value${currentblock.dir}/mocks/xsl:attribute
+ /property
+
+ property name=build.currentblock.mocks.dir
+xsl:attribute
name=value${build.blocks.root}/${currentblock.name}/mocks/xsl:attribute
+ /property
+
+ mkdir
+xsl:attribute
name=dir${build.currentblock.mocks.dir}/xsl:attribute
+ /mkdir
+
+
+
+
+ path id=currentblock.classpath
+fileset
+ xsl:attribute name=dir${lib.dir}/xsl:attribute
+
+ include name=**/*.jar /
+/fileset
+
+fileset
+ xsl:attribute name=dir${build.dir}/xsl:attribute
+
+ include
+ xsl:attribute name=name*.jar/xsl:attribute
+ /include
+/fileset
+
+pathelement
+ xsl:attribute
name=path${build.currentblock.mocks.dir}/xsl:attribute
+/pathelement
+
+ /path
+
copy filtering=on
xsl:attribute name=todir${build.currentblock.src}/xsl:attribute
@@ -231,6 +303,11 @@
xsl:attribute name=file${blocks.dir}/xsl:value-of
select=$block-name//samples/sitemap.xmap/xsl:attribute
/available
+ !-- Test if this block has a sample --
+ available property=currentblock.has.mocks type=dir
+ xsl:attribute name=file${blocks.dir}/xsl:value-of
select=$block-name//mocks//xsl:attribute
+ /available
+
xsl:if test=@status='unstable'
echo message=---/
echo message=ATTENTION: {$block-name} is marked unstable/
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2 changes.xml
nicolaken2002/12/03 08:55:14 Modified:.changes.xml Log: action dev=NKB type=update Updated block build system to compile and use mock objects in the mocks subdir of the blocks if present. /action Revision ChangesPath 1.298 +20 -1 xml-cocoon2/changes.xml Index: changes.xml === RCS file: /home/cvs/xml-cocoon2/changes.xml,v retrieving revision 1.297 retrieving revision 1.298 diff -u -r1.297 -r1.298 --- changes.xml 3 Dec 2002 16:44:50 - 1.297 +++ changes.xml 3 Dec 2002 16:55:14 - 1.298 @@ -56,6 +56,25 @@ Fixed SimpleFormTransformer: Malformed XML with textarea elements. /action action dev=NKB type=update +Updated block build system to compile and use mock objects in +the mocks subdir of the blocks if present. + /action + action dev=CH type=fix + New Logicsheet for use with InputModules. + /action + action dev=CH type=add + xsp.xsl now includes all xsp:init-page tags. Additional xsp:exit-page tag for + cleanup operations. + /action + action dev=CH type=add + New InputModule to map parameter names to / from another name. Uses translation + table and additional prefix / suffix. New InputModule to access contents of + an XMLFile using JXPath, based on patch from Jeff Turner ([EMAIL PROTECTED]). + /action + action dev=CH type=fix fixes-bug=14739 + Fixed SimpleFormTransformer: Malformed XML with textarea elements. + /action + action dev=NKB type=update Moved endorsed libs in ./lib/endorsed, so that they can be added in the build file easily as java jvm args, or in the future copied to the webserver or Java endorsed dir. Currently it enables Jetty to run easily in 1.4 JVMs without need to copy libs to -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2 changes.xml
nicolaken2002/12/03 08:55:56 Modified:.changes.xml Log: action dev=NKB type=update Updated block build system to compile and use mock objects in the mocks subdir of the blocks if present. /action Revision ChangesPath 1.299 +1 -16 xml-cocoon2/changes.xml Index: changes.xml === RCS file: /home/cvs/xml-cocoon2/changes.xml,v retrieving revision 1.298 retrieving revision 1.299 diff -u -r1.298 -r1.299 --- changes.xml 3 Dec 2002 16:55:14 - 1.298 +++ changes.xml 3 Dec 2002 16:55:56 - 1.299 @@ -40,21 +40,6 @@ /devs release version=@version@ date=@date@ - action dev=CH type=fix - New Logicsheet for use with InputModules. - /action - action dev=CH type=add - xsp.xsl now includes all xsp:init-page tags. Additional xsp:exit-page tag for - cleanup operations. - /action - action dev=CH type=add - New InputModule to map parameter names to / from another name. Uses translation - table and additional prefix / suffix. New InputModule to access contents of - an XMLFile using JXPath, based on patch from Jeff Turner ([EMAIL PROTECTED]). - /action - action dev=CH type=fix fixes-bug=14739 - Fixed SimpleFormTransformer: Malformed XML with textarea elements. - /action action dev=NKB type=update Updated block build system to compile and use mock objects in the mocks subdir of the blocks if present. -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp - New directory
nicolaken2002/12/03 08:59:13 xml-cocoon2/src/blocks/jsp - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp/conf - New directory
nicolaken2002/12/03 08:59:21 xml-cocoon2/src/blocks/jsp/conf - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp/java - New directory
nicolaken2002/12/03 08:59:34 xml-cocoon2/src/blocks/jsp/java - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp/mocks - New directory
nicolaken2002/12/03 08:59:39 xml-cocoon2/src/blocks/jsp/mocks - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp/samples - New directory
nicolaken2002/12/03 08:59:45 xml-cocoon2/src/blocks/jsp/samples - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp/java/org - New directory
nicolaken2002/12/03 08:59:57 xml-cocoon2/src/blocks/jsp/java/org - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp/java/org/apache - New directory
nicolaken2002/12/03 09:00:02 xml-cocoon2/src/blocks/jsp/java/org/apache - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp/java/org/apache/cocoon - New directory
nicolaken2002/12/03 09:00:07 xml-cocoon2/src/blocks/jsp/java/org/apache/cocoon - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp/java/org/apache/cocoon/components - New directory
nicolaken2002/12/03 09:00:12 xml-cocoon2/src/blocks/jsp/java/org/apache/cocoon/components - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp/java/org/apache/cocoon/reading - New directory
nicolaken2002/12/03 09:00:17 xml-cocoon2/src/blocks/jsp/java/org/apache/cocoon/reading - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp/java/org/apache/cocoon/generation - New directory
nicolaken2002/12/03 09:00:22 xml-cocoon2/src/blocks/jsp/java/org/apache/cocoon/generation - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp/java/org/apache/cocoon/components/jsp - New directory
nicolaken2002/12/03 09:00:27 xml-cocoon2/src/blocks/jsp/java/org/apache/cocoon/components/jsp - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp/mocks/weblogic - New directory
nicolaken2002/12/03 09:00:41 xml-cocoon2/src/blocks/jsp/mocks/weblogic - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp/mocks/weblogic/servlet - New directory
nicolaken2002/12/03 09:00:46 xml-cocoon2/src/blocks/jsp/mocks/weblogic/servlet - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/jsp JSPEngine.java JSPEngineImpl.java JSPEngineImplNamedDispatcherInclude.java JSPEngineImplWLS.java
nicolaken2002/12/03 09:07:29 Removed: src/java/org/apache/cocoon/components/jsp JSPEngine.java JSPEngineImpl.java JSPEngineImplNamedDispatcherInclude.java JSPEngineImplWLS.java Log: action dev=NKB type=update Moved the jsp components to the jsp block, using hand-made-to-be-cleaned mock objects for the weblogic specific imports. Had also to move some definitions from the cocoon roles and xconf file. This moving of the blocks is indeed cleaning the core! :-) /action -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp/conf jsp.xconf jsp.xmap jsp.xroles
nicolaken2002/12/03 09:07:39 Added: src/blocks/jsp/conf jsp.xconf jsp.xmap jsp.xroles Log: action dev=NKB type=update Moved the jsp components to the jsp block, using hand-made-to-be-cleaned mock objects for the weblogic specific imports. Had also to move some definitions from the cocoon roles and xconf file. This moving of the blocks is indeed cleaning the core! :-) /action Revision ChangesPath 1.1 xml-cocoon2/src/blocks/jsp/conf/jsp.xconf Index: jsp.xconf === ?xml version=1.0? xconf xpath=/cocoon unless=jsp-engine !-- JSP Engine: The JspGenerator selects a JSPEngine component. The JSPEngine component launches a JSP servlet engine of your servlet container, feeds the HttpRequest into the JSP servlet engine, and pipes the jsp response as SAX events into Cocoon2. The JSP page is specified by the HttpRequest. This way you can continue to use your JSP pages. Your migration from JSP to XSP may be done step by step. You may specify your JSP pages either as JSP scriptlets or as JSP-XML. But keep in mind that your JSP output should be valid XML. -- jsp-engine logger=core.jsp-engine parameter name=servlet-class value=org.apache.jasper.servlet.JspServlet/ parameter name=servlet-name value=*.jsp/ /jsp-engine /xconf 1.1 xml-cocoon2/src/blocks/jsp/conf/jsp.xmap Index: jsp.xmap === ?xml version=1.0? xmap xpath=/sitemap/components/readers unless=reader[@name='jsp'] map:reader name=jsp src=org.apache.cocoon.reading.JSPReader/ /xmap 1.1 xml-cocoon2/src/blocks/jsp/conf/jsp.xroles Index: jsp.xroles === ?xml version=1.0? xroles xpath=/role-list unless=role[@name='org.apache.cocoon.components.jsp.JSPEngine'] role name=org.apache.cocoon.components.jsp.JSPEngine shorthand=jsp-engine default-class=org.apache.cocoon.components.jsp.JSPEngineImpl/ /xroles -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/reading JSPReader.java servlet.xmap
nicolaken2002/12/03 09:07:52 Removed: src/java/org/apache/cocoon/generation JspGenerator.java src/java/org/apache/cocoon/reading JSPReader.java servlet.xmap Log: action dev=NKB type=update Moved the jsp components to the jsp block, using hand-made-to-be-cleaned mock objects for the weblogic specific imports. Had also to move some definitions from the cocoon roles and xconf file. This moving of the blocks is indeed cleaning the core! :-) /action -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/blocks/jsp/mocks/weblogic/servlet/internal ServletContextImpl.java ServletOutputStreamImpl.java ServletResponseImpl.java
nicolaken2002/12/03 09:08:02
Added: src/blocks/jsp/mocks/weblogic/servlet/internal
ServletContextImpl.java
ServletOutputStreamImpl.java
ServletResponseImpl.java
Log:
action dev=NKB type=update
Moved the jsp components to the jsp block, using hand-made-to-be-cleaned
mock objects for the weblogic specific imports.
Had also to move some definitions from the cocoon roles and xconf file.
This moving of the blocks is indeed cleaning the core! :-)
/action
Revision ChangesPath
1.1
xml-cocoon2/src/blocks/jsp/mocks/weblogic/servlet/internal/ServletContextImpl.java
Index: ServletContextImpl.java
===
/*
The Apache Software License, Version 1.1
Copyright (C) 1999-2002 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 weblogic.servlet.internal;
import java.io.*;
import java.net.*;
import java.util.*;
import javax.servlet.*;
/**
* **
* *W A R N I N G *
* **
*
* This is a mock object of the class, not the actual class.
* It's used to compile the code in absence of the actual class.
*
* This clsss is created by hand, not automatically.
*
* **
*
* @version CVS $Id: ServletContextImpl.java,v 1.1 2002/12/03 17:08:02 nicolaken Exp
$
*/
public class ServletContextImpl implements ServletContext{
public Enumeration getServlets(){
return null;
}
public void log(String string){
}
public void setExpectedLog(String string){
}
public void setupGetResource(URL resource){
}
public URL getResource(String string){
return null;
}
public void setupGetResourcePaths(Set resourcePaths){
}
public Set getResourcePaths(String string){
return null;
}
public ServletContext getContext(String string){
return null;
}
public int
cvs commit: xml-cocoon2/src/blocks/jsp/java/org/apache/cocoon/reading JSPReader.java
nicolaken2002/12/03 09:08:12
Added: src/blocks/jsp/java/org/apache/cocoon/components/jsp
JSPEngine.java JSPEngineImpl.java
JSPEngineImplNamedDispatcherInclude.java
JSPEngineImplWLS.java
src/blocks/jsp/java/org/apache/cocoon/generation
JspGenerator.java
src/blocks/jsp/java/org/apache/cocoon/reading JSPReader.java
Log:
action dev=NKB type=update
Moved the jsp components to the jsp block, using hand-made-to-be-cleaned
mock objects for the weblogic specific imports.
Had also to move some definitions from the cocoon roles and xconf file.
This moving of the blocks is indeed cleaning the core! :-)
/action
Revision ChangesPath
1.1
xml-cocoon2/src/blocks/jsp/java/org/apache/cocoon/components/jsp/JSPEngine.java
Index: JSPEngine.java
===
/*
The Apache Software License, Version 1.1
Copyright (C) 1999-2002 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.components.jsp;
import org.apache.avalon.framework.component.Component;
import org.xml.sax.SAXException;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
/**
* A component for loading and running JSP.
*
* @author a href=mailto:[EMAIL PROTECTED];Davanum Srinivas/a
* @version CVS $Id: JSPEngine.java,v 1.1 2002/12/03 17:08:11 nicolaken Exp $
*/
public interface JSPEngine extends Component {
String ROLE = JSPEngine.class.getName();
/**
* execute the JSP and return the output
*
* @param context The Servlet Context
* @exception IOException
* @exception ServletException
* @exception SAXException
* @exception Exception
*/
byte[] executeJSP(String url,
HttpServletRequest request,
HttpServletResponse response,
ServletContext context)
throws IOException, ServletException, SAXException, Exception;
}
1.1
cvs commit: xml-cocoon2/src/blocks/jsp/samples notyet.txt
nicolaken2002/12/03 09:08:20 Added: src/blocks/jsp/samples notyet.txt Log: action dev=NKB type=update Moved the jsp components to the jsp block, using hand-made-to-be-cleaned mock objects for the weblogic specific imports. Had also to move some definitions from the cocoon roles and xconf file. This moving of the blocks is indeed cleaning the core! :-) /action Revision ChangesPath 1.1 xml-cocoon2/src/blocks/jsp/samples/notyet.txt Binary file -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2 changes.xml module.xml properties.xml
nicolaken2002/12/03 09:08:36
Modified:.changes.xml module.xml properties.xml
Log:
action dev=NKB type=update
Moved the jsp components to the jsp block, using hand-made-to-be-cleaned
mock objects for the weblogic specific imports.
Had also to move some definitions from the cocoon roles and xconf file.
This moving of the blocks is indeed cleaning the core! :-)
/action
Revision ChangesPath
1.300 +7 -1 xml-cocoon2/changes.xml
Index: changes.xml
===
RCS file: /home/cvs/xml-cocoon2/changes.xml,v
retrieving revision 1.299
retrieving revision 1.300
diff -u -r1.299 -r1.300
--- changes.xml 3 Dec 2002 16:55:56 - 1.299
+++ changes.xml 3 Dec 2002 17:08:35 - 1.300
@@ -41,6 +41,12 @@
release version=@version@ date=@date@
action dev=NKB type=update
+Moved the jsp components to the jsp block, using hand-made-to-be-cleaned
+mock objects for the weblogic specific imports.
+Had also to move some definitions from the cocoon roles and xconf file.
+This moving of the blocks is indeed cleaning the core! :-)
+ /action
+ action dev=NKB type=update
Updated block build system to compile and use mock objects in
the mocks subdir of the blocks if present.
/action
1.19 +19 -0 xml-cocoon2/module.xml
Index: module.xml
===
RCS file: /home/cvs/xml-cocoon2/module.xml,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- module.xml28 Nov 2002 15:12:33 - 1.18
+++ module.xml3 Dec 2002 17:08:35 - 1.19
@@ -352,6 +352,25 @@
/project
+ project name=jsp-block
+packageorg.apache.cocoon/package
+
+ant target=block
+ property name=block-name value=jsp/
+/ant
+
+depend project=xml-cocoon2/
+
+work nested=tools/anttasks/
+home nested=build/cocoon/
+
+jar name=jsp-block.jar/
+
+nag from=Nicola Ken Barozzi lt;[EMAIL PROTECTED]gt;
+ to=[EMAIL PROTECTED]/
+
+ /project
+
!--
COCOON SUPPLIED PROJECTS
1.17 +1 -0 xml-cocoon2/properties.xml
Index: properties.xml
===
RCS file: /home/cvs/xml-cocoon2/properties.xml,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- properties.xml3 Dec 2002 00:06:02 - 1.16
+++ properties.xml3 Dec 2002 17:08:35 - 1.17
@@ -120,6 +120,7 @@
precept/
poi include=true/
naming include=true/
+jsp include=true/
/blocks
!-- Specify what should be included in the web application (war) file --
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[SHOWSTOPPER] Regression test fails
Hi all, I found out several failures on the following regression tests: 1) http://localhost:8080/cocoon/sub/xsp-dynamic test does not go through anymore: XSP generation date never changes (same for http://localhost:8080/cocoon/sub/all-dynamic) 2) When XSP is generated from cocoon:/sub/xsp-source, file is wrongly created in ...\jakarta-tomcat-4.1.16\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\cocoon_\_\sub\xsp_source.java instead of ...\jakarta-tomcat-4.1.16\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\sub\xsp_source.java 3) When root sitemap is generated from the sitemap.xmap file, Java source file is wrongly created in ...\jakarta-tomcat-4.1.16\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\file_\C_\apache_bin\jakarta_tomcat_4_1_16\webapps\cocoon\sitemap_xmap.java instead of ...\jakarta-tomcat-4.1.16\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\sitemap_xmap.java 4) http://localhost:8080/cocoon/sub/generror does not reset content anymore: it shows parts of generated page and error report. AFAIR, it showed only error report in 2.0.3 release. Seems that source resolving is broken in current 2.0.4-dev. Does anybody have a clue? PS I won't be able (for sure) to look into it till weekend. PPS Thanks to Timothy Larson for bringing up the issue. Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon cocoon.roles
nicolaken2002/12/03 09:09:14 Modified:src/java/org/apache/cocoon cocoon.roles Log: action dev=NKB type=update Moved the jsp components to the jsp block, using hand-made-to-be-cleaned mock objects for the weblogic specific imports. Had also to move some definitions from the cocoon roles and xconf file. This moving of the blocks is indeed cleaning the core! :-) /action Revision ChangesPath 1.38 +0 -4 xml-cocoon2/src/java/org/apache/cocoon/cocoon.roles Index: cocoon.roles === RCS file: /home/cvs/xml-cocoon2/src/java/org/apache/cocoon/cocoon.roles,v retrieving revision 1.37 retrieving revision 1.38 diff -u -r1.37 -r1.38 --- cocoon.roles 3 Dec 2002 12:57:37 - 1.37 +++ cocoon.roles 3 Dec 2002 17:09:14 - 1.38 @@ -79,10 +79,6 @@ shorthand=program-generator default-class=org.apache.cocoon.components.language.generator.ProgramGeneratorImpl/ - role name=org.apache.cocoon.components.jsp.JSPEngine -shorthand=jsp-engine -default-class=org.apache.cocoon.components.jsp.JSPEngineImpl/ - role name=org.apache.cocoon.components.classloader.ClassLoaderManager shorthand=classloader default-class=org.apache.cocoon.components.classloader.ClassLoaderManagerImpl/ -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/webapp/WEB-INF cocoon.xconf
nicolaken2002/12/03 09:09:45 Modified:src/webapp/WEB-INF cocoon.xconf Log: action dev=NKB type=update Moved the jsp components to the jsp block, using hand-made-to-be-cleaned mock objects for the weblogic specific imports. Had also to move some definitions from the cocoon roles and xconf file. This moving of the blocks is indeed cleaning the core! :-) /action Revision ChangesPath 1.45 +0 -15 xml-cocoon2/src/webapp/WEB-INF/cocoon.xconf Index: cocoon.xconf === RCS file: /home/cvs/xml-cocoon2/src/webapp/WEB-INF/cocoon.xconf,v retrieving revision 1.44 retrieving revision 1.45 diff -u -r1.44 -r1.45 --- cocoon.xconf 3 Dec 2002 16:44:08 - 1.44 +++ cocoon.xconf 3 Dec 2002 17:09:45 - 1.45 @@ -182,21 +182,6 @@ parameter name=preload value=true/ /program-generator - !-- JSP Engine: -The JspGenerator selects a JSPEngine component. The JSPEngine component -launches a JSP servlet engine of your servlet container, feeds the -HttpRequest into the JSP servlet engine, and pipes the jsp response as -SAX events into Cocoon2. The JSP page is specified by the HttpRequest. -This way you can continue to use your JSP pages. Your migration from JSP -to XSP may be done step by step. You may specify your JSP pages either as -JSP scriptlets or as JSP-XML. But keep in mind that your JSP output should -be valid XML. - -- - jsp-engine logger=core.jsp-engine -parameter name=servlet-class value=org.apache.jasper.servlet.JspServlet/ -parameter name=servlet-name value=*.jsp/ - /jsp-engine - !-- i18n Bundle Factory: BundleFactory loads Bundles with i18n resources for the given locale. Bundles are loaded from the 'catalogue_location'. Bundle base name is -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Flow wishlist :)
Let me be clear that I'm not looking for dynamic pipeline generation. Cool. The mapping of URI to generator is well defined for everything that what we want to do. The selection of transformer is a little less so; for example, the 1 result vs. multiple results example we talked about earlier. That's still a static sitemap, but the transformer is chosen at run time; so the understanding of dynamic vs. static sitemap should be clear: dynamic sitemap would mean building the sitemap every time it's run. I can't imagine anyone that would want that? The ability to attach new components to pipelines at runtime has been asked for in the past and I've always been against this (and I still am). Darn semantics... I'm not trying to attach anything new to the sitemap at run time, just choose between predefined components at run time, the same way the sitemap currently works. It's just that the language I want to use to choose between components is XSLT instead of JavaScript. big snip on background info/ In-other-words, for us, the decision on what action to take at any given point is dynamically evaluated (like most action handlers), but the decisions are just based on one heck of a lot of complex processing (and not just simple form field evaluation), this processing falls into the general CS pattern of expert systems processing and more specifically rules based expert systems (among other things). As a result, in our particular case, functional programming meets our needs better than most other solutions. Cool, I trust your reasoning on this and I'm starting to understand why you want special XSLT templating where rules are stored into databases. But I think that what you are looking for is a special transformer. It doesn't require changes to what cocoon pipelines are. At least, I don't see why it should. That could be and it's partly why I've started this discussion. This morning in a responses to Ovidiu I pointed out that perhaps what I really want is just to be able to use XSLT as the flow language? I'm not quite sure how that would work, but that's essentially what I'm looking for... big snip/ The rules don't go into the database, the rule selectors go into the database. I don't think any extensions should be needed; the context data will be created using standard generators and possibly aggregation, though as we proceed we're finding that our generators inherit from each other and aggregation isn't needed; each generator picks up what is needed automatically. Likely, for the other cases we'll end up using composition in the generators and eliminate aggregation in the sitemap. So, why don't you so something like map:transform type=xslt src=cocoon://.../ where is a cocoon pipeline that generates the stylesheet you need? I've considered this in the past and it now occurs to me that this is probably a better solution than the dynamically created cinclude/xinclude solution that was also discussed in this thread. I'll have to do some analysis on how much work it would be to code this up, but I think it would be pretty straight forward. Again the issue of caching comes up, but we already know this thing is going to take some pretty hefty hardware in any case... how that is goint to be any better than a sitemap+flowmap is *very* hard to see from where I stand. Better is a relative thing. Oh, totally. As we've sort of concluded, in some cases your development requirements get messy no matter what way you go. When you're building systems for research it's often a case of picking the less of two evils... Wise sentence. Still here you are pointing out that cocoon might require changes to its internal model while I really don't see this as it seems that your concerns happen to reside on a higher application level than the sitemap+flowscript (if I understood correctly, of course) I hope no changes should be needed other than those that are currently be worked on to support flow and blocks. Part of my reason for pursuing this is to see if it will be possible to use flow and/or blocks to support what I want to do. If I use the dynamic XSLT approach then even these changes might not be needed, but ultimately I suspect I could get better performance using an approach that didn't need dynamic XSLT. small snip/ However, I could also see how there might be situations where the serialization decision might be part of the new thingy, and thus the blocks discussion and how to hand off service calls becomes relevant. It is *NOT* a transformer decision to drive the serialization process. It's against both SoC and IoC! There is nothing planned for Cocoon Blocks that will allow this to happen and as soon as I have to vote around here, you'll get my -1 on anything that makes possible for one pipeline component to modify dynamically the pipeline execution, including choosing a serializer. I'm not asking for the
Re: OT: Announcement: Cocoon Stammtisch @ Frankfurt
Great, looking forward to it! :) Thanks for organising this Michael! Cheers, Marcus On Mon, Dec 02, 2002 at 06:52:44PM +0100, Michael Hartle wrote: Hello all, FYI, the Cocoon Stammtisch @ Frankfurt now has a reservation for a location in downtown Frankfurt on Monday, December 9th for 25-30 people - currently I have 21 people by name who are probably going to visit the Stammtisch, so there still are some spare seats left. You will find all the details at http://outerthought.net/wiki/Wiki.jsp?page=FrankfurtherStammtisch Hope to see you all at Frankfurt, Best regards, Michael Hartle, Hartle Klug Consulting GmbH - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- . ,,$, Marcus Crafter ;$' ':Computer Systems Engineer $: : ManageSoft GmbH $ o_)$$$: 82-84 Mainzer Landstrasse ;$,_/\ :' 60327 Frankfurt Germany ' /( \_' . : - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/modules modules.xconf
haul2002/12/03 09:36:20
Modified:src/webapp/samples/modules index.xhtml menu.xml sitemap.xmap
src/java/org/apache/cocoon/components/modules modules.xconf
Added: src/webapp/samples/modules forrestconf.xml
Log:
Sample for new XMLFileModule thanks to Jeff Turner ([EMAIL PROTECTED])
Revision ChangesPath
1.3 +4 -0 xml-cocoon2/src/webapp/samples/modules/index.xhtml
Index: index.xhtml
===
RCS file: /home/cvs/xml-cocoon2/src/webapp/samples/modules/index.xhtml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- index.xhtml 13 Nov 2002 22:47:41 - 1.2
+++ index.xhtml 3 Dec 2002 17:36:20 - 1.3
@@ -24,6 +24,10 @@
tda href=system-property.xspsystem-property/a/td
tdSystem properties (environment variables)/td
/tr
+ tr
+ tda href=xml.xspxml/a/td
+ tdXML node values/td
+ /tr
/table
/td
/tr
1.3 +1 -0 xml-cocoon2/src/webapp/samples/modules/menu.xml
Index: menu.xml
===
RCS file: /home/cvs/xml-cocoon2/src/webapp/samples/modules/menu.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- menu.xml 13 Nov 2002 22:47:41 - 1.2
+++ menu.xml 3 Dec 2002 17:36:20 - 1.3
@@ -15,6 +15,7 @@
menu-item label=RequestModule href=request.xsp/
menu-item label=SessionModule href=session.xsp/
menu-item label=SystemPropertiesModule href=system-property.xsp/
+menu-item label=XMLModule href=xml.xsp/
menu-item label=AttributeModule /
/menu
1.3 +16 -1 xml-cocoon2/src/webapp/samples/modules/sitemap.xmap
Index: sitemap.xmap
===
RCS file: /home/cvs/xml-cocoon2/src/webapp/samples/modules/sitemap.xmap,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- sitemap.xmap 13 Nov 2002 22:47:41 - 1.2
+++ sitemap.xmap 3 Dec 2002 17:36:20 - 1.3
@@ -138,6 +138,21 @@
/map:match
+map:match pattern=content/xml.xsp
+ map:generate type=serverpages src=properties.xsp
+map:parameter name=version
value={myxml:/forrestconf/@version}/
+map:parameter name=skin value={myxml:/forrestconf/skin}/
+map:parameter name=base-url value={myxml:/*/base-url}/
+!--
+map:parameter name=slashdot-headline
value={slashdot:/*:RDF/item[1]/title}/
+--
+ /map:generate
+ map:transform src=properties2html.xsl
+map:parameter name=title value=XML Input Module
(XMLModule)/
+ /map:transform
+ map:serialize /
+/map:match
+
!-- Menu generation --
map:match pattern=menu/*
map:generate src=menu.xml/
1.1 xml-cocoon2/src/webapp/samples/modules/forrestconf.xml
Index: forrestconf.xml
===
forrestconf version=1.0
skinforrest-site/skin
base-urlhttp://localhost:8787/cocoon/base-url
/forrestconf
1.11 +6 -0
xml-cocoon2/src/java/org/apache/cocoon/components/modules/modules.xconf
Index: modules.xconf
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/modules/modules.xconf,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- modules.xconf 17 Nov 2002 18:00:02 - 1.10
+++ modules.xconf 3 Dec 2002 17:36:20 - 1.11
@@ -31,6 +31,12 @@
input-module name=session-attr/
input-module name=defaults/
/component-instance
+ component-instance
class=org.apache.cocoon.components.modules.input.XMLFileModule
logger=core.modules.xml name=myxml
+file src=context:///samples/modules/forrestconf.xml/
+ /component-instance
+ component-instance
class=org.apache.cocoon.components.modules.input.XMLFileModule
logger=core.modules.xml name=slashdot
+file src=http://slashdot.org/slashdot.rss;
+ /component-instance
/input-modules
output-modules
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Re: [SHOWSTOPPER] Regression test fails
On Tue, Dec 03, 2002 at 12:08:38PM -0500, Vadim Gritsenko wrote: 3) When root sitemap is generated from the sitemap.xmap file, Java source file is wrongly created in ...\jakarta-tomcat-4.1.16\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\file_\C_\apache_bin\jakarta_tomcat_4_1_16\webapps\cocoon\sitemap_xmap.java instead of ...\jakarta-tomcat-4.1.16\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\sitemap_xmap.java I think I remember somewhere a discussion about switching 2.0.3 branch to use the interpreted sitemap by default - I don't remember the outcome though - did we decide not to do this ? Cheers, Marcus -- . ,,$, Marcus Crafter ;$' ':Computer Systems Engineer $: : ManageSoft GmbH $ o_)$$$: 82-84 Mainzer Landstrasse ;$,_/\ :' 60327 Frankfurt Germany ' /( \_' . : - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
jsp block with mock objects
I've committed the jsp block with the use of mock objects (in the mocks dir of the block). The build with mock objects simply checks if there are classes in that dir, compiles them before the block, and uses those classes in the classpath for the compilation of the block. They don't figure in the resulting block jar. The mock objects I out in are hand-made and really suck. I put them in because I don't have weblogic and I needed to put the classes to make compilation not break. Whoever has those jars please make correct mock objects or send the jar to me so I'll create it. Option 1 is highly appreciated ;-) The mock4blocks build system is available to all blocks, just add them in the mocks dir of that block. Please report eventual problems. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Flow wishlist :)
Ok, seems to me that we are finally converging to something. Great. Hunsberger, Peter wrote: That could be and it's partly why I've started this discussion. This morning in a responses to Ovidiu I pointed out that perhaps what I really want is just to be able to use XSLT as the flow language? I'm not quite sure how that would work, but that's essentially what I'm looking for... Ok, so instead of sitemap+flowscript you want XSLT+sitemap. Ok, I'm starting to get it. [snip] I hope no changes should be needed other than those that are currently be worked on to support flow and blocks. Part of my reason for pursuing this is to see if it will be possible to use flow and/or blocks to support what I want to do. H, I'm not currently in favor of a pluggable sitemap engine... but you do have a point here, so let's keep the door open for a possibility. NOTE: the way cocoon is already architected makes it very easy to connect a new sitemap engine (we already have two: interpreted and compiled) and its also completely detached from the request environment (as for CLI abstraction). It would be pretty straightforward to plug in a different sitemap engine that didn't use the current sitemap semantics but something else entirely. But I consider this a last resource, something that gets *too* close to FS and over-componentization. [snip] Yes, I agree; I kept out of the blocks language discussion for the most part because I don't have enough experience with trying to plug new things into C2 yet. It looks like that discussion has come to some consensus but I'm not quite sure what it is? It seems to me that however it shakes out will be sufficient for my needs... Hmmm, so far there has been *no* discussion whatsoever in allowing blocks to extend or overwrite the internal core functionalities of cocoon. And that was on purpose. This is the first time it emerges but it's good to see if it makes sense or it's just FS. This is more a community-thing that a technical issue, but look at the mess that Avalon became after allowing people to diverge without creating consensus :/ Not familiar with the issues, but I'll trust you on that and stay away from getting involved if you don't mind ;-) Oh, lucky you :) [snip] There are definitely two issues here. I'm not very concerned about this last one, more about how easy it would be to plug something new in to manage flow. Ok, got it. After working through this discussion it seems that this primary concern is probably: sitemap+flowxslt instead of sitemap+flowscript. The problem now is that, (like you ?), I can't quite see how the two concepts could be pluggable replacements for each other? Yes, I definately can't see why anybody would want to use XSLT for the flow description but that might well be my personal limitation kicking in and I fully want to understand your point so that I might learn something that I failed to see before. Still, XSLT was *NOT* designed for those type of things and my gut feeling is that by twisting its model too much you might end up having something that uses the same XSLT syntax but is not XSLT anymore... so it might simply confuse people and appear as a 'golden-hammer' anti-pattern. [and XSLT is so overloaded with that that's sad!] I'd rather avoid using XSLT extensions, so I guess that means having some kind of DOM model where the input is a bunch of data and the XSLT reduced it to a single node that the flow controller then somehow interprets as the next step instruction? What you are presenting above is a very complex way to transform your data. Gee, couldn't the same be said of all of Cocoon? :-) No, that can be said for Xalan. Cocoon is much more than a way to transform your data. I don't see what you can['t] manage flow with XSLT. Well, as you pointed out earlier, all Turing complete languages are isomorphic to each other... In case you didn't realize, XSLT is definately *not* a turing-complete language :) [you need internal scripting or extensions to turn it into one] Well we're still in an architecture mode and I haven't yet started on a prototype, but off the top of my head I could see an XSLT that looked something like the following. (Bear with me for a moment, this isn't right, but I think it introduces the concept better than jumping directly to what I want): Great. xslt:template match=count(data/*) = 0 map:transform src=error.xsl map:parameter name=parms value=/request:parms/*/ /map:transform /xslt:template xslt:template match=count(data/*) = 1 map:transform src=detail.xsl map:parameter name=data value=data/*/ /map:transform /xslt:template xslt:template match=count(data/*) 1 map:transform src=list.xsl map:parameter name=data value=./ /map:transform /xslt:template Ah, we are coming back to the XPathSelector!!! map:select type=xpath map:when test=count(data/*) = 0 map:transform src=error.xsl/ /map:when ... /map:select This
Re: The organization of xml.apache.org
Ted: Can you give us a couple examples, without exposing anything sensitive, of previous litigation and or attempted litigation against Apache open source members? It would be very helpful to have some understanding of how and why this can come about so that we can adopt a preventive posture. To date, my understanding of open source software is that it expresses no warranty at all. I'm unclear on what basis someone would be held libel in a legal action. Inquiring Minds Want To Know Steve Punte Candlelight SoftwareDo you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now
RE: Flow wishlist :)
Hi, In case you didn't realize, XSLT is definately *not* a turing-complete language :) [you need internal scripting or extensions to turn it into one] http://www.unidex.com/turing/utm.htm best, -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Flow wishlist :)
In case you didn't realize, XSLT is definately *not* a turing-complete language :) [you need internal scripting or extensions to turn it into one] http://www.google.de/search?hl=deie=UTF-8oe=UTF-8q=turing+completeness+XSLTbtnG=Google-Suchemeta= http://www.unidex.com/turing/utm.htm http://www.biglist.com/lists/xsl-list/archives/200105/msg01383.html http://www.biglist.com/lists/xsl-list/archives/200105/msg01485.html but: http://www.biglist.com/lists/xsl-list/archives/200105/msg01506.html Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [SHOWSTOPPER] Regression test fails
On 03.Dec.2002 -- 06:38 PM, Marcus Crafter wrote: On Tue, Dec 03, 2002 at 12:08:38PM -0500, Vadim Gritsenko wrote: I think I remember somewhere a discussion about switching 2.0.3 branch to use the interpreted sitemap by default - I don't remember the outcome though - did we decide not to do this ? I'd like to object unless the 2.0.4 interpreted sitemap supports InputModules as the 2.1 one does. And if we change just two days before release we should consider calling 2.0.4 a beta or release candidate to be sure it really is a sane switch. 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Flow wishlist :)
That could be and it's partly why I've started this discussion. This morning in a responses to Ovidiu I pointed out that perhaps what I really want is just to be able to use XSLT as the flow language? I'm not quite sure how that would work, but that's essentially what I'm looking for... Ok, so instead of sitemap+flowscript you want XSLT+sitemap. Ok, I'm starting to get it. Great, you may have to explain it to me at some point I hope no changes should be needed other than those that are currently be worked on to support flow and blocks. Part of my reason for pursuing this is to see if it will be possible to use flow and/or blocks to support what I want to do. H, I'm not currently in favor of a pluggable sitemap engine... but you do have a point here, so let's keep the door open for a possibility. NOTE: the way cocoon is already architected makes it very easy to connect a new sitemap engine (we already have two: interpreted and compiled) and its also completely detached from the request environment (as for CLI abstraction). It would be pretty straightforward to plug in a different sitemap engine that didn't use the current sitemap semantics but something else entirely. But I consider this a last resource, something that gets *too* close to FS and over-componentization. Yes, I suspect so. Also, what I'm proposing would use all of existing sitemap capabilities so I don't want to reinvent that... [snip] Yes, I agree; I kept out of the blocks language discussion for the most part because I don't have enough experience with trying to plug new things into C2 yet. It looks like that discussion has come to some consensus but I'm not quite sure what it is? It seems to me that however it shakes out will be sufficient for my needs... Hmmm, so far there has been *no* discussion whatsoever in allowing blocks to extend or overwrite the internal core functionalities of cocoon. And that was on purpose. This is the first time it emerges but it's good to see if it makes sense or it's just FS. I'm not sure that this would hit the core? It looks to me more like a resource that wants to call other resources. I plug this new thing into the sitemap, it take over for a transformer at some point, then it calls other resources as defined in the sitemap. snip After working through this discussion it seems that this primary concern is probably: sitemap+flowxslt instead of sitemap+flowscript. The problem now is that, (like you ?), I can't quite see how the two concepts could be pluggable replacements for each other? Yes, I definately can't see why anybody would want to use XSLT for the flow description but that might well be my personal limitation kicking in and I fully want to understand your point so that I might learn something that I failed to see before. Hmm, I meant that I couldn't easily see how to replace a script engine with a functional engine not that that I couldn't see how to use XSLT to drive other transformations. Still, XSLT was *NOT* designed for those type of things and my gut feeling is that by twisting its model too much you might end up having something that uses the same XSLT syntax but is not XSLT anymore... so it might simply confuse people and appear as a 'golden-hammer' anti-pattern. I'd have to disagree. I think XSLT was designed precisely for this purpose: sort through some data and determine what data should be created as a result. I'd rather avoid using XSLT extensions, so I guess that means having some kind of DOM model where the input is a bunch of data and the XSLT reduced it to a single node that the flow controller then somehow interprets as the next step instruction? What you are presenting above is a very complex way to transform your data. Gee, couldn't the same be said of all of Cocoon? :-) No, that can be said for Xalan. Cocoon is much more than a way to transform your data. Such as? Ultimately all of computer science is just about data transformation... I don't see what you can['t] manage flow with XSLT. Well, as you pointed out earlier, all Turing complete languages are isomorphic to each other... In case you didn't realize, XSLT is definately *not* a turing-complete language :) [you need internal scripting or extensions to turn it into one] No, there are several proofs of XSLT Turing completeness. See http://www.unidex.com/turing/utm.htm for starters... snip of example 1/ Ah, we are coming back to the XPathSelector!!! map:select type=xpath map:when test=count(data/*) = 0 map:transform src=error.xsl/ /map:when ... /map:select This was proposed a while ago but was voted down since the sitemap routing components shouldn't have a way to access the content of the pipeline. But sitemap components already have ways to access the content of the pipeline, it's just that currently you have to expose those contents as
Re: Flow wishlist :)
Robert Koberg wrote: Hi, In case you didn't realize, XSLT is definately *not* a turing-complete language :) [you need internal scripting or extensions to turn it into one] http://www.unidex.com/turing/utm.htm Only one comment: oh my deity;! I was wrong. You learn something new every day :-) -- Stefano Mazzocchi [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [SHOWSTOPPER] Regression test fails
Christian Haul wrote:
On 03.Dec.2002 -- 06:38 PM, Marcus Crafter wrote:
On Tue, Dec 03, 2002 at 12:08:38PM -0500, Vadim Gritsenko wrote:
I think I remember somewhere a discussion about switching 2.0.3 branch
to use the interpreted sitemap by default - I don't remember the
outcome though - did we decide not to do this ?
I'd like to object unless the 2.0.4 interpreted sitemap supports
InputModules as the 2.1 one does. And if we change just two days
before release we should consider calling 2.0.4 a beta or release
candidate to be sure it really is a sane switch.
I ported the InputModule-enabled sitemap from 2.1 to 2.0.4 a week ago,
and I've been using it with no problems since then.
Other people may want to test it before we officially make the switch.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Flow wishlist :)
I thought you were trying to spark the reply we (Joerg, Peter I) made to come back with some proof that it wasn't, especially given the emphasis :) OK, it is settled, everything moves to XSLT :-D -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 03, 2002 1:03 PM To: [EMAIL PROTECTED] Subject: Re: Flow wishlist :) Robert Koberg wrote: Hi, In case you didn't realize, XSLT is definately *not* a turing-complete language :) [you need internal scripting or extensions to turn it into one] http://www.unidex.com/turing/utm.htm Only one comment: oh my deity;! I was wrong. You learn something new every day :-) -- Stefano Mazzocchi [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Flow wishlist :)
Hunsberger, Peter wrote: I'm not sure that this would hit the core? It looks to me more like a resource that wants to call other resources. I plug this new thing into the sitemap, it take over for a transformer at some point, then it calls other resources as defined in the sitemap. Yeah, that's basically what cinclude does. No need to change anything if you follow that pattern. After working through this discussion it seems that this primary concern is probably: sitemap+flowxslt instead of sitemap+flowscript. The problem now is that, (like you ?), I can't quite see how the two concepts could be pluggable replacements for each other? Yes, I definately can't see why anybody would want to use XSLT for the flow description but that might well be my personal limitation kicking in and I fully want to understand your point so that I might learn something that I failed to see before. Hmm, I meant that I couldn't easily see how to replace a script engine with a functional engine not that that I couldn't see how to use XSLT to drive other transformations. Sure, I got that. Still, XSLT was *NOT* designed for those type of things and my gut feeling is that by twisting its model too much you might end up having something that uses the same XSLT syntax but is not XSLT anymore... so it might simply confuse people and appear as a 'golden-hammer' anti-pattern. I'd have to disagree. I think XSLT was designed precisely for this purpose: sort through some data and determine what data should be created as a result. Hmmm, sure. but that is only a very small part of what flow-management is about. How would you keep the state across requests in XSLT? Ah, we are coming back to the XPathSelector!!! map:select type=xpath map:when test=count(data/*) = 0 map:transform src=error.xsl/ /map:when ... /map:select This was proposed a while ago but was voted down since the sitemap routing components shouldn't have a way to access the content of the pipeline. But sitemap components already have ways to access the content of the pipeline, it's just that currently you have to expose those contents as parameters... Selectors, matchers and actions have no way to get the content of a pipeline (by design!) snip of example 2/ Yeah, I think that all you want might be achieved with the XPathSelector. Well, these are somewhat trivial examples, I'd think that you can see that much more would be possible inside of a real XSLT... Ok The use of XSLT is *clearly* overkill. What you are describing is *NOT* XSLT: even if it uses the same syntax, the semantics are totally different (in fact, you are mixing XSLT semantics with the sitemap semantics... this cannot possibly be easier to learn/use/maintain than just the sitemap semantics) That doesn't make sense: in that case you'd have to consider the production of HTML from XML via XSLT a mixing of HTML semantics with XSLT semantics? No, because that content is *passive*. Here, you are mixing xslt and sitemap which are both 'active' content, content that has server-side semantics and will not be passed passivly on. So, in fact, the complexity of sitemap+flowscript is repeated in XSLT+sitemap, just that your solution doesn't have a way to separate the two. NOTE: I've been proposing that the flowscript might be generated out of a cocoon pipeline. That implies that you might use whatever declerative markup you want to describe your rules (as people do in a workflow environment) and have a stylesheet transform it into flowscript. That would: 1) give you a way to keep the rules separated from the resources 2) still use a declarative view of your rule engine (your rules can even be extracted out of a database and cached since I don't think they change that often) 3) no need for custom sitemap transformation components this is how I would do it. Using XSLT as a pipeline componentization skeleton sounds golden-hammer all the way. So if someone needs to make a pipeline decision based on metadata they are out of luck? Why? you can plug your own selectors and matchers for that. That's exactly what they were build for (they can even connect via JDBC to your rule-database if you want and using Java, not some foolish XSLT extension for that). Really, our entire model is metadata driven, there is no hard data at any point outside of metadata selector patterns... You have some pipeline metadata and you have to make some decisions based on that. Great. Write a matcher or a selector that reacts on that metadata. There is *no* need to aggregate this into the pipeline and then extract it again from there. This, instead of mixing stuff in the pipeline, enforces separation and clean design. I'm still keeping the processing of the metadata separate from the pipeline. You have to call the new thing to access the metadata and the metadata is not exposed in the pipeline (as it would be with XPathSelector). Then I'm lost. Your bunch
Re: Flow wishlist :)
Robert Koberg wrote: I thought you were trying to spark the reply we (Joerg, Peter I) made to come back with some proof that it wasn't, especially given the emphasis :) What's the point? We started with Scheme and moved to ECMAScript. Now XSLT is proposed as a flow description language. What's next? Prolog? oh, no, wait, what about Postscript? no, maybe you like Logo more? They are all turing-complete languages after all, aren't they? ;-) [i'm just kidding, don't take this as an insult, ok? just kidding] -- Stefano Mazzocchi [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/generation AbstractServerPage.java
sylvain 2002/12/03 14:10:57
Modified:src/java/org/apache/cocoon/generation Tag:
cocoon_2_0_3_branch AbstractServerPage.java
Log:
Fix a bug that prevents automatic recompilation of dynamically-generated XSPs
Revision ChangesPath
No revision
No revision
1.8.2.2 +2 -2
xml-cocoon2/src/java/org/apache/cocoon/generation/AbstractServerPage.java
Index: AbstractServerPage.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/generation/AbstractServerPage.java,v
retrieving revision 1.8.2.1
retrieving revision 1.8.2.2
diff -u -r1.8.2.1 -r1.8.2.2
--- AbstractServerPage.java 11 Sep 2002 12:43:58 - 1.8.2.1
+++ AbstractServerPage.java 3 Dec 2002 22:10:57 - 1.8.2.2
@@ -108,7 +108,7 @@
* since it was created
*/
public boolean modifiedSince(long date) {
-if (dateCreated date) {
+if (date == 0 || dateCreated date) {
return true;
}
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/generation AbstractServerPage.java
sylvain 2002/12/03 14:11:26
Modified:src/java/org/apache/cocoon/generation
AbstractServerPage.java
Log:
Fix a bug that prevents automatic recompilation of dynamically-generated XSPs
Revision ChangesPath
1.11 +2 -2
xml-cocoon2/src/java/org/apache/cocoon/generation/AbstractServerPage.java
Index: AbstractServerPage.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/generation/AbstractServerPage.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- AbstractServerPage.java 11 Sep 2002 12:44:09 - 1.10
+++ AbstractServerPage.java 3 Dec 2002 22:11:26 - 1.11
@@ -111,7 +111,7 @@
* since it was created
*/
public boolean modifiedSince(long date) {
-if (dateCreated date) {
+if (date == 0 || dateCreated date) {
return true;
}
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SHOWSTOPPER] Regression test fails
Vadim Gritsenko wrote:
Hi all,
I found out several failures on the following regression tests:
1) http://localhost:8080/cocoon/sub/xsp-dynamic test does not go
through anymore: XSP generation date never changes (same for
http://localhost:8080/cocoon/sub/all-dynamic)
I introduced this change while solving a bug in the XSP engine (see
http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg21575.html). In
ProgramGeneratorImpl, the XSP was *always* recompiled if it's source's
getLastModified() returns zero (SitemapSource always returns zero).
This is very constraining in a production environment, so I removed this
check in ProgramGeneratorImpl and let the decision be taken by the XSP's
modifiedSince() method which can be overriden in an xsp:logic
I just updated AbstractServerPage to add the zero-check in the default
implementation of modifiedSince().
Bug fixed !
2) When XSP is generated from cocoon:/sub/xsp-source, file is wrongly
created in
...\jakarta-tomcat-4.1.16\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\cocoon_\_\sub\xsp_source.java
instead of
...\jakarta-tomcat-4.1.16\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\sub\xsp_source.java
It seems to me this is the correct behaviour, since the XSP source is
obtained through a cocoon: source and not a file (see
IOUtils.normalizedFilename)
3) When root sitemap is generated from the sitemap.xmap file, Java
source file is wrongly created in
...\jakarta-tomcat-4.1.16\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\file_\C_\apache_bin\jakarta_tomcat_4_1_16\webapps\cocoon\sitemap_xmap.java
instead of
...\jakarta-tomcat-4.1.16\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\sitemap_xmap.java
?? works for me with tomcat 4.1.12
4) http://localhost:8080/cocoon/sub/generror does not reset content
anymore: it shows parts of generated page and error report. AFAIR, it
showed only error report in 2.0.3 release.
Same here, and no clue on that one (time to go to sleep...)
Seems that source resolving is broken in current 2.0.4-dev. Does
anybody have a clue?
Could this be related to TC 4.1.16 ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
[OT] RE: Flow wishlist :)
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] [snipidy snip] like Logo more? Ah, good old days, when things were simple, brings back fond memories. Thanks, Artur... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Flow wishlist :)
Stefano Mazzocchi wrote: We started with Scheme and moved to ECMAScript. Now XSLT is proposed as a flow description language. What's next? Prolog? oh, no, wait, what about Postscript? no, maybe you like Logo more? PostScript would be great! Sitemap in PostStript - I bet marketing and documentation departments would be all over that one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Flow wishlist :)
What's next? Prolog? oh, no, wait, what about Postscript? no, maybe you like Logo more? No No No! just XSL! :) I might be able to deal with Lego... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [SHOWSTOPPER] Regression test fails
Sylvain Wallez wrote: Vadim Gritsenko wrote: Hi all, I found out several failures on the following regression tests: 1) http://localhost:8080/cocoon/sub/xsp-dynamic test does not go through anymore: XSP generation date never changes (same for http://localhost:8080/cocoon/sub/all-dynamic) I introduced this change while solving a bug in the XSP engine (see http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg21575.html). In ProgramGeneratorImpl, the XSP was *always* recompiled if it's source's getLastModified() returns zero (SitemapSource always returns zero). This is very constraining in a production environment, so I removed this check in ProgramGeneratorImpl and let the decision be taken by the XSP's modifiedSince() method which can be overriden in an xsp:logic I just updated AbstractServerPage to add the zero-check in the default implementation of modifiedSince(). Bug fixed ! Great! 2) When XSP is generated from cocoon:/sub/xsp-source, file is wrongly created in ...\jakarta-tomcat-4.1.16\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\cocoon_\_\sub\xsp_source.java instead of ...\jakarta-tomcat-4.1.16\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\sub\xsp_source.java It seems to me this is the correct behaviour, since the XSP source is obtained through a cocoon: source and not a file (see IOUtils.normalizedFilename) Hm... Have to check against 2.0.3... 3) When root sitemap is generated from the sitemap.xmap file, Java source file is wrongly created in ...\jakarta-tomcat-4.1.16\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\file_\C_\apache_bin\jakarta_tomcat_4_1_16\webapps\cocoon\sitemap_xmap.java instead of ...\jakarta-tomcat-4.1.16\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\sitemap_xmap.java ?? works for me with tomcat 4.1.12 Doesn't work with 4.0.6: ...\jakarta-tomcat-4.0.6\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\file_\C_\apache_bin\jakarta_tomcat_4_0_6\webapps\cocoon\sitemap_xmap.java :( 4) http://localhost:8080/cocoon/sub/generror does not reset content anymore: it shows parts of generated page and error report. AFAIR, it showed only error report in 2.0.3 release. Same here, and no clue on that one (time to go to sleep...) Seems that source resolving is broken in current 2.0.4-dev. Does anybody have a clue? Could this be related to TC 4.1.16 ? See above - same error (3) with TC 4.0.6. My env is: WinXP, JDK 1.3.1. Vadim Sylvain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Flow wishlist :)
I'm not sure that this would hit the core? It looks to me more like a resource that wants to call other resources. I plug this new thing into the sitemap, it take over for a transformer at some point, then it calls other resources as defined in the sitemap. Yeah, that's basically what cinclude does. No need to change anything if you follow that pattern. Cinclude keeps rearing it's head, we may explore it, but somehow I suspect there are deeper issues connected with what it does vs. what I want to do that just aren't quite apparent... snip/ Still, XSLT was *NOT* designed for those type of things and my gut feeling is that by twisting its model too much you might end up having something that uses the same XSLT syntax but is not XSLT anymore... so it might simply confuse people and appear as a 'golden-hammer' anti-pattern. I'd have to disagree. I think XSLT was designed precisely for this purpose: sort through some data and determine what data should be created as a result. Hmmm, sure. but that is only a very small part of what flow-management is about. How would you keep the state across requests in XSLT? Same way you would in any other web app That's partially why I've got aggregation of the session, request and other context data feeding this thing. Ah, we are coming back to the XPathSelector!!! map:select type=xpath map:when test=count(data/*) = 0 map:transform src=error.xsl/ /map:when ... /map:select This was proposed a while ago but was voted down since the sitemap routing components shouldn't have a way to access the content of the pipeline. But sitemap components already have ways to access the content of the pipeline, it's just that currently you have to expose those contents as parameters... Selectors, matchers and actions have no way to get the content of a pipeline (by design!) Well if they don't your solution of having a generator create a parameter for choosing between the count=1 vs. count1 transforms wouldn't work... They may not have access directly, but they have access? The use of XSLT is *clearly* overkill. What you are describing is *NOT* XSLT: even if it uses the same syntax, the semantics are totally different (in fact, you are mixing XSLT semantics with the sitemap semantics... this cannot possibly be easier to learn/use/maintain than just the sitemap semantics) That doesn't make sense: in that case you'd have to consider the production of HTML from XML via XSLT a mixing of HTML semantics with XSLT semantics? No, because that content is *passive*. Here, you are mixing xslt and sitemap which are both 'active' content, content that has server-side semantics and will not be passed passivly on. So, in fact, the complexity of sitemap+flowscript is repeated in XSLT+sitemap, just that your solution doesn't have a way to separate the two. I don't think I understand your distinction. Consider for example that instead of using XSLT I was proposing to use Haskell to write my flow control manager. Would you have the same objection? There's no difference between using XSLT+sitemap and using flowscript+sitemap they both separate things identically. The difference is that with flowscript I use callPage (or whatever) to get things back to the sitemap, with XSLT I use Cocoon:select (or whatever) to get things back to the sitemap. I think you see what I am proposing as part of sitemap, but I think, rather, that it is part of flow...??? NOTE: I've been proposing that the flowscript might be generated out of a cocoon pipeline. That implies that you might use whatever declerative markup you want to describe your rules (as people do in a workflow environment) and have a stylesheet transform it into flowscript. That would: 1) give you a way to keep the rules separated from the resources 2) still use a declarative view of your rule engine (your rules can even be extracted out of a database and cached since I don't think they change that often) 3) no need for custom sitemap transformation components this is how I would do it. Using XSLT as a pipeline componentization skeleton sounds golden-hammer all the way. Well that would meet our needs, but if a flowscript can be generated out of a pipeline what's the difference between using the output of that generator to control the flow and using the input directly to control the flow of the pipeline? It seems that we're simply skipping a step and making things more efficient (caching of course pretty well negates that argument)? snip on side tracked discussion about metadata in pipelines/ This, instead of mixing stuff in the pipeline, enforces separation and clean design. I'm still keeping the processing of the metadata separate from the pipeline. You have to call the new thing to access the metadata and the metadata is not exposed in the pipeline (as it would be with XPathSelector). Then I'm lost. Consider the flow manager a
ResourceReader and pdf
hi everybody
i had problems getting a pdf (as file) through the cocoon ResourceReader. on
the browser side always a message box appeared with the text The file is
damaged and could not be repaired..
after i inserted the method shouldSetContentLength into ResourceReader
(overriding AbstractReader method) ...
/**
* Test if the component wants to set the content length
*/
public boolean shouldSetContentLength() {
return true;
}
... everything worked fine. the problem was, that in AbstractReader the
method returns false.
is this fix totally wrong ?
greetings,
lars
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
