Database.js
Hi peeps,
I'm messing around with the GetTogether registration page, which gives
me a chance to test all this new wonderful Woody flow stuff, but I'm
stuck on the usage of Database.js. I'm not planning to use any O/R
mapping, since I'll have two tables at most.
In PetStoreImpl.js, there's a code fragment that reads:
PetStore.prototype.getConnection = function(id) {
if (true) {
// temporary hack to avoid requiring datasource config in
cocoon.xconf
java.lang.Class.forName(org.hsqldb.jdbcDriver);
var jdbc =
java.sql.DriverManager.getConnection(jdbc:hsqldb:., sa, )
var conn = new Database(jdbc);
if (this.hsql == null) {
// keep hsql in-memory database alive
this.hsql =
java.sql.DriverManager.getConnection(jdbc:hsqldb:., sa, );
}
return conn;
} else {
// lookup datasource in cocoon.xconf
return Database.getConnection(id);
}
}
but since I want to use my cocoon.xconf datasources config, I'm trying
to set up a connection using:
cocoon.load(resource://org/apache/cocoon/components/flow/javascript/Database.js);
Registration.prototype.getConnection = function(id) {
return Database.getConnection(id);
}
and:
var conn = this.getConnection(id);
somewhere.
I'm greeted however with the interesting message: The undefined value
has no properties. Has anyone already played with this? I'm looking for
a snippet of sample code, without the weight that Petstore carries, to
open a connection to a cocoon.xconf-defined pool.
Thanks,
/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
[RT] Improving Views
It's seems we have RT Time :) With views we have a nice sitemap feature that imho can be improved as well: One major disadvantage currently is that views are not inherited to subsitemaps, so I: Views should be inherited and can be extended/overwritten in subsitemaps like any other component. Views are used for different scenarios; they provide a different ending of your pipeline. This is e.g. useful for debugging. Now by default the content view is enabled (for the main sitemap), and most times this view is not disabled when the application goes in production, so a user can invoke this view on deployed applications and see the output of the generator. But, this might contain sensitive data which is not intended to be seen by the average user. So it makes sense to have a way to turn off views. But at the same time you might need views in different areas of your application, so: Views can have a default state: enabled or disabled that can be set in the sitemap: map:views default=enabled (or disabled) This default can be overwritten on a map:pipeline base: map:pipeline views=disabled (or enabled) In addition, you can allow only some views, like: map:pipeline allow-views=x,z And now you :) Carsten Carsten Ziegeler Open Source Group, SN AG http://radio.weblogs.com/0107211/
cvs commit: cocoon-2.1/src/documentation/xdocs/developing/webapps session.xml
cziegeler2003/08/20 00:24:53 Modified:src/documentation/xdocs/developing/webapps session.xml Log: Adding missing note Revision ChangesPath 1.4 +8 -0 cocoon-2.1/src/documentation/xdocs/developing/webapps/session.xml Index: session.xml === RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/developing/webapps/session.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- session.xml 4 Jul 2003 10:44:18 - 1.3 +++ session.xml 20 Aug 2003 07:24:53 - 1.4 @@ -416,6 +416,14 @@ sourcelt;session:inputxml name=forename context=userdata path=/user/forenamegt; Defaultname lt;/session:inputxmlgt;/source +pBut as always there is one drawback with this approach as well, you + have to put the emsession-form-manager/em action somewhere so + that it is called when the form values are submitted. As this + action does no harm, it can simply be put as the first action in your + main sitemap:/p +source +lt;map:act type=session-form-manager/gt; +/source /s2 /s1 /body
Re: [RT] Improving Views
On Mittwoch, August 20, 2003, at 09:07 Uhr, Carsten Ziegeler wrote: It's seems we have RT Time :) With views we have a nice sitemap feature that imho can be improved as well: One major disadvantage currently is that views are not inherited to subsitemaps, so I: Views should be inherited and can be extended/overwritten in subsitemaps like any other component. Views are used for different scenarios; they provide a different ending of your pipeline. This is e.g. useful for debugging. Now by default the content view is enabled (for the main sitemap), and most times this view is not disabled when the application goes in production, so a user can invoke this view on deployed applications and see the output of the generator. But, this might contain sensitive data which is not intended to be seen by the average user. So it makes sense to have a way to turn off views. But at the same time you might need views in different areas of your application, so: Views can have a default state: enabled or disabled that can be set in the sitemap: map:views default=enabled (or disabled) This default can be overwritten on a map:pipeline base: map:pipeline views=disabled (or enabled) In addition, you can allow only some views, like: map:pipeline allow-views=x,z And now you :) I think it is not sufficient to have views that can be enabled/disabled. Sometimes other components depend on certain views (like the Lucene indexer) and so you can't disable. Maybe we need a sort of access restriction mechanism. /Leo Carsten Carsten Ziegeler Open Source Group, SN AG http://radio.weblogs.com/0107211/
Re: accessing sitemap parameters in a flow script
Stefano Mazzocchi wrote:
On Friday, Aug 15, 2003, at 23:49 Europe/Rome, Sylvain Wallez wrote:
snip/
And this really demonstrates how dangerous can be this translation to
positional parameter ;-)
why don't we fix this, then?
Well, positional parameters have been there since day one in FlowScript,
and many of the existing flows, including Cocoon's own flow libraries
such as XMLForm and Woody rely on this feature.
So we can't remove it abruptly. But we could deprecate it, meaning keep
it functional to avoid breaking things, but remove any reference to this
feature in the code and the docs.
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
DO NOT REPLY [Bug 22574] - poi HSSFSerializer error with formula cells
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=22574. 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=22574 poi HSSFSerializer error with formula cells --- Additional Comments From [EMAIL PROTECTED] 2003-08-20 07:44 --- Created an attachment (id=7896) patch EPCell.java CellType.java to allow formula cell content
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/pipeline/impl AbstractCachingProcessingPipeline.java
cziegeler2003/08/20 01:34:16
Modified:src/java/org/apache/cocoon/components/pipeline/impl
AbstractCachingProcessingPipeline.java
Log:
Don't throw an exception if the cached content is not correct. Just don't use it
Revision ChangesPath
1.13 +48 -39
cocoon-2.1/src/java/org/apache/cocoon/components/pipeline/impl/AbstractCachingProcessingPipeline.java
Index: AbstractCachingProcessingPipeline.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/pipeline/impl/AbstractCachingProcessingPipeline.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- AbstractCachingProcessingPipeline.java11 Aug 2003 07:33:08 - 1.12
+++ AbstractCachingProcessingPipeline.java20 Aug 2003 08:34:16 - 1.13
@@ -719,50 +719,59 @@
}
SourceValidity[] validities = cachedObject.getValidityObjects();
if (validities == null || validities.length != 1) {
-throw new ProcessingException(Cached response is not
correct.);
-}
-SourceValidity cachedValidity = validities[0];
-int result = cachedValidity.isValid();
-boolean valid = false;
-if ( result == 0 ) {
-// get reader validity and compare
-if (isCacheableProcessingComponent) {
-readerValidity =
((CacheableProcessingComponent)super.reader).getValidity();
-} else {
-CacheValidity cv =
((Cacheable)super.reader).generateValidity();
-if ( cv != null ) {
-readerValidity =
CacheValidityToSourceValidity.createValidity( cv );
-}
+// to avoid getting here again and again, we delete it
+this.cache.remove( pcKey );
+if (this.getLogger().isDebugEnabled()) {
+this.getLogger().debug(
+Cached response for ' + environment.getURI() +
+' using key: + pcKey + is invalid.
+);
}
-if (readerValidity != null) {
-result = cachedValidity.isValid(readerValidity);
-if ( result == 0 ) {
-readerValidity = null;
+cachedResponse = null;
+} else {
+SourceValidity cachedValidity = validities[0];
+int result = cachedValidity.isValid();
+boolean valid = false;
+if ( result == 0 ) {
+// get reader validity and compare
+if (isCacheableProcessingComponent) {
+readerValidity =
((CacheableProcessingComponent)super.reader).getValidity();
} else {
-valid = (result == 1);
+CacheValidity cv =
((Cacheable)super.reader).generateValidity();
+if ( cv != null ) {
+readerValidity =
CacheValidityToSourceValidity.createValidity( cv );
+}
}
+if (readerValidity != null) {
+result = cachedValidity.isValid(readerValidity);
+if ( result == 0 ) {
+readerValidity = null;
+} else {
+valid = (result == 1);
+}
+}
+} else {
+valid = (result 0);
}
-} else {
-valid = (result 0);
-}
-if (valid) {
-if (this.getLogger().isDebugEnabled()) {
-this.getLogger().debug(processReader: using valid
cached content for ' + environment.getURI() + '.);
-}
-byte[] response = cachedObject.getResponse();
-if (response.length 0) {
-usedCache = true;
-outputStream = environment.getOutputStream(0);
-
Re: [RT] Improving Sitemap and Flowscript
Stefano: So, after making a request for this a few days ago, with some people's help (a suggestion to look into mounted sitemaps) there seems to be an already existing solution. Rather than adding extra functionality to support doing this in cocoon.xconf, wouldn't it make more sense to just ship an extra sitemap with the default distribution? It could exist in WEB-INF as like base.xmap or something and be referenced in cocoon.xconf as the main sitemap. Then, it does: map:match pattern=** map:mount check-reload=yes src=sitemap.xmap uri-prefix= / /map:match It makes more sense to me to use this already existing feature before tacking on a new one. I've already started using this solution on my websites and it seems to do the trick rather well (and also keep the default error handler in it so I don't need that in my sitemaps either). I'd still like to see a better cocoon.xconf refactorization (so I could have a single file with just my datasources/ configuration), but I'm guessing real blocks would deal with that? Regardless, I still haven't gotten around to really reading through and absorbing the page on blocks that someone referred me to (so in reference to your other e-mail; this happened on the users list, though, not sure if you saw it). Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] - Original Message - From: Stefano Mazzocchi [EMAIL PROTECTED] To: Apache Cocoon [EMAIL PROTECTED] Sent: Friday, August 15, 2003 5:11 PM Subject: [RT] Improving Sitemap and Flowscript ... Moving Sitemap components into cocoon.xconf --- the default sitemap is too verbose and this scares people away. I would like to move the default sitemap component definitions into the cocoon.xconf. Note that with blocks, the definitions of those components will be in the block.xconf as well and this will be aggregated by the block manager. ... -- Stefano.
Woody flow example do not work
I do not think it's a thing to be put into bugzilla so it goes here: while the standard woody form example is fully functional the flow version does not allow you to add or remove a contact. cocoon version: today's CVS LG -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(600)341118 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
Re: Status of Woody?
Timothy Larson wrote: What is the current status of Woody? status is still alfa (as in 'getting there') it should be usable for smaller short-lived projects here and now (gets the job done) but that usage is bound to generate more clues on typical usage that could guide us through essesntial refactorings in short: the code is probably more stable then the interfaces to it :-) I am running the nightly snapshot from 19-Aug-2003 03:17. http://cvs.apache.org/snapshots/cocoon-2.1/cocoon-2.1_20030819101653.tar.gz Several of the samples do not work: Various -- adds blank rows to Firstname Lastname... table at the bottom. I'm running cvs head and didn't see this (the firstname should be filled in) XML Binding -- Cannot add or remove contacts just tested this and saw the same, looks like a problem with the formhandler, I'll need a deeper look (but short on time here and now) Bean Binding -- Cannot add or remove contacts didn't test, but is using the same formhandler, so kinda logic Uh, 2nd thought: not logic at all: the Various sample is using the same FormHandler and it works over there! So this is actually tied to how the flow is dealing with the formhandler! (that's a part I haven't looked into) I know development is ongoing. Are these samples just not updated yet to match the code changes, or am I encountering Woody errors? probably a small Woody error in how it is tied up to the FlowScript... (need to check for updates in cvs there) regards, -marc= PS: Bruno is on holiday this week... -- 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]
Re: [RT] Improving Views
leo leonid wrote: On Mittwoch, August 20, 2003, at 09:07 Uhr, Carsten Ziegeler wrote: It's seems we have RT Time :) With views we have a nice sitemap feature that imho can be improved as well: One major disadvantage currently is that views are not inherited to subsitemaps, so I: Views should be inherited and can be extended/overwritten in subsitemaps like any other component. Views are used for different scenarios; they provide a different ending of your pipeline. This is e.g. useful for debugging. Now by default the content view is enabled (for the main sitemap), and most times this view is not disabled when the application goes in production, so a user can invoke this view on deployed applications and see the output of the generator. But, this might contain sensitive data which is not intended to be seen by the average user. So it makes sense to have a way to turn off views. But at the same time you might need views in different areas of your application, so: Views can have a default state: enabled or disabled that can be set in the sitemap: map:views default=enabled (or disabled) This default can be overwritten on a map:pipeline base: map:pipeline views=disabled (or enabled) In addition, you can allow only some views, like: map:pipeline allow-views=x,z And now you :) I think it is not sufficient to have views that can be enabled/disabled. Sometimes other components depend on certain views (like the Lucene indexer) and so you can't disable. Maybe we need a sort of access restriction mechanism. Like map:pipeline views=internal or map:pipeline allow-views=x,y internal-views=a,b? The same would apply to the command line/bean, which requires link view, but which you might not want to expose to the public. Upayavira
Re: Status of Woody?
Timothy Larson wrote:
What is the current status of Woody?
I am running the nightly snapshot from 19-Aug-2003 03:17.
http://cvs.apache.org/snapshots/cocoon-2.1/cocoon-2.1_20030819101653.tar.gz
Several of the samples do not work:
Various -- adds blank rows to Firstname Lastname... table at the bottom.
XML Binding -- Cannot add or remove contacts
Bean Binding -- Cannot add or remove contacts
I know development is ongoing. Are these samples just not updated yet to
match the code changes, or am I encountering Woody errors?
There has be no code change that should have intentionally broken
these samples.
This means we have to investigate and fix the bug ;-)
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: [RT] Improving Sitemap and Flowscript
So, after making a request for this a few days ago, with some people's help (a suggestion to look into mounted sitemaps) there seems to be an already existing solution. Rather than adding extra functionality to support doing this in cocoon.xconf, wouldn't it make more sense to just ship an extra sitemap with the default distribution? It could exist in WEB-INF as like base.xmap or something and be referenced in cocoon.xconf as the main sitemap. :) +1 I think it could be called components.xconf since it is all about. I think it could not be a big change if we separate the current sitemap.xmap in: WEB-INF/components.xconf- map:components part of current sitemap.xmap sitemap.xmap- just map:pipelines To dont make the change to traumatic to the overall code, initially we can specialize a class of the current sitemap processor that just will merge this to files in in once and give the control back to the current sitemap processor. What do you think? Note: merging map:components and cocoon.xconf will be worse. Newbies tend to keep away from cocooon.xconf because they simple does not understand it (I said that based in my own experience). Best Regards, Antonio Gallardo
Re: [RT] Improving Sitemap and Flowscript
note I resend again this post, since I dont got it in my mailbox. It seems like the 2 virus in the wild (Sobig.f and MSBlast) are causing major troubles in the Internet... Please stop using the major virus called Windows ;-D /note So, after making a request for this a few days ago, with some people's help (a suggestion to look into mounted sitemaps) there seems to be an already existing solution. Rather than adding extra functionality to support doing this in cocoon.xconf, wouldn't it make more sense to just ship an extra sitemap with the default distribution? It could exist in WEB-INF as like base.xmap or something and be referenced in cocoon.xconf as the main sitemap. :) +1 I think it could be called components.xconf since it is all about. I think it could not be a big change if we separate the current sitemap.xmap in: WEB-INF/components.xconf- map:components part of current sitemap.xmap sitemap.xmap- just map:pipelines To dont make the change to traumatic to the overall code, initially we can specialize a class of the current sitemap processor that just will merge this to files in in once and give the control back to the current sitemap processor. What do you think? Note: merging map:components and cocoon.xconf will be worse. Newbies tend to keep away from cocooon.xconf because they simple does not understand it (I said that based in my own experience). Best Regards, Antonio Gallardo
RE: Using cocoon: source in xsl:imports
Vadim Gritsenko wrote: Phil Shafer wrote: Vadim Gritsenko writes: Try the suggestion above. Will do. Thanks for the help. Is there a PR open for this? Should I open one? I think there is no bug open for this. Also, I'd ping Carsten to hear his opinion. Carsten? PS Thread: http://marc.theaimsgroup.com/?t=10606751317r=1w=2 Pong. I think this is something the internal processing should handle, which means, if the reader sets such a header it should simply be ignored instead of being passed on. Now, I guess this is very easy as we could create a response wrapper for internal requests (we already have a request wrapper) and filter the headers. Carsten
cvs commit: cocoon-2.1/src/blocks/portal/samples sitemap.xmap
cziegeler2003/08/20 05:05:35
Modified:
src/blocks/portal/java/org/apache/cocoon/portal/layout/renderer/aspect/impl
WindowAspect.java CompositeContentAspect.java
TabContentAspect.java
src/blocks/portal/conf portal.samplesxconf
src/blocks/portal/samples sitemap.xmap
Log:
Fixing parameter handling
Revision ChangesPath
1.6 +10 -3
cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/layout/renderer/aspect/impl/WindowAspect.java
Index: WindowAspect.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/layout/renderer/aspect/impl/WindowAspect.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- WindowAspect.java 19 Aug 2003 14:09:34 - 1.5
+++ WindowAspect.java 20 Aug 2003 12:05:35 - 1.6
@@ -81,19 +81,25 @@
final PreparedConfiguration config =
(PreparedConfiguration)context.getAspectConfiguration();
final CopletInstanceData copletInstanceData =
((CopletLayout)layout).getCopletInstanceData();
-XMLUtils.startElement(contenthandler, config.tagName);
+if ( config.rootTag ) {
+XMLUtils.startElement(contenthandler, config.tagName);
+}
XMLUtils.createElement(contenthandler, title,
copletInstanceData.getCopletData().getTitle());
context.invokeNext( layout, service, contenthandler );
-XMLUtils.endElement(contenthandler, config.tagName);
+if ( config.rootTag ) {
+XMLUtils.endElement(contenthandler, config.tagName);
+}
}
protected class PreparedConfiguration {
public String tagName;
+public boolean rootTag;
public void takeValues(PreparedConfiguration from) {
this.tagName = from.tagName;
+this.rootTag = from.rootTag;
}
}
@@ -104,6 +110,7 @@
throws ParameterException {
PreparedConfiguration pc = new PreparedConfiguration();
pc.tagName = configuration.getParameter(tag-name, window);
+pc.rootTag = configuration.getParameterAsBoolean(root-tag, true);
return pc;
}
1.5 +10 -3
cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/layout/renderer/aspect/impl/CompositeContentAspect.java
Index: CompositeContentAspect.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/layout/renderer/aspect/impl/CompositeContentAspect.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- CompositeContentAspect.java 19 Aug 2003 14:09:34 - 1.4
+++ CompositeContentAspect.java 20 Aug 2003 12:05:35 - 1.5
@@ -85,9 +85,13 @@
throws SAXException {
PreparedConfiguration config =
(PreparedConfiguration)context.getAspectConfiguration();
-XMLUtils.startElement(handler, config.tagName);
+if ( config.rootTag ) {
+XMLUtils.startElement(handler, config.tagName);
+}
super.toSAX(context, layout, service, handler);
-XMLUtils.endElement(handler, config.tagName);
+if ( config.rootTag ) {
+XMLUtils.endElement(handler, config.tagName);
+}
}
@@ -120,9 +124,11 @@
protected class PreparedConfiguration {
public String tagName;
+public boolean rootTag;
public void takeValues(PreparedConfiguration from) {
this.tagName = from.tagName;
+this.rootTag = from.rootTag;
}
}
@@ -133,6 +139,7 @@
throws ParameterException {
PreparedConfiguration pc = new PreparedConfiguration();
pc.tagName = configuration.getParameter(tag-name, composite);
+pc.rootTag = configuration.getParameterAsBoolean(root-tag, true);
return pc;
}
1.11 +7 -3
cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/layout/renderer/aspect/impl/TabContentAspect.java
Index: TabContentAspect.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/layout/renderer/aspect/impl/TabContentAspect.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- TabContentAspect.java 19 Aug 2003 14:09:34 - 1.10
+++ TabContentAspect.java 20 Aug 2003 12:05:35 - 1.11
@@ -88,7 +88,9 @@
if (layout instanceof CompositeLayout) {
TabPreparedConfiguration config =
cvs commit: cocoon-2.1/src/blocks/session-fw/java/org/apache/cocoon/webapps/session/components AbstractSessionComponent.java
cziegeler2003/08/20 05:11:13 Modified:src/blocks/session-fw/java/org/apache/cocoon/webapps/session/components AbstractSessionComponent.java Log: Changing comment Revision ChangesPath 1.3 +7 -3 cocoon-2.1/src/blocks/session-fw/java/org/apache/cocoon/webapps/session/components/AbstractSessionComponent.java Index: AbstractSessionComponent.java === RCS file: /home/cvs/cocoon-2.1/src/blocks/session-fw/java/org/apache/cocoon/webapps/session/components/AbstractSessionComponent.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- AbstractSessionComponent.java 4 May 2003 20:19:41 - 1.2 +++ AbstractSessionComponent.java 20 Aug 2003 12:11:13 - 1.3 @@ -73,8 +73,12 @@ import org.xml.sax.SAXException; /** - * The base class for all components - * + * The base class for own components + * This is only here for compatibility + * + * @deprecated Lookup the components yourself and use contextualizable to get the + * current object model + * * @author a href=mailto:[EMAIL PROTECTED]Carsten Ziegeler/a * @version CVS $Id$ */
DO NOT REPLY [Bug 20271] - [PATCH] General background task manager leveraging Avalon
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=20271. 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=20271 [PATCH] General background task manager leveraging Avalon --- Additional Comments From [EMAIL PROTECTED] 2003-08-20 13:55 --- A couple weeks ago, I pulled down 2.1rc1 to get the task stuff integrated nicely with it. My goal was to create a package that could easily be added into 2.1 and run right out of the box. I was mostly sucessfull. I can configure tasks that time trigger. I got stuck on the pipeline trigger (by action) and posted a note to the cocoon-dev list about the issue. Then, work started calling... I'm supposed to go on vacation today (for the first time in 3.5 years) and when I get back next week, I'll try to wrap that up and convert(and update) the documentation. THanks!
Re: cvs commit: cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/components/persistanceRequestDataStoreImpl.java RequestDataStore.java
[EMAIL PROTECTED] wrote:
cziegeler2003/08/20 00:34:37
Modified:src/blocks/portal/java/org/apache/cocoon/portal/impl
PortalServiceImpl.java
src/blocks/portal/conf portal.xconf
Added: src/blocks/portal/java/org/apache/cocoon/portal/impl
PortalServiceInfo.java
src/blocks/portal/java/org/apache/cocoon/components/persistance
RequestDataStoreImpl.java RequestDataStore.java
Log:
Removing use of RequestLifecycleComponent
Adding new request data store instead
snip/
package org.apache.cocoon.components.persistance;
My english dictionnary tells me that this should be spelled persistence...
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
cvs commit: cocoon-2.1/src/blocks/webdav/samples/flowsample/styles dir2html.xsl file2html.xsl new2html.xsl request2data.xsl request2meta.xsl
gcasper 2003/08/20 08:26:43
Added: src/blocks/webdav/samples/flowsample edit.js new.xml
sitemap.xmap
src/blocks/webdav/samples/flowsample/repo contentA.xml
contentA.xml.meta
src/blocks/webdav/samples/flowsample/repo/dir1 contentB.xml
contentB.xml.meta contentC.xml contentC.xml.meta
src/blocks/webdav/samples/flowsample/repo/dir2 contentA.xml
contentA.xml.meta contentB.xml contentB.xml.meta
contentC.xml contentC.xml.meta
src/blocks/webdav/samples/flowsample/repo/dir2/subdir1
contentA.xml contentA.xml.meta
src/blocks/webdav/samples/flowsample/styles dir2html.xsl
file2html.xsl new2html.xsl request2data.xsl
request2meta.xsl
Log:
Added WebDAV sample using flow
TODO: move to a repository abstraction like Linotype's once that has
stabilized
Revision ChangesPath
1.1 cocoon-2.1/src/blocks/webdav/samples/flowsample/edit.js
Index: edit.js
===
function editPage() {
var page = cocoon.parameters[page];
var repoUri = cocoon.parameters[repo];
var editPage = editpage/ + page;
var docUri = repo/ + page;
cocoon.sendPageAndWait(editPage, {});
writeDoc(repoUri+docUri, getdata);
writeDoc(repoUri+docUri+.meta, getmetadata);
var dir = docUri.substring(0, docUri.lastIndexOf(/)+1);
cocoon.sendPage(dir, {});
}
function newPage() {
var dir = cocoon.parameters[dir];
var repoUri = cocoon.parameters[repo];
cocoon.sendPageAndWait(newpage, {});
var page = cocoon.request.getParameter(filename);
var docUri = dir+page;
writeDoc(repoUri+docUri, getdata);
writeDoc(repoUri+docUri+.meta, getmetadata);
cocoon.sendPage(dir, {});
}
function writeDoc(doc, pipeline) {
var resolver = null;
var source = null;
var output = null;
try {
resolver =
cocoon.getComponent(Packages.org.apache.excalibur.source.SourceResolver.ROLE);
source = resolver.resolveURI(doc);
if (source instanceof Packages.org.apache.excalibur.source.ModifiableSource)
{
output = source.getOutputStream();
cocoon.processPipelineTo(pipeline, {}, output);
output.close();
} else {
cocoon.log.error(Cannot write to + doc + : not a modifiable source);
}
} catch (error) {
cocoon.log.error(Error getting output stream: + error);
} finally {
if (source != null) resolver.release(source);
cocoon.releaseComponent(resolver);
if (output != null) {
try {
output.close();
} catch (error) {
cocoon.log.error(Error closing output stream: + error);
}
}
}
}
1.1 cocoon-2.1/src/blocks/webdav/samples/flowsample/new.xml
Index: new.xml
===
?xml version=1.0?
page
page
titleTitle/title
content
paraParagraph 1/para
paraParagraph 2/para
/content
/page
metapage
authoryou/author
category/category
statenew/state
/metapage
/page
1.1 cocoon-2.1/src/blocks/webdav/samples/flowsample/sitemap.xmap
Index: sitemap.xmap
===
?xml version=1.0?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:components
map:generators default=file
map:generator name=traverse
src=org.apache.cocoon.generation.TraversableGenerator/
map:generator name=jx src=org.apache.cocoon.generation.JXTemplateGenerator/
/map:generators
map:transformers default=xslt
map:transformer name=jx
src=org.apache.cocoon.transformation.JXTemplateTransformer/
/map:transformers
/map:components
map:flow language=javascript
map:script src=edit.js/
/map:flow
map:pipelines
map:component-configurations
global-variables
staging/staging
!--stagingwebdav://localhost/webdav/flowsample//staging--
/global-variables
/map:component-configurations
map:pipeline
map:match pattern=**/*.kont
map:call continuation={2}/
/map:match
map:match pattern=**/new
map:call function=newPage
map:parameter name=dir value={1}//
map:parameter name=repo value={global:staging}/
/map:call
/map:match
map:match pattern=repo/
map:generate type=traverse src={global:staging}repo/
map:parameter name=exclude value=[\w]*.meta/
/map:generate
RE: can you reach sitemap params from JXTemplate?
Without trying it ...
#{parameters.myParameter} should do it ...
Cheers,
Reinhard
-Original Message-
From: Jeremy Quinn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 20, 2003 4:35 PM
To: [EMAIL PROTECTED]
Subject: can you reach sitemap params from JXTemplate?
Hi All
Does anyone know the correct syntax for getting a Sitemap
parameter in
JXTemplate?
I have tried all of the following:
#{cocoon/parameters[publishedJobServer]}
#{cocoon/parameters/publishedJobServer/}
${cocoon.parameters[publishedJobServer]}
${cocoon.getParameters(publishedJobServer)}
${cocoon.parameters.publishedJobServer}
The first two throw exceptions, the others output nothing.
I can use cocoon.getParameters(publishedJobServer) in my FlowScript
without a problem, but I would prefer not to have to pass it
specially
to the view in cocoon.sendPage().
Any ideas?
thanks
regards Jeremy
cvs commit: cocoon-2.1/src/blocks/webdav/samples/flowsample/styles - New directory
gcasper 2003/08/20 08:17:30 cocoon-2.1/src/blocks/webdav/samples/flowsample/styles - New directory
cvs commit: cocoon-2.1/src/blocks/webdav/samples/flowsample/repo - New directory
gcasper 2003/08/20 08:17:04 cocoon-2.1/src/blocks/webdav/samples/flowsample/repo - New directory
cvs commit: cocoon-2.1/src/blocks/webdav/samples/flowsample/repo/dir2/subdir1 - New directory
gcasper 2003/08/20 08:21:25 cocoon-2.1/src/blocks/webdav/samples/flowsample/repo/dir2/subdir1 - New directory
Re: can you reach sitemap params from JXTemplate?
On Wednesday, August 20, 2003, at 06:11 PM, Sylvain Wallez wrote:
Jeremy Quinn wrote:
Hi All
Does anyone know the correct syntax for getting a Sitemap parameter
in JXTemplate?
I have tried all of the following:
#{cocoon/parameters[publishedJobServer]}
#{cocoon/parameters/publishedJobServer/}
${cocoon.parameters[publishedJobServer]}
${cocoon.getParameters(publishedJobServer)}
${cocoon.parameters.publishedJobServer}
The first two throw exceptions, the others output nothing.
I can use cocoon.getParameters(publishedJobServer) in my FlowScript
without a problem, but I would prefer not to have to pass it
specially to the view in cocoon.sendPage().
Any ideas?
The cocoon object only exists in the flowscript. In JXTemplate, you
can directly access the parameters variable :
#{$parameters.getParameter('publishedJobServer')}
I cannot get this to work, I get:
org.apache.commons.jxpath.JXPathException: Invalid XPath:
'$parameters.getParameter(\publishedJobServer\)'. Syntax error after:
'$p'
If I try :
${$parameters.getParameter('publishedJobServer')}
nothing happens
This makes me think we should unify the notation across the various
components of a flow-script application.
In this regard, it would be more consistent to have request,
session, context and parameter as children of a cocoon
variable instead of having them directly as toplevel variables.
I agree
Or are they available as toplevel variables to mimic JSTL from which
JXTemplate is inspired ?
They look like they are by a cursory reading of the code, but I have
not been able to read many yet ;)
Thanks for your suggestions
regards Jeremy
Re: can you reach sitemap params from JXTemplate?
On Wednesday, August 20, 2003, at 05:42 PM, Reinhard Pötz wrote:
Without trying it ...
#{parameters.myParameter} should do it ...
no go
tried both:
#{parameters.publishedJobServer}
${parameters.publishedJobServer}
no output on either
thanks
regards Jeremy
Cheers,
Reinhard
-Original Message-
From: Jeremy Quinn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 20, 2003 4:35 PM
To: [EMAIL PROTECTED]
Subject: can you reach sitemap params from JXTemplate?
Hi All
Does anyone know the correct syntax for getting a Sitemap
parameter in
JXTemplate?
I have tried all of the following:
#{cocoon/parameters[publishedJobServer]}
#{cocoon/parameters/publishedJobServer/}
${cocoon.parameters[publishedJobServer]}
${cocoon.getParameters(publishedJobServer)}
${cocoon.parameters.publishedJobServer}
The first two throw exceptions, the others output nothing.
I can use cocoon.getParameters(publishedJobServer) in my FlowScript
without a problem, but I would prefer not to have to pass it
specially
to the view in cocoon.sendPage().
Any ideas?
thanks
regards Jeremy
[OT] Not getting emails
I'd noticed that traffic is very low -- because I'm not getting all the emails which I can see on marc. I hope that this is temprorary situation, may be due to overloaded mail servers in between, and I hope I'll get those emails eventually... Vadim
Re: forced caching of volatile data
Sorry for the late reply. Vacation time + lousy GPRS + heavy spam/worm
activities nearly killed my ability to read email.
Miles Elam wrote:
I'm running into a snag and was wondering if anyone had some wisdom to
grant to me. The current behavior of caching pipelines is to aggregate
the keys of all cacheable pipeline components and use them as the cache
hash lookup. In the case of a pipeline that has uncacheable components
but has an expiry, this scheme doesn't work: the key is incomplete or
nonexistent. My first thought was to use the request URI but therein
lies the snag; Any actions or selectors in use that would fundamentally
alter the request would be erroneously cached. In 90% of the cases, I
don't see this as a problem. But in cases like when different formats
are sent to different clients for the same URI
Yes, this was exactly my showstopper when I tried to quickly force
caching uncacheable stuff. I really need to catch up on caching
internals as it's been a few months since I looked at it, but I was
kinda of planning to add a fake cache key for each component in the
pipeline which is uncacheable. The problem is coming up with a syntax
that is reversible, so that the resulting key can be successfully looked up.
The trick should lie somewhere in
o.a.c.components.pipeline.impl.AbstractCachingProcessingPipeline#generateCachingKey():
there should be, in particular, some kind of surrogate that returns a
key for each non cacheable component. I'm still uncertain whether this
key should be unique (based, i.e., on the positional parameter of the
component in the sitemap) or if a simple label could work. I'm for the
latter ATM: of course I need to check it out, but the following snippet
(extended to transformers serializer) might work.
// is the generator cacheable?
if (super.generator instanceof CacheableProcessingComponent) {
key = ((CacheableProcessingComponent)super.generator).getKey();
this.generatorIsCacheableProcessingComponent = true;
} else if (super.generator instanceof Cacheable) {
key = new Long(((Cacheable)super.generator).generateKey());
} else if (expires != 0) {
// Component is not cacheable, but an explicit expires
// was set. Provide a fake cache key.
key = new String(Forced-Expires);
}
Doing so, we would end up with a PipelineCacheKey that's made up of
different caching keys, some of which are real and some of which are
just placeholders. I'm going to try this path and see what comes out of it.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
cvs commit: cocoon-2.1 status.xml
joerg 2003/08/20 10:29:07
Modified:
src/blocks/poi/java/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements
EPCell.java CellType.java Cell.java
.status.xml
Log:
POI: fixed formula support (Bug 22574, thanks to Neil Bacon)
Revision ChangesPath
1.4 +3 -2
cocoon-2.1/src/blocks/poi/java/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/EPCell.java
Index: EPCell.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/poi/java/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/EPCell.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- EPCell.java 14 Jun 2003 00:26:27 - 1.3
+++ EPCell.java 20 Aug 2003 17:29:07 - 1.4
@@ -233,7 +233,8 @@
*/
public void initialize(final Attribute[] attributes, final ElementProcessor
parent) throws IOException {
super.initialize(attributes, parent);
-int cellType = -1;
+// default value (when gmr:Cell has no ValueType attribute)
+int cellType = CellType.CELL_TYPE_FORMULA;
try {
cellType = getCellType();
} catch (NullPointerException ignored) {
1.3 +13 -24
cocoon-2.1/src/blocks/poi/java/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/CellType.java
Index: CellType.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/poi/java/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/CellType.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- CellType.java 11 Mar 2003 19:05:01 - 1.2
+++ CellType.java 20 Aug 2003 17:29:07 - 1.3
@@ -52,8 +52,6 @@
package org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements;
-
-
import org.apache.poi.hssf.usermodel.HSSFCell;
/**
@@ -62,8 +60,10 @@
* @author Marc Johnson ([EMAIL PROTECTED])
* @version CVS $Id$
*/
-public class CellType
-{
+public class CellType {
+
+
+public static final int CELL_TYPE_FORMULA = -1;
public static final int CELL_TYPE_EMPTY = 10;
public static final int CELL_TYPE_BOOLEAN = 20;
public static final int CELL_TYPE_INTEGER = 30;
@@ -73,33 +73,27 @@
public static final int CELL_TYPE_CELLRANGE = 70;
public static final int CELL_TYPE_ARRAY = 80;
-private CellType()
-{
+private CellType() {
}
/**
* Is this a valid cell type?
*
* @param val value to be checked
- *
* @return true if valid, false otherwise
*/
-
-public static boolean isValid(final int val)
-{
-switch (val)
-{
-
+public static boolean isValid(final int val) {
+switch (val) {
case CELL_TYPE_EMPTY :
case CELL_TYPE_BOOLEAN :
case CELL_TYPE_INTEGER :
case CELL_TYPE_FLOAT :
case CELL_TYPE_ERROR :
case CELL_TYPE_STRING :
+case CELL_TYPE_FORMULA :
case CELL_TYPE_CELLRANGE :
case CELL_TYPE_ARRAY :
return true;
-
default :
return false;
}
@@ -109,22 +103,17 @@
* Convert a CellType enum into an HSSFCell enum
*
* @param val the value to be converted
- *
* @return the converted value
*/
-
-static int convertCellType(final int val)
-{
-switch (val)
-{
-
+static int convertCellType(final int val) {
+switch (val) {
case CELL_TYPE_INTEGER :
case CELL_TYPE_FLOAT :
return HSSFCell.CELL_TYPE_NUMERIC;
-
case CELL_TYPE_STRING :
return HSSFCell.CELL_TYPE_STRING;
-
+case CELL_TYPE_FORMULA :
+return HSSFCell.CELL_TYPE_FORMULA;
default :
return HSSFCell.CELL_TYPE_BLANK;
}
1.5 +1 -8
cocoon-2.1/src/blocks/poi/java/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/Cell.java
Index: Cell.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/poi/java/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/Cell.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Cell.java 8 Aug 2003 13:42:47 - 1.4
+++ Cell.java 20 Aug 2003 17:29:07 - 1.5
@@ -108,13 +108,6 @@
* @exception IOException
*/
void setContent(final String content) throws
Checkboxes in JXForms - javascript OK, java NOT
Based on the samples, I've been looking at checkboxes in JXForms and have a few
questions...
Given the following snippet from an xform definition:
xf:select ref=validchecks appearance=full
xf:labelCheck if field is Present amp; Legible/xf:label
xf:itemset nodeset=fieldset
xf:label ref=key/
xf:value ref=value/
/xf:itemset
/xf:select
1) Do you have to use the nodeset? This is fine if you want multiple checks, but if I
just want one checkbox? I tried a number of things, but none worked. e.g. an
xf:input with a hard-coded type=checkbox. This displayed okay, but the
checked/unchecked state wasn't recorded anywhere that I could find. If you don't need
the nodeset, is there a sample and/or docs?
2) I got the above to work in javascript with the following structure.
var modelObj= {
validchecks: [],
// define a nodeset (list of all checkboxes in a group)
fieldset: [{key:Description, value:desc},// key=what to display,
value=what to store in var
{key:Name, value:name},
etc...
};
form.setModel(modelObj);
form.sendView(form/form-submit.xml);
When I hit submit, the validchecks is filled out with the value of anything that was
checked.
3) Instead of using an object defined in javascript, I wanted to use my own Java Bean
(to facilitate access to the form data after submit). The javascript now looks like:
var modelObj = new Packages.elrsproto.FormBean();
form.setModel(modelObj);
form.sendView(form/form-submit.xml);
The FormBean looks like this:
public class FormBean
{
private String validchecks;
private FieldBean[] fieldset = {
new FieldBean(Description, desc),
new FieldBean(Name, name),
etc...
};
...
FieldBean is a helper class that contains two strings named key and value.
This displays correctly on screen (i.e. looks the same as the totally javascript
version). The plain edit controls on the form and their String representations in the
FormBean (not shown) work fine. However, only the value of the first selected
checkbox shows up. If I check five checkboxes, I only see one value in the
validchecks variable. When I do this in javascript, I see a comma-delimited list
with all of the selected values.
Does this fall under the heading of you aren't supposed to do that, so don't? Is
this a bug? Do I just have the syntax wrong? (I tried a number of things, like
making the validchecks an array, but they all threw errors of varying sorts.)
Help.
Thanks,
Chris
Need help fixing a Woody flow sample
In woody.js [1] there was a change in version 1.6 that stopped calling:
cocoon.request.setAttribute(this.attrName, this.form);
and did this instead:
var bizData = { woody-form: this.form };
This will require a change in this part of form1_success.xsp [2]:
// get reference to form and some of the widgets on it
Form form = (Form)request.getAttribute(form1);
Field field = (Field)form.getWidget(email);
IIUC the change would involve using the jpath logicsheet, but I have
not been able to figure out how to get the Form object.
Anybody know how to do this?
[1] cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js
[2] cocoon-2.1/src/blocks/woody/samples/forms/form1_success.xsp
--Tim Larson
__
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
cvs commit: cocoon-2.1/src/blocks/webdav/samples/davmap webdav.js sitemap.xmap
gcasper 2003/08/20 11:57:22
Modified:src/blocks/webdav/samples/davmap sitemap.xmap
Added: src/blocks/webdav/samples/davmap webdav.js
Log:
Moved request routing to flowscript
This further simplifies the sitemap (the flowscript is barely 4 lines) and
hopefully flattens the way to using request factories
Revision ChangesPath
1.4 +100 -129 cocoon-2.1/src/blocks/webdav/samples/davmap/sitemap.xmap
Index: sitemap.xmap
===
RCS file: /home/cvs/cocoon-2.1/src/blocks/webdav/samples/davmap/sitemap.xmap,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- sitemap.xmap 10 Aug 2003 07:52:42 - 1.3
+++ sitemap.xmap 20 Aug 2003 18:57:21 - 1.4
@@ -6,132 +6,14 @@
map:generator name=traverse
src=org.apache.cocoon.generation.TraversableGenerator/
/map:generators
map:selectors default=browser
-map:selector logger=sitemap.selector.method name=request-method
src=org.apache.cocoon.selection.RequestMethodSelector/
map:selector logger=sitemap.selector.header name=depth
src=org.apache.cocoon.selection.HeaderSelector
header-nameDepth/header-name
/map:selector
/map:selectors
/map:components
-
-map:resources
-
-map:resource name=GET
- map:match pattern=repo/
-map:generate type=traverse src={global:staging}repo/
- map:parameter name=depth value=1/
-/map:generate
-map:serialize type=xml/
- /map:match
- map:match pattern=**
-map:generate src={global:staging}{1}/
-map:serialize type=xml/
- /map:match
-/map:resource
-
-map:resource name=OPTIONS
- map:match pattern=**
-map:act type=set-header
- map:parameter name=DAV value=DAV:1/
- map:parameter name=Allow value=OPTIONS, GET, HEAD, POST, DELETE,TRACE,
PROPFIND, PROPPATCH, COPY, MOVE/
-/map:act
-map:generate src=dummy.xml/
-map:serialize type=xml/
- /map:match
-/map:resource
-
-map:resource name=PROPFIND
- map:match pattern=**/*.*
-map:generate type=traverse src={global:staging}{1}//
-map:transform src={global:staging}styles/file2propfind0.xsl
- map:parameter name=requestURI value={request:requestURI}/
- map:parameter name=directory value={1}/
- map:parameter name=file value={2}.{3}/
-/map:transform
-map:serialize type=xml status-code=207/
- /map:match
- map:match pattern=**/
-map:generate type=traverse src={global:staging}{1}//
-map:select type=depth
- map:when test=0
-map:transform src={global:staging}styles/dir2propfind0.xsl
- map:parameter name=requestURI value={request:requestURI}/
-/map:transform
- /map:when
- map:otherwise
-map:transform src={global:staging}styles/dir2propfind1.xsl
- map:parameter name=requestURI value={request:requestURI}/
-/map:transform
- /map:otherwise
-/map:select
-map:serialize type=xml status-code=207/
- /map:match
- map:match pattern=**
-map:generate type=traverse src={global:staging}{1}//
-map:select type=depth
- map:when test=0
-map:transform src={global:staging}styles/dir2propfind0.xsl
- map:parameter name=requestURI value={request:requestURI}/
-/map:transform
- /map:when
- map:otherwise
-map:transform src={global:staging}styles/dir2propfind1.xsl
- map:parameter name=requestURI value={request:requestURI}/
-/map:transform
- /map:otherwise
-/map:select
-map:serialize type=xml status-code=207/
- /map:match
-/map:resource
-
-map:resource name=PUT
- map:match pattern=**/*.*
-map:generate type=stream
- map:parameter name=defaultContentType value=text/xml/
-/map:generate
-map:transform src=styles/stream2write.xsl
- map:parameter name=file value={global:staging}{1}/{2}.{3}/
-/map:transform
-map:transform type=write-source/
-map:serialize/
- /map:match
-/map:resource
-
-map:resource name=DELETE
- map:generate src=dummy.xml/
- map:serialize type=xml/
-/map:resource
-
-map:resource name=COPY
- map:generate src=dummy.xml/
- map:serialize type=xml/
-/map:resource
-
-map:resource name=MOVE
- map:generate src=dummy.xml/
- map:serialize type=xml/
-/map:resource
-
-map:resource name=PROPPATCH
- map:generate src=dummy.xml/
- map:serialize type=xml/
-/map:resource
-
-map:resource name=LOCK
- map:generate src=dummy.xml/
- map:serialize type=xml/
-/map:resource
-
-map:resource name=HEAD
- map:generate src=dummy.xml/
- map:serialize type=xml/
-/map:resource
-
-map:resource name=TRACE
- map:generate src=dummy.xml/
- map:serialize type=xml/
-/map:resource
-
-/map:resources
+map:flow language=javascript
Re: forced caching of volatile data
I apologize if I've already mentioned this, but I think there are some
different angles on solving your problem which you may want to consider.
One is implemented in part in the event-cache block but it could be
generalized to work for any component. Unico Hommes wrote a Generator
(in that block, but don't know its name) which uses a Delegation pattern
to wrap any other arbitrary Generator. It delegates all interface
methods to the wrapped generator except for the get Validity (and
currently the key as well, but I think that might need to change. He
then uses a factory which specifies how to construct the overridden
validity. The plan was to generalize this to work with any component.
Hope that makes sense.
The second possibly simpler solution is to create a new pipeline
implementation that always caches. So, when you have a pipeline that
should be forced to cache, you segregate it into its own map:pipeline
section with a parameter that speficies how long to cache.
A third is to consider the event based cache stuff itself.
Geoff
Gianugo Rabellino wrote:
Sorry for the late reply. Vacation time + lousy GPRS + heavy spam/worm
activities nearly killed my ability to read email.
Miles Elam wrote:
I'm running into a snag and was wondering if anyone had some wisdom to
grant to me. The current behavior of caching pipelines is to
aggregate the keys of all cacheable pipeline components and use them
as the cache hash lookup. In the case of a pipeline that has
uncacheable components but has an expiry, this scheme doesn't work:
the key is incomplete or nonexistent. My first thought was to use the
request URI but therein lies the snag; Any actions or selectors in
use that would fundamentally alter the request would be erroneously
cached. In 90% of the cases, I don't see this as a problem. But in
cases like when different formats are sent to different clients for
the same URI
Yes, this was exactly my showstopper when I tried to quickly force
caching uncacheable stuff. I really need to catch up on caching
internals as it's been a few months since I looked at it, but I was
kinda of planning to add a fake cache key for each component in the
pipeline which is uncacheable. The problem is coming up with a syntax
that is reversible, so that the resulting key can be successfully looked
up.
The trick should lie somewhere in
o.a.c.components.pipeline.impl.AbstractCachingProcessingPipeline#generateCachingKey():
there should be, in particular, some kind of surrogate that returns a
key for each non cacheable component. I'm still uncertain whether this
key should be unique (based, i.e., on the positional parameter of the
component in the sitemap) or if a simple label could work. I'm for the
latter ATM: of course I need to check it out, but the following snippet
(extended to transformers serializer) might work.
// is the generator cacheable?
if (super.generator instanceof CacheableProcessingComponent) {
key = ((CacheableProcessingComponent)super.generator).getKey();
this.generatorIsCacheableProcessingComponent = true;
} else if (super.generator instanceof Cacheable) {
key = new Long(((Cacheable)super.generator).generateKey());
} else if (expires != 0) {
// Component is not cacheable, but an explicit expires
// was set. Provide a fake cache key.
key = new String(Forced-Expires);
}
Doing so, we would end up with a PipelineCacheKey that's made up of
different caching keys, some of which are real and some of which are
just placeholders. I'm going to try this path and see what comes out of it.
Ciao,
cvs commit: cocoon-2.1/src/blocks/webdav/samples/flowsample/repo/dir2 - New directory
gcasper 2003/08/20 08:18:34 cocoon-2.1/src/blocks/webdav/samples/flowsample/repo/dir2 - New directory
Re: Woody flow example do not work
Leszek Gawron wrote:
I do not think it's a thing to be put into bugzilla so it goes here:
while the standard woody form example is fully functional the flow version
does not allow you to add or remove a contact.
We've debugged this offline already (Marc and myself during a car ride
this afternoon), and changing line 156-157 into:
if (validator != undefined) {
finished = validator(this) finished;
will solve this as far as we can see now. But since Sylvain was quite
specific about this in his commit changing the original version some
days ago, we've not patched this before getting the word out to him.
Anyway, the reverting patch is attached if you can't wait.
Cheers,
/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
Index: src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js,v
retrieving revision 1.8
diff -u -r1.8 woody.js
--- src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js 16 Aug
2003 13:22:28 - 1.8
+++ src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js 20 Aug
2003 18:37:12 -
@@ -153,8 +153,8 @@
} else {
this.submitId = undefined;
}
-if (finished validator != undefined) {
-finished = validator(this);
+if (validator != undefined) {
+finished = validator(this) finished;
}
if (finished) {
break;
Re: forced caching of volatile data
Geoff Howard wrote: I apologize if I've already mentioned this, but I think there are some different angles on solving your problem which you may want to consider. One is implemented in part in the event-cache block but it could be generalized to work for any component. Unico Hommes wrote a Generator (in that block, but don't know its name) which uses a Delegation pattern to wrap any other arbitrary Generator. It delegates all interface methods to the wrapped generator except for the get Validity (and currently the key as well, but I think that might need to change. He then uses a factory which specifies how to construct the overridden validity. The plan was to generalize this to work with any component. Hope that makes sense. Interesting and worth a look, but I see a few problems: 1. Usability wise it might be uncomfortable for users to wrap every non cacheable sitemap component into a delegate (provided that users know what is cacheable and what is not); 2. There is no transformer yet (even if, agreed, it would be pretty easy to build one); 3. AFAIU, in order to use the delegate components, you should be using the EventAwareCacheImpl, am I wrong? This might be a serious showstopper. The whole idea of this expires-enabled stuff is that of a simple solution for a simple scenario where the user knows in advance for how long a pipeline might be valid. A sitemap parameter, and you are ready to go, just as httpd's mod_expires does ... I'm not sure that the delegate solution is understandable by a non java programmer: it requires quite a bit of understanding of how the event cache works and a good knowledge of Cocoon internals, don't you think so? The second possibly simpler solution is to create a new pipeline implementation that always caches. So, when you have a pipeline that should be forced to cache, you segregate it into its own map:pipeline section with a parameter that speficies how long to cache. Yes and no. We have been through this before, but again there is both a backward incompatibilty to consider (the current CachingProcessingPipeline supports Expires) and a fair amount of code duplication needed between the two implementations. But again, it's something to consider. A third is to consider the event based cache stuff itself. Which looks really cool, and definitely it's something to work on, apart from the Expires stuff. How much do you still consider it alpha stuff? Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
[RT] towards perfect application framework
Sorry if this is repost for any of you, I did not get it myself. This will be long. Here are some of my thought concerning building a proper web application (framework). Please mind that I started from the position of PHP user that barely knew Java and MVC concept. The second part is the reason why I wrote this post so if you do not have time just skip the part one * PART ONE * * Title: How I became a cocoon user * First I started to use cocoon in quite a PHP + templates style. I mean I've been using pipelining in cocoon just to provide the website with a common look. I've been handling the forms myself, which means managing the whole state machine with hidded input fields and so on. The actions at the time were a bliss. Especially when XSP action was introduced. When you do not know how to work with a bean model XSP action + ESQL is really a helpful thing. Then the problems came: - there were just too many actions - the sitemap language was a nightmare ( as matches, selectors and other sitemap components are just enough for document rendering, I think that coding flow in the sitemap was even a step backward from the ease I had in PHP). Especially when action-sets disappeared in 2.1 :) - when the SimpleFormTransformer was intruduced it was much easier (and cleaner) to fill the form with values but still it was not what tigers like the most. - my software users (and me really too) would like the software to present more advanced GUI - the most simple GUI there is is not usually ergonomic enough. At the time cocoon flow started to emerge and the potential was (is) huge. It was really nice to move all the logic to javascript code. I am still at the stage that I find calling actions from flow very useful. Maybe it should be all placed in business logic classes but as I said: up till now XSP action + ESQL rock! Today I am still coding my software the way I described (do not know how to do it the other way) so I started to fill a little stressed about the fact that it is not way I should do it. * PART TWO * * Title: toward the perfect web application and why such lame as me couldn't * achieve it with cocoon in it's current state * Title 2: a taste for even more Some of my research thoughts (this is the main purpose of this mail): flow + persistence + woody is not enough to create a full blown web application. Why? Just because web application is (according to me and my current knowledge state): 1. data model 2. business logic (in specific database actions) 3. flow (which pages are shown, what actions are being fired) 4. GUI ad 1. We can build various data models in cocoon (beans, xml). That's fine. There is always some but: the support for persistence is quite none. All the samples use the temporary solution creating sesions only for their own purpose. Some Avalon component would be needed I think (I am still digging into Avalon lifecycle - it's not easy). The rest would be a piece of cake. ad 2. We can code business logic in components, actions ad 3. flow is flow :) we got it WE DO NOT HAVE GUI FRAMEWORK! While Woody is nice and a great leap for mankind it's not enough to build a full blown up GUI. While looking for Eclipse plugins I have found a commercial package called W4Toolkit (http://www.w4toolkit.com). It is i think similar to .NET philosophy but coded entirely in Java. Please mind that I do not want to advertise any of the products. I am just pointing ideas ( I do not even like both :) ) Both .NET and W4Toolkit: - abstract coding web applications completely. While in .NET you can use ASP.NET pages which mix HTML with web controls, in W4Toolkit you have only Java objects. Both give user a set of controls like: - menu - tree control - panel - tabbed pane - standard form controls like edits, listbox, selects and so on. This is the first step: provide user with controls that would allow him to build a complete GUI ( implementing a tree control, either server side or client side is not easy) Second thing to do is to provide user with an invensive event model. For those: - .NET uses single hidden input which stores a page state ( binary form ) - really stupid from my point of view - for some pages the page content is a few kilobytes while state takes nearly 50 kB - W4Toolkit uses JavaScript intensively. Not a good idea in some environments also, but it allows to do quite anything concerning events - you can render a submit button as an image or a link, you can trigger an event while expanding a tree ) What are the biggest pros of unified GUI framework? - you abstract web programming even more. Writing a web application with a rich GUI would feel like writing a Java Swing application. There are even layout managers in W4Toolkit so you can do panel.add( control, layout.NORTH ); - you do not respond to low level submit names, hidden inputs and other weird techniques but just HANDLE THE
Re: [RT] Improving Sitemap and Flowscript
Antonio: The complaint I would have about a complete seperation of sitemaps (rather than my original sitemap override proposal, or my revised just use mounted subsitemaps) is that then, if you have a particular component that you want in your app, or a particular configuration of an existing one, you're back modifying the base sitemap. I would want components to be capable of going in either, and subsitemaps do that without any changes to the overall code :). Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] - Original Message - From: Antonio Gallardo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 20, 2003 5:57 AM Subject: Re: [RT] Improving Sitemap and Flowscript ... I think it could not be a big change if we separate the current sitemap.xmap in: WEB-INF/components.xconf- map:components part of current sitemap.xmap sitemap.xmap- just map:pipelines To dont make the change to traumatic to the overall code, initially we can specialize a class of the current sitemap processor that just will merge this to files in in once and give the control back to the current sitemap processor. What do you think? ... Best Regards, Antonio Gallardo
[miniRT] External namespaces in sitemaps
Quite a few sitemap components rely on parameters that actually contain XML element/attribute or XPath references: the first examples that cross my mind are XPath*Generator, HTMLGenerator and FilterTransformer (not to mention all the JXPath stuff). Sometimes (a lot of times, actually) it's necessary to pass *namespaced* references, and the situation is only going to get worse with the increasing use of advanced XML (think about the SOAP or DAV nightmare). Currently only the XPathTraversableGenerator supports a way to pass namespaced elements, and to do that it uses a hack made of parameters starting with xmlns: whose value is the namespace URI. this seems silly to me, since the sitemap is an XML file. How better would it be to write (a' la XSLT): map:generate type=xpathtraversable src=my.xml xpath=/html:head/html:title xmlns:html=http://www.w3.org/1999/xhtml/ instead than: map:generate type=xpathtraversable src=my.xml xpath=/html:head/html:title map:parameter name=xmlns:html value=http://www.w3.org/1999/xhtml/ /map:generate The former looks to me as the simplest and more consistent solution, with the only problem being the TreeProcessor being able to pass namespace informations to the components. It could be as easy as a NamespaceMap being available in the object model, but I'm sure that the TreeProcessor gurus might have a better idea to deal with this particular issue. Does all this make sense? -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Woody, maps, and repeaters
I am trying to use the Woody sample that uses a Java bean for its binding (form2bean.flow). I want to store the contacts in this example in a map instead of in a list, but in this case the contacts are not displayed (one empty contact instead of 4), and submit gives an insert error for contacts[1]). I had an almost identical problem with JXForms. When I skip the Woody form in my flowscript, and just show the result page (form2_jx.xml), all my contacts are displayed OK. So JXPath knows how to iterate over a Map. I dived into the Woody sources and an obvious place to look is the Java class RepeaterJXPathBinding.java and especially the line Iterator rowPointers = repeaterContext.iteratePointers(this.rowPath); in the function loadFormFromModel in this class. Can someone tell me whether this function iteratePointers() gives me the expected result: an iterator over the Map (this.rowPath)? I did check the JXPath docs and tried Google. I guess the answer is no, and because the iterator seems to have one value, I guess it returns one object with a list of keys and a list of values. Thanks Hugo Burm
DO NOT REPLY [Bug 22574] - [PATCH] poi HSSFSerializer error with formula cells
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=22574. 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=22574 [PATCH] poi HSSFSerializer error with formula cells [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|poi HSSFSerializer error|[PATCH] poi HSSFSerializer |with formula cells |error with formula cells --- Additional Comments From [EMAIL PROTECTED] 2003-08-20 17:32 --- Patch applied. Please cross-test. Thanks. Joerg
DO NOT REPLY [Bug 22132] - Cannot use redirect-to after submit jxform
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=22132. 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=22132 Cannot use redirect-to after submit jxform --- Additional Comments From [EMAIL PROTECTED] 2003-08-20 17:33 --- Unfortunately, our project is not at a point where I can update my version of Cocoon. We may move to 2.1 release in about a month so if the changes are in the release I can test then. If the changes are after the 2.1 final, I won't be in a position to test them for quite a while (probably not until they make it into a milestone or release candidate).
RE: [RT] Improving Views
Sylvain Wallez wrote: Relating this to the newly introduced virtual components, we can consider the view definition as a virtual serializer. Example : map:serializers map:serializer type=xml src=oacs.XMLSerializer/ map:serializer type=pretty-xml map:transform type=xslt src=xml2pretty.xsl/ map:serialize type=xml/ /map:serializer /map:serializers map:views map:view name=content from-label=content serializer=xml/ map:view name=pretty-content from-label=content serializer=pretty-xml/ /map:views I like this, and while we're at it - I'd also like to see the ability to define different views with the same name. I don't think this is possible at present. e.g. map:views map:view name=search from-label=tei serializer=tei-search/ map:view name=search from-label=html serializer=html-search/ map:view name=search from-label=svg serializer=svg-search/ /map:views When accessing a pipeline using a view called X, the pipeline processor could branch off from the main pipeline at the FIRST label Y for which there exists a map:view with @name=X and @from-label=Y. This would make it easy to define e.g. a search view of heterogeneous pipelines, with different types of content. Typically the label attributes in the pipeline would refer to the TYPE of the content at that stage in the pipeline. Cheers Con
DO NOT REPLY [Bug 20271] - [PATCH] General background task manager leveraging Avalon
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=20271. 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=20271 [PATCH] General background task manager leveraging Avalon [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2003-08-20 13:07 --- Hi David, Could you please provide the documentation in xml format as the other cocoon doc is? I will then apply your patch to Cocoon.
cvs commit: cocoon-2.0/lib/optional batik-all-1.5.jar fop-0.20.5.jar batik-all-1.5b5.jar
joerg 2003/08/20 19:11:02 Modified:lib jars.xml lib/optional fop-0.20.5.jar Added: lib/core commons-httpclient-2.0-rc1.jar lib/optional batik-all-1.5.jar Removed: lib/core commons-httpclient-20020423.jar lib/optional batik-all-1.5b5.jar Log: Updated HttpClient to the latest version 2.0 RC 1. Backported changes to SOAPHelper from Cocoon 2.1. Updated Batik to the latest released version 1.5. Rebuilt Fop 0.20.5. Revision ChangesPath 1.11 +4 -4 cocoon-2.0/lib/jars.xml Index: jars.xml === RCS file: /home/cvs/cocoon-2.0/lib/jars.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- jars.xml 29 Jul 2003 18:49:29 - 1.10 +++ jars.xml 21 Aug 2003 02:11:01 - 1.11 @@ -209,7 +209,7 @@ and feature-rich package implementing the client side of the most recent HTTP standards and recommendations./description used-bySOAP logicsheet/used-by -libcore/commons-httpclient-20020423.jar/lib +libcore/commons-httpclient-2.0-rc1.jar/lib homepagehttp://jakarta.apache.org/commons/httpclient//homepage /file file @@ -244,7 +244,7 @@ /file file titleThe XML APIs/title -descriptionJAXP, DOM and SAX interfaces. +descriptionJAXP, DOM and SAX interfaces. These are the common interfaces for XML processing./description used-byCocoon/used-by libcore/xml-apis.jar/lib @@ -256,7 +256,7 @@ the Scalable Vector Graphics (SVG) format for various purposes, such as viewing, generation or manipulation./description used-bySVG serializer (SVG to JPG, PNG)/used-by -liboptional/batik-all-1.5b5.jar/lib +liboptional/batik-all-1.5.jar/lib homepagehttp://xml.apache.org/batik//homepage /file file @@ -358,7 +358,7 @@ /file file titleSearch engine/title -descriptionjakarta-lucene is a search engine toolkit designed for +descriptionjakarta-lucene is a search engine toolkit designed for indexing and searching of documents./description used-by?/used-by liboptional/lucene-1.2.jar/lib 1.1 cocoon-2.0/lib/core/commons-httpclient-2.0-rc1.jar Binary file 1.2 +4908 -4741cocoon-2.0/lib/optional/fop-0.20.5.jar Binary file 1.1 cocoon-2.0/lib/optional/batik-all-1.5.jar Binary file
cvs commit: cocoon-2.0/src/java/org/apache/cocoon/components/language/markup/xsp SOAPHelper.java
joerg 2003/08/20 19:11:59
Modified:src/java/org/apache/cocoon/components/language/markup/xsp
SOAPHelper.java
Log:
Updated HttpClient to the latest version 2.0 RC 1. Backported changes to SOAPHelper
from Cocoon 2.1.
Revision ChangesPath
1.2 +42 -49
cocoon-2.0/src/java/org/apache/cocoon/components/language/markup/xsp/SOAPHelper.java
Index: SOAPHelper.java
===
RCS file:
/home/cvs/cocoon-2.0/src/java/org/apache/cocoon/components/language/markup/xsp/SOAPHelper.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SOAPHelper.java 9 Mar 2003 00:01:56 - 1.1
+++ SOAPHelper.java 21 Aug 2003 02:11:59 - 1.2
@@ -50,6 +50,11 @@
*/
package org.apache.cocoon.components.language.markup.xsp;
+import java.io.InputStreamReader;
+import java.io.Reader;
+import java.net.MalformedURLException;
+import java.net.URL;
+
import org.apache.avalon.framework.component.ComponentException;
import org.apache.avalon.framework.component.ComponentManager;
@@ -62,13 +67,8 @@
import org.apache.commons.httpclient.HttpConnection;
import org.apache.commons.httpclient.HttpState;
import org.apache.commons.httpclient.methods.PostMethod;
-import org.xml.sax.InputSource;
-import java.io.InputStreamReader;
-import java.io.Reader;
-import java.net.MalformedURLException;
-import java.net.URL;
-import java.util.HashMap;
+import org.xml.sax.InputSource;
/**
* Helper for the SOAP logicsheet.
@@ -115,51 +115,46 @@
conn = new HttpConnection(host, port);
}
-PostMethod method = new PostMethod(url.getFile()) {
-protected String generateRequestBody(HashMap params) {
-try {
-StringBuffer bodyBuffer
-= new
StringBuffer(super.generateRequestBody(params));
+PostMethod method = new PostMethod(url.getFile());
+String request;
-// Write the SOAP request body
-if (xscriptObject instanceof XScriptObjectInlineXML) {
-// Skip overhead
-bodyBuffer.append(((XScriptObjectInlineXML)
xscriptObject).getContent());
-} else {
-InputSource saxSource = xscriptObject.getInputSource();
-
-Reader r = null;
-// Byte stream or character stream?
-if (saxSource.getByteStream() != null) {
-r = new
InputStreamReader(saxSource.getByteStream());
-} else {
-r = saxSource.getCharacterStream();
-}
-
-try {
-char[] buffer = new char[1024];
-int len;
-while ((len = r.read(buffer)) 0)
-bodyBuffer.append(buffer, 0, len);
-} finally {
-if (r != null) {
-r.close();
-}
-}
-}
+try {
+// Write the SOAP request body
+if (xscriptObject instanceof XScriptObjectInlineXML) {
+// Skip overhead
+request = ((XScriptObjectInlineXML) xscriptObject).getContent();
+} else {
+StringBuffer bodyBuffer = new StringBuffer();
+InputSource saxSource = xscriptObject.getInputSource();
+
+Reader r = null;
+// Byte stream or character stream?
+if (saxSource.getByteStream() != null) {
+r = new InputStreamReader(saxSource.getByteStream());
+} else {
+r = saxSource.getCharacterStream();
+}
-return bodyBuffer.toString();
-} catch (Exception ex) {
-// FIXME (VG): Will result in NPE in httpClient code
-return null;
+try {
+char[] buffer = new char[1024];
+int len;
+while ((len = r.read(buffer)) 0)
+bodyBuffer.append(buffer, 0, len);
+} finally {
+if (r != null) {
+r.close();
+}
cvs commit: cocoon-2.1/src/webapp/WEB-INF web.xml
joerg 2003/08/20 19:20:28 Modified:src/webapp/WEB-INF web.xml Log: UTF-8 Revision ChangesPath 1.6 +1 -1 cocoon-2.1/src/webapp/WEB-INF/web.xml Index: web.xml === RCS file: /home/cvs/cocoon-2.1/src/webapp/WEB-INF/web.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- web.xml 23 May 2003 02:48:03 - 1.5 +++ web.xml 21 Aug 2003 02:20:28 - 1.6 @@ -1,4 +1,4 @@ -?xml version=1.0 encoding=ISO-8859-1? +?xml version=1.0 encoding=UTF-8? !--+ | This is the Cocoon web-app configurations file
cvs commit: cocoon-2.1/src/blocks/fop/lib fop-0.20.5.jar
joerg 2003/08/20 18:57:42 Modified:src/blocks/fop/lib fop-0.20.5.jar Log: after update to batik 1.5 rebuild of fop 0.20.5 Revision ChangesPath 1.3 +4888 -4746cocoon-2.1/src/blocks/fop/lib/fop-0.20.5.jar Binary file
cvs commit: cocoon-2.0/src/java/org/apache/cocoon/util NetUtils.java
joerg 2003/08/20 19:16:14
Modified:src/java/org/apache/cocoon/util NetUtils.java
Log:
fixed javadoc
Revision ChangesPath
1.2 +2 -2 cocoon-2.0/src/java/org/apache/cocoon/util/NetUtils.java
Index: NetUtils.java
===
RCS file: /home/cvs/cocoon-2.0/src/java/org/apache/cocoon/util/NetUtils.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- NetUtils.java 9 Mar 2003 00:03:27 - 1.1
+++ NetUtils.java 21 Aug 2003 02:16:14 - 1.2
@@ -267,7 +267,7 @@
* Relativize an absolute resource on a given absolute path.
*
* @param path The absolute path
- * @param relativeResource The absolute resource
+ * @param absoluteResource The absolute resource
* @return the resource relative to the given path
*/
public static String relativize(String path, String absoluteResource) {
RE: cvs commit: cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/components/persistance RequestDataStoreImpl.java RequestDataStore.java
Sylvain Wallez wrote: package org.apache.cocoon.components.persistance; My english dictionnary tells me that this should be spelled persistence... I guess you have to buy a new one :) Seriously, thanks for spotting this (it has already been reported and I was too lazy), I will now rename it asap. Thanks Carsten
