Re: Java Language Advocacy (was Re: How ASF membership works and what it means)
On Sat, 28 Jun 2003, Nicola Ken Barozzi wrote: Christopher Oliver wrote, On 28/06/2003 19.19: Nicola Ken Barozzi wrote: ... I'm really confused about this SWT thing. On my computer Eclipse feels slower than JBuilder. And I still have to understand what makes SWT so compelling and AWT so dreaded. Check out JGoodies' fake eclipse LF using swing: http://www.jgoodies.com/freeware/metamorphosis/index.html JGoodies is now open source on java.net. Yeah, I know, thanks anyway. The fact is that SWT is crap. Total crap. Ok, now what do we say? ;-) In reality, SWT is just a better AWT, that had been stopped because of consistency of user interfaces between systems and widget customization. If I want to make my widget in Swing it's sooo easy, and I get the same interface on all systems. I remember the bad days of AWT in this regard. No, Swing sucks because of how it's implemented underneath. If you look at the editor code, it's full of events going round like mad, and objects being created in abundance. For example, here is a system that uses OpenGL to make Swing faster. As you can see it's better, but not an order of magnitude as many think it may be: http://www.lri.fr/~fekete/agile2d/ Just because SWT *may* feel better on some systems doesn't mean that it's the answer. The single biggest difference between so-so and really great Swing apps is about the way developers handle threading issues. Swing is single threaded, and so we see apps that keep blocking. I programmed AWT/Swing applications a lot in the past. I agree with you that Swing programming is far more easier than SWT. But the thing of Swing that brothers me most is that Swing application doesn't match the lookfeel on other systems than Windows. In a Gnome/GTK environment Swing looks really ugly. Yes, I know JGoodies too, but I want that my applications adapts the lookfeel of the system. In this sense, Swing doesn't have a change. I know that Sun support GTK themes in the last JDK, but only an emulation of image themes not native ones. And that's only because Sun want to use Gnome 2.x for their workstations. _This_ is really crap. My 2 cents, Stephan.
DO NOT REPLY [Bug 21177] New: - a crash in the name() function of the xslt, when using SQL transformer
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=21177.
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=21177
a crash in the name() function of the xslt, when using SQL transformer
Summary: a crash in the name() function of the xslt, when using
SQL transformer
Product: Cocoon 2
Version: 2.1m2
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: Other
Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
- when using sqltransformer, if on the pipeline the next transformer is standard
xslt, you can not use name() or local-name() functions for guessing the names of
the attributes of SQL namespaced elements. (rowset, by example). it throws al
ava.lang.indexOutofBounds exception. It only happens when you use it on
attributes:
xsl:for-each select=@*
xsl:attribute name={name()}blabla/xsl:attribute
/xsl:for-each
but xsl:for-each select=@sql:*
xsl:attrbute name={name()}sdfsdf/xsl:attribute
/xsl:for-each
works fine.
I think it only happes the firts time you enter a sql-namespaced element in
applying the templates.
In cocoon2.0.4 this used to work fine.
the stacktrace:
java.lang.ArrayIndexOutOfBoundsException: 7 = 1
at java.util.Vector.elementAt(Vector.java:427)
at org.apache.xml.dtm.ref.DTMStringPool.indexToString(DTMStringPool.java:137)
at org.apache.xml.dtm.ref.sax2dtm.SAX2DTM2.getNodeName(SAX2DTM2.java:2770)
at org.apache.xalan.xsltc.dom.SAXImpl.getNodeName(SAXImpl.java:1016)
at org.apache.xalan.xsltc.dom.DOMAdapter.getNodeName(DOMAdapter.java:282)
at cleanc.applyTemplates()
at cleanc.applyTemplates()
at cleanc.applyTemplates()
at cleanc.transform()
at org.apache.xalan.xsltc.runtime.AbstractTranslet.transform(AbstractTranslet.
java:533)
the stylesheet:
xsl:template match=/
xsl:apply-templates select=block/
/xsl:template
xsl:template match=block
xsl:copy
xsl:for-each select=@*
xsl:attribute name={name()}
xsl:value-of select=./
/xsl:attribute
/xsl:for-each
xsl:apply-templates select=sql:rowset/
/xsl:copy
/xsl:template
xsl:template match=sql:rowset
xsl:copy
xsl:for-each select=@*
xsl:value-of select=local-name()/
/xsl:for-each
/xsl:copy
/xsl:template
this stylesheet is applied after a standard SQLTransformation.
and it crashes on local-name().
cvs commit: cocoon-2.1/src/documentation/xdocs/howto howto-html-pdf-publishing.xml
bdelacretaz2003/06/30 02:36:41 Modified:src/documentation/xdocs/howto howto-html-pdf-publishing.xml Log: updated for Cocoon 2.1, mount subdirectory not needed anymore Revision ChangesPath 1.2 +38 -36 cocoon-2.1/src/documentation/xdocs/howto/howto-html-pdf-publishing.xml Index: howto-html-pdf-publishing.xml === RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/howto/howto-html-pdf-publishing.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- howto-html-pdf-publishing.xml 9 Mar 2003 00:07:58 - 1.1 +++ howto-html-pdf-publishing.xml 30 Jun 2003 09:36:41 - 1.2 @@ -16,12 +16,15 @@ This How-To shows you how to publish XML documents in HTML and PDF using Cocoon. It requires no prior knowledge of Cocoon, XSLT or XSL-FO. /p +p +It has been updated for Cocoon 2.1, which does not require the use of the emmount/em directory anymore. +/p /s1 s1 title=Purpose p You will learn how to build a simple pipeline that converts XML documents on-the-fly to HTML or PDF using simple -XSLT transforms. This is similar to the codehello.html/code and codehello.pdf/code samples of the standard Cocoon installation. However, this How-To teaches you how to build these mechanisms yourself. Thus, you will get a better feel of how Cocoon publishing really works. +XSLT transforms. This is similar to the codehello.html/code and codehello.pdf/code samples of the standard Cocoon installation. However, this How-To teaches you how to build these mechanisms yourself. Thus, you will get a better feel of how Cocoon publishing really works. /p /s1 @@ -35,21 +38,23 @@ pHere's what you need:/p ul -liCocoon must be running on your system. The steps below have been tested with Cocoon 2.0.2-dev, but they should work with any 2.x version./li -liThis document assumes a standard installation where -codehttp://localhost:8080/cocoon/mount//code points to -the codemount/code subdirectory of the Cocoon installation. Calling this URL should display a page -titled Directory Listing of mount. -br / +liCocoon must be running on your system. The steps below have been tested with Cocoon 2.1m3-dev, but they should work with any 2.1 version./li +liThis document assumes a standard installation where Cocoon is started by the emcocoon.sh/em (or cocoon.bat) script and where +codehttp://localhost://code points to the emWelcome to Apache Cocoon/em page. +br / If your installation runs on a different URL, you will have to adjust the URLs provided throughout this How-To as necessary. /li -liYou must be able to create and edit XML files in the codemount/code subdirectory of the Cocoon installation. -In a standard installation, this is codewebapps/cocoon/mount/code under the directory of the Tomcat installation. +liYou must be able to create and edit XML files in the main directory of the Cocoon installation. +When started from cocoon.sh, this directory is codebuild/webapp/code under the directory that contains cocoon.sh. /li /ul noteYou will not need a fancy XML editor for this How-To. Copying and pasting the sample code snippets into any text editor will do./note +note +Running build clean deletes everything under build/webapp, make sure to save your example files if you +need to do a clean build. + /note /s1 @@ -58,13 +63,15 @@ Here's how to proceed. /p -s2 title=1. Create the work directory under mount +s2 title=1. Create the work directory p -Under codewebapps/cocoon/mount/code, create a new directory and name it codehtml-pdf/code. +Under codebuild/webapp/code, create a new directory and name it codehtml-pdf/code. All files used by this How-To will reside in this directory. /p p -After a browser refresh, codehttp://localhost:8080/cocoon/mount//code should display the name of this new directory, among others. +At this point, codehttp://localhost:/html-pdf//code should display an error page saying emResource not found/em, +indicating that the file embuild/webapp/html-pdf/sitemap.xmap/em was not found. This is normal, as the newly +created directory does not yet contain the required sitemap file. /p /s2 @@ -179,27 +186,18 @@ ?xml version=1.0 encoding=iso-8859-1? map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0; -!-- use the standard components -- -map:components -map:generators default=file/ -map:transformers default=xslt/ -map:readers default=resource/ -map:serializers default=html/ -map:selectors default=browser/ -map:matchers default=wildcard/ -/map:components - +!-- define the Cocoon processing pipelines -- map:pipelines map:pipeline -
DO NOT REPLY [Bug 21177] - a crash in the name() function of the xslt, when using SQL transformer
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=21177. 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=21177 a crash in the name() function of the xslt, when using SQL transformer --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 10:47 --- Could this be the same as bug 19770 ? If not, could you try to reproduce this bug outside Cocoon and file it as a XSLTC bug? Using Xalan instead of XSLTC should also help.
portal-fw: coplet configuration with XSP
Dear all,
I'm currently playing around with the portal framework (2.1 M2, jdk
1.3.1, resin 2.0.4). I'm trying to create a configurable coplet. Because
the basis for the configuration is dynamic, I want the configuration to
be created by an XSP instead of a static XML. However, I get really
weird results. Most often it does not work, because I get
NullPointerExceptions (from different places, e.g.
org.apache.cocoon.environment.AbstractEnvironment, line 511), or the
portal simply refuses to show the content of the coplet and keeps
showing the configuration (but no errors in the logs). But what's really
frustrating: sometimes it works. I have been trying for the last couple
of hours to create an easy example for this list that never works, but
it seems impossible.
Anyway, this shows basically what I'm trying to do:
?xml version=1.0 encoding=ISO-8859-1?
xsp:page language=java xmlns:xsp=http://apache.org/xsp;
xmlns:session=http://apache.org/cocoon/session/1.0;
page
session:form name=coplettest method=POST
session:action
session:getxml context=portal path=/configuration/uri/
/session:action
session:content
xsp:logic
for(int i=1; i lt; 4; i++)
{
xsp:content
session:inputxml context=portal type=text
xsp:attribute
name=path/coplet-data/valuexsp:expri/xsp:expr/xsp:attribute
xsp:attribute
name=nameValuexsp:expri/xsp:expr/xsp:attribute
/session:inputxml
/xsp:content
}
/xsp:logic
/session:content
input type=submit value=Change/
/session:form
/page
/xsp:page
This is the pipeline:
map:generate type=serverpages
src=resources/auth/copletconfig-test.xsp/
map:transform type=session/
map:transform src=styles/config2html.xsl/
map:serialize type=xml/
This didn't work half an hour ago, now it works... right, I'm just back
from lunch, now it doesn't work anymore.
I tried it with Cocoon 2.0.4 and ran into the same problems (no
NullPointerException yet, but also the refusal to show the content after
doing the configuration).
Any ideas? Are there any known problems with configuring coplets via
XSP? To me, this smells like a race condition, but I have no idea how to
pinpoint it.
Cheers,
Holger
--
Holger Dewes
extending the Request object!?
Hi group, I often need to manipulate the queryString from the Request, so that I can use the manipulated one in links. Manipulate the String object is ugly and error prone. What do you think about extending the Request object, so that we can 1) delete Request Parameter 2) add Request Parameter 3) get Request Parameter by substring I think about creating a Map from the ServletRequest, the Map-key is the Parameter name and the values are stored in a Vector: name1 - Vector(param1a, param1b, ...) name2 - Vector(param2a, param2b, ...) All methods for the Request object than have to be rewritten to use this Map. Is this a practicable way or do we have such functionallity somewhere? BTW, what is a MultiPartRequest? Michael
RE: extending the Request object!?
-Original Message- From: Enke, Michael [mailto:[EMAIL PROTECTED] Sent: Monday 30 June 2003 14:12 To: [EMAIL PROTECTED] Subject: extending the Request object!? Hi group, I often need to manipulate the queryString from the Request, so that I can use the manipulated one in links. Manipulate the String object is ugly and error prone. What do you think about extending the Request object, so that we can 1) delete Request Parameter 2) add Request Parameter 3) get Request Parameter by substring I think about creating a Map from the ServletRequest, the Map-key is the Parameter name and the values are stored in a Vector: name1 - Vector(param1a, param1b, ...) name2 - Vector(param2a, param2b, ...) All methods for the Request object than have to be rewritten to use this Map. Is this a practicable way or do we have such functionallity somewhere? Does it not make more sense to put this functionality into a specialised utility class for manipulating a request query string - SOC and all that... BTW, what is a MultiPartRequest? A special implementation of Request to decode and provide access to MIME-multipart encoded submissions (required for posting files to the server). Michael Any e-mail message from the European Central Bank (ECB) is sent in good faith but shall neither be binding nor construed as constituting a commitment by the ECB except where provided for in a written agreement. This e-mail is intended only for the use of the recipient(s) named above. Any unauthorised disclosure, use or dissemination, either in whole or in part, is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and delete this e-mail from your system.
Re: extending the Request object!?
Geissel, Adrian wrote: -Original Message- From: Enke, Michael [mailto:[EMAIL PROTECTED] Sent: Monday 30 June 2003 14:12 To: [EMAIL PROTECTED] Subject: extending the Request object!? Hi group, I often need to manipulate the queryString from the Request, so that I can use the manipulated one in links. Manipulate the String object is ugly and error prone. What do you think about extending the Request object, so that we can 1) delete Request Parameter 2) add Request Parameter 3) get Request Parameter by substring I think about creating a Map from the ServletRequest, the Map-key is the Parameter name and the values are stored in a Vector: name1 - Vector(param1a, param1b, ...) name2 - Vector(param2a, param2b, ...) All methods for the Request object than have to be rewritten to use this Map. Is this a practicable way or do we have such functionallity somewhere? Does it not make more sense to put this functionality into a specialised utility class for manipulating a request query string - SOC and all that... But the Request object is used nearly everywhere in cocoon. And with the extended Request we have nothing to change, only call the new methods on the same object. BTW, what is a MultiPartRequest? A special implementation of Request to decode and provide access to MIME-multipart encoded submissions (required for posting files to the server). Michael Any e-mail message from the European Central Bank (ECB) is sent in good faith but shall neither be binding nor construed as constituting a commitment by the ECB except where provided for in a written agreement. This e-mail is intended only for the use of the recipient(s) named above. Any unauthorised disclosure, use or dissemination, either in whole or in part, is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and delete this e-mail from your system.
Re: Java Language Advocacy (was Re: How ASF membership works and what it means)
snip I have used Swing quite a lot, and as you know I even gave a shot at making a WYSIWYG editor for XML. I had to debug the Editor. Which xml namespaces were you trying to do this for? xhtml, svg, mathml? I've tried numerous times to extend the javax.swing.text.*.* packages and had difficulties with replacing dtd's and applying schemas, etc. Is there any good open source endeavor in the area of editing XML? I like Bruno's pollo for the namespaces it is designed for. What I would like to see is a good client WYSIWYG editing system that works thru Cocoon services for multiple authors(with permissions and say corporate associations) from different parts of the world. Have it work the xml documents like CVS does source code. And please don't point out anything with zilla on the end. -Roger From this experience, AFAIK, Swing's problems are not speed. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
cvs commit: cocoon-2.1/src/documentation/xdocs/installing updating.xml
cziegeler2003/06/30 05:59:26 Modified:src/documentation/xdocs/installing updating.xml Log: Enhancing update doc Revision ChangesPath 1.11 +71 -60cocoon-2.1/src/documentation/xdocs/installing/updating.xml Index: updating.xml === RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/installing/updating.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- updating.xml 21 Jun 2003 05:24:55 - 1.10 +++ updating.xml 30 Jun 2003 12:59:26 - 1.11 @@ -15,26 +15,83 @@ s1 title=Updating Cocoon pPlease take your time to read this document completely before trying to upgrade from - a Cocoon 2.0.x version to 2.1 (or above)./p + a Cocoon 2.0.x installation to 2.1 (or above)./p p This is a brief discussion of the changes between the latest official release @released.version@ and the current development version of Apache Cocoon. You only need this information if you are updating an existing Cocoon installation, or if you want to know what is going on in the development of Cocoon. /p - p - The Cocoon team has developed many Avalon components which are not specific to Cocoon and have - been donated to the Avalon Excalibur project and moved out - of Cocoon. This has led to some configuration changes which are described - in this document. + pThe Cocoon team took great care in making this new version as compatible as +possible. However in order to achieve even more flexibility, usability and +performance, the internal architecure of Cocoon has been improved. Due to these +improvements it has not been possible to be compatible in every little detail. +But if you follow this document closely and follow the instructions listed here, +you should have running an upgraded version very quickly. /p p -The internal architecture of cocoon has also been improved to give more flexibility, usability and performance. + The Cocoon team has developed many Avalon components that are not specific to Cocoon + and therefore have been donated to the Avalon Excalibur project and moved out + of Cocoon. This has led to some configuration changes which are also described + in this document. /p /s1 s1 title=Sitemap pThere are some changes in the sitemap and in the configuration of some components in the sitemap./p + s2 title=Pipelines configuration in the sitemap + p + The configuration of the pipelines has moved from cocoon.xconf to the sitemap. + To update your installation, you have to remove the event-pipeline and stream-pipeline section + from your cocoon.xconf and add the codemap:pipes/code section to the codemap:components/code section + of your sitemap. You can find the pipelines components definition in the sample + main sitemap of Cocoon. Here is an example: + /p + source![CDATA[ +map:sitemap + map:components + ... + map:pipes default=caching + map:pipe name=caching +src=org.apache.cocoon.components.pipeline.impl.CachingProcessingPipeline/ + map:pipe name=noncaching +src=org.apache.cocoon.components.pipeline.impl.NonCachingProcessingPipeline/ + /map:pipes + /map:components + ... +/map:sitemap + ]]/source + pYou can choose these different pipeline implementations + in the codemap:pipeline/code section by specifying their codetype/code attribute: + /p + source![CDATA[ +map:sitemap + ... + map:pipelines + map:pipeline type=noncaching + map:match pattern=welcome + ... + /map:match +.. + /map:pipeline + /map:pipelines +/map:sitemap + ]]/source + pThis is similar to choosing the type of a generator or any other sitemap + component. If the type attribute is omitted, the default configuration from the codemap:components/code + section is used. + /p + pThe SAXConnectors have been removed, so if you upgrade manually you have to remove +the emsax-connectors/em configuration from emcocoon.xconf/em./p + pSo it's not that bad, despite incompatible changes in the Cocoon code there is + little to do to update your Cocoon installation./p +/s2 + s2 title=Individual configuration of pipelines +pThe sitemap now provides individual configuration of codemap:pipeline/code sections. + You can now define one pipeline using caching, another one not using + caching at all and a third one using a different caching implementation, for example. +/p + /s2 s2 title=FOP Serializer pRelative paths in FOP serializer's lt;user-configgt; are now resolved relatively to the directory that contains the
cvs commit: cocoon-2.1/src/documentation/xdocs/installing updating.xml
cziegeler2003/06/30 06:17:43 Modified:src/documentation/xdocs/installing updating.xml Log: Enhancing update doc Revision ChangesPath 1.12 +7 -1 cocoon-2.1/src/documentation/xdocs/installing/updating.xml Index: updating.xml === RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/installing/updating.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- updating.xml 30 Jun 2003 12:59:26 - 1.11 +++ updating.xml 30 Jun 2003 13:17:43 - 1.12 @@ -203,7 +203,13 @@ s2 title=Stores pThe Store and StoreJanitor components and implementations have been moved to Avalon Excalibur./p -pTODO:Changes in cocoon.xconf.../p +pTo make upgrading easier, the class attributes of the store janitor + component has been removed in the emcocoon.xconf/em as the class names have changed. + The emcache-transient/em and emcache-persistent/em components do + not exists anymore, so remove any reference from the cocoon.xconf. Instead + the empersistent-store/em and emtransient-store/em components + fulfil their tasks. +/p pIn general the package names changed from emorg.apache.cocoon.components.store/em to emorg.apache.excalibur.store/em (and emorg.apache.excalibur.store.impl/em). So if you have custom java code using these components, you have to change
cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/formmodel Form.java
bruno 2003/06/30 06:25:28
Modified:src/blocks/woody/java/org/apache/cocoon/woody
FormContext.java
src/blocks/woody/java/org/apache/cocoon/woody/acting
HandleFormSubmitAction.java
src/blocks/woody/java/org/apache/cocoon/woody/formmodel
Form.java
Log:
Make the FormHandler a property of the Form rather than the FormContext.
Revision ChangesPath
1.2 +1 -11
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/FormContext.java
Index: FormContext.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/FormContext.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- FormContext.java 14 May 2003 11:33:37 - 1.1
+++ FormContext.java 30 Jun 2003 13:25:28 - 1.2
@@ -62,17 +62,11 @@
private Request request;
private Locale locale;
private ActionEvent actionEvent;
-private FormHandler formHandler;
private boolean doValidation;
public FormContext(Request request, Locale locale) {
-this(request, locale, null);
-}
-
-public FormContext(Request request, Locale locale, FormHandler formHandler) {
this.request = request;
-this.locale = locale;
-this.formHandler = formHandler;
+this.locale = locale;;
doValidation = true;
}
@@ -107,9 +101,5 @@
public boolean doValidation() {
return doValidation;
-}
-
-public FormHandler getFormHandler() {
-return formHandler;
}
}
1.4 +2 -5
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/acting/HandleFormSubmitAction.java
Index: HandleFormSubmitAction.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/acting/HandleFormSubmitAction.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- HandleFormSubmitAction.java 14 May 2003 11:33:38 - 1.3
+++ HandleFormSubmitAction.java 30 Jun 2003 13:25:28 - 1.4
@@ -96,13 +96,10 @@
Class clazz = Class.forName(formHandlerClassName);
formHandler = (FormHandler)clazz.newInstance();
formHandler.setup(form);
+form.setFormHandler(formHandler);
}
-FormContext formContext;
-if (formHandler == null)
-formContext = new FormContext(request, Locale.US);
-else
-formContext = new FormContext(request, Locale.US, formHandler);
+FormContext formContext = new FormContext(request, Locale.US);
boolean finished = form.process(formContext);
request.setAttribute(formAttribute, form);
1.4 +8 -2
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/formmodel/Form.java
Index: Form.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/formmodel/Form.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Form.java 14 May 2003 11:45:44 - 1.3
+++ Form.java 30 Jun 2003 13:25:28 - 1.4
@@ -52,6 +52,7 @@
import org.apache.cocoon.woody.Constants;
import org.apache.cocoon.woody.FormContext;
+import org.apache.cocoon.woody.FormHandler;
import org.apache.cocoon.xml.AttributesImpl;
import org.xml.sax.ContentHandler;
import org.xml.sax.SAXException;
@@ -66,6 +67,7 @@
private List widgets;
private Map widgetsById;
private FormDefinition definition;
+private FormHandler formHandler;
public Form(FormDefinition definition) {
widgets = new ArrayList();
@@ -79,6 +81,10 @@
widgetsById.put(widget.getId(), widget);
}
+public void setFormHandler(FormHandler formHandler) {
+this.formHandler = formHandler;
+}
+
/**
* Processes a form submit. This consists of multiple steps:
* ul
@@ -94,8 +100,8 @@
*/
public boolean process(FormContext formContext) {
readFromRequest(formContext);
-if (formContext.getActionEvent() != null formContext.getFormHandler() !=
null) {
-
formContext.getFormHandler().handleActionEvent(formContext.getActionEvent());
+if (formContext.getActionEvent() != null formHandler != null) {
+formHandler.handleActionEvent(formContext.getActionEvent());
}
if (formContext.doValidation())
return validate(formContext);
Re: Java Language Advocacy (was Re: How ASF membership works and what it means)
Roger I Martin PhD wrote, On 30/06/2003 14.57: snip I have used Swing quite a lot, and as you know I even gave a shot at making a WYSIWYG editor for XML. I had to debug the Editor. Which xml namespaces were you trying to do this for? xhtml, svg, mathml? DocumentDTD, basically like xhtml I've tried numerous times to extend the javax.swing.text.*.* packages and had difficulties with replacing dtd's and applying schemas, etc. I rewrote all the underlying Document stuff to wrap XML DOM, and all the view mappings. It was really hard to debug. It works, but it's still buggy. Is there any good open source endeavor in the area of editing XML? I like Bruno's pollo for the namespaces it is designed for. What I would like to see is a good client WYSIWYG editing system that works thru Cocoon services for multiple authors(with permissions and say corporate associations) from different parts of the world. Have it work the xml documents like CVS does source code. And please don't point out anything with zilla on the end. Lenya http://cocoon.apache.org/lenya/ is a CMS that can work on it. And as for editing, OpenOffice 1.1 has xml filters, and can output in XHTML. My Java implementation is still around, if you have time, just ask me. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: NullPointerException in JXFormsGenerator
Title: Re: NullPointerException in JXFormsGenerator Chris I checked out the code and that same NULL_LOCATOR problem exists around line 824 in the characters method. I fixed that on my local copy and the transformer works as planned. Thanks, Jon
cvs commit: cocoon-2.1/src/documentation/xdocs who.xml
reinhard2003/06/30 06:59:41 Modified:src/documentation/xdocs who.xml Log: First commit ;-) Revision ChangesPath 1.6 +1 -0 cocoon-2.1/src/documentation/xdocs/who.xml Index: who.xml === RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/who.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- who.xml 18 May 2003 10:54:21 - 1.5 +++ who.xml 30 Jun 2003 13:59:40 - 1.6 @@ -59,6 +59,7 @@ liChristopher Oliver (coliver.at.apache.org)/li liGiacomo Pati (giacomo.at.apache.org)/li liKonstantin Piroumian (kpiroumian.at.apache.org)/li + liReinhard P#246;tz(reinhard.at.apache.org)/li liOvidiu Predescu (ovidiu.at.apache.org)/li liJeremy Quinn (jeremy.at.apache.org)/li liGianugo Rabellino (gianugo.at.apache.org)/li
Re: cvs commit: cocoon-2.1/src/documentation/xdocs who.xml
On 30/06/2003 15:59 [EMAIL PROTECTED] wrote: reinhard2003/06/30 06:59:41 Modified:src/documentation/xdocs who.xml Log: First commit ;-) Welcome! /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Introduction Reinhard Pötz
I'm really moved by the vote and I want to thank you for the confidence. I'm 25 years old and live in Vienna, Austria. I studied business consultancy and graduated three years ago. Now I work as consultant for EFP Consulting Austria and as freelancer (Cocoon consulting and training). The first time I came in touch with Cocoon was during the JAX2001 (conference for Java, Apache, XML and WebServices) in Frankfurt. Used to use (released) commercial software I was impressed by the quality of open source *alpha* software (Cocoon was available in version 2.0alpha5). After this experience Michael Gerzabek and I started to build our first prototyp connecting Cocoon with SAP. This was also the hour of birth of Web3 which has been part of Cocoon 2.1dev since the beginning of this year. Web3 has also become the basis of some of our projects. On my Cocoon todo-list the top issue is finishing the flow (design implementation) and I hope this can be reached within the next two weeks. After this I want to spend some time on documentation espacially the flow. The next big thing on my list is finding/finshing/promoting a/the Cocoon form framworks that can compete against M$ webforms, JSF, Struts, ... Apart from Cocoon I'm on the way to become a Certified Transactional Analyst (this has nothing to do with IT as many people believe but more with psychology), like to read, play tennis and learn to dance (waltz, cha-cha, jive, ... ;-) Cheers, Reinhard
cvs commit: cocoon-2.1 announcement.xml
cziegeler2003/06/30 07:05:55 Modified:src/documentation/stylesheets announcement.xsl .announcement.xml Log: Fixing announcement target Revision ChangesPath 1.2 +1 -1 cocoon-2.1/src/documentation/stylesheets/announcement.xsl Index: announcement.xsl === RCS file: /home/cvs/cocoon-2.1/src/documentation/stylesheets/announcement.xsl,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- announcement.xsl 9 Mar 2003 00:07:30 - 1.1 +++ announcement.xsl 30 Jun 2003 14:05:55 - 1.2 @@ -6,6 +6,6 @@ xsl:template match=changes xsl:variable name=file select=@file/ xsl:variable name=version select=@version/ -xsl:apply-templates select=document($file)/changes/[EMAIL PROTECTED]($version)]/ +xsl:apply-templates select=document($file)/status/changes/[EMAIL PROTECTED]($version)]/ /xsl:template /xsl:stylesheet 1.3 +2 -2 cocoon-2.1/announcement.xml Index: announcement.xml === RCS file: /home/cvs/cocoon-2.1/announcement.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- announcement.xml 17 Mar 2003 00:47:42 - 1.2 +++ announcement.xml 30 Jun 2003 14:05:55 - 1.3 @@ -40,6 +40,6 @@ /p /body - changes version=@version@ file=changes.xml/ + changes version=@version@ file=status.xml/ /announcement
Re: Introduction Reinhard Pötz
Welcome, Reinhard! It's good to hear that you have energy and time to invest in the forms/flow department, having good examples and docs will be a major step forward IMHO. ...Apart from Cocoon I'm on the way to become a Certified Transactional Analyst. (this has nothing to do with IT as many people believe but more with psychology)... At first I though this was some (very) funny IT-related certification, but I know what you're talking of. I'm sure the Cocoon mailing lists must be a gold mine to study for Transactional Analysis ;-) -Bertrand
cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/formmodel AggregateField.java
bruno 2003/06/30 07:16:02
Modified:src/blocks/woody/java/org/apache/cocoon/woody/formmodel
AggregateField.java
Log:
Fixed getValue() method
Revision ChangesPath
1.3 +22 -5
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/formmodel/AggregateField.java
Index: AggregateField.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/formmodel/AggregateField.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- AggregateField.java 27 Jun 2003 13:01:46 - 1.2
+++ AggregateField.java 30 Jun 2003 14:16:02 - 1.3
@@ -88,7 +88,6 @@
private String enteredValue;
private List fields = new ArrayList();
private Map fieldsById = new HashMap();
-private boolean satisfiesSplitExpr = false;
private ValidationError validationError;
protected AggregateField(AggregateFieldDefinition definition) {
@@ -106,7 +105,6 @@
public void readFromRequest(FormContext formContext) {
enteredValue = formContext.getRequest().getParameter(getFullyQualifiedId());
-satisfiesSplitExpr = false;
validationError = null;
// whitespace empty field handling
@@ -133,7 +131,13 @@
// objects)
((Field)fieldsById.get(splitMapping.getFieldId())).setValue(result);
}
-satisfiesSplitExpr = true;
+} else {
+// set values of the fields to null
+Iterator fieldsIt = fields.iterator();
+while (fieldsIt.hasNext()) {
+Field field = (Field)fieldsIt.next();
+field.setValue(null);
+}
}
}
}
@@ -142,7 +146,7 @@
* Always returns a String for this widget (or null).
*/
public Object getValue() {
-if (satisfiesSplitExpr) {
+if (fieldsHaveValues()) {
String value;
try {
value = (String)definition.getCombineExpression().evaluate(new
ExpressionContextImpl(this, true));
@@ -157,6 +161,19 @@
}
}
+/**
+ * Returns true if their is at least one field which has a value.
+ */
+private boolean fieldsHaveValues() {
+Iterator fieldsIt = fields.iterator();
+while (fieldsIt.hasNext()) {
+Field field = (Field)fieldsIt.next();
+if (field.getValue() != null)
+return true;
+}
+return false;
+}
+
public boolean validate(FormContext formContext) {
// valid unless proven otherwise
validationError = null;
@@ -166,7 +183,7 @@
return false;
} else if (enteredValue == null)
return true;
-else if (!satisfiesSplitExpr) {
+else if (!fieldsHaveValues()) {
Object splitFailMessage = definition.getSplitFailMessage();
if (splitFailMessage != null)
validationError = new ValidationError(splitFailMessage);
cvs commit: cocoon-2.1/src/documentation/xdocs/installing updating.xml
bdelacretaz2003/06/30 07:23:57 Modified:src/documentation/xdocs/installing updating.xml Log: minor typos and style changes Revision ChangesPath 1.13 +10 -10cocoon-2.1/src/documentation/xdocs/installing/updating.xml Index: updating.xml === RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/installing/updating.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- updating.xml 30 Jun 2003 13:17:43 - 1.12 +++ updating.xml 30 Jun 2003 14:23:57 - 1.13 @@ -22,12 +22,13 @@ You only need this information if you are updating an existing Cocoon installation, or if you want to know what is going on in the development of Cocoon. /p - pThe Cocoon team took great care in making this new version as compatible as -possible. However in order to achieve even more flexibility, usability and + p +The Cocoon team took great care in making this new version as compatible as +possible. However, in order to achieve even more flexibility, usability and performance, the internal architecure of Cocoon has been improved. Due to these improvements it has not been possible to be compatible in every little detail. -But if you follow this document closely and follow the instructions listed here, -you should have running an upgraded version very quickly. +If you follow the instructions of document closely, however, +you should be able to quickly upgrade your Cocoon 2.0.x installation. /p p The Cocoon team has developed many Avalon components that are not specific to Cocoon @@ -131,8 +132,8 @@ pIn order to reflect the new version, the version information in the emcocoon.xconf/em has changed from em2.0/em to em2.1/em. /p -pWe suggest for updating the emcocoon.xconf/em to start with the new cocoon.xconf and - incorporate your changes instead of trying to migrate the old configuration file./p +pTo update emcocoon.xconf/em, we recommend that you start with the new cocoon.xconf from V2.1 and + incorporate your changes in it, instead of trying to migrate your old configuration file./p /s2 s2 title=Source Resolver pThe SourceResolver is now an Avalon component @@ -204,11 +205,10 @@ pThe Store and StoreJanitor components and implementations have been moved to Avalon Excalibur./p pTo make upgrading easier, the class attributes of the store janitor - component has been removed in the emcocoon.xconf/em as the class names have changed. + component have been removed in emcocoon.xconf/em as the class names have changed. The emcache-transient/em and emcache-persistent/em components do - not exists anymore, so remove any reference from the cocoon.xconf. Instead - the empersistent-store/em and emtransient-store/em components - fulfil their tasks. + not exist anymore, so any reference to them must be removed from cocoon.xconf. + Use the empersistent-store/em and emtransient-store/em components instead. /p pIn general the package names changed from emorg.apache.cocoon.components.store/em to emorg.apache.excalibur.store/em (and emorg.apache.excalibur.store.impl/em). So
cvs commit: cocoon-2.1/src/scratchpad/src/org/apache/cocoon/generation JXFormsGenerator.java
coliver 2003/06/30 07:27:49
Modified:src/scratchpad/src/org/apache/cocoon/generation
JXFormsGenerator.java
Log:
handle null locator in characters()
Revision ChangesPath
1.19 +5 -1
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/generation/JXFormsGenerator.java
Index: JXFormsGenerator.java
===
RCS file:
/home/cvs/cocoon-2.1/src/scratchpad/src/org/apache/cocoon/generation/JXFormsGenerator.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- JXFormsGenerator.java 29 Jun 2003 15:30:21 - 1.18
+++ JXFormsGenerator.java 30 Jun 2003 14:27:49 - 1.19
@@ -820,7 +820,11 @@
throws SAXException {
if (charBuf == null) {
charBuf = new StringBuffer();
-charLocation = new LocatorImpl(locator);
+if (locator != null) {
+charLocation = new LocatorImpl(locator);
+} else {
+charLocation = NULL_LOCATOR;
+}
}
charBuf.append(ch, start, length);
}
cvs commit: cocoon-2.1/tools/src blocks-build.xsl
cziegeler2003/06/30 07:28:29
Modified:tools/src blocks-build.xsl
Log:
Build system: show message when a block is excluded
Revision ChangesPath
1.25 +7 -1 cocoon-2.1/tools/src/blocks-build.xsl
Index: blocks-build.xsl
===
RCS file: /home/cvs/cocoon-2.1/tools/src/blocks-build.xsl,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- blocks-build.xsl 23 Jun 2003 18:11:41 - 1.24
+++ blocks-build.xsl 30 Jun 2003 14:28:29 - 1.25
@@ -133,11 +133,17 @@
xsl:template match=project
xsl:variable name=block-name
select=substring-after(@name,'cocoon-block-') /
+ target name=[EMAIL PROTECTED] if=exclude.block.{$block-name}
+ echo message=---/
+ echo message=ATTENTION: {$block-name} is excluded from the build./
+ echo message=---/
+ /target
+
target name=[EMAIL PROTECTED] unless=unless.exclude.block.{$block-name}/
target name=[EMAIL PROTECTED] unless=unless.exclude.block.{$block-name}
xsl:if test=depend
-xsl:attribute name=dependsxsl:value-of
select=@name/xsl:for-each
select=depend[contains(@project,'cocoon-block-')]xsl:text,/xsl:textxsl:value-of
select=@project/-compile/xsl:for-each/xsl:attribute
+xsl:attribute name=dependsxsl:value-of
select=@name/,xsl:value-of select=@name/-excludedxsl:for-each
select=depend[contains(@project,'cocoon-block-')]xsl:text,/xsl:textxsl:value-of
select=@project/-compile/xsl:for-each/xsl:attribute
/xsl:if
!-- Test if this block has special build --
cvs commit: cocoon-2.1 README.txt
cziegeler2003/06/30 07:33:16 Modified:.README.txt Log: Correcting minimal jdk version Revision ChangesPath 1.2 +1 -1 cocoon-2.1/README.txt Index: README.txt === RCS file: /home/cvs/cocoon-2.1/README.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- README.txt9 Mar 2003 00:01:31 - 1.1 +++ README.txt30 Jun 2003 14:33:16 - 1.2 @@ -41,7 +41,7 @@ Cocoon is implemented both as a Java servlet and a Java command line application. The following requirements exist for installing it: - o A Java 1.2 or later compatible virtual machine for your operating system. + o A Java 1.3 or later compatible virtual machine for your operating system. o Server API 2.2 compatible Servlet Engine. [optional for command line operation]
Re: cvs commit: cocoon-2.1 status.xml
On 29 Jun 2003 at 8:40, [EMAIL PROTECTED] wrote: ... Revert the previous revision. It is the concern of the stylesheets to show the release status. ... - release version=@version@ date=not yet released + release version=@version@ date=@date Should this be @[EMAIL PROTECTED] Regards, Upayavira
More on FOM
Hi friends, The following items reflect the discussions Stefano and I have had around the FOM: - The load(uri) global function should be supported. This is clearly needed for nested source file inclusion (which map:script does not support). - The cocoon.releaseComponent(component) method should be supported in conjunction with cocoon.getComponent(id). Further discussion is needed about whether the FOM implementation should automatically take care of releasing components. - There should be unrestricted access to all components via cocoon.getComponent(id). Among other goodies, this will give indirect access to Actions and Modules without providing explicit FOM support for them. Access to request input modules, in particular, should account for request.getURI(). - Access to continuation objects should be provided. var kont = sendPageAndWait(uri, data) This is deemed necessary as certain continuation usage patterns may call for explicit, programmatic invalidation of continuations. - Properties - id - Methods - getParent() - getChildren() - invalidate() - Events - onExpiration() What do you guys think? Ricardo
RE: More on FOM
Hi Ricardo, From: Ricardo Rocha [mailto:[EMAIL PROTECTED] Hi friends, The following items reflect the discussions Stefano and I have had around the FOM: - The load(uri) global function should be supported. This is clearly needed for nested source file inclusion (which map:script does not support). +1 - The cocoon.releaseComponent(component) method should be supported in conjunction with cocoon.getComponent(id). Further discussion is needed about whether the FOM implementation should automatically take care of releasing components. I'm with you that this part will need more investigation and use cases. But for now I'm fine without some automatism. So +1 too. - There should be unrestricted access to all components via cocoon.getComponent(id). I'll implement getComponent( id ) and releaseComponent( component) ASAP because the current flow implementation exposes the component manager and this leads to a serious bug! If you have more than one user the component manager can become null. This can be very annoying if you want to train some people ... Among other goodies, this will give indirect access to Actions and Modules without providing explicit FOM support for them. Access to request input modules, in particular, should account for request.getURI(). AFAIK many of them need the object model and this is not provided by the flow so I think you have no chance to use the actions and input modules which need objects of the object model. Am I right here? - Access to continuation objects should be provided. var kont = sendPageAndWait(uri, data) This is deemed necessary as certain continuation usage patterns may call for explicit, programmatic invalidation of continuations. - Properties - id - Methods - getParent() - getChildren() - invalidate() - Events - onExpiration() What do you guys think? sounds good. It should also be possible to create your own continuations objects without sending a page. See the JXForms implementation which needs this to provide previous/next-navigation. I'll add all those things to the proposal ASAP. Reinhard
Re: More on FOM
Ricardo Rocha wrote:
Hi friends,
The following items reflect the discussions Stefano and I have had
around the FOM:
- The load(uri) global function should be supported. This is clearly
needed for nested source file inclusion (which map:script does not
support).
- The cocoon.releaseComponent(component) method should be supported in
conjunction with cocoon.getComponent(id). Further discussion is needed
about whether the FOM implementation should automatically take care of
releasing components.
Hehe, I should go to Ecuador, as I advocated both ;-)
I suggested that components being heavyweight resource, allowing them to
cross continuation boundaries should be prohibited. Automatic release
doesn't seem a good solution to me, as it would mean that script
variables would hold released components, thus leading to unpredictable
behaviour (think about stateful pooled components). So my opinion is to
raise an error if there are some unreleased components when a
continuation is created. This will allow users to quickly learn the safe
practices related to component management in flow scripts.
- There should be unrestricted access to all components via
cocoon.getComponent(id).
Hehe again ;-)
Among other goodies, this will give indirect access to Actions and
Modules without providing explicit FOM support for them. Access to
request input modules, in particular, should account for
request.getURI().
Two remarks here :
- if we give access to request.getURI through an input module, then why
removing it from the request object ??
- modules need the object model and actions need it also, along with a
(Cocoon) resolver and a redirector. How will the flow be able to access
these objects to pass them to the components ?
IMO, the second point calls for some refactored interfaces since the
(Excalibur) resolver is now a regular component and we decided some time
ago to make the object model accessible through the Avalon context
(don't know if it has been implemented, though).
- Access to continuation objects should be provided.
var kont = sendPageAndWait(uri, data)
This is deemed necessary as certain continuation usage patterns may
call for explicit, programmatic invalidation of continuations.
- Properties
- id
- Methods
- getParent()
- getChildren()
- invalidate()
- Events
- onExpiration()
Sounds good.
What do you guys think?
Read inline !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: More on FOM
Reinhard Pötz wrote: - There should be unrestricted access to all components via cocoon.getComponent(id). I'll implement getComponent( id ) and releaseComponent( component) ASAP because the current flow implementation exposes the component manager and this leads to a serious bug! If you have more than one user the component manager can become null. This can be very annoying if you want to train some people ... Cool :-) Among other goodies, this will give indirect access to Actions and Modules without providing explicit FOM support for them. Access to request input modules, in particular, should account for request.getURI(). AFAIK many of them need the object model and this is not provided by the flow so I think you have no chance to use the actions and input modules which need objects of the object model. Am I right here? Yes, you are... :-( - Access to continuation objects should be provided. var kont = sendPageAndWait(uri, data) This is deemed necessary as certain continuation usage patterns may call for explicit, programmatic invalidation of continuations. - Properties - id - Methods - getParent() - getChildren() - invalidate() - Events - onExpiration() sounds good. It should also be possible to create your own continuations objects without sending a page. See the JXForms implementation which needs this to provide previous/next-navigation. Yes, creating continuations without sending pages is all-important. I'll add all those things to the proposal ASAP. Hey Reinhard, you're a committed committer, cool! Regards, Ricardo
RE: External/Event Based Cache Invalidation (somewhat long)
Geoff Howard wrote: From: Unico Hommes [mailto:[EMAIL PROTECTED] I can't believe I've missed this post. Damn. Below is the larger picture I envision for a new kind of cache invaliditation ... depending on other factors might never come. It seems to me more fitting with the transient nature of events to act on them when they arrive and then discard them. That would definitely be the way to go. Good - I'm getting closer to a system that can at least be tested using this method. ... Here are the issues the event aware CacheImpl would need to take care of: - during store() it gets the SourceValidity[] from the CachedResponse and looks for instanceof EventValidity (recursively for AggregatedValidity). - if found, it calls EventValidity.getEvent() and stores the key-event mapping. - expose a removeByEvent(Event e) method that can be called by the specific event-handling component. This could be a jms listener (as I've orginally envisioned it) or an http/soap based system (as in the ESI patch that was in bugzilla) or even a cocoon Action or Flow, or some combination of all of the above. I think this (though I've changed the method name to processEvent(Event e)) is the contract that needs to be exposed to the cache listening systems. Whether the first implementation I'm working on for how the events/cache keys are handled internally holds water over time remains to be seen, but the way I'm trying to go should leave this open to alternative implementations of the internals without changing this simple contract. OK. - When the key is ejected from the cache for other reasons (another pipeline component signalled invalid for example) I think it's necessary to at that moment remove the event-key mapping entry. This introduces a complication in the data structure used to store these mappings as I mention below. I also haven't looked into the effect of the store janitor - if it acts directly on the Store without going through the CacheImpl wrapper, that introduces a wrinkle. Hmm, that does seem to be the case. Well, I've thought this through more - if you are using persistent cache, then the store janitor simply moves items from the Memory store to the persistent store which should have no effect on the event tracking. If not using the persistent cache then there could be a problem - but I think that could be looked into later - I'd guess it's rare that people needing the event cache are going to use in-memory only caching. Just for my understanding. The way the cache and the event register can get out of synch is when not using persistent store, the storejanitor removes an item from the memory store, effectively removing it completely when the system is shut down. This is in fact the same situation as when someone should delete the persistent store manually. In these cases there may exist event-key mappings with non-existent keys. But why is that a problem? If an event is received that is mapped to non-existent keys, each of these non-existent keys is checked, if it exists then remove from cache otherwise ignore (and possibly remove the non-existent key-event mapping from the register). So? Most of the above is accounted for - except for the data structure to store the event-key mappings. As discussed above, it needs to: - allow duplicate keys (each event may uncache multiple pipelines, and each pipeline might be uncached by any of multiple events). So it needs a Bag. - allow lookup of mappings based on either event or key. Jakarta Commons Collections has a DoubleOrderedMap, but not a DoubleOrderedBag. Bummer. Ok, I was a little muddled here on the MultiMap/Bag distinction. At least as interpreted by the jakarta collections stuff, we need a DoubleOrderedMultiMap - which still doesn't exist. But I've got a solution nearly done on my hard drive not yet ready to commit even to scratchpad (but soon!) that uses two MultiMaps to create a de-facto DoubleOrderedMultiMap. I think only time and testing will tell if a more dedicated solution is needed. It occurred to me that since all we're storing is relatively light-weight Event's and PipelineCacheKeys, keeping two synced MultiMaps may be fine. There are some threading issues that need to get tested though. - be persistent across shutdown and startup, and needs to recover gracefully when the cache is missing (like when it's been manually deleted) Currently still unimplemented. If the double MultiMap solution turns out OK, it may be enough to serialize this out to disk - I think every thing should be serializable. Although the Event's are not yet explicitly so they are simple. - be efficient We'll see! I have made an assumption so far that I'd like tested by some sharp minds.
Re: More on FOM
Sylvain Wallez wrote: Ricardo Rocha wrote: The following items reflect the discussions Stefano and I have had around the FOM: - The load(uri) global function should be supported. This is clearly needed for nested source file inclusion (which map:script does not support). - The cocoon.releaseComponent(component) method should be supported in conjunction with cocoon.getComponent(id). Further discussion is needed about whether the FOM implementation should automatically take care of releasing components. Hehe, I should go to Ecuador, as I advocated both ;-) You're welcome anytime my friend! :-) I suggested that components being heavyweight resource, allowing them to cross continuation boundaries should be prohibited. Automatic release doesn't seem a good solution to me, as it would mean that script variables would hold released components, thus leading to unpredictable behaviour (think about stateful pooled components). So my opinion is to raise an error if there are some unreleased components when a continuation is created. This will allow users to quickly learn the safe practices related to component management in flow scripts. I see your point Sylvain. Your solution sounds somewhat draconian but it's probably the only safe bet... The question then becomes: does anyone envision real-world scenarios in which stateful components *are* needed across continuation boundaries? (if so, imo, it might imply curent Avalon component management isn't safe for continuations) Or can we *always* formulate our flow so that we don't need to keep component state across continuations? (for example, database connections can be acquired/released as needed precisely because they're pooled). On a separate thread, if *all* acquired components *must* be released prior to creating a continuation... wouldn't it make sense for the FOM implementation to automagically release them?? I know it may sound dangerous at first, but then again it would relieve developers from that tedious, anti-scripting release idiom... - There should be unrestricted access to all components via cocoon.getComponent(id). Hehe again ;-) Hahaha! There's nothing quite like the flavor of victory, is there? ;-) Among other goodies, this will give indirect access to Actions and Modules without providing explicit FOM support for them. Access to request input modules, in particular, should account for request.getURI(). Two remarks here : - if we give access to request.getURI through an input module, then why removing it from the request object ?? Until proven otherwise, I don't think getURI() is _needed_ by the flow, so the request object shouldn't expose it. Imo, the flow renders actions (and modules outside the sitemap) unnecessary, so we shouldn't encourage their continued use by providing FOM-level support for them. The idea, in the long term, is to stop using actions (and xsp's, for that matter) in favor of the flow. That said, *indirect* access to modules and actions would satisfy short-term, transitional requests to allow reuse of such legacy components from the flow (if only by popular demand :-)). - modules need the object model and actions need it also, along with a (Cocoon) resolver and a redirector. How will the flow be able to access these objects to pass them to the components ? Yes, you're right. Reinhard also pointed this out. IMO, the second point calls for some refactored interfaces since the (Excalibur) resolver is now a regular component and we decided some time ago to make the object model accessible through the Avalon context (don't know if it has been implemented, though). Yes, this solution is clean. If the object model is available legacy actions would be accessible. What I'd oppose -in any case- is giving actions/modules first-class status in the FOM... Ricardo
Re: Aspect-based pipelines and link view ( Re: Link view goodness)
Guys, The link stuff is a cross-cutting concern. This thread has IMHO shown how aspects can be easily added to the sitemap, and effectively used. Let's see... - We're abusing the name 'transformer', since nothing is transformed. If we're really going to go this way, let's define a new sitemap element, map:link-gatherer/. There are transformers that do not transform, it's not unusual, I can't think of any others? some OTOMH, maybe not 100% correct: LogTransformer XMLFormTransformer WriteDOMSessionTransformer SourceWritingTransformer Yup. Now, I've got an (untested) LinkGatheringTransformer ready and compiling. It shouldn't be much work to test it and get it going. snip links to stuff I mostly missed - thanks So basically we are adding a contract to the sitemap, by saying that each sitemap implementation has to provide a list of links if requested to (as seen above). As you state, a Transformer does not feel right. In fact, a sitemap has now a new contract that it has to give links. The question is: how can it be made more versatile? Who can we tell the pipeline where we want the link gathering to occur? What about a named pipeline that is inserted by the link gatherer where it gets the links? What about using a spacial label to indicate where to gather links? What is a named pipeline? How would the link gatherer (or rather the bean) 'insert a named pipeline'? Hmm.. interesting. Perhaps we just need to augment Resources a bit: map:resource name=gather-links from-position=content !-- Any required link munging -- map:transformer type=gather-links/ /map:resource Cool, you have put my words in code, adding that last bit that makes them worthwile :-) This really looks like some sort of final solution, intriguing. So how does this work? I don't get it. You're specifying a resource, but presumably you're going to still have to insert it somehow? Hmmm, it also has to do with the named pipelines thread, or the pipeline==reusable_component one that Stefano had started. Seems like simply adding this capability to resources is nice. We could similarly make a link-view that uses the same transformer and a serializer. In this way it could also be compatible with the 3pass method. Hmmm... Ie, a Resource inserted in each pipeline after the 'content' label. Rather AOP'ish. Yup. As link gathering is a cross-cutting concern, it also makes sense conceptually. So you're saying, with a resource that has a 'from-position' attribute, that specifies after which label it should be inserted? That makes sense. So you only have to have the resource once per sitemap, rather than having to insert it into every pipeline. But - what if the pipeline itself needs modifying to expose links from within PDFs for example. The LinkGatheringTransformer I have coded has two modes, one where it just hunts for href, src and xlink attributes, and the other that searches for attributes in the http://apache.org/cocoon/link-gatherer/1.0 namespace (probably to be used with a 'link' prefix). This latter kind is required for gathering links that don't conform to the href, src or xlink conventions. Just auto-inserting a link gatherer wouldn't work in this case. The thing here is how it's called by the sitemap engine. There is no explicit call in the pipelines, but instead a from-position attribute. It could easily have also a serializer, and in this way it would terminate all pipelines... but it's like fa view in this case... But a view then would become an AOPish resource with a serializer called only on certain conditions. Let's call them aspects instead of resources. So: - pipelines are called per request one after the other till the sitemap exits - resources are sitemap snippets called by the pipelines - views are exit points that get called at a particular label (effectively a hard-wired AOP feature) by the sitemap Pipelines and resources are effectively the same thing not that there is the cocoon protocol. What remains is the views part, that has introduce pipeline-stage metadata, as a label. It's an aspect that gets called when that particular condition is met (I won't use AOP terminology that I personally don't yet like) So we can generalize it, and add configurability to the view mechanism to specify other conditions. map:view name=content from-label=content map:serialize type=xml/ /map:view becomes: map:view name=content type=from-label test=content map:serialize type=xml/ /map:view This makes it possible to make a different position where to start from... What can also be made configurable is *when*, in which condition, it's triggered, but the logic has to be inverted. Now we say: when the view is triggered, start at a label After it could be: when the view is triggered, start at position Instead we need: when the position
cvs commit: cocoon-2.1/src/targets ide-build.xml
reinhard2003/06/30 12:22:16
Modified:.build.properties
src/targets ide-build.xml
Log:
- support for a OUTPUT_DIR property -- so it can be overwritten locally
Revision ChangesPath
1.22 +3 -0 cocoon-2.1/build.properties
Index: build.properties
===
RCS file: /home/cvs/cocoon-2.1/build.properties,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- build.properties 13 Jun 2003 10:27:38 - 1.21
+++ build.properties 30 Jun 2003 19:22:15 - 1.22
@@ -147,6 +147,9 @@
tools.loader.dest=${tools}/loader
tools.jetty=${tools}/jetty
+# IDE
+ide.eclipse.outputdir=${build.root}/eclipse/classes
+
# Libraries
lib=lib
lib.core=${lib}/core
1.7 +1 -1 cocoon-2.1/src/targets/ide-build.xml
Index: ide-build.xml
===
RCS file: /home/cvs/cocoon-2.1/src/targets/ide-build.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ide-build.xml 23 Jun 2003 18:11:30 - 1.6
+++ ide-build.xml 30 Jun 2003 19:22:16 - 1.7
@@ -84,7 +84,7 @@
filter token=SRC_DIRS value=${srcs}/
filter token=LIBS value=${libs}/
filter token=MOCKS_DIRS value=${mockss}/
-filter token=OUTPUT_DIR value=${build.root}/eclipse/classes/
+filter token=OUTPUT_DIR value=${ide.eclipse.outputdir}/
/filterset
/copy
cvs commit: cocoon-2.1/src/scratchpad/src/org/apache/cocoon/components/flow/javascript/fom FOM_Cocoon.java
reinhard2003/06/30 12:11:10
Modified:src/scratchpad/src/org/apache/cocoon/components/flow/javascript/fom
FOM_Cocoon.java
Log:
- Implemented functions:
* getComponent( id )
* releaseComponent( component)
* load( script)
- support for cocoon:// protocol when sending pages
- some code formatting
Revision ChangesPath
1.7 +81 -16
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/components/flow/javascript/fom/FOM_Cocoon.java
Index: FOM_Cocoon.java
===
RCS file:
/home/cvs/cocoon-2.1/src/scratchpad/src/org/apache/cocoon/components/flow/javascript/fom/FOM_Cocoon.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- FOM_Cocoon.java 26 Jun 2003 19:44:04 - 1.6
+++ FOM_Cocoon.java 30 Jun 2003 19:11:10 - 1.7
@@ -49,9 +49,12 @@
*/
package org.apache.cocoon.components.flow.javascript.fom;
+
import java.io.OutputStream;
import java.util.Map;
+import org.apache.avalon.framework.component.Component;
+import org.apache.avalon.framework.component.ComponentException;
import org.apache.avalon.framework.component.ComponentManager;
import org.apache.avalon.framework.logger.Logger;
import org.apache.cocoon.components.flow.ContinuationsManager;
@@ -63,13 +66,20 @@
import org.apache.cocoon.environment.Response;
import org.apache.cocoon.environment.Session;
import org.mozilla.javascript.JavaScriptException;
+import org.mozilla.javascript.Script;
import org.mozilla.javascript.Scriptable;
import org.mozilla.javascript.ScriptableObject;
import org.mozilla.javascript.Undefined;
import org.mozilla.javascript.Wrapper;
import org.mozilla.javascript.continuations.Continuation;
+
/**
- * Implementation of FOM (Flow Object Model)
+ * Implementation of FOM (Flow Object Model).
+ *
+ * @since 2.1
+ * @author a href=mailto:coliver.at.apache.org;Christopher Oliver/a
+ * @author a href=mailto:reinhard.at.apache.org;Reinhard Pötz/a
+ * @version CVS $Id$
*/
public class FOM_Cocoon extends ScriptableObject {
@@ -120,6 +130,7 @@
this.interpreter = null;
}
+
private void forwardTo(String uri, Object bizData,
Continuation continuation)
throws Exception {
@@ -132,8 +143,14 @@
lastContinuation,
0);
}
-interpreter.forwardTo(getParentScope(), this, cocoon://+
- environment.getURIPrefix() + uri,
+
+String redUri = uri;
+
+if(! uri.startsWith( cocoon:// ) ) {
+redUri = cocoon:// + this.environment.getURIPrefix() + uri;
+}
+
+interpreter.forwardTo(getParentScope(), this, redUri,
bizData, wk, environment);
}
@@ -179,12 +196,64 @@
}
*/
-
-public Object jsFunction_getComponent(String id) {
-// what is this?
-return null;
+
+/**
+ * Access components.
+ *
+ * TODO: Do we want to restrict the access of sitemap components? (RP)
+ * TODO: Do we want to raise an error or return null? (RP)
+ */
+public Object jsFunction_getComponent( String id ) {
+Object o = null;
+try {
+ o = this.componentManager.lookup( id );
+ } catch (ComponentException e) {
+ o = null;
+ }
+return o;
+}
+
+/**
+ * Release pooled components.
+ *
+ * @param component - an codeObject/code that is an instance
+ * of codeorg.apache.avalon.framework.component.Component/code
+ */
+public void jsFunction_releaseComponent( Object component )
+ throws JavaScriptException {
+try {
+this.componentManager.release( (Component) component );
+} catch( ClassCastException cce ) {
+throw new JavaScriptException( Only components can be released! );
+} catch( Exception e ) {
+throw new JavaScriptException( Error during release of component
occurred! + e.getMessage() );
+}
}
+/**
+ * Load the script file specified as argument.
+ *
+ * @param filename a codeString/code value
+ * @return an codeObject/code value
+ * @exception JavaScriptException if an error occurs
+ */
+public Object jsFunction_load( String filename )
+throws JavaScriptException {
+org.mozilla.javascript.Context cx =
+org.mozilla.javascript.Context.getCurrentContext();
+try {
+Scriptable scope = getParentScope();
+Script script =
cvs commit: cocoon-2.0/src/documentation/xdocs/link livesites.xml
joerg 2003/06/30 12:53:16 Modified:src/documentation/xdocs/link livesites.xml Log: Center for Technology in Govenment added Revision ChangesPath 1.7 +1 -0 cocoon-2.0/src/documentation/xdocs/link/livesites.xml Index: livesites.xml === RCS file: /home/cvs/cocoon-2.0/src/documentation/xdocs/link/livesites.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- livesites.xml 27 Jun 2003 21:41:34 - 1.6 +++ livesites.xml 30 Jun 2003 19:53:16 - 1.7 @@ -30,6 +30,7 @@ lilink href=http://www.cueandreview.org.uk/;Cue and Review Recording Services/link/li lilink href=http://www.standardlifeinvestments.com;Standard Life Investments/link/li lilink href=http://www.megabag.gr;MegaBag S.A./link - Industrial and trading company of specialized polymer materials/li + lilink href=http://www.ctg.albany.edu;Center for Technology in Government/link/li /ul /s2 s2 title=Cocoon 2.0.3
cvs commit: cocoon-2.1/src/documentation/xdocs/link hosting.xml
joerg 2003/06/30 12:50:10 Modified:src/documentation/xdocs/link hosting.xml Log: RimuHosting added Revision ChangesPath 1.3 +27 -32cocoon-2.1/src/documentation/xdocs/link/hosting.xml Index: hosting.xml === RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/link/hosting.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- hosting.xml 16 Jun 2003 21:19:22 - 1.2 +++ hosting.xml 30 Jun 2003 19:50:10 - 1.3 @@ -8,54 +8,49 @@ person name=Robin Green email=[EMAIL PROTECTED]/ /authors /header - body + s1 title=Cocoon Hosting + p +Here is a list of some sites that provide Apache Cocoon web hosting +(in no particular order). Version information may not be up-to-date +on this list, so always check with the site itself to make sure. Of course, +most are commercial providers, yet some have free services. + /p - s1 title=Cocoon Hosting - p - Here is a list of some sites that provide Apache Cocoon web hosting - (in no particular order). Version information may not be up-to-date - on this list, so always check with the site itself to make sure. Of course, - most are commercial providers, yet some have free services. - /p - - ul - lilink href=http://www.aoindustries.com/;AO Industries/link - Cocoon 1.8/li - lilink href=http://webartists.net/webhosting.html;Webartists/link (German)/li - lilink href=http://www.capital-internet.net/;Capital Internet/link - Cocoon 2 (pre-2.0 support will still be available)/li - lilink href=http://dev.startcom.org/;MediaHost Developer Accounts/link - from Cocoon 1.8.2 up to latest Cocoon 2.1/li - lilink href=http://www.va.com.au/;Virtual Artists Pty Ltd/link - Cocoon 1 or Cocoon 2/li - lilink href=http://www.hub.org/;Hub.Org Networking Services/link - Cocoon 2 or Cocoon 1/li - lilink href=http://www.dyanet.com/;Dyanet/link - Cocoon 2/li - lilink href=http://www.mmaweb.net/;Motivational Marketing Associates, Inc/link - Cocoon 1.7.4/li - lilink href=http://www.webappcabaret.com;WebAppCabaret/link - Cocoon 2.0.2/li - lilink href=http://www.wisernet.com;Wiserlabz/link - Cocoon 2.0.3 for commercial projects./li - lilink href=http://www.hebergement-pro.com;Hebergement-pro/link - Cocoon 2.0.2, including cheap starter pack./li - - /ul - - pstrongFree .../strong/p - ul - lilink href=http://www.wiserlabz.com;Wiserlabz/link - free Cocoon, Tomcat and Apache developer accounts./li - /ul + ul +lilink href=http://www.aoindustries.com/;AO Industries/link - Cocoon 1.8/li +lilink href=http://webartists.net/webhosting.html;Webartists/link (German)/li +lilink href=http://www.capital-internet.net/;Capital Internet/link - Cocoon 2 (pre-2.0 support will still be available)/li +lilink href=http://dev.startcom.org/;MediaHost Developer Accounts/link - from Cocoon 1.8.2 up to latest Cocoon 2.1/li +lilink href=http://www.va.com.au/;Virtual Artists Pty Ltd/link - Cocoon 1 or Cocoon 2/li +lilink href=http://www.hub.org/;Hub.Org Networking Services/link - Cocoon 2 or Cocoon 1/li +lilink href=http://www.dyanet.com/;Dyanet/link - Cocoon 2/li +lilink href=http://www.mmaweb.net/;Motivational Marketing Associates, Inc/link - Cocoon 1.7.4/li +lilink href=http://www.webappcabaret.com;WebAppCabaret/link - Cocoon 2.0.2/li +lilink href=http://www.wisernet.com;Wiserlabz/link - Cocoon 2.0.3 for commercial projects./li +lilink href=http://www.hebergement-pro.com;Hebergement-pro/link - Cocoon 2.0.2, including cheap starter pack./li +lilink href=http://rimuhosting.com;RimuHosting/link - Java Hosting Specialists, latest Cocoon on request./li + /ul + + pstrongFree .../strong/p + ul +lilink href=http://www.wiserlabz.com;Wiserlabz/link - free Cocoon, Tomcat and Apache developer accounts./li + /ul /s1 s1 title=How to get listed p If you do not find your site here, make sure you link href=mailto:[EMAIL PROTECTED] Hosting:tell us/link. -Enter a meaningful title after the words quot;Link Hosting:quot; +Enter a meaningful title after the words Link Hosting: in the subject, provide a short summary of your site and do not forget to tell us the URL. You could also follow the link href=../contrib.htmlContributing/link page to make it easier for everyone. /p - p You must have Cocoon up and running and be accepting application forms. /p - /s1 - /body /document
cvs commit: cocoon-2.0/src/documentation/xdocs/link hosting.xml
joerg 2003/06/30 12:50:35 Modified:src/documentation/xdocs/link hosting.xml Log: RimuHosting added Revision ChangesPath 1.3 +27 -32cocoon-2.0/src/documentation/xdocs/link/hosting.xml Index: hosting.xml === RCS file: /home/cvs/cocoon-2.0/src/documentation/xdocs/link/hosting.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- hosting.xml 16 Jun 2003 21:18:30 - 1.2 +++ hosting.xml 30 Jun 2003 19:50:35 - 1.3 @@ -8,54 +8,49 @@ person name=Robin Green email=[EMAIL PROTECTED]/ /authors /header - body + s1 title=Cocoon Hosting + p +Here is a list of some sites that provide Apache Cocoon web hosting +(in no particular order). Version information may not be up-to-date +on this list, so always check with the site itself to make sure. Of course, +most are commercial providers, yet some have free services. + /p - s1 title=Cocoon Hosting - p - Here is a list of some sites that provide Apache Cocoon web hosting - (in no particular order). Version information may not be up-to-date - on this list, so always check with the site itself to make sure. Of course, - most are commercial providers, yet some have free services. - /p - - ul - lilink href=http://www.aoindustries.com/;AO Industries/link - Cocoon 1.8/li - lilink href=http://webartists.net/webhosting.html;Webartists/link (German)/li - lilink href=http://www.capital-internet.net/;Capital Internet/link - Cocoon 2 (pre-2.0 support will still be available)/li - lilink href=http://dev.startcom.org/;MediaHost Developer Accounts/link - from Cocoon 1.8.2 up to latest Cocoon 2.1/li - lilink href=http://www.va.com.au/;Virtual Artists Pty Ltd/link - Cocoon 1 or Cocoon 2/li - lilink href=http://www.hub.org/;Hub.Org Networking Services/link - Cocoon 2 or Cocoon 1/li - lilink href=http://www.dyanet.com/;Dyanet/link - Cocoon 2/li - lilink href=http://www.mmaweb.net/;Motivational Marketing Associates, Inc/link - Cocoon 1.7.4/li - lilink href=http://www.webappcabaret.com;WebAppCabaret/link - Cocoon 2.0.2/li - lilink href=http://www.wisernet.com;Wiserlabz/link - Cocoon 2.0.3 for commercial projects./li - lilink href=http://www.hebergement-pro.com;Hebergement-pro/link - Cocoon 2.0.2, including cheap starter pack./li - - /ul - - pstrongFree .../strong/p - ul - lilink href=http://www.wiserlabz.com;Wiserlabz/link - free Cocoon, Tomcat and Apache developer accounts./li - /ul + ul +lilink href=http://www.aoindustries.com/;AO Industries/link - Cocoon 1.8/li +lilink href=http://webartists.net/webhosting.html;Webartists/link (German)/li +lilink href=http://www.capital-internet.net/;Capital Internet/link - Cocoon 2 (pre-2.0 support will still be available)/li +lilink href=http://dev.startcom.org/;MediaHost Developer Accounts/link - from Cocoon 1.8.2 up to latest Cocoon 2.1/li +lilink href=http://www.va.com.au/;Virtual Artists Pty Ltd/link - Cocoon 1 or Cocoon 2/li +lilink href=http://www.hub.org/;Hub.Org Networking Services/link - Cocoon 2 or Cocoon 1/li +lilink href=http://www.dyanet.com/;Dyanet/link - Cocoon 2/li +lilink href=http://www.mmaweb.net/;Motivational Marketing Associates, Inc/link - Cocoon 1.7.4/li +lilink href=http://www.webappcabaret.com;WebAppCabaret/link - Cocoon 2.0.2/li +lilink href=http://www.wisernet.com;Wiserlabz/link - Cocoon 2.0.3 for commercial projects./li +lilink href=http://www.hebergement-pro.com;Hebergement-pro/link - Cocoon 2.0.2, including cheap starter pack./li +lilink href=http://rimuhosting.com;RimuHosting/link - Java Hosting Specialists, latest Cocoon on request./li + /ul + + pstrongFree .../strong/p + ul +lilink href=http://www.wiserlabz.com;Wiserlabz/link - free Cocoon, Tomcat and Apache developer accounts./li + /ul /s1 s1 title=How to get listed p If you do not find your site here, make sure you link href=mailto:[EMAIL PROTECTED] Hosting:tell us/link. -Enter a meaningful title after the words quot;Link Hosting:quot; +Enter a meaningful title after the words Link Hosting: in the subject, provide a short summary of your site and do not forget to tell us the URL. You could also follow the link href=../contrib.htmlContributing/link page to make it easier for everyone. /p - p You must have Cocoon up and running and be accepting application forms. /p - /s1 - /body /document
[Flow] Serious problem with cocoon.getComponent(id)
I think we have I serious problem with the lookup of components
within flow scripts.
Under load the component manager can become null!!!
Could somebody with more knowledge about this part of Cocoon have
a look at it?
TIA!
Cheers,
Reinhard
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, June 30, 2003 9:11 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/components/flo
w/javascript/fom FOM_Cocoon.java
reinhard2003/06/30 12:11:10
Modified:
src/scratchpad/src/org/apache/cocoon/components/flow/javascript/fom
FOM_Cocoon.java
snip/
+public Object jsFunction_getComponent( String id ) {
+Object o = null;
+try {
+ o = this.componentManager.lookup( id );
+ } catch (ComponentException e) {
+ o = null;
+ }
+return o;
+}
RE: [Flow] Serious problem with cocoon.getComponent(id)
You need to describe how to recreate the problem in more detail for me to help you.
The component manager will only become null when the FOM_Cocoon object is invalidated.
Your scripts should not be executing in this state. If they are that that indicates a
bug and we need to find it.
Regards,
Chris
-Original Message-
From: Reinhard Pötz [mailto:[EMAIL PROTECTED]
Sent: Monday, June 30, 2003 12:57 PM
To: [EMAIL PROTECTED]
Subject: [Flow] Serious problem with cocoon.getComponent(id)
Importance: High
I think we have I serious problem with the lookup of components
within flow scripts.
Under load the component manager can become null!!!
Could somebody with more knowledge about this part of Cocoon have
a look at it?
TIA!
Cheers,
Reinhard
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, June 30, 2003 9:11 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/components/flo
w/javascript/fom FOM_Cocoon.java
reinhard2003/06/30 12:11:10
Modified:
src/scratchpad/src/org/apache/cocoon/components/flow/javascript/fom
FOM_Cocoon.java
snip/
+public Object jsFunction_getComponent( String id ) {
+Object o = null;
+try {
+ o = this.componentManager.lookup( id );
+ } catch (ComponentException e) {
+ o = null;
+ }
+return o;
+}
Re: More on FOM
Ricardo Rocha wrote: Sylvain Wallez wrote: Ricardo Rocha wrote: The following items reflect the discussions Stefano and I have had around the FOM: - The load(uri) global function should be supported. This is clearly needed for nested source file inclusion (which map:script does not support). - The cocoon.releaseComponent(component) method should be supported in conjunction with cocoon.getComponent(id). Further discussion is needed about whether the FOM implementation should automatically take care of releasing components. Hehe, I should go to Ecuador, as I advocated both ;-) You're welcome anytime my friend! :-) Cool ! This is one of the good things of Apache : world-wide friends, ready to welcome you for good time and geek talks :-) I suggested that components being heavyweight resource, allowing them to cross continuation boundaries should be prohibited. Automatic release doesn't seem a good solution to me, as it would mean that script variables would hold released components, thus leading to unpredictable behaviour (think about stateful pooled components). So my opinion is to raise an error if there are some unreleased components when a continuation is created. This will allow users to quickly learn the safe practices related to component management in flow scripts. I see your point Sylvain. Your solution sounds somewhat draconian but it's probably the only safe bet... The question then becomes: does anyone envision real-world scenarios in which stateful components *are* needed across continuation boundaries? (if so, imo, it might imply curent Avalon component management isn't safe for continuations) Or can we *always* formulate our flow so that we don't need to keep component state across continuations? (for example, database connections can be acquired/released as needed precisely because they're pooled). Databases connections are a good use case. IMO, the sequential nature of a flow script will make people want to keep stateful components as the do in standard code, as it is somewhat unnatural to release a connection just before a sendPageAndWait() and then look it up just after. The modified Rhino intepreter has some extensions to exception management to allow clearing and restoring variables when a continuation is suspended/reactivated. This will be very useful in large scripts when a continuation is suspended several function call deeper than the location where the component is used. On a separate thread, if *all* acquired components *must* be released prior to creating a continuation... wouldn't it make sense for the FOM implementation to automagically release them?? I know it may sound dangerous at first, but then again it would relieve developers from that tedious, anti-scripting release idiom... Once again, I agree that explicit release is very unnatural. But automagic release is good only if we can have some automagic restore. For this we can have getComponent() actually return a proxy to the real component, and have the proxy do a release/lookup when a continuation is suspended/reactivated. But as elegant this may seem, this won't work : stateful components have... a state, and a release/lookup cycle destroys this state. So I don't see any other solution... - There should be unrestricted access to all components via cocoon.getComponent(id). Hehe again ;-) Hahaha! There's nothing quite like the flavor of victory, is there? ;-) Mmmh... it's not about victory in the fight meaning, where there's a winner and a looser. We all win in discussing our thoughts and taking good ideas where they come. This time these are mine and, well, this feels good ;-) Among other goodies, this will give indirect access to Actions and Modules without providing explicit FOM support for them. Access to request input modules, in particular, should account for request.getURI(). Two remarks here : - if we give access to request.getURI through an input module, then why removing it from the request object ?? Until proven otherwise, I don't think getURI() is _needed_ by the flow, so the request object shouldn't expose it. Actually, I think that if the flow needs something from the URI, this information should be passed by the sitemap through map:parameters in the map:call. The sitemap is responsible for handling the URI space, including extracting information from it for other components. Imo, the flow renders actions (and modules outside the sitemap) unnecessary, so we shouldn't encourage their continued use by providing FOM-level support for them. The idea, in the long term, is to stop using actions (and xsp's, for that matter) in favor of the flow. That said, *indirect* access to modules and actions would satisfy short-term, transitional requests to allow reuse of such legacy components from the flow (if only by popular demand :-)). Ok. So we allow some abuse to satify transition of legacy applications or code. -
RE: [Flow] Serious problem with cocoon.getComponent(id)
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
You need to describe how to recreate the problem in more
detail
ok, here some more details:
As you can see I implemented cocoon.getComponent(id). If I call
this method from the flow and do a lot of refreshes at once
(pushing the F5 key at IE) this error occurs.
If I include a debug statement writing the ComponentManager to
System.out I sometimes get null and not the manager.
IIRC last week a problem with the petstore examples and the
database connections was reported altough the old implementation
exposed the ComponentManager itself.
If you need more information please let me know!
Reinhard
for me to help you. The component manager will only
become null when the FOM_Cocoon object is invalidated. Your
scripts should not be executing in this state. If they are
that that indicates a bug and we need to find it.
Regards,
Chris
-Original Message-
From: Reinhard Pötz [mailto:[EMAIL PROTECTED]
Sent: Monday, June 30, 2003 12:57 PM
To: [EMAIL PROTECTED]
Subject: [Flow] Serious problem with cocoon.getComponent(id)
Importance: High
I think we have I serious problem with the lookup of
components within flow scripts. Under load the component
manager can become null!!!
Could somebody with more knowledge about this part of Cocoon
have a look at it?
TIA!
Cheers,
Reinhard
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, June 30, 2003 9:11 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/components/flo
w/javascript/fom FOM_Cocoon.java
reinhard2003/06/30 12:11:10
Modified:
src/scratchpad/src/org/apache/cocoon/components/flow/javascript/fom
FOM_Cocoon.java
snip/
+public Object jsFunction_getComponent( String id ) {
+Object o = null;
+try {
+ o = this.componentManager.lookup( id );
+ } catch (ComponentException e) {
+ o = null;
+ }
+return o;
+}
Continuation patterns (too long!)
Hi friends,
Is this a rant? A random thought? A pontification? Well, let's say it's
just a personal story (and a concern) I want to share with my fellow
Cocooners...
Someone said continuations can be grasped in five minutes, but it
may take a lifetime to master them :-)
When first introduced to web programming with continuations I was
profoundly impressed to see how continuations reinvert IoC and turn
event-oriented programming into good ole' sequential programming.
I was even more impressed to see how -with continuations- the infamous
back button could become in fact a new, all-powerful tool for what-if
scenarios and exploratory browsing.
Boy, is this a triumph of spirit over matter! :-)
After such intellectual orgasm it followed naturally that -from now on-
all my EJB-based webapp development *had to* be developed using Cocoon's
flowscript.
Unsurprisingly, I was rapidly hit by real-life's nasty habit of
impairing golden hammers:
After executing a database-modifying EJB method from the flow, I saw how
invoking the same continuation twice resulted in inconsistent database
state! Obviously, database modifications reflect all updates made
throughout the session, regardless of continuations...
In general, any store will reflect changes made in time. Continuations
only preserve _program_ state. Store state has to be accounted for
separatedly. Thus, continuations wouldn't spare me from having to keep
some sort of explicit dialog control after all...
Since I was playing with a utility screen Javascript object (not
unlike Chris' [JX]Form wrapper) I was able to easily add a low-level
sequence number check to ensure obsolete continuations were detected
and rejected. Easy hack: it didn't propagate to my application-level
flow code.
All of my dialog pages had a Cancel button users could click on at any
time to abort the current transaction. Checking to see if it was pressed
became sort of an aspect for every submitted page.
Because pages can be sent (executed) at any function call nesting
level I decided to implement cancellation processing as a Javascript
exception that propagates all the way up to the top-level sitemap
function dispatcher. Later on, I realized it would be more elegant (and
continuation-aware) to create a globally accessible continuation inside
the dispatcher and use it as an escape procedure. Upon invoking such
continuation, all other outstanding continuations should be invalidated.
I also faked a Javascript component manager which -in absence of the
upcoming Cocoon blocks- would provide me with subsitemap-specific
components for use in my flow.
By combining form objects, local components and [remote] EJB's, I could
keep my flow logic *strictly* flow-related:
...
dataModel.dateFormatter = components.dateFormatter;
...
welcomeScreen.execute(dataModel);
dataModel.requestData =
requestDataScreen.execute(dataModel);
dataModel.requestAnalysis =
requestManagerEJB.analyzeRequest(dataModel.requestData);
if (requestAnalysys.evaluation == APPROVED) {
confirmationScreen.execute(dataModel);
requestManagerEJB.processRequest(dataModel.requestData);
} else {
sorryScreen.execute(dataModel);
}
This was definitively approaching nirvana: flowScript gluing components
across application layers. No misplaced business logic, no cluttered
controller logic, absolute separation of concerns.
But then I realized I had to deal with releasing stateful components...
Sylvain and I have addressed the infamous automatic component
releasing problem which stems from having to account for continuation
trees. His harsh solution (no components leased at continuation
creation) seems to be the way to go...
If I'm to follow my intutition -and my own experience- I'd bet many
Cocoon developers tend to think in terms of a _single_ outstanding
continuation that reflects the webapp's expected flow of execution.
(It was because of such incomplete mindset, btw, that I first thought
acquired components could be automatically released upon sitemap
function completion...)
These and similar experiences suggest web programming with continuations
is an uncharted, brave new world whose deep ramifications we -mere
mortals, non-Lisp gurus- are only beginning to grasp...
Clearly, we need to come up with web-oriented continuation patterns that
reflect real-world application constraints. (Does it make sense to
reuse continuations for form validation? How do we implement one-shot
or linear continuations for transactional dialogs with remote servers?)
The core Continuation implementation is superb. The FOM is rapidly
approaching a stable form. The next challenge is understanding how to
take advantage of this tremendous power while avoiding to shoot our
boots.
Just food for thought...
Ricardo
RE: Contribution: MultiPartPostAction FilePartGenerator
Eric, Please use Bugzilla (http://nagoya.apache.org) to provide your enhancements otherwise I fear that they will be overlooked. Additionally I cc'ed cocoon-dev. Without looking at your sources and examples: What does your generator provide what http://cocoon.apache.org/2.1/userdocs/generators/stream-generator.html can't do for you? Cheers, Reinhard -Original Message- From: Simmerman, Eric [mailto:[EMAIL PROTECTED] Sent: Monday, June 30, 2003 7:50 PM To: [EMAIL PROTECTED] Subject: Contribution: MultiPartPostAction FilePartGenerator Hello all, As per the Cocoon contribution guidelines, I've made some Cocoon extensions source code available for download at: http://www.tempeststrings.com/cocoon/in dex.html. There are two files that meet the guidelines for contribution to the Cocoon code base: org.apache.cocoon.acting.MultiPartPostAction.java org.apache.cocoon.generation.FilePartGenerator.java Together, these will allow Cocoon to accept a multi part post containing an uploaded file and kickoff a pipeline by parsing the file's contents for generation. I've used this source to configure a Cocoon installation as a real-time data conversion service. Using the service, a user can upload a file in XML format, and immediately receive a response containing the same data in any format supported by Cocoon Serializers. A sample sitemap.xconf is included in the header comments of MultiPartPostAction. My hope is that these contributions will make their way into the Coccon code base. Please let me know if I can assist in any way. Please note that the other files (not the two described above) found in this distribution rely on GPL code and can not be released under the Apache license. Thanks, -Eric Simmerman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: cocoon-2.1/lib jars.xml
ghoward 2003/06/30 18:54:51 Modified:lib jars.xml Log: upgrade to latest sourceresolve package Revision ChangesPath 1.54 +2 -2 cocoon-2.1/lib/jars.xml Index: jars.xml === RCS file: /home/cvs/cocoon-2.1/lib/jars.xml,v retrieving revision 1.53 retrieving revision 1.54 diff -u -r1.53 -r1.54 --- jars.xml 29 Jun 2003 09:23:12 - 1.53 +++ jars.xml 1 Jul 2003 01:54:51 - 1.54 @@ -195,7 +195,7 @@ support high level server development. /description used-byCocoon/used-by - libcore/excalibur-sourceresolve-20030615.jar/lib + libcore/excalibur-sourceresolve-20030630.jar/lib homepagehttp://avalon.apache.org/excalibur//homepage /file
cvs commit: cocoon-2.1/lib/core excalibur-sourceresolve-20030630.jar
ghoward 2003/06/30 19:43:28 Added: lib/core excalibur-sourceresolve-20030630.jar Log: upgrade to latest sourceresolve package Revision ChangesPath 1.1 cocoon-2.1/lib/core/excalibur-sourceresolve-20030630.jar Binary file
cvs commit: cocoon-2.1/lib/core excalibur-sourceresolve-20030615.jar
ghoward 2003/06/30 19:51:08 Removed: lib/core excalibur-sourceresolve-20030615.jar Log: upgrade to latest sourceresolve package
cvs commit: cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity NameValueEvent.java Event.java EventValidity.java NamedEvent.java
ghoward 2003/06/30 20:44:17
Modified:src/scratchpad/src/org/apache/cocoon/caching/validity
NameValueEvent.java Event.java EventValidity.java
NamedEvent.java
Log:
Add hashCode for lookup in EventAwareCacheImpl
Revision ChangesPath
1.2 +19 -11
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity/NameValueEvent.java
Index: NameValueEvent.java
===
RCS file:
/home/cvs/cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity/NameValueEvent.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- NameValueEvent.java 21 Jun 2003 03:36:14 - 1.1
+++ NameValueEvent.java 1 Jul 2003 03:44:16 - 1.2
@@ -60,27 +60,35 @@
private String m_name;
private String m_value;
+private int m_hashcode;
+/**
+ * Constructor requires two Strings - the name/value
+ * pair which defines this Event.
+ *
+ * @param name
+ * @param value
+ */
public NameValueEvent(String name, String value) {
m_name = name;
m_value = value;
+m_hashcode = (name + value).hashCode();
}
-private String getName() {
-return m_name;
-}
-
-private String getValue() {
-return m_value;
-}
-
+/**
+ * Must return true when both name and value are
+ * equivalent Strings.
+ */
public boolean equals(Event e) {
if (e instanceof NameValueEvent) {
NameValueEvent nve = (NameValueEvent)e;
-return ( m_name.equals(nve.getName())
-m_value.equals(nve.getValue()) );
+return ( m_name.equals(nve.m_name)
+m_value.equals(nve.m_value) );
}
return false;
}
-
+
+public int hashCode() {
+return m_hashcode;
+}
}
1.2 +14 -0
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity/Event.java
Index: Event.java
===
RCS file:
/home/cvs/cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity/Event.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Event.java21 Jun 2003 03:36:14 - 1.1
+++ Event.java1 Jul 2003 03:44:16 - 1.2
@@ -59,7 +59,21 @@
*/
public abstract class Event {
+/**
+ * Used by EventValidity for equals(Object o) which
+ * is important for determining whether a received event
+ * should uncache a held Pipeline key.
+ *
+ * @param event Another Event to compare.
+ * @return true if
+ */
public abstract boolean equals(Event e);
+
+/**
+ * This hash code is the only way the system can locate
+ * matching Events when a new event notification is received.
+ */
+public abstract int hashCode();
public boolean equals(Object o) {
if (o instanceof Event) {
1.2 +30 -4
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity/EventValidity.java
Index: EventValidity.java
===
RCS file:
/home/cvs/cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity/EventValidity.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- EventValidity.java21 Jun 2003 03:36:14 - 1.1
+++ EventValidity.java1 Jul 2003 03:44:16 - 1.2
@@ -55,32 +55,58 @@
* The SourceValidity object for cache invalidation based on
* external events.
*
- * @author Geoff Howard([EMAIL PROTECTED])
- * @version $CVS$
+ * @author Geoff Howard ([EMAIL PROTECTED])
+ * @version $CVS$
*/
public class EventValidity implements SourceValidity {
private Event m_event;
+/**
+ * Constructor requires any subclass of Event.
+ * @param ev
+ */
public EventValidity(Event ev) {
m_event = ev;
}
+/**
+ * Returns the specific Event this validity is based on.
+ *
+ * @return Event
+ */
public Event getEvent() {
return m_event;
}
- /** Basic implementation is always valid until event signals
- * otherwise. May never need other behavior.
+ /**
+ * Basic implementation is always valid until event signals
+ * otherwise. May never need other behavior.
*/
public int isValid() {
return VALID;
}
+/**
+ * Older style of isValid
+ */
public int isValid(SourceValidity sv) {
cvs commit: cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity NameValueEvent.java Event.java EventValidity.java NamedEvent.java
ghoward 2003/06/30 20:54:13
Modified:src/scratchpad/src/org/apache/cocoon/caching/validity
NameValueEvent.java Event.java EventValidity.java
NamedEvent.java
Log:
oops
Revision ChangesPath
1.3 +1 -1
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity/NameValueEvent.java
Index: NameValueEvent.java
===
RCS file:
/home/cvs/cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity/NameValueEvent.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- NameValueEvent.java 1 Jul 2003 03:44:16 - 1.2
+++ NameValueEvent.java 1 Jul 2003 03:54:13 - 1.3
@@ -54,7 +54,7 @@
* An example might be table_name, primary_key
*
* @author Geoff Howard ([EMAIL PROTECTED])
- * @version $CVS$
+ * @version $Id$
*/
public class NameValueEvent extends Event {
1.3 +1 -2
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity/Event.java
Index: Event.java
===
RCS file:
/home/cvs/cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity/Event.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Event.java1 Jul 2003 03:44:16 - 1.2
+++ Event.java1 Jul 2003 03:54:13 - 1.3
@@ -54,8 +54,7 @@
* uncache event.
*
* @author Geoff Howard ([EMAIL PROTECTED])
- *
- * @version $CVS$
+ * @version $Id$
*/
public abstract class Event {
1.3 +1 -1
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity/EventValidity.java
Index: EventValidity.java
===
RCS file:
/home/cvs/cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity/EventValidity.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- EventValidity.java1 Jul 2003 03:44:16 - 1.2
+++ EventValidity.java1 Jul 2003 03:54:13 - 1.3
@@ -56,7 +56,7 @@
* external events.
*
* @author Geoff Howard ([EMAIL PROTECTED])
- * @version $CVS$
+ * @version $Id$
*/
public class EventValidity implements SourceValidity {
1.3 +1 -1
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity/NamedEvent.java
Index: NamedEvent.java
===
RCS file:
/home/cvs/cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/validity/NamedEvent.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- NamedEvent.java 1 Jul 2003 03:44:16 - 1.2
+++ NamedEvent.java 1 Jul 2003 03:54:13 - 1.3
@@ -54,7 +54,7 @@
* (not necessarily useful) could include Easter or Shutdown
*
* @author Geoff Howard ([EMAIL PROTECTED])
- * @version $CVS$
+ * @version $Id$
*/
public class NamedEvent extends Event {
cvs commit: cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/impl - New directory
ghoward 2003/06/30 21:38:40 cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/impl - New directory
cvs commit: cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/impl EventAwareCacheImpl.java
ghoward 2003/06/30 21:38:48
Added: src/scratchpad/src/org/apache/cocoon/caching/impl
EventAwareCacheImpl.java
Log:
Add event aware cache implementation
Revision ChangesPath
1.1
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/impl/EventAwareCacheImpl.java
Index: EventAwareCacheImpl.java
===
/*
The Apache Software License, Version 1.1
Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or without modifica-
tion, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. The end-user documentation included with the redistribution, if any, must
include the following acknowledgment: This product includes software
developed by the Apache Software Foundation (http://www.apache.org/).
Alternately, this acknowledgment may appear in the software itself, if
and wherever such third-party acknowledgments normally appear.
4. The names Apache Cocoon and Apache Software Foundation must not be
used to endorse or promote products derived from this software without
prior written permission. For written permission, please contact
[EMAIL PROTECTED]
5. Products derived from this software may not be called Apache, nor may
Apache appear in their name, without prior written permission of the
Apache Software Foundation.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
package org.apache.cocoon.caching.impl;
import java.util.Collection;
import java.util.Iterator;
import java.util.Map;
import org.apache.avalon.framework.component.ComponentException;
import org.apache.avalon.framework.component.ComponentManager;
import org.apache.cocoon.ProcessingException;
import org.apache.cocoon.caching.CachedResponse;
import org.apache.cocoon.caching.PipelineCacheKey;
import org.apache.cocoon.caching.validity.Event;
import org.apache.cocoon.caching.validity.EventValidity;
import org.apache.commons.collections.MultiHashMap;
import org.apache.excalibur.source.SourceValidity;
import org.apache.excalibur.source.impl.validity.AggregatedValidity;
/**
* Very experimental start at external cache invalidation.
* Warning - API very unstable. Do not use!
*
* This implementation holds all mappings between Events and PipelineCacheKeys
* in two MultiHashMap to facilitate efficient lookup by either as Key.
*
* TODO: Implement Persistence.
* TODO: Test performance.
*
* @author Geoff Howard ([EMAIL PROTECTED])
* @version $Id: EventAwareCacheImpl.java,v 1.1 2003/07/01 04:38:48 ghoward Exp $
*/
public class EventAwareCacheImpl extends CacheImpl {
/**
* Clears the entire Cache, including all held event-pipeline key
* mappings..
*
* @see org.apache.cocoon.caching.Cache#clear()
*/
public void clear() {
super.clear();
m_keyMMap.clear();
m_eventMMap.clear();
}
/**
* Compose
*
* TODO: the Maps should not be initialized here (and should not be hardcoded
size)
* TODO: Attempt to recover/deserialize persisted event listing. (but not here)
*
* @see
org.apache.avalon.framework.component.Composable#compose(org.apache.avalon.framework.component.ComponentManager)
*/
public void compose(ComponentManager manager) throws ComponentException {
super.compose(manager);
cvs commit: cocoon-2.1/src/scratchpad/src/org/apache/cocoon/acting CacheEventAction.java
ghoward 2003/06/30 21:40:00
Added: src/scratchpad/src/org/apache/cocoon/acting
CacheEventAction.java
Log:
Action to manually fire Cache Events - for testing/sample mainly.
Revision ChangesPath
1.1
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/acting/CacheEventAction.java
Index: CacheEventAction.java
===
/*
The Apache Software License, Version 1.1
Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or without modifica-
tion, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. The end-user documentation included with the redistribution, if any, must
include the following acknowledgment: This product includes software
developed by the Apache Software Foundation (http://www.apache.org/).
Alternately, this acknowledgment may appear in the software itself, if
and wherever such third-party acknowledgments normally appear.
4. The names Apache Cocoon and Apache Software Foundation must not be
used to endorse or promote products derived from this software without
prior written permission. For written permission, please contact
[EMAIL PROTECTED]
5. Products derived from this software may not be called Apache, nor may
Apache appear in their name, without prior written permission of the
Apache Software Foundation.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This software consists of voluntary contributions made by many individuals
on behalf of the Apache Software Foundation and was originally created by
Stefano Mazzocchi [EMAIL PROTECTED]. For more information on the Apache
Software Foundation, please see http://www.apache.org/.
*/
package org.apache.cocoon.acting;
import java.util.Map;
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.avalon.framework.thread.ThreadSafe;
import org.apache.cocoon.caching.Cache;
import org.apache.cocoon.caching.impl.EventAwareCacheImpl;
import org.apache.cocoon.caching.validity.NamedEvent;
import org.apache.cocoon.environment.ObjectModelHelper;
import org.apache.cocoon.environment.Redirector;
import org.apache.cocoon.environment.Request;
import org.apache.cocoon.environment.SourceResolver;
/**
* Very experimental start at external cache invalidation.
* Warning - API very unstable. Do not use! In fact, if this
* becomes useful, it would probably move to Excalibur SourceResolve.
*
* Simple action to cause notification of a NamedEvent to an EventAwareCacheImpl.
* The event name is taken from a sitemap parameter named event.
*
* This action returns null (fails) if the configured event is null or the
* empty string. Otherwise, it succeeds and returns an empty Map.
*
* This is used in the Event based cache example.
*
* @author Geoff Howard ([EMAIL PROTECTED])
* @version $CVS$
*/
public class CacheEventAction extends ComposerAction implements ThreadSafe {
/**
* Lookup the cache and call its processEvent method. Returns an
* empty map to signal success.
*/
public Map act(Redirector redirector,
SourceResolver resolver,
Map objectModel,
String src,
Parameters par
) throws Exception {
Cache cache = (Cache)this.manager.lookup(Cache.ROLE);
if (cache instanceof EventAwareCacheImpl) {
Re: More on FOM
On 30 Jun 2003 at 22:29, Sylvain Wallez wrote: ... I suggested that components being heavyweight resource, allowing them to cross continuation boundaries should be prohibited. Automatic release doesn't seem a good solution to me, as it would mean that script variables would hold released components, thus leading to unpredictable behaviour (think about stateful pooled components). So my opinion is to raise an error if there are some unreleased components when a continuation is created. This will allow users to quickly learn the safe practices related to component management in flow scripts. I tend to agree. ... Once again, I agree that explicit release is very unnatural. But automagic release is good only if we can have some automagic restore. For this we can have getComponent() actually return a proxy to the real component, and have the proxy do a release/lookup when a continuation is suspended/reactivated. But as elegant this may seem, this won't work : stateful components have... a state, and a release/lookup cycle destroys this state. So I don't see any other solution... How about defining a FlowSafe interface (contains no state and can be released/looked up transparently), and maybe a FlowSerializable interface (has a way that the state can be stored into the continuation and then restored, all transparently? So you would have to consciously code your components to use either of these interfaces, otherwise you'll have to manually release them before creating a continuation. Upayavira
cvs commit: cocoon-2.1 status.xml
crossley2003/06/30 22:31:52 Modified:.status.xml Log: Fix the date replacement tag. Revision ChangesPath 1.69 +2 -2 cocoon-2.1/status.xml Index: status.xml === RCS file: /home/cvs/cocoon-2.1/status.xml,v retrieving revision 1.68 retrieving revision 1.69 diff -u -r1.68 -r1.69 --- status.xml29 Jun 2003 08:40:39 - 1.68 +++ status.xml1 Jul 2003 05:31:51 - 1.69 @@ -182,7 +182,7 @@ changes - release version=@version@ date=@date + release version=@version@ date=@date@ action dev=JH type=fix fixes-bug=19104 due-to=Johan Stuyts due-to-email=[EMAIL PROTECTED] Fixed SchematronValidator.evalRule() in xmlforms block: create a relative context instead of an absolute one. This allows to refer to another form field by using relative paths (../password) instead of choosing a common root.
Re: cvs commit: cocoon-2.1 status.xml
Upayavira wrote: [EMAIL PROTECTED] wrote: ... Revert the previous revision. It is the concern of the stylesheets to show the release status. ... - release version=@version@ date=not yet released + release version=@version@ date=@date Should this be @[EMAIL PROTECTED] Absolutely. My mistake - thanks for spotting this. Fixed now. --David
[woody] binding the forms to data
Hi all,
just want to share some thoughts on a possble nice addition for
the woody forms, feel free to comment
(see http://wiki.cocoondev.org/Wiki.jsp?page=Woody for the
miinimal current docs)
the woody forms as of today allow you to define the form-model
(woody-definition file, with some validation in there) and have a
way to template the defined widgets into an HTML-form frame
(woody-template file)
however, filling the form with data comming from your backend
needs to be done programmtically (various
frm.getWidget(..).setValue (..) calls)
this got me thinking (and thinkering) towards a declarative way
for expresiing what I would call 'form-binding'
Using a similar factory/builder pattern as the current woody
forms there could be some binding-definition file that gets build
into some runtime Binding object that actually performs the
trick for you:
Form frm ...;
BindingManager bm = serviceManager.lookup(..);
Binding b = bm.createBinding(source);
Object model = BackendService.interact();
b.loadFormFromModel(frm, model);
// and something similar for the way back?
b.saveFormToModel(frm,model)?
The actual binding definition file could be filled with:
bnd:field id=widget-name
path=xpath expression into model /
and possibly a bit more complex constructs to ease on the typing
with context narrowing:
bnd:context path=xpath to context
bnd:field path=relative-path id=widget-name /
bnd:field path=relative-path id=widget-name /
/bnd:context
Thinking about a context like 'address' and fields as
'addressline', 'city', 'zip'
This would call for the Binding object to be in fact a nested
tree of binding objects reflecting the widget-tree inside the
form. Each of these Binding objects could then narrow the scope
of the current context and pass over to the children to continue
on the binding. (assuming jxpath usage for inspecting the model)
e.g. for this context-thing:
public void loadFormFromModel(
ContainerWidget c, JXPathContext jxpc){
JXPathContext subContext;
subContext = jxpc.getRelativeContext(
jxpc.getPointer(this.xpath));
continueLoadingFromChildren(c, subContext);
}
similar there could be binding for repeaters and the new
aggregate fields
bnd:repeater path=.. id=..
bnd:field .../
/bnd:repeater
bnd:aggregate path=.. id=..
bnd:field .../
/bnd:aggregate
Using JXPath there should be a fairly easy way to have this
binding work for a backend producing either javabeans or XML files.
what do people think?
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
[EMAIL PROTECTED] [EMAIL PROTECTED]
