RE: latest xform
At 5:13 PM +0200 29/7/01, Torsten Curdt wrote: * input/output mapper [me] Although prepare for such mappings the mapping needs to be implemented for basic use cases: - xform - bean - classes in general - maybe even databases? Should we add 'file' to this? Forgive me if I misunderstood what you are saying here, but could we add the ability to process/update XML File as DOM to this, allowing us to throw away the FP TagLib (which was always intended as a 'thought experiment'). Definitly! I haven't been using the FP taglib but AFIAK this should be possible and desireable... We need to take a closer look at that -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: xforms - inline values fix names
Torsten, although I've said that doing this with xslt is feasible I think I was wrong. So here is a transformer that does a) handle the complete xform binding spec and adds instance data as value/ child element to form controls and b) adds a @name attribute to them containing the form name + / + path to instance data (e.g. name=order_form/address/street) It does not remove anything from the document, e.g. form declarations or @refs. So we are back to the transformer ;) We should really decide which way to go! So what are your PROs for the transformer now? The package name is a temporal convenience and will change. I did waste quite some time toying with an DTM representation, since this transformer is quite slow and DTM looked like it would speed it up a lot. E.g. creating the cached form declaration took half the time. Unfortunately I had to find out the hard way that a number of important API calls are not implemented yet :-( Since this transformer caches form declarations which also contain the model necessary for validation, I think it would be nice to register this model (+submitInfo) somewhere so that it is available when validation takes place. This doesn't need to be session bound (doesn't register instance data). Not for the submitInfo and the model. But you don't wanna POST the instance all the time, don't you? Where do you wanna hold the instance data? Do we agree on holding the instance as DOM in the session? This information would be useful also when determining which form has been submitted. Caching is done only during the lifetime of a transformer instance as I have no idea how to decide easily if a cached form declaration instance data is still valid. Ideas? Well, I decided that the structure of the xform instance may not change but the values. So what already works for me is the following: xform:xform id=myform xform:submitInfo href=submit/ xform:model /xform:model xform:instance customernrmy:customerid//customernr positionidxsp-request:get-parameter name=id//positionid date/ deliveryaddress id=00200843 esql:connection esql:pooldff/esql:pool esql:execute-query esql:query select street, zip, city from addresses where CUS_ID='xform:output ref=/customernr/' and ADDRESSID = 'xform:output ref=/deliveryaddress/@id/' /esql:query esql:results esql:row-results esql:get-columns/ /esql:row-results /esql:results /esql:execute-query /esql:connection /deliveryaddress esql:connection esql:pooldff/esql:pool esql:execute-query esql:query select * from customer where CUS_ID='xform:output ref=/customernr/' and AP_ID = 'xform:output ref=/positionid/' /esql:query esql:results esql:row-results esql:get-columns/ /esql:row-results /esql:results /esql:execute-query /esql:connection /xform:instance /xform:xform Right now I'm trying to update the instance data directly via SAX events. But this gave me some headaches in the last few days... BTW if I understand the xforms WD correctly, form controls need to set the default namespace or child elements like caption/, hint/ c. need to explicitly carry their namespace. So your sample xform.xml needs to be changed: xform:textbox ref=order/city xform=orderForm captionCity/caption /xform:textbox becomes xform:textbox ref=order/city xform=orderForm xmlns=http://www.w3.org/2001/06/xforms; captionCity/caption /xform:textbox This might be true I will next look into such a registry that keeps track of xform declarations and provides them to a validator. Obviously, I will go and see if I can use the code you posted earlier :-) Sure. -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: weird build problem - seems to be dependent on jar name
Thanks Carsten, The jar name is catalog.jar to add entity resolver support. It does not contain DOM stuff. However, it certainly does have SAX-based classes - i mean it does import org.xml.sax.EntityResolver etc. Note that everything works beautifully with the public release of c2b2. There were no such build problems. I have almost finished a documentation page to give background, examples, and development notes, and i was just about to start discussing adding entity resolver support with the dev list. regards, David -- Date: Tue, 7 Aug 2001 09:39:39 +0200 From: Carsten Ziegeler [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] What was the original name of your jar file and which classes (packages) did it contain (any sax or dom package?) Carsten -Ursprüngliche Nachricht- Von: David Crossley [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 7. August 2001 04:23 An: [EMAIL PROTECTED] Betreff: weird build problem - seems to be dependent on jar name We have successfully added some new functionality into our copy of the public release of Apache Cocoon 2.0b2 This involved some tweaks to core code to hook in another Java package. All went smoothly (adding our jar file into $COCOON_HOME/lib and edits to src/org/...). Re-build is fine and our new functionality works as expected. However, then i CVS checkout the whole cocoon_20_branch and try to verify that our changes work with the most recent code. The initial build is fine. Then i make the exact same mods and try to re-build. Ant bombs with the following obscure error and does not even get through init phase. ant -v or ant -debug do not shed any light. A workaround solution is to rename our jar file so that it begins with z i.e. zcatalog.jar Now re-build runs perfectly. Why is that hack needed? Linux RedHat 7.1 java.vm.version=Blackdown-1.3.1-FCS jakarta-tomcat-3.2.2 Help please, days have been wasted trying to get past this. thanks, David Crossley = Apache Cocoon 2 Build System Buildfile: build.xml BUILD FAILED java.lang.NoSuchMethodError at org.xml.sax.helpers.XMLReaderAdapter$AttributesAdapter.getName(XML ReaderAdapter.java:470) at org.apache.tools.ant.ProjectHelper$ProjectHandler.init(ProjectHelp er.java:288) at org.apache.tools.ant.ProjectHelper$RootHandler.startElement(Projec tHelper.java:262) at org.xml.sax.helpers.XMLReaderAdapter.startElement(XMLReaderAdapter .java:329) at org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1376) at org.apache.xerces.validators.common.XMLValidator.callStartElement( XMLValidator.java:1191) at org.apache.xerces.framework.XMLDocumentScanner.scanElement(XMLDocu mentScanner.java:1862) at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.d ispatch(XMLDocumentScanner.java:1005) at org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocume ntScanner.java:381) at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1081) at org.xml.sax.helpers.XMLReaderAdapter.parse(XMLReaderAdapter.java:223) at javax.xml.parsers.SAXParser.parse(SAXParser.java:345) at org.apache.tools.ant.ProjectHelper.parse(ProjectHelper.java:117) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper. java:85) at org.apache.tools.ant.Main.runBuild(Main.java:403) at org.apache.tools.ant.Main.main(Main.java:149) = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: weird build problem - seems to be dependent on jar name
Seems like you have some sax classes in your catalog.jar. Probably another version than the ones cocoon uses, and thus missing some methods (like getName in org.xml.sax.helpers.XMLReaderAdapter$AttributesAdapter). Putting a 'z' in front of the jar name causes the jar to be loaded lastly, and thus allowing cocoon to load the right version of the classes. To make a long story short: don't provide more than 1 class definition of the same class in your libs directory. It causes trouble. hth, tomK -Original Message- From: David Crossley [mailto:[EMAIL PROTECTED]] Sent: dinsdag 7 augustus 2001 4:23 To: [EMAIL PROTECTED] Subject: weird build problem - seems to be dependent on jar name We have successfully added some new functionality into our copy of the public release of Apache Cocoon 2.0b2 This involved some tweaks to core code to hook in another Java package. All went smoothly (adding our jar file into $COCOON_HOME/lib and edits to src/org/...). Re-build is fine and our new functionality works as expected. However, then i CVS checkout the whole cocoon_20_branch and try to verify that our changes work with the most recent code. The initial build is fine. Then i make the exact same mods and try to re-build. Ant bombs with the following obscure error and does not even get through init phase. ant -v or ant -debug do not shed any light. A workaround solution is to rename our jar file so that it begins with z i.e. zcatalog.jar Now re-build runs perfectly. Why is that hack needed? Linux RedHat 7.1 java.vm.version=Blackdown-1.3.1-FCS jakarta-tomcat-3.2.2 Help please, days have been wasted trying to get past this. thanks, David Crossley = Apache Cocoon 2 Build System Buildfile: build.xml BUILD FAILED java.lang.NoSuchMethodError at org.xml.sax.helpers.XMLReaderAdapter$AttributesAdapter.getName(XMLReaderAdap ter.java:470) at org.apache.tools.ant.ProjectHelper$ProjectHandler.init(ProjectHelper.java:28 8) at org.apache.tools.ant.ProjectHelper$RootHandler.startElement(ProjectHelper.ja va:262) at org.xml.sax.helpers.XMLReaderAdapter.startElement(XMLReaderAdapter.java:329) at org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1376) at org.apache.xerces.validators.common.XMLValidator.callStartElement(XMLValidat or.java:1191) at org.apache.xerces.framework.XMLDocumentScanner.scanElement(XMLDocumentScanne r.java:1862) at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XM LDocumentScanner.java:1005) at org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner. java:381) at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1081) at org.xml.sax.helpers.XMLReaderAdapter.parse(XMLReaderAdapter.java:223) at javax.xml.parsers.SAXParser.parse(SAXParser.java:345) at org.apache.tools.ant.ProjectHelper.parse(ProjectHelper.java:117) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:85) at org.apache.tools.ant.Main.runBuild(Main.java:403) at org.apache.tools.ant.Main.main(Main.java:149) = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[C2][VOTE]: Logging
I just wanted to start a vote on the logging features of C2.0. The 2.1 branch containes the enhanced CocoonLogFormatter which outputs more information, e.g. the current uri, thread name etc. So let's vote if this should go into the 2.0 branch! I am +1 for adding this to 2.0. Further, I want to make the log format and which formatter class is used configurable in the web.xml. So, next vote: +1 for adding formatter class and formatter format to the web.xml. Comments and votes are welcome. Carsten Open Source GroupsunShine - b:Integrated Carsten Ziegeler, SN AG, Klingenderstrasse 5, D-33100 Paderborn www.sundn.de mailto: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[C2]: Performance and logging
Hi,
I know that we had this discussion some time ago, with no real solution,
so I thought: why not start it again?
Looking at the way logging is performed in cocoon 2, I think this is
not very fast. Here an example:
CODE
getLogger().debug(Creating new Templates in + this + for +
this.inputSource.getSystemId());
/CODE
Even if the priority debug is disabled, the method getLogger() (from
AbstractLoggable) is called
returning the logger, the expensive string concatenation is performed and
the debug() method
of the logger is called. And these steps are done for every debug message!
We should change two things here:
a) Replace the getLogger() call with the use of an instance variable logger.
This requires to make an own AbstractLoggable class which offers the
logger as an instance
variable and not via a method.
b) Before logging testing the priority.
So the example above should read:
CODE
if (this.logger.isDebugEnabled() == true) {
this.logger.debug(Creating new Templates in + this + for +
this.inputSource.getSystemId());
}
/CODE
Comments? Ideas? Suggestions? Volunteers?
Carsten
Open Source GroupsunShine - b:Integrated
Carsten Ziegeler, SN AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
[GUMP] Build Failure - Cocoon2
This email is autogenerated from the output from:
http://jakarta.apache.org/builds/gump/2001-08-07/xml-cocoon2.html
Buildfile: build.xml
init:
[echo] --- Apache Cocoon 2.1-dev [1999-2001]
prepare:
[mkdir] Created dir: /home/rubys/jakarta/xml-cocoon2/build/cocoon
generate-java-code-check:
generate-java-code:
[style] DEPRECATED - the style attribute should be relative to the project's
[style] basedir, not the tasks's basedir.
[style] Transforming into
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/components/browser
[style] Transforming into
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/components/browser
[style] Loading stylesheet
/home/rubys/jakarta/xml-cocoon2/src/org/apache/cocoon/components/browser/BrowserImpl.xsl
prepare-src-main:
[mkdir] Created dir: /home/rubys/jakarta/xml-cocoon2/build/cocoon/classes
[copy] Copying 302 files to /home/rubys/jakarta/xml-cocoon2/build/cocoon/src
prepare-src-22-maybeupload:
prepare-src-23-maybeupload:
[copy] Copying 1 file to
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/environment/http
prepare-src-23:
prepare-src-22:
prepare-src:
compile:
[copy] Copying 15 files to /home/rubys/jakarta/xml-cocoon2/build/cocoon/classes
[javac] Compiling 287 source files to
/home/rubys/jakarta/xml-cocoon2/build/cocoon/classes
[javac]
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/serialization/FOPSerializer.java:123:
Method format() not found in class org.apache.fop.apps.Driver.
[javac] this.driver.format();
[javac] ^
[javac]
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/serialization/FOPSerializer.java:124:
No method matching render() found in class org.apache.fop.apps.Driver.
[javac] this.driver.render();
[javac] ^
[javac]
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/serialization/FOPSerializer.java:125:
Exception java.io.IOException is never thrown in the body of the corresponding try
statement.
[javac] } catch (IOException e) {
[javac] ^
[javac]
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/serialization/FOPSerializer.java:128:
Exception org.apache.fop.apps.FOPException is never thrown in the body of the
corresponding try statement.
[javac] } catch (FOPException e) {
[javac] ^
[javac] Note: 14 files use or override a deprecated API. Recompile with
-deprecation for details.
[javac] 4 errors, 1 warning
BUILD FAILED
Compile failed, messages should have been provided.
Total time: 53 seconds
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/xdocs log-transformer.xml
cziegeler01/08/07 03:44:40
Modified:src/org/apache/cocoon/transformation LogTransformer.java
xdocslog-transformer.xml
Log:
Correct parameter doc for log transformer
Revision ChangesPath
1.3 +3 -3
xml-cocoon2/src/org/apache/cocoon/transformation/LogTransformer.java
Index: LogTransformer.java
===
RCS file:
/home/cvs/xml-cocoon2/src/org/apache/cocoon/transformation/LogTransformer.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- LogTransformer.java 2001/05/22 14:47:36 1.2
+++ LogTransformer.java 2001/08/07 10:44:40 1.3
@@ -30,8 +30,8 @@
* p
* pre
* lt;map:transform type=loggt;
- * nbsp;nbsp;lt;parameter name=logfile value=logfile.log/gt;
- * nbsp;nbsp;lt;parameter name=append value=no/gt;
+ * nbsp;nbsp;lt;map:parameter name=logfile value=logfile.log/gt;
+ * nbsp;nbsp;lt;map:parameter name=append value=no/gt;
* lt;/map:transformgt;
* /pre
* /p
@@ -43,7 +43,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Giacomo Pati/a
* (PWR Organisation amp; Entwicklung)
- * @version CVS $Revision: 1.2 $ $Date: 2001/05/22 14:47:36 $
+ * @version CVS $Revision: 1.3 $ $Date: 2001/08/07 10:44:40 $
*
*/
public class LogTransformer extends AbstractTransformer implements Poolable {
1.7 +2 -2 xml-cocoon2/xdocs/log-transformer.xml
Index: log-transformer.xml
===
RCS file: /home/cvs/xml-cocoon2/xdocs/log-transformer.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- log-transformer.xml 2001/07/19 14:20:23 1.6
+++ log-transformer.xml 2001/08/07 10:44:40 1.7
@@ -22,8 +22,8 @@
transformer as follows:/p
source
lt;map:transform type=loggt;
- nbsp;nbsp;lt;parameter name=logfile value=logfile.log/gt;
- nbsp;nbsp;lt;parameter name=append value=no/gt;
+ nbsp;nbsp;lt;map:parameter name=logfile value=logfile.log/gt;
+ nbsp;nbsp;lt;map:parameter name=append value=no/gt;
lt;/map:transformgt;
/source
p
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Bug 2861] - CachingStreamPipeline, setContentLength when should == false
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2861 *** shadow/2861 Fri Jul 27 12:41:21 2001 --- shadow/2861.tmp.15071 Tue Aug 7 03:56:56 2001 *** *** 2,8 | CachingStreamPipeline, setContentLength when should == false | ++ |Bug #: 2861Product: Cocoon 2| ! | Status: NEW Version: 2.0b1 | | Resolution:Platform: PC | | Severity: Normal OS/Version: Windows NT/2K | | Priority: Other Component: general components | --- 2,8 | CachingStreamPipeline, setContentLength when should == false | ++ |Bug #: 2861Product: Cocoon 2| ! | Status: ASSIGNEDVersion: 2.0b1 | | Resolution:Platform: PC | | Severity: Normal OS/Version: Windows NT/2K | | Priority: Other Component: general components | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/org/apache/cocoon/components/pipeline CachingStreamPipeline.java
cziegeler01/08/07 03:56:50
Modified:src/org/apache/cocoon/components/pipeline
CachingStreamPipeline.java
Log:
The content length was set twice when the CachingStreamPipeline could cache.
The second call was too late. This is fixed now.
PR: bug 2861
Revision ChangesPath
1.10 +1 -3
xml-cocoon2/src/org/apache/cocoon/components/pipeline/CachingStreamPipeline.java
Index: CachingStreamPipeline.java
===
RCS file:
/home/cvs/xml-cocoon2/src/org/apache/cocoon/components/pipeline/CachingStreamPipeline.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- CachingStreamPipeline.java2001/08/05 16:33:27 1.9
+++ CachingStreamPipeline.java2001/08/07 10:56:49 1.10
@@ -45,7 +45,7 @@
* /ul
*
* @author a href=mailto:[EMAIL PROTECTED];Carsten Ziegeler/a
- * @version CVS $Revision: 1.9 $ $Date: 2001/08/05 16:33:27 $
+ * @version CVS $Revision: 1.10 $ $Date: 2001/08/07 10:56:49 $
*/
public class CachingStreamPipeline extends AbstractStreamPipeline {
@@ -366,8 +366,6 @@
// store the response
if (pcKey != null) {
byte[] bytes =
((CachingOutputStream)outputStream).getContent();
-environment.setContentLength(bytes.length);
-
this.streamCache.store(pcKey,
new CachedStreamObject(validityObjects, bytes));
}
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/org/apache/cocoon/components/pipeline CachingStreamPipeline.java
cziegeler01/08/07 03:56:25
Modified:src/org/apache/cocoon/components/pipeline Tag:
cocoon_20_branch CachingStreamPipeline.java
Log:
The content length was set twice when the CachingStreamPipeline could cache.
The second call was too late. This is fixed now.
PR: bug 2861
Revision ChangesPath
No revision
No revision
1.3.2.9 +1 -3
xml-cocoon2/src/org/apache/cocoon/components/pipeline/CachingStreamPipeline.java
Index: CachingStreamPipeline.java
===
RCS file:
/home/cvs/xml-cocoon2/src/org/apache/cocoon/components/pipeline/CachingStreamPipeline.java,v
retrieving revision 1.3.2.8
retrieving revision 1.3.2.9
diff -u -r1.3.2.8 -r1.3.2.9
--- CachingStreamPipeline.java2001/08/05 16:34:48 1.3.2.8
+++ CachingStreamPipeline.java2001/08/07 10:56:25 1.3.2.9
@@ -45,7 +45,7 @@
* /ul
*
* @author a href=mailto:[EMAIL PROTECTED];Carsten Ziegeler/a
- * @version CVS $Revision: 1.3.2.8 $ $Date: 2001/08/05 16:34:48 $
+ * @version CVS $Revision: 1.3.2.9 $ $Date: 2001/08/07 10:56:25 $
*/
public class CachingStreamPipeline extends AbstractStreamPipeline {
@@ -366,8 +366,6 @@
// store the response
if (pcKey != null) {
byte[] bytes =
((CachingOutputStream)outputStream).getContent();
-environment.setContentLength(bytes.length);
-
this.streamCache.store(pcKey,
new CachedStreamObject(validityObjects, bytes));
}
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Bug 2861] - CachingStreamPipeline, setContentLength when should == false
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2861 *** shadow/2861 Tue Aug 7 03:56:56 2001 --- shadow/2861.tmp.15225 Tue Aug 7 03:59:02 2001 *** *** 2,9 | CachingStreamPipeline, setContentLength when should == false | ++ |Bug #: 2861Product: Cocoon 2| ! | Status: ASSIGNEDVersion: 2.0b1 | ! | Resolution:Platform: PC | | Severity: Normal OS/Version: Windows NT/2K | | Priority: Other Component: general components | ++ --- 2,9 | CachingStreamPipeline, setContentLength when should == false | ++ |Bug #: 2861Product: Cocoon 2| ! | Status: RESOLVEDVersion: 2.0b1 | ! | Resolution: FIXED Platform: PC | | Severity: Normal OS/Version: Windows NT/2K | | Priority: Other Component: general components | ++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: latest xform
At 7:34 PM +0200 6/8/01, Torsten Curdt wrote: Forgive me if I misunderstood what you are saying here, but could we add the ability to process/update XML File as DOM to this, allowing us to throw away the FP TagLib (which was always intended as a 'thought experiment'). Definitly! I haven't been using the FP taglib but AFIAK this should be possible and desireable... We need to take a closer look at that I'd be happy to help with this, but first I need to get up to speed with the whole XForm mechanism you have developed so far. Where do I start ? ;) regards Jeremy -- ___ Jeremy Quinn Karma Divers webSpace Design HyperMedia Research Centre mailto:[EMAIL PROTECTED]http://www.media.demon.co.uk phone:+44.[0].20.7737.6831pager:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[C2]: Simplyfying log configuration
The configuration of the log is currently done in the web.xml. This includes the log level, the log file name etc. What do you all think about moving this configuration to the cocoon.xconf? This would allow any change to take effect immediately after it was changed when cocoon is reloaded. And personally I think it would make things a little bit easier for users as they must only deal with one configuration file. Carsten Open Source GroupsunShine - b:Integrated Carsten Ziegeler, SN AG, Klingenderstrasse 5, D-33100 Paderborn www.sundn.de mailto: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [C2]: Performance and logging
Carsten Ziegeler wrote:
Hi,
I know that we had this discussion some time ago, with no real solution,
so I thought: why not start it again?
Looking at the way logging is performed in cocoon 2, I think this is
not very fast. Here an example:
CODE
getLogger().debug(Creating new Templates in + this + for +
this.inputSource.getSystemId());
/CODE
You can use the following construct:
CODE
if ( getLogger().isDebugEnabled() ) {
getLogger().debug(Creating new Templates in + this + for +
this.inputSource.getSystemId());
}
/CODE
That way your string concatenation only happens when necessary.
You can also getLogger() at the beginning of the method so that the method
is only called once:
CODE
private void myMethod() {
Logger log = getLogger();
//do some stuff
if (log.isDebugEnabled() ) {
log.debug(Create + + Expensive + + String + +
Concatenations.);
}
}
/CODE
Even if the priority debug is disabled, the method getLogger() (from
AbstractLoggable) is called
returning the logger, the expensive string concatenation is performed and
the debug() method
of the logger is called. And these steps are done for every debug message!
We should change two things here:
a) Replace the getLogger() call with the use of an instance variable logger.
This requires to make an own AbstractLoggable class which offers the
logger as an instance
variable and not via a method.
When you extend AbstractLoggable, the instance variable is called m_logger.
the getLogger() is a convenience so that you are spared the implementation
details of class. If the instance variable name was changed (as there is no
contract to enforce this name to be the same) it will not break your code if
you use the getLogger() method. It only needs to be called once in a method
though.
b) Before logging testing the priority.
So the example above should read:
CODE
if (this.logger.isDebugEnabled() == true) {
this.logger.debug(Creating new Templates in + this + for +
this.inputSource.getSystemId());
}
/CODE
You shouldn't use the == true because that is not only implied, but violates
Sun's coding standards. It's a boolean already.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [C2]: Simplyfying log configuration
Carsten Ziegeler wrote: The configuration of the log is currently done in the web.xml. This includes the log level, the log file name etc. What do you all think about moving this configuration to the cocoon.xconf? This would allow any change to take effect immediately after it was changed when cocoon is reloaded. And personally I think it would make things a little bit easier for users as they must only deal with one configuration file. :) I already proposed this a week and a half ago. William Vambenepe from hp.com has volunteered to start this effort. This will also help us separate different categories into different logtargets. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: [C2]: Simplyfying log configuration
Berin Loritsch wrote: Carsten Ziegeler wrote: The configuration of the log is currently done in the web.xml. This includes the log level, the log file name etc. What do you all think about moving this configuration to the cocoon.xconf? This would allow any change to take effect immediately after it was changed when cocoon is reloaded. And personally I think it would make things a little bit easier for users as they must only deal with one configuration file. :) I already proposed this a week and a half ago. William Vambenepe from hp.com has volunteered to start this effort. This will also help us separate different categories into different logtargets. Ups, must have missed that (I got app. 2000 emails during my vacation...) Great, when is it finished...? Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: [C2]: Performance and logging
Berin Loritsch wrote:
Carsten Ziegeler wrote:
Hi,
I know that we had this discussion some time ago, with no real solution,
so I thought: why not start it again?
Looking at the way logging is performed in cocoon 2, I think this is
not very fast. Here an example:
CODE
getLogger().debug(Creating new Templates in + this + for +
this.inputSource.getSystemId());
/CODE
You can use the following construct:
CODE
if ( getLogger().isDebugEnabled() ) {
getLogger().debug(Creating new Templates in + this + for +
this.inputSource.getSystemId());
}
/CODE
That way your string concatenation only happens when necessary.
You can also getLogger() at the beginning of the method so that the method
is only called once:
CODE
private void myMethod() {
Logger log = getLogger();
//do some stuff
if (log.isDebugEnabled() ) {
log.debug(Create + + Expensive + + String + +
Concatenations.);
}
}
/CODE
Yes, this reduces the overhead a little bit, but I still have it in every
method although the logger is only set once for each object.
Even if the priority debug is disabled, the method getLogger() (from
AbstractLoggable) is called
returning the logger, the expensive string concatenation is
performed and
the debug() method
of the logger is called. And these steps are done for every
debug message!
We should change two things here:
a) Replace the getLogger() call with the use of an instance
variable logger.
This requires to make an own AbstractLoggable class which offers the
logger as an instance
variable and not via a method.
When you extend AbstractLoggable, the instance variable is called
m_logger.
the getLogger() is a convenience so that you are spared the implementation
details of class. If the instance variable name was changed (as
there is no
contract to enforce this name to be the same) it will not break
your code if
you use the getLogger() method. It only needs to be called once
in a method
though.
That's the reason why I thought writing an own AbstractLoggable class
which enforces the name of the instance variable to be e.g. logger
or something like that.
b) Before logging testing the priority.
So the example above should read:
CODE
if (this.logger.isDebugEnabled() == true) {
this.logger.debug(Creating new Templates in + this + for +
this.inputSource.getSystemId());
}
/CODE
You shouldn't use the == true because that is not only implied,
but violates
Sun's coding standards. It's a boolean already.
Well, there are so many coding standards and consulting java beginners
for more than 3 years now, I found out that it is for beginners more
readable to add the == true or == false to boolean expressions.
But fortunately this is not the topic of this email...
Carsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
AW: [C2]: Performance and logging
Vadim Gritsenko wrote:
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 07, 2001 6:36 AM
To: Cocoon-Dev@Xml. Apache. Org
Subject: [C2]: Performance and logging
Hi,
I know that we had this discussion some time ago, with no real solution,
so I thought: why not start it again?
Looking at the way logging is performed in cocoon 2, I think this is
not very fast. Here an example:
CODE
getLogger().debug(Creating new Templates in + this + for +
this.inputSource.getSystemId());
/CODE
Even if the priority debug is disabled, the method getLogger() (from
AbstractLoggable) is called returning the logger,
IIRC, argument here was that getLogger() method is final and should
be inlined by hotspot/JIT engine...
Yes, but looking through the LogKit website, there is the hint to
make the test itself and do not rely on this hotspot feature.
I find it very dangerous to rely on a special jvm implementation when
it comes to performance.
the expensive string concatenation is performed and the debug() method
of the logger is called. And these steps are done for every
debug message!
Same thing here: if method is inlined, first is...enabled() check
should occur.
I'm not sure however that this occurs in reality.
Carssten,
Did you try to coment out all debug messages to check the difference in
processing time?
No, I didn't have the time right now as there are some many log statements
and I think one should remove/change all when testing.
Did anyone else do this?
Carsten
Vadim
We should change two things here:
a) Replace the getLogger() call with the use of an instance
variable logger.
This requires to make an own AbstractLoggable class which offers the
logger as an instance
variable and not via a method.
b) Before logging testing the priority.
So the example above should read:
CODE
if (this.logger.isDebugEnabled() == true) {
this.logger.debug(Creating new Templates in + this + for +
this.inputSource.getSystemId());
}
/CODE
Comments? Ideas? Suggestions? Volunteers?
Carsten
Open Source GroupsunShine - b:Integrated
Carsten Ziegeler, SN AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: I18nTransformer patch
Fine! I like your changes. I'd like to add a fiew comments: Hi, I have added some lines of code to I18nTransformer.java and tested. It is attached to this mail. I hope this is useful not only to me ;-) 1) before: i18n:date ... / - date and time now: i18n:date ... / - only date - incompatibility - new URI: http://apache.org/cocoon/i18n/2.1 i18n:time ... / - time i18n:date-time ... / - date and time 2) the src-pattern and pattern attributes for date and time recognizes now also:short, medium, long and full in addition to a regular pattern 3) fixed a bug in i18n:number/ wich caused wrong output if the value was given as text and not as value=...: i18n:number sub-type=currency 123.45 /i18n:number 4) for number and date/time: introduced the attributes 'locale' and 'src-locale', e.g.: Why only in number and date/time? I think that 'locale' attribute can be useful also in all other tags, such as i18n:text, i18n:param, etc. If you are using a locale stack (as I proposed in one of my emails) then it will be very easy to add this, isn't it? I would do it myself, but unfortunately I am very busy at my paid work and even have no possibility to checkout the CVS snapshot. :((( i18n:date src-pattern=short src-locale=en_US locale=de_DE 12/24/01 /i18n:date will result in 24.12.2001 A given real pattern and src-pattern (not short, medium, long, full) overwrites the locale and src-locale I send a diff -u old new where new is: a) - src/org/apache/cocoon/transformation/I18nTransformer.java b) - xdocs/i18n-transformer.xml The original document was xdocs/i18n.xml. I noticed there they are the same with i18n-transformer.xml. Is there a good reason for having to sets of identical documents? Does anybody have suggestions/remarks? Not yet ;) Btw, the common procedure is to send a 'diff' from the CVS root directory. In this case, you'd have one file instead of two. And also it's easier to apply the patch. Best regards, Michael Regards, Konstantin Piroumian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [C2.1] Update junit to 3.7
Stuart Roebuck wrote: Could the junit.jar file in Cocoon 2.1 be updated to 3.7 which includes the new AssertTrue methods? This doesn't break any of the mass of existing tests :-) and helps me with some of my own! Besides, assert is a keyword in JDK 1.4. Avalon is now using JUnit 3.7 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
esql-patch
Hi,
I'd like to use esql:get-string column=abc encoding=UTF-8/
but for the encoding we have to catch
java.io.UnsupportedEncodingException
These exception is not catched yet.
Because I have no access to cvs I post the patch as
diff -u esql.xsl.orig esql.xsl
Regards,
Michael
--- esql.xsl.orig Tue Aug 7 16:25:16 2001
+++ esql.xslTue Aug 7 16:23:13 2001
@@ -637,6 +637,9 @@
/xsl:choose
} catch (Exception _esql_exception_xsl:value-of select=generate-id(.)/_2) {}
}
+catch(java.io.UnsupportedEncodingException e) {
+ throw new RuntimeException(e.toString());
+}
if (_esql_queries.empty()) {
_esql_query = null;
} else {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/org/apache/cocoon/util/log CocoonLogFormatter.java ExtensiblePatternFormatter.java
cziegeler01/08/07 08:07:02
Modified:src/org/apache/cocoon/util/log CocoonLogFormatter.java
ExtensiblePatternFormatter.java
Log:
Synced logger with latest logkit and changed getTime output format to
AvalonLogFormatter style
Revision ChangesPath
1.3 +14 -1
xml-cocoon2/src/org/apache/cocoon/util/log/CocoonLogFormatter.java
Index: CocoonLogFormatter.java
===
RCS file:
/home/cvs/xml-cocoon2/src/org/apache/cocoon/util/log/CocoonLogFormatter.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- CocoonLogFormatter.java 2001/07/24 12:57:41 1.2
+++ CocoonLogFormatter.java 2001/08/07 15:07:02 1.3
@@ -8,6 +8,7 @@
package org.apache.cocoon.util.log;
+import java.util.Date;
import java.util.Map;
import org.apache.avalon.framework.CascadingThrowable;
@@ -32,7 +33,7 @@
* /ul
*
* @author a href=mailto:[EMAIL PROTECTED];Sylvain Wallez/a
- * @version CVS $Revision: 1.2 $ $Date: 2001/07/24 12:57:41 $
+ * @version CVS $Revision: 1.3 $ $Date: 2001/08/07 15:07:02 $
*/
public class CocoonLogFormatter extends ExtensiblePatternFormatter
@@ -195,6 +196,18 @@
}
return sb.toString();
+}
+
+/**
+ * Utility method to format time.
+ *
+ * @param time the time
+ * @param format ancilliary format parameter - allowed to be null
+ * @return the formatted string
+ */
+protected String getTime( final long time, final String format )
+{
+return new Date().toString();
}
}
1.3 +13 -8
xml-cocoon2/src/org/apache/cocoon/util/log/ExtensiblePatternFormatter.java
Index: ExtensiblePatternFormatter.java
===
RCS file:
/home/cvs/xml-cocoon2/src/org/apache/cocoon/util/log/ExtensiblePatternFormatter.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ExtensiblePatternFormatter.java 2001/07/24 12:57:41 1.2
+++ ExtensiblePatternFormatter.java 2001/08/07 15:07:02 1.3
@@ -23,12 +23,12 @@
* The +|- indicates left or right justify.
* The #.# indicates the minimum and maximum size of output.
* 'field' indicates which field is to be output and must be one of
- * proeprties of LogEvent
+ * properties of LogEvent
* 'subformat' indicates a particular subformat and is currently unused.
*
* @author a href=mailto:[EMAIL PROTECTED];Peter Donald/a
* @author a href=mailto:[EMAIL PROTECTED];Sylvain Wallez/a
- * @version CVS $Revision: 1.2 $ $Date: 2001/07/24 12:57:41 $
+ * @version CVS $Revision: 1.3 $ $Date: 2001/08/07 15:07:02 $
*/
public class ExtensiblePatternFormatter
implements Formatter
@@ -254,8 +254,15 @@
}
else if( maxSize 0 maxSize size )
{
+if( rightJustify )
+{
+sb.append( output.substring( size - maxSize ) );
+}
+else
+{
sb.append( output.substring( 0, maxSize ) );
}
+}
else
{
sb.append( output );
@@ -311,8 +318,6 @@
{
final StringBuffer sb = new StringBuffer();
-String str = null;
-
for( int i = 0; i m_formatSpecification.length; i++ )
{
final PatternRun run = m_formatSpecification[ i ];
@@ -324,11 +329,11 @@
}
else
{
-str = formatPatternRun( event, run );
+final String data = formatPatternRun( event, run );
-if (str != null)
+if( null != data )
{
-append( sb, run.m_minSize, run.m_maxSize, run.m_rightJustify,
str );
+append( sb, run.m_minSize, run.m_maxSize, run.m_rightJustify,
data );
}
}
}
@@ -560,4 +565,4 @@
{
parse( format );
}
-}
\ No newline at end of file
+}
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C2][VOTE]: Logging
Carsten Ziegeler wrote: I just wanted to start a vote on the logging features of C2.0. The 2.1 branch containes the enhanced CocoonLogFormatter which outputs more information, e.g. the current uri, thread name etc. So let's vote if this should go into the 2.0 branch! I am +1 for adding this to 2.0. +1. Seems you liked it :) But it will need some little update at the next LogKit release which deprecates ContextStack in favor or the new ContextMap. Further, I want to make the log format and which formatter class is used configurable in the web.xml. So, next vote: +1 for adding formatter class and formatter format to the web.xml. I would prefer it in cocoon.xconf, as you propose in another post. IMO web.xml should be reserved as far as possible to servlet-specific deployment configurations. Comments and votes are welcome. Carsten Open Source GroupsunShine - b:Integrated Carsten Ziegeler, SN AG, Klingenderstrasse 5, D-33100 Paderborn www.sundn.de mailto: [EMAIL PROTECTED] -- Sylvain Wallez Anyware Technologies - http://www.anyware-tech.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: map:parameter in map:components
On Mon, 23 Jul 2001, Christian Haul wrote: And a last one: I proposed some changes to esql.xsl on 04.jul. and posted a patch on 11.jul. You asked me not to commit changes to esql.xsl without review. So far no one had any comments. What course of action would you suggest? I say if no one responded/reviewed your suggestion within a week put it into CVS if you think you can take the responsability for the change. OK, will do. I figure I should check it into C2.1 first to get a bit less flamed :-) Don't forget to commit it to the C1 repo as well. Giacomo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/skins/printer/stylesheets document2html.xsl
bloritsch01/08/07 10:17:15
Modified:lib Tag: cocoon_20_branch avalon-excalibur.jar
skins/printer/stylesheets Tag: cocoon_20_branch
document2html.xsl
Log:
Update Excalibur with corrected Driver loading
Revision ChangesPath
No revision
No revision
1.2.2.5 +323 -360 xml-cocoon2/lib/avalon-excalibur.jar
Binary file
No revision
No revision
1.1.1.1.2.1 +3 -15 xml-cocoon2/skins/printer/stylesheets/document2html.xsl
Index: document2html.xsl
===
RCS file: /home/cvs/xml-cocoon2/skins/printer/stylesheets/document2html.xsl,v
retrieving revision 1.1.1.1
retrieving revision 1.1.1.1.2.1
diff -u -r1.1.1.1 -r1.1.1.1.2.1
--- document2html.xsl 2001/05/09 20:50:35 1.1.1.1
+++ document2html.xsl 2001/08/07 17:17:14 1.1.1.1.2.1
@@ -23,20 +23,8 @@
link rel=stylesheet type=text/css href=resources/simple.css
title=Simple Style/
/head
body
-
-!-- THE MAIN PANEL (SIDEBAR AND CONTENT) --
-table id=main-panel
- tr
-!-- THE SIDE BAR --
-td id=side-bar valign=top
- xsl:apply-templates select=document($stylebook.project)/
-/td
-!-- THE CONTENT PANEL --
-td id=content-panel
- xsl:apply-templates/
-/td
- /tr
-/table
+xsl:apply-templates/br/
+xsl:apply-templates select=document($stylebook.project)/
/body
/html
/xsl:if
@@ -186,4 +174,4 @@
a name={@id}xsl:commentanchor/xsl:comment/a
/xsl:template
-/xsl:stylesheet
\ No newline at end of file
+/xsl:stylesheet
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [C2][VOTE]: Logging
+1, and +1 to place config into cocoon.xconf. Vadim -Original Message- From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 07, 2001 1:50 PM To: [EMAIL PROTECTED] Subject: Re: [C2][VOTE]: Logging Carsten Ziegeler wrote: I just wanted to start a vote on the logging features of C2.0. The 2.1 branch containes the enhanced CocoonLogFormatter which outputs more information, e.g. the current uri, thread name etc. So let's vote if this should go into the 2.0 branch! I am +1 for adding this to 2.0. +1. Seems you liked it :) But it will need some little update at the next LogKit release which deprecates ContextStack in favor or the new ContextMap. Further, I want to make the log format and which formatter class is used configurable in the web.xml. So, next vote: +1 for adding formatter class and formatter format to the web.xml. I would prefer it in cocoon.xconf, as you propose in another post. IMO web.xml should be reserved as far as possible to servlet-specific deployment configurations. Comments and votes are welcome. Carsten Open Source GroupsunShine - b:Integrated Carsten Ziegeler, SN AG, Klingenderstrasse 5, D-33100 Paderborn www.sundn.de mailto: [EMAIL PROTECTED] -- Sylvain Wallez Anyware Technologies - http://www.anyware-tech.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [C2][VOTE]: Logging
Vadim Gritsenko wrote: +1, and +1 to place config into cocoon.xconf. Perhaps a different file as cocoon.xconf is getting crowded. Besides, logging is not a component. Vadim -Original Message- From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 07, 2001 1:50 PM To: [EMAIL PROTECTED] Subject: Re: [C2][VOTE]: Logging Carsten Ziegeler wrote: I just wanted to start a vote on the logging features of C2.0. The 2.1 branch containes the enhanced CocoonLogFormatter which outputs more information, e.g. the current uri, thread name etc. So let's vote if this should go into the 2.0 branch! I am +1 for adding this to 2.0. +1. Seems you liked it :) But it will need some little update at the next LogKit release which deprecates ContextStack in favor or the new ContextMap. Further, I want to make the log format and which formatter class is used configurable in the web.xml. So, next vote: +1 for adding formatter class and formatter format to the web.xml. I would prefer it in cocoon.xconf, as you propose in another post. IMO web.xml should be reserved as far as possible to servlet-specific deployment configurations. Comments and votes are welcome. Carsten Open Source GroupsunShine - b:Integrated Carsten Ziegeler, SN AG, Klingenderstrasse 5, D-33100 Paderborn www.sundn.de mailto: [EMAIL PROTECTED] -- Sylvain Wallez Anyware Technologies - http://www.anyware-tech.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some comments on Cocoon 2.0b2
On Tue, 24 Jul 2001, Stuart Roebuck wrote: On Tuesday, July 24, 2001, at 11:25 am, Stefano Mazzocchi wrote: content aggregation --- Content aggregation at sitemap level is, IMHO, limiting and imposes some degree of overlap between concerns. An example clarifies this in detail: suppose you want to create some JetSpeed-like application using Cocoon2. Aggregation on the same resource (say '/') should depend on user identity and its preferences (think my.netscape.com) which might be stored someplace in a database, LDAP, file, memory, session, cookie, you name it. This is not possible if the aggregation controls are hardwired into the sitemap. It has been recently noted how there is no component that aggregates. Sure, you could say: ok, let's make a pluggable aggregating component to make this user-preferred portal possible. Yes, that's a solution, but I believe the design mistake here is that aggregation is seen as generation while I see it as transformation. ... The what is a generator question you raise is one I was thinking about the other day. Wouldn't it be a lot tidier if we decided that anything that takes an XML input and transforms it in some way to create an XML output should be a transformer and that Generators should simply be means of obtaining raw input in a suitable form for processing. This means that the ServerPagesGenerator would be a Transformer taking XSP as input (from a Generator). Do I understand you correctly? A Generator should be the counterpart of the Serializer. While the Serializers only responsability is to convert a SAX event stream to a byte stream, the Generators only responsability should be to generate a SAX stream from an input sources (be it a DOM-Fragment created by an Action, a file from the file system, a.s.o). And the real processing will be done by Transformers. Well, it is worth discussing it's pros and cons, don't you? Giacomo Cocoon:/ protocol - While I consider the concept of being able to refert to sitemap generated resources directly with a specific protocol very good, I question the necessity for the ability to access the root of the sitemap. I'm still not sure myself about this, but I believe that it might lead to concern overlap between the different people responsible for the different sitemaps. One of the original goals of the sitemap semantics were that they must be fully relocatable: this means that you can mount your sitemap on /news one day and on /new-news the next without having to tell the people responsible for the news sitemap. It's true that the use of absolute paths doesn't break sitemap relocability, but we must avoid something like cocoon:/../logo since *this* breaks relocability since it assumes something on the mount point of the sitemap and this is *bad*! Also we must ask ourselves if the ability of having absolute access to nternal resources might result in contract failure between the concern islands responsible for the current sitemap and the root sitemap. I honestly don't know, let's see if my comments trigger something. now some RT I'm having in the back of my mind I'm comfortable that this access to the root sitemap is valuable. The root provides a mechanism for handling 'global' or 'common' elements of a site independent of the location of subsitemaps. Stuart. - Stuart Roebuck [EMAIL PROTECTED] Lead Developer Java, XML, MacOS X, XP, etc. ADOLOS http://www.adolos.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [C2]: Simplyfying log configuration
On Tue, 7 Aug 2001, Carsten Ziegeler wrote: The configuration of the log is currently done in the web.xml. This includes the log level, the log file name etc. What do you all think about moving this configuration to the cocoon.xconf? This would allow any change to take effect immediately after it was changed when cocoon is reloaded. And personally I think it would make things a little bit easier for users as they must only deal with one configuration file. +1 - donald - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[C2] SQLTransformer
Hi all, There's a serious bug in the SQLTransformer: a query gets executed, and after that the results are sucked out of it. Now, the moment the query is executed, its Connection is given back to the Pool it belongs is (which is good). But, if this Connection is reused before the results are sucked out of it, serious problems arise (genre NullPointerException). The problem does not arise ATM with the Excalibur that is in C2 now, because that also has a serious bug in it (which I will report and patch tomorrow to the Avalon people). I'm working on a solution for the SQLTransformer, but I need one piece of information: can I trust C2 to execute recycle() or dispose() as soon as the pipeline has ended executing? This would allow me to allocate a Connection in the setup(), and throw it back in the Pool in the recycle() resp. dispose(). Once this is solved, I will of course send the patch to the list, but I need this information to be able to patch it. Thanks a lot, tomK - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[C2]ReadDOMSessionTransformer patch
I have a patch for a bug in the ReadDOMSessionTransformer. It is currently inserting an XML prolog in the middle of an XML document, regardless of where I attempt to insert the DOM fragment. This is because the DOMSteamer it uses automatically fires start document/end document events. I saw in the mailing list where somebody used the EmbeddedXMLPipe to catch these. Hence, this minor patch. I will look further, because there may be more bugs like this in connection with the DOMStreamer. Below is an example of what can happen. Here is the sitemap reference: map:generate type=file src=main/result.xml / map:transform type=readDOMsession map:parameter name=dom-name value=formModel/ map:parameter name=trigger-element value=body/ map:parameter name=position value=after/ /map:transform map:serialize type=xml/ Here is the file I'm generating from: ?xml version=1.0 encoding=UTF-8? page titleMy title/title body/ /page And here is the result: ?xml version=1.0 encoding=UTF-8? page titleMy title/title body/?xml version=1.0 encoding=UTF-8? question_form currentID=37 id=2 sectionID=2 xmlns:p3n=http://www.p3n.org/p3n;question id=37 text=How often do you travel outside the United States? type=single-select vieworder=1 xmlns:p3n=http://www.p3n.org/p3n; answer id=7 text=1-2 weeks vieworder=1/ answer id=8 text=3-5 weeks vieworder=1/ /question /question_form /page ReadDOMSessionTransformer.java.diff-u - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [C2][VOTE]: Logging
Can anybody vote or only committers (I've always been a little hazy on this) In any case (if my vote counts) +1 to extended logging As far as the cocoon.xconf vs. the web.xml issue, I'm unsure. Berin stated that logging is not a component, which may be valid, but why not, why shouldn't I be able to set the logging information based on the pipeline being executed. My feeling is that the web.xml file is not the right place, so I'll say: web.xml -1 k. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: weird build problem - seems to be dependent on jar name
Woops, yes the catalog.jar did contain some partial SAX classes. I blindly assumed that the jar only contained the catalog classes. When i remove the sax.* and re-pack the jar, then all is fixed. Sorry and thanks to all, David Crossley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal: C2.1] Split CocoonServlet from Cocoon
On Thu, 26 Jul 2001, Berin Loritsch wrote: * New CocoonTask environment: Allows for a new Ant task to build documentation using cocoon! This would be very cool :) How to perform the solution: We need a generic Servlet that performs the following things: 1) Create a CocoonConfigurator Interface with an initialize method that accepts a map and a getProcessor() method that handles Cocoon creation and useage. 2) Loads the classes into a known ClassLoader. You mean an approach similar to the init-param init-classloader we have today and a path (probably absolute) where the libs are? 3) Copies the initialization parameters into a Map (generic java object). This is to generalize the ServletConfig (and any other environment specifiy configuration methods/objects) into simple name/value pairs? 4) instantiates a CocoonConfigurator object using reflection. I don't get why there seems the need for using reflection. What different constructors do you have in mind for the different environments? 5) calls initialize(Map) 6) calls getProcessor().process() with the Environment object for each request. How do you see the cocoon-reload is handled? 7) the Processor interface, and the environment interfaces, and the new CocoonConfigurator interface should be packaged into a cocoon-env.jar that is used for environment adapting. +1 8) the Servlet package, and the implementations for all the Http environment classes get moved into a cocoon-servlet.jar +1 9) the Main class, and the implementations for all the CLI environment classes get moved into a cocooncli.jar +1 10) the CocoonConfiguratorImpl class is the same for all environments and is included in the cocoon.jar along with all the other cocoon classes. If the CocoonConfiguratorImpl is used by all environments whats the benefit of having a interface as well? Sounds like a good plan to me. Giacomo (yes, I'm back from vacation but still some hundered mails away from the head :/ ). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FW: [VOTE?] RE: Processing Time in last line in C2 like in 1.8?
On Fri, 27 Jul 2001, Vadim Gritsenko wrote: -Original Message- From: Berin Loritsch [mailto:[EMAIL PROTECTED]] Sent: Friday, July 27, 2001 4:15 PM To: [EMAIL PROTECTED] Subject: Re: FW: [VOTE?] RE: Processing Time in last line in C2 like in 1.8? Vadim Gritsenko wrote: Oops! Sent to wrong list! So, what's the public opinion on this? Uh, personally I like seeing the times in the log file. That makes it much easier to keep a track of how long a page processed, as well as gleaning average vs. peak times (i.e. when the JVM is garbage collecting). I agree that this is personally :) With that ability, the request time embedded in the file I don't like. It's turned off by default. Many users get used to it - may be they like this? One cool thing was to find cocoon site through Google and alike searching for the processing time string :) Giacomo Keep in mind that this also affects binary files (something that Cocoon 1 safely ignored). Unless you intend to filter on mime-type I don't recommend embedding it for all requests. I will add test for text/. Vadim I added show-time parameter to web.xml in HEAD branch. (This preserves existing functionality of cocoon-showtime parameter which is given higher priority) Shall we add this parameter to 2.0 also? Vadim -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] Sent: Monday, July 16, 2001 11:40 AM To: [EMAIL PROTECTED]; Cocoon-Dev@Xml. Apache. Org Subject: AW: Processing Time in last line in C2 like in 1.8? No, this is not possible. You must (currently) specify this parameter to each request, so you can get the processing time for one specific request, but not for all. I forward this email to the developers mailing list: Is this usefull for C2? Perhaps can someone enlighten us, why the approach with the special request parameter was choosen when this was designed and not a configuration parameter? Carsten Open Source GroupsunShine - b:Integrated Carsten Ziegeler, SN AG, Klingenderstrasse 5, D-33100 Paderborn www.sundn.de mailto: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: Dinkar Ganti [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 16. Juli 2001 17:41 An: [EMAIL PROTECTED] Betreff: RE: Processing Time in last line in C2 like in 1.8? Can the parameter be added to the web.xml file. I tried adding the following lines, but they did not show the processing times. init-param param-namecocoon-showtime/param-name param-valuetrue/param-value /init-param Any suggestions? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
