RE: workflow block commited
Hi Gianugo, I'm personnaly not the one with the OSWorkflow experience. I'll ask the right person to post his experiences. Arje -Original Message- From: Gianugo Rabellino [mailto:[EMAIL PROTECTED] Posted At: Monday, March 01, 2004 7:42 PM Posted To: Cocoon Dev List Conversation: workflow block commited Subject: Re: workflow block commited Arje Cahn wrote: I'm interested in a workflow block as well. We currently have experience using OpenSymphony Workflow and would like to share this on the Cocoon list. Please do. I'm really interested in that, I don't quite get what all this workflow fuss is about, so it would be good to know how you're integrating external workflow engines in a publishing environment. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2
Christoph Gaffga wrote: The idea is to set JSDK 1.4 as the minimum supported JDK supported for the next major release 2.2 of Cocoon. Currently we are supporting also 1.3 but seems like few people is using it. but what about the maximum support JDK? I tried to compile with 1.5beta, but it didn't work. So I compiled with 1.4 and let it run with 1.5. The gc ist much better with 1.5! Did you solve your problems with running ant using JDK? I proposed to run Ant with a JRE 1.5 and use the 1.5 compiler explicitly in the javac task of Ant. Did you try this? -- Reinhard
Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2
Reinhard Pötz dijo: Did you solve your problems with running ant using JDK? I proposed to run Ant with a JRE 1.5 and use the 1.5 compiler explicitly in the javac task of Ant. Did you try this? It would be fine to already include it in the build system. Soon or later we will need to make the change. Doing it right now, will encourge more people to let do a try. Best Regards, Antonio Gallardo
Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2
Antonio Gallardo wrote: Reinhard Pötz dijo: Did you solve your problems with running ant using JDK? I proposed to run Ant with a JRE 1.5 and use the 1.5 compiler explicitly in the javac task of Ant. Did you try this? It would be fine to already include it in the build system. Soon or later we will need to make the change. Doing it right now, will encourge more people to let do a try. Yes, we could make the compiler configurable. If I have some time I'll make the change. -- Reinhard
Re: [ANN] GUIapplication for Offline Processing
Okay, Simon, sorry for my delay in replying. Here's my idea of what I'd like to see. Firstly, I'd ___love___ to see a really thin GUI, with no editors (or a really cut down notepad style editor) living within Cocoon CVS, and packaged with Cocoon .This GUI should make use of as much of Cocoon's code as poss, e.g. its loader, Avalon, etc, to minimise the amount of new code that is added because of it. If that can be pluggable (preferably using an Avalon style component system), that would be great. I think that this GUI, if it can be simple enough so that it will be easily maintainable by other Cocoon committers as well as Simon, would significantly reduce the entry barrier to using Cocoon in offline mode, and could increase its use in that area quite substantially. Anything more, e.g. OpenOffice editor plugins, etc, that might require more significant library dependencies, etc, can live in the to be created Cocoon-Tools CVS repository. Maybe it could be the thing that causes that repository to be set up. What do you all make of this as an approach? Regards, Upayavira Simon Mieth wrote: Dear Cocoon community, I want today announce my small GUIapplication, which uses the CocoonBean. I started for developing a small OfflineCMS with cocoon-inside. During working with the OpenOfficeBean (only available for Windows and Linux/Unix) and the nessecity to use dynamic classloading, i got the idea to try it with CocoonBean too. After getting a friendly hint from Upayavira to announce here and look if there is some interest. I have setup a small page with some documentation and binary and source-packages. the url: http://www.mieth-xml.de/openproject/cligui/ It is not a stable release yet and currently my OpenOfficePlugin is broken in some cases under Windows. A workaround is *dont* use Quit from OpenOffice File-menu, otherwise OO and the application hangs and the TaskManager will be your friend. :-( It is more a snapshot of what I'm doing, but it can simple launch Cocoon for Offline generation. Only open the cli.xconf from a Cocoon-distribution and hit process. Best Regards and Thanx again to Upayavira, Simon pure-OT After breaking my OpenOfficePlugin and searching for days, where I shot self in the foot. I'm feeling like this guy from this short movie ;-) (3 MB) http://files.purempegs.com/files/aliensong.mpeg /pure-OT
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
Antonio Gallardo wrote:
[EMAIL PROTECTED] dijo:
joerg 2004/03/03 11:47:35
Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding
RepeaterJXPathBinding.java
Log:
clean up: removed unused code (for reverting changes we have CVS, so
please remove old stuff always), JavaDoc added, comments fixed;
changed isNullAllListElements() = isAnyListElementNotNull(): the
duplicate negation at usage time breaks my brain ;-)
This depends of the POV you see it:
isNullAllListElements() - This is not a negation. It check if :
All elements on the List are null. Where is the negation?
isAnyListElementNotNull() - Here is a negation Not null :-D
Generally speaking, negative forms should be avoided, as their
interpretation may be difficult depending on people's linguistic
background. I used to work with Japanese people long time ago, and I'm
sure this name, even with a single negation, would be very hard for them
to understand.
So what about hasNonNullElements()?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
Sylvain Wallez dijo: Antonio Gallardo wrote: [EMAIL PROTECTED] dijo: joerg 2004/03/03 11:47:35 Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java Log: clean up: removed unused code (for reverting changes we have CVS, so please remove old stuff always), JavaDoc added, comments fixed; changed isNullAllListElements() = isAnyListElementNotNull(): the duplicate negation at usage time breaks my brain ;-) This depends of the POV you see it: isNullAllListElements() - This is not a negation. It check if : All elements on the List are null. Where is the negation? isAnyListElementNotNull() - Here is a negation Not null :-D Generally speaking, negative forms should be avoided, as their interpretation may be difficult depending on people's linguistic background. I used to work with Japanese people long time ago, and I'm sure this name, even with a single negation, would be very hard for them to understand. I agree. So what about hasNonNullElements()? The problem again is the hidden Non. This is a kind of negative. Look as the standard isNull() function. Why it is not isNotNull()? Because there is a negation. Then, the original function name is better to me: isNullAllListElements() or areNullAllListElements() To me it clearly states what we had in mind. Goerg changed the function name (and behavior) to write: if (isAnyListElementNotNull(...)) instead of if (!isNullAllListElements(...)) As a rule I try to avoid negation inside the names. In the case hasNonNullElements(), we can write also: if (hasNonNullElements()) Interesting is that the method need to check for each element if the value is null. At the end, I think I am not the best to decide the best name of the function. :-D Best Regards, Antonio Gallardo.
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
On 04.03.2004 09:31, Sylvain Wallez wrote: changed isNullAllListElements() = isAnyListElementNotNull(): the duplicate negation at usage time breaks my brain ;-) This depends of the POV you see it: isNullAllListElements() - This is not a negation. It check if : All elements on the List are null. Where is the negation? isAnyListElementNotNull() - Here is a negation Not null :-D Hmm, that's true. But what I meant was the usage of !isNullAllListElements and ListElement != null inside the function. What you are really testing for is the availableness/usability of the list for unique identification. So the function itself should not return true if it only contains nulls. Generally speaking, negative forms should be avoided, as their interpretation may be difficult depending on people's linguistic background. I used to work with Japanese people long time ago, and I'm sure this name, even with a single negation, would be very hard for them to understand. So what about hasNonNullElements()? Yes, this might be more obvious/understandable than any and not in my version. Joerg
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
In fact we can call it: isValidKey(...) --- I prefer this one over the below name. isValidUniqueRowId(...) The other names are too specific to what the function do. Sometimes it is good to call the functions by what solve and not by how is the internal implementation (using List, Set or whatever). WDYT? Best Regards, Antonio Gallardo. Joerg Heinicke dijo: On 04.03.2004 09:31, Sylvain Wallez wrote: changed isNullAllListElements() = isAnyListElementNotNull(): the duplicate negation at usage time breaks my brain ;-) This depends of the POV you see it: isNullAllListElements() - This is not a negation. It check if : All elements on the List are null. Where is the negation? isAnyListElementNotNull() - Here is a negation Not null :-D Hmm, that's true. But what I meant was the usage of !isNullAllListElements and ListElement != null inside the function. What you are really testing for is the availableness/usability of the list for unique identification. So the function itself should not return true if it only contains nulls. Generally speaking, negative forms should be avoided, as their interpretation may be difficult depending on people's linguistic background. I used to work with Japanese people long time ago, and I'm sure this name, even with a single negation, would be very hard for them to understand. So what about hasNonNullElements()? Yes, this might be more obvious/understandable than any and not in my version. Joerg
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/bindingRepeat erJXPathBinding.java
On 04.03.2004 03:06, Antonio Gallardo wrote: Antonio, I guess you are the only one using it at the moment. Can you test it please? I tested it before committing. I can not assure it is totaly bug free. What I can said is I will use it in many places. If there is a bug it will be showed. It was not meant that I expect your code to be bug free. I just thought you already have it in work somewhere and after my changes that I made more or less just for personal taste and consistency I asked you for testing it again, so that I have the comparison between your and my changes and no regression came in. Joerg
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/bindingRepeat erJXPathBinding.java
Joerg Heinicke dijo: On 04.03.2004 03:06, Antonio Gallardo wrote: Antonio, I guess you are the only one using it at the moment. Can you test it please? I tested it before committing. I can not assure it is totaly bug free. What I can said is I will use it in many places. If there is a bug it will be showed. It was not meant that I expect your code to be bug free. I just thought you already have it in work somewhere and after my changes that I made more or less just for personal taste and consistency I asked you for testing it again, so that I have the comparison between your and my changes and no regression came in. Yep. I did it. The code is working good. Thanks. I thought you jut changed the internal names and I answer to this mail before reviewing the posted code. Later, I saw you make a full refactoring instead of just changing some internal names. Best Regards, Antonio Gallardo
Re: Entry level JSDK 1.4 in Cocoon 2.2
Did you solve your problems with running ant using JDK? I proposed to run Ant with a JRE 1.5 and use the 1.5 compiler explicitly in the javac task of Ant. Did you try this? no, I haven't tried yet. I just started build with JAVA_HOME pointing to 1.5 and getting an error like: Buildfile: build.xml init-tasks: Compiling 2 source files to /home/cgaffga/data/cocoon-2.1.4/tools/anttasks javac: source release 1.4 requires target release 1.4 BUILD FAILED /home/cgaffga/data/cocoon-2.1.4/tools/targets/init-build.xml:132: Compile failed; see the compiler error output for details. So I had a look at init-build.xml, but couldn't figure out what went wrong. But for seems that it has something to do with changed -target param in javac. http://stefanbodewig.blogger.de/20040112/ As soon as I have some time, I will try with JRE 1.4 nad javac from 1.5 regards Christoph Gaffga [EMAIL PROTECTED] - Original Message - From: Reinhard Ptz [EMAIL PROTECTED] Newsgroups: gmane.text.xml.cocoon.devel Sent: Thursday, March 04, 2004 9:45 AM Subject: Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2 Christoph Gaffga wrote: The idea is to set JSDK 1.4 as the minimum supported JDK supported for the next major release 2.2 of Cocoon. Currently we are supporting also 1.3 but seems like few people is using it. but what about the maximum support JDK? I tried to compile with 1.5beta, but it didn't work. So I compiled with 1.4 and let it run with 1.5. The gc ist much better with 1.5! Did you solve your problems with running ant using JDK? I proposed to run Ant with a JRE 1.5 and use the 1.5 compiler explicitly in the javac task of Ant. Did you try this? -- Reinhard
DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
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=27432. 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=27432 Malformed HTTP headers (debug information in Parameters object) Summary: Malformed HTTP headers (debug information in Parameters object) Product: Cocoon 2 Version: 2.1.4 Platform: Sun OS/Version: Solaris Status: NEW Severity: Major Priority: Other Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello everybody, I encountered the following issue introduced with the Cocoon-2.1.4 release. As it turned out, a new feature of Cocoon-2.1.4 meant to provide detailed debug information in case of an error, is the cause of the problem. Each Parameters object given to a component is filled by Cocoon with an additional key org.apache.cocoon.sitemap/Location. We use the HttpHeaderAction to add custom headers to the output stream. This action iterates other the Parameters object and sets each Parameter as a HTTP header. The debug information now appears as well as a header and causes some mobiles to refuse to display the requested content. This bug is probably not restricted to the HttpHeaderAction alone, but most likely affects every component iterating over all submitted Parameters instead of picking out one directly. Best regards Lars
Re: [JCS] Test drive
Antonio Gallardo wrote: Hi: How to test drive the current JCS store implementation? An example configuration is now being patched in automatically by the build system. Look for JCS keyword and uncomment the configuration. I ran into a nasty circular dependency with the RepositorySource and CachedSource by the way which both depend on Cache. So be sure to comment these out if they're present. Unico
DO NOT REPLY [Bug 27432] - Malformed HTTP headers (debug information in Parameters object)
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=27432. 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=27432 Malformed HTTP headers (debug information in Parameters object) --- Additional Comments From [EMAIL PROTECTED] 2004-03-04 12:57 --- I forgot to add a log of the generated HTTP headers. Here they are: HTTP/1.1 200 OK Date: Tue, 03 Mar 2004 16:51:42 GMT Server: Jetty/4.2.12 (SunOS/5.8 sparc java/1.4.2_03) X-Cocoon-Version: 2.1.4 Pragma: no-cache Expires: -1 Cache-Control: no-cache, must-revalidate, max-age=0 Set-Cookie: JSESSIONID=dprp67a11b67o.sit1;path=/ org.apache.cocoon.sitemap/Location: file:/apps/DE/vsky/vsky-tng-30-0- 20040224/webapp/sitemap.xmap:1121:44 Transfer-Encoding: chunked Content-Type: application/xhtml+xml; charset=UTF-8
Re: [JCS] Test drive
Antonio Gallardo wrote: Hi: How to test drive the current JCS store implementation? Hmm, I can't seem to get past this NPE: Caused by: java.lang.NullPointerException at java.io.Reader.init(Unknown Source) at java.io.InputStreamReader.init(Unknown Source) at java.util.Properties.load(Unknown Source) at org.apache.jcs.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:203) at org.apache.jcs.JCS.ensureCacheManager(JCS.java:141) at org.apache.jcs.JCS.getInstance(JCS.java:101) at org.apache.cocoon.components.store.AbstractJCSStore.setup(AbstractJCSStore.java:118) I verified that the config file it tries to load from exists. Suggestions? Unico
Re: cvs commit: cocoon-2.1/lib jars.xml
[EMAIL PROTECTED] wrote: antonio 2004/03/03 23:01:56 Modified:lib jars.xml Log: Updated POI to 2.5-final-20040302 Is name of the JAR file coming from POI project? It's weird to see poi-2.5-final-20040302 instead of poi-2.5 as for other projects. Vadim
RE: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Wow, that's a nice one :) Now, I think passing this debug information into the Parameters is not the correct way to go. It can cause - as we see - problems and in addition this is an incompatible change! So all sitemap components that are iterating over the parameters object are affected by this problem. I think, we should disable this feature for now and find a better and compatible way. Anyone against this? Carsten -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 1:21 PM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object) 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=27432. 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=27432 Malformed HTTP headers (debug information in Parameters object) Summary: Malformed HTTP headers (debug information in Parameters object) Product: Cocoon 2 Version: 2.1.4 Platform: Sun OS/Version: Solaris Status: NEW Severity: Major Priority: Other Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello everybody, I encountered the following issue introduced with the Cocoon-2.1.4 release. As it turned out, a new feature of Cocoon-2.1.4 meant to provide detailed debug information in case of an error, is the cause of the problem. Each Parameters object given to a component is filled by Cocoon with an additional key org.apache.cocoon.sitemap/Location. We use the HttpHeaderAction to add custom headers to the output stream. This action iterates other the Parameters object and sets each Parameter as a HTTP header. The debug information now appears as well as a header and causes some mobiles to refuse to display the requested content. This bug is probably not restricted to the HttpHeaderAction alone, but most likely affects every component iterating over all submitted Parameters instead of picking out one directly. Best regards Lars
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Le Jeudi, 4 mars 2004, à 14:37 Europe/Zurich, Carsten Ziegeler a écrit : ...I think, we should disable this feature for now and find a better and compatible way Wouldn't just changing the header name from org.apache.cocoon.sitemap/Location to something like X-Cocoon-debug-sitemap-location fix the problem? Using a known prefix like X-Cocoon-debug- also makes it easy to filter out these headers when needed. -Bertrand
RE: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Bertrand Delacretaz wrote: Le Jeudi, 4 mars 2004, à 14:37 Europe/Zurich, Carsten Ziegeler a écrit : ...I think, we should disable this feature for now and find a better and compatible way Wouldn't just changing the header name from org.apache.cocoon.sitemap/Location to something like X-Cocoon-debug-sitemap-location fix the problem? Perhaps in this special case, I don't know, perhaps Lars can answer this. Using a known prefix like X-Cocoon-debug- also makes it easy to filter out these headers when needed. But then you have to change every component that currently iterates over the parameters and every component has to filter. We actually really introduced an incompatible feature and to be honest, I don't even know where it is used and if it's useful at all. Carsten
RE: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Bertrand Delacretaz wrote: Le Jeudi, 4 mars 2004, à 15:01 Europe/Zurich, Carsten Ziegeler a écrit : Bertrand Delacretaz wrote: ...Using a known prefix like X-Cocoon-debug- also makes it easy to filter out these headers when needed. But then you have to change every component that currently iterates over the parameters and every component has to filter. Yes, right. debugging info is not Parameters. There must be a better way. Yes, so if someone knows where this is used/useful we can perhaps think about an alternative. Carsten
RE: [JCS] Test drive
I didn't test it :) Perhaps the JCS version I put into the CVS from yesterday doesn't work? Or I did something wrong file I refactored the code a little bit? Corin, which version of JCS did you use? Carsten -Original Message- From: Unico Hommes [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 2:06 PM To: [EMAIL PROTECTED] Subject: Re: [JCS] Test drive Antonio Gallardo wrote: Hi: How to test drive the current JCS store implementation? Hmm, I can't seem to get past this NPE: Caused by: java.lang.NullPointerException at java.io.Reader.init(Unknown Source) at java.io.InputStreamReader.init(Unknown Source) at java.util.Properties.load(Unknown Source) at org.apache.jcs.engine.control.CompositeCacheManager.configure( CompositeCacheManager.java:203) at org.apache.jcs.JCS.ensureCacheManager(JCS.java:141) at org.apache.jcs.JCS.getInstance(JCS.java:101) at org.apache.cocoon.components.store.AbstractJCSStore.setup(Abst ractJCSStore.java:118) I verified that the config file it tries to load from exists. Suggestions? Unico
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Le Jeudi, 4 mars 2004, à 15:07 Europe/Zurich, Carsten Ziegeler a écrit : ...Yes, so if someone knows where this is used/useful we can perhaps think about an alternative. It is used to add location info to Exceptions, for example in o.a.c.matching.AbstractRegexpMatcher.preparedMatch() (search for SITEMAP_PARAMETERS_LOCATION). -Bertrand
AW: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers ( debug information in Parameters object)
Wouldn't just changing the header name from org.apache.cocoon.sitemap/Location to something like X-Cocoon-debug-sitemap-location fix the problem? Perhaps in this special case, I don't know, perhaps Lars can answer this. Just renaming might solve it, but I would not be happy with this solution. And I doubt that this prevents Cocoon from sending possibly non-RFC-conforming HTTP headers under all circumstances. Not to mention that I cannot oversee impacts this has on other components that iterate over Parameter objects. Best regards Lars Vodafone Global Content Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No. 4064873 This e-mail is for the addressee(s) only. If you are not an addressee, you must not distribute, disclose, copy, use or rely on this e-mail or its contents, and you must immediately notify the sender and delete this e-mail and all copies from your system. Any unauthorised use may be unlawful. The information contained in this e-mail is confidential and may also be legally privileged.
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Bertrand Delacretaz wrote: Le Jeudi, 4 mars 2004, à 15:07 Europe/Zurich, Carsten Ziegeler a écrit : ...Yes, so if someone knows where this is used/useful we can perhaps think about an alternative. It is used to add location info to Exceptions, for example in o.a.c.matching.AbstractRegexpMatcher.preparedMatch() (search for SITEMAP_PARAMETERS_LOCATION). Sitemap statement location information is present on the sitemap processor level. If you look at PreparableMatchNode class you'll see it is quite easy to augment the exception with location information there. Unico
DO NOT REPLY [Bug 27440] New: - nesting-error in SQLTransformer
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=27440.
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=27440
nesting-error in SQLTransformer
Summary: nesting-error in SQLTransformer
Product: Cocoon 2
Version: Current CVS 2.1
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: general components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
What I was looking for was somethink like
SELECT key FROM a UNION B
SELECT * FROM a WHERE key
SELECT * FROM b WHERE key
When nesting multiple sql:execute-querysql:query//sql:execute-querys
inside a top-level sql:execute-query-element, nothing is
done/executed/displayed. This is due to a bug with
SQLTransformer.current_query_index:
Here is the relevant code from SQLTransformer.java:
413:startExecuteQueryElement() {
417: current_query_index = queries.size();
503:endExecuteQueryElement() {
506: if (current_query_index == 0) executeQuery(0)
511: else current_query_index--; // BUG
Here is a trace of an example to illustrate the bug:
sql:execure-querycurrent_query_index := 0;
sql:execute-query current_query_index := 1;
/sql:execute-query current_query_index := 1-- = 0;
sql:execute-query current_query_index := 2;
/sql:execute-query current_query_index := 2-- = 1;
/sql:execute-query current_query_index == 1 != 0 // NO executeQuery(0)
Analysis of the bug:
* current_query_index is used two-fold:
1. As an index into the Vector queries to indicate the last query,
2. As an indicator of nesting-level.
This only works when each execute-query contains at-most one other
execute-query element.
* Using current_query_index as an indicator for nesting-level does work for
123//2/1 but not for 12/3/1.
* current_query_index is used in conjunction with sql:ancestor-value/@sql:level
to compute the parent query.
Clarification/comment:
A DTD for the current working (linear)queries would look like:
!ELEMENT execute-query (query,execute-query?)
A DTD for tree-queries, what I tried, would look like:
!ELEMENT execute-query (query,execute-query*)
Bug resolution:
Either document that only the 1st type of queries is allowed or rewrite
SQLTransformer to also allow the 2nd type of queries. Would a patch be accepted
if I would implement type 2?
Further comment:
I found one other posting of a person trying to do the same as I:
http://archives.real-time.com/pipermail/cocoon-users/2003-July/036617.html
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
agreed, 'nice one' was my reaction also :-) I ran into this already some weeks ago, probably should have reported it on the mailling list. It is in my upgrade 'report' however :-), but I didn't consider it a bug or so. We're using a pagination component that started behaving really weird because of this. What really surprised me is that this feature caused problems after an upgrade to 2.1.4, coming from 2.1.3 (I think). I started looking in the changes list and I found an entry for this [1] *before* the release of 2.1.3. Probably I didn't notice it in 2.1.3, but it should be there ever since. I find it really strange that nobody reported problems with this before, so I thought it was a well considered and intended 'feature' instead of a possible 'bug' :-) Jan [1] Sitemap components (matchers, actions, generators, etc) can know the location of their use in the sitemap unsing a special parameter named Constants.SITEMAP_PARAMETERS_LOCATION Jan Uyttenhove [EMAIL PROTECTED] Xume - http://www.xume.com Carsten Ziegeler wrote: Wow, that's a nice one :) Now, I think passing this debug information into the Parameters is not the correct way to go. It can cause - as we see - problems and in addition this is an incompatible change! So all sitemap components that are iterating over the parameters object are affected by this problem. I think, we should disable this feature for now and find a better and compatible way. Anyone against this? Carsten -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 1:21 PM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object) 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=27432. 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=27432 Malformed HTTP headers (debug information in Parameters object) Summary: Malformed HTTP headers (debug information in Parameters object) Product: Cocoon 2 Version: 2.1.4 Platform: Sun OS/Version: Solaris Status: NEW Severity: Major Priority: Other Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello everybody, I encountered the following issue introduced with the Cocoon-2.1.4 release. As it turned out, a new feature of Cocoon-2.1.4 meant to provide detailed debug information in case of an error, is the cause of the problem. Each Parameters object given to a component is filled by Cocoon with an additional key org.apache.cocoon.sitemap/Location. We use the HttpHeaderAction to add custom headers to the output stream. This action iterates other the Parameters object and sets each Parameter as a HTTP header. The debug information now appears as well as a header and causes some mobiles to refuse to display the requested content. This bug is probably not restricted to the HttpHeaderAction alone, but most likely affects every component iterating over all submitted Parameters instead of picking out one directly. Best regards Lars smime.p7s Description: S/MIME Cryptographic Signature
Instrumentation, anyone?
It was a long time since I last used the Avalon instrumentation stuff, but it just seems like it's not working anymore. I'm following the provided instructions under tools/instrumentation, something is listening on port 1 as expected but the GUI seems just to sleep in a Not connected status (and tcpdump shows very little, if any, traffic on that port). Am I overlooking something? More in general, I'm wondering what is the overall status of instrumentation and checking for community interest on this particular topic. I don't quite understand what is the status in Avalon-land of the instrumentation thingy, but it doesn't seem quite active. OTOH, I start to think that this proprietary instrumentation is a dead-end since it seems pretty clear that JMX is the way to go. I'm wondering if there is any interest (and kowledgeable people) in JMX-enabling Cocoon (for monitoring and management purposes only). I think that Cocoon deployments could benefit quite a bit from being properly instrumented. Opinions? -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
RE: Instrumentation, anyone?
Actually, I have a requirement to do exactly that, so if anyone has already done it I'd happily use the code. Ralph -Original Message- From: Gianugo Rabellino [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 7:53 AM To: [EMAIL PROTECTED] Subject:Instrumentation, anyone? It was a long time since I last used the Avalon instrumentation stuff, but it just seems like it's not working anymore. I'm following the provided instructions under tools/instrumentation, something is listening on port 1 as expected but the GUI seems just to sleep in a Not connected status (and tcpdump shows very little, if any, traffic on that port). Am I overlooking something? More in general, I'm wondering what is the overall status of instrumentation and checking for community interest on this particular topic. I don't quite understand what is the status in Avalon-land of the instrumentation thingy, but it doesn't seem quite active. OTOH, I start to think that this proprietary instrumentation is a dead-end since it seems pretty clear that JMX is the way to go. I'm wondering if there is any interest (and kowledgeable people) in JMX-enabling Cocoon (for monitoring and management purposes only). I think that Cocoon deployments could benefit quite a bit from being properly instrumented. Opinions? -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
RE: Instrumentation, anyone?
Gianugo Rabellino wrote: It was a long time since I last used the Avalon instrumentation stuff, but it just seems like it's not working anymore. I'm following the provided instructions under tools/instrumentation, something is listening on port 1 as expected but the GUI seems just to sleep in a Not connected status (and tcpdump shows very little, if any, traffic on that port). Am I overlooking something? More in general, I'm wondering what is the overall status of instrumentation and checking for community interest on this particular topic. I don't quite understand what is the status in Avalon-land of the instrumentation thingy, but it doesn't seem quite active. It's not an official statement but I think I read on the Avalon dev list that instrumentation is dead, perhaps I'm wrong. OTOH, I start to think that this proprietary instrumentation is a dead-end since it seems pretty clear that JMX is the way to go. I'm wondering if there is any interest (and kowledgeable people) in JMX-enabling Cocoon (for monitoring and management purposes only). I think that Cocoon deployments could benefit quite a bit from being properly instrumented. Yes, JMX is imho the way to go, so a general +1. I don't have much knowledge of JMX, but I would assistent and help in such an effort whereever I can. The simple question is only, which version we would use as base, I would suggest 2.2. Carsten
Re: Instrumentation, anyone?
Carsten Ziegeler wrote: Yes, JMX is imho the way to go, so a general +1. I don't have much knowledge of JMX, but I would assistent and help in such an effort whereever I can. The simple question is only, which version we would use as base, I would suggest 2.2. It really depends on how far we are from 2.2. I don't want to sound pessimistic, and I must confess that I'm the first one lagging behind the Fortress migration, but I have an overall feeling that we are still quite far away, and I think that we could use something ASAP. I'm no JMX expert at all, but I understand that basic JMX support can be easily piggybacked on existing code, as long as you're basically happy with monitoring and small management tasks: more important needs might require significant changes to the code base, so if I were to draw a plan I would say that we _might_ include some JMX code right now and that we _should_ plan JMX support for 2.2, even if that requires some refactoring. I have the feeling that a complex application like Cocoon really could use some management tools. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
RE: Instrumentation, anyone?
Gianugo Rabellino wrote: Carsten Ziegeler wrote: Yes, JMX is imho the way to go, so a general +1. I don't have much knowledge of JMX, but I would assistent and help in such an effort whereever I can. The simple question is only, which version we would use as base, I would suggest 2.2. It really depends on how far we are from 2.2. I don't want to sound pessimistic, and I must confess that I'm the first one lagging behind the Fortress migration, but I have an overall feeling that we are still quite far away, :), yes this might be true. and I think that we could use something ASAP. Sure I'm no JMX expert at all, but I understand that basic JMX support can be easily piggybacked on existing code, as long as you're basically happy with monitoring and small management tasks: more important needs might require significant changes to the code base, so if I were to draw a plan I would say that we _might_ include some JMX code right now and that we _should_ plan JMX support for 2.2, even if that requires some refactoring. I have the feeling that a complex application like Cocoon really could use some management tools. Sounds like a good plan! Carsten
RE: Instrumentation, anyone?
I second this opinion. Our development is focused on using 2.1 since that is what is available. Although we are many months from deploying I wouldn't want to make a switch to 2.2 that late in the development. We have a requirement to be able to instrument as much as possible, so getting a handle on pool sizes, etc. would be very valuable. We have a requirement to do this through JMX, so I'm definitely up to doing some work on this. This task is actually already on my schedule for the week after next. As for how hard it is, you just create Mbeans that monitor and manage things. As long as they can call methods that get and set the needed information you're set. There are also some very nice tools around to do some of this for you. One of the tools we are evaluating is AdventNet JMX Studio and Applications Manager. If anyone has experience with these please let me know. Ralph -Original Message- From: Gianugo Rabellino [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 8:28 AM To: [EMAIL PROTECTED] Subject:Re: Instrumentation, anyone? It really depends on how far we are from 2.2. I don't want to sound pessimistic, and I must confess that I'm the first one lagging behind the Fortress migration, but I have an overall feeling that we are still quite far away, and I think that we could use something ASAP. I'm no JMX expert at all, but I understand that basic JMX support can be easily piggybacked on existing code, as long as you're basically happy with monitoring and small management tasks: more important needs might require significant changes to the code base, so if I were to draw a plan I would say that we _might_ include some JMX code right now and that we _should_ plan JMX support for 2.2, even if that requires some refactoring. I have the feeling that a complex application like Cocoon really could use some management tools. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
RE: Instrumentation, anyone?
There were some posts on February 4 that indicated that excalibur-instrument was a good way to get info on the pools was excalibur-instrument-manager (and presumably excalibur-instrument). Your earlier post indicated that avalon instrumentation is dead. Are these the same things? Ralph -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 8:32 AM To: [EMAIL PROTECTED] Subject:RE: Instrumentation, anyone? I'm no JMX expert at all, but I understand that basic JMX support can be easily piggybacked on existing code, as long as you're basically happy with monitoring and small management tasks: more important needs might require significant changes to the code base, so if I were to draw a plan I would say that we _might_ include some JMX code right now and that we _should_ plan JMX support for 2.2, even if that requires some refactoring. I have the feeling that a complex application like Cocoon really could use some management tools. Sounds like a good plan! Carsten
Re: Instrumentation, anyone?
Sorry to put my noose in this discussion :-) -Mensagem original- De: Gianugo Rabellino [mailto:[EMAIL PROTECTED] I'm no JMX expert at all, but I understand that basic JMX support can be easily piggybacked on existing code, as long as you're basically happy with monitoring and small management tasks: more important needs might require significant changes to the code base, so if I were to draw a plan I would say that we _might_ include some JMX code right now and that we _should_ plan JMX support for 2.2, even if that requires some refactoring. I have the feeling that a complex application like Cocoon really could use some management tools. I feel your pain. Why don't you take a different direction using AOP (avoiding tangling) or even XDoclet to generate the required MBean interfaces? (I'm completly ignorant about the license of these tools, I'm just want to point that maybe put this support directly in the Cocoon code by now couldn't be a good idea.. maybe) -- hammett
Re: Instrumentation, anyone?
Ralph Goers wrote: I second this opinion. Our development is focused on using 2.1 since that is what is available. Although we are many months from deploying I wouldn't want to make a switch to 2.2 that late in the development. We have a requirement to be able to instrument as much as possible, so getting a handle on pool sizes, etc. would be very valuable. We have a requirement to do this through JMX, so I'm definitely up to doing some work on this. This task is actually already on my schedule for the week after next. As for how hard it is, you just create Mbeans that monitor and manage things. As long as they can call methods that get and set the needed information you're set. Yeah, well... that's as easy as it can be. However, I was looking for something a bit more intelligent so that we don't have to write MBeans for everything. I was looking into dynamic MBeans, which look like a quite different beast to manage. Do you have any experience on that? Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
Re: Instrumentation, anyone?
Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote: I'm no JMX expert at all, but I understand that basic JMX support can be easily piggybacked on existing code, as long as you're basically happy with monitoring and small management tasks: more important needs might require significant changes to the code base, so if I were to draw a plan I would say that we _might_ include some JMX code right now and that we _should_ plan JMX support for 2.2, even if that requires some refactoring. I have the feeling that a complex application like Cocoon really could use some management tools. I feel your pain. Why don't you take a different direction using AOP (avoiding tangling) or even XDoclet to generate the required MBean interfaces? (I'm completly ignorant about the license of these tools, I'm just want to point that maybe put this support directly in the Cocoon code by now couldn't be a good idea.. maybe) You have a point indeed. While AOP could be a bit too much for the current codebase, the XDoclet approach might make a lot of sense since MBeans could be built automagically at compile time. A nasty issue, actually, could be that some of the most interesting manageable stuff isn't really under Cocoon control since it belongs to Excalibur, but I feel that if we could come out with a decent XDoclet based JMX implementation even Excalibur would be happy to include it. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
DO NOT REPLY [Bug 27440] - nesting-error in SQLTransformer
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=27440. 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=27440 nesting-error in SQLTransformer --- Additional Comments From [EMAIL PROTECTED] 2004-03-04 17:47 --- Created an attachment (id=10665) Rewrite to allow tree structure + more documentation
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Carsten Ziegeler wrote:
Bertrand Delacretaz wrote:
Le Jeudi, 4 mars 2004, à 14:37 Europe/Zurich, Carsten
Ziegeler a écrit :
...I think, we should disable this feature for now and find
a better
and compatible way
Wouldn't just changing the header name from
org.apache.cocoon.sitemap/Location to something like
X-Cocoon-debug-sitemap-location fix the problem?
Perhaps in this special case, I don't know, perhaps Lars can answer this.
Using a known prefix like X-Cocoon-debug- also makes it
easy to filter out these headers when needed.
This information is absolutely not meant to be sent back to the browser!
But then you have to change every component that currently iterates over the parameters and every component has to filter.
We actually really introduced an incompatible feature and to be honest, I don't even know where it is used and if it's useful at all.
I'm the one who introduced this feature: it allows every sitemap
component to know the location from where it is invoked, which allows
more meaningful messages to be produced by these components. You can
find some example usage of this in e.g. AbstractWildcardMatcher and
AbstractProcessingPipeline.
The parameters object is the only one that is related to a particular
usage of a component in a sitemap statement, and therefore the only
place where this information can be stored.
Now I understand the problem Lars encountered, and I'm sorry to have
missed that when I implemented that feature (I don't use these
parameter-iterating actions).
So how do we solve this? I do want to keep this information which is an
important means to provide more help to the developper in case of problem.
So here's a proposal (I should have thought about it way earlier...):
let's use a LocatedParameters, subclass of Parameters with an
additional getLocation() method. It has no impact on components that
iterate on parameters, and yet still provide location whenever it's needed.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Instrumentation, anyone?
Gianugo Rabellino wrote:
Carsten Ziegeler wrote:
Yes, JMX is imho the way to go, so a general +1. I don't have
much knowledge of JMX, but I would assistent and help in such
an effort whereever I can.
The simple question is only, which version we would use as base,
I would suggest 2.2.
It really depends on how far we are from 2.2. I don't want to sound
pessimistic, and I must confess that I'm the first one lagging behind
the Fortress migration, but I have an overall feeling that we are
still quite far away, and I think that we could use something ASAP.
I'm no JMX expert at all, but I understand that basic JMX support can
be easily piggybacked on existing code, as long as you're basically
happy with monitoring and small management tasks: more important needs
might require significant changes to the code base, so if I were to
draw a plan I would say that we _might_ include some JMX code right
now and that we _should_ plan JMX support for 2.2, even if that
requires some refactoring. I have the feeling that a complex
application like Cocoon really could use some management tools.
+1.
I once tried to understand the communication between the instrument
manager and instrument client, but totally got lost in AltRMI stuff.
But the basing Instrument and InstrumentManager stuff seems quite
simple, and maybe the quickest way towards JMX compliance is to consider
the instruments as the MBeans. I don't have much JMX experience, though...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Instrumentation, anyone?
Gianugo Rabellino wrote: Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote: I'm no JMX expert at all, but I understand that basic JMX support can be easily piggybacked on existing code, as long as you're basically happy with monitoring and small management tasks: more important needs might require significant changes to the code base, so if I were to draw a plan I would say that we _might_ include some JMX code right now and that we _should_ plan JMX support for 2.2, even if that requires some refactoring. I have the feeling that a complex application like Cocoon really could use some management tools. I feel your pain. Why don't you take a different direction using AOP (avoiding tangling) or even XDoclet to generate the required MBean interfaces? (I'm completly ignorant about the license of these tools, I'm just want to point that maybe put this support directly in the Cocoon code by now couldn't be a good idea.. maybe) You have a point indeed. While AOP could be a bit too much for the current codebase, the XDoclet approach might make a lot of sense since MBeans could be built automagically at compile time. A nasty issue, actually, could be that some of the most interesting manageable stuff isn't really under Cocoon control since it belongs to Excalibur, but I feel that if we could come out with a decent XDoclet based JMX implementation even Excalibur would be happy to include it. Just keep in mind that everytime you do code generation IDEs that need to compile classes to operate (like Eclipse or Idea) choke big time. If we can use introspection or dynamic proxying instead, it would be a much better thing, IMO, for this very reason. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Instrumentation, anyone?
Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote: -Mensagem original- De: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Just keep in mind that everytime you do code generation IDEs that need to compile classes to operate (like Eclipse or Idea) choke big time. Haven't had this experience. All the time things got out-of-date I ran an Ant script to exec xdoclet. Eclipse saw the 'gensrc' as a source dir and compiled everything without choking. But this gets pretty hairy with CVS and a distributed workgroup, believe me. If we can use introspection or dynamic proxying instead, it would be a much better thing, IMO, for this very reason. I think you should worry about tangling. JMX code scattered all over the place should be avoided in any project for any scenario. If was my choice I would pickup AspectJ, but it seems to fail miserably with large projects. I do see the value of aspect orientation, especially in this context, but no java technology for AOP is mature enough for us to use, I fear. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Sylvain Wallez wrote: Carsten Ziegeler wrote: Bertrand Delacretaz wrote: Le Jeudi, 4 mars 2004, à 14:37 Europe/Zurich, Carsten Ziegeler a écrit : ...I think, we should disable this feature for now and find a better and compatible way Wouldn't just changing the header name from org.apache.cocoon.sitemap/Location to something like X-Cocoon-debug-sitemap-location fix the problem? Perhaps in this special case, I don't know, perhaps Lars can answer this. Using a known prefix like X-Cocoon-debug- also makes it easy to filter out these headers when needed. This information is absolutely not meant to be sent back to the browser! But then you have to change every component that currently iterates over the parameters and every component has to filter. We actually really introduced an incompatible feature and to be honest, I don't even know where it is used and if it's useful at all. I'm the one who introduced this feature: it allows every sitemap component to know the location from where it is invoked, which allows more meaningful messages to be produced by these components. You can find some example usage of this in e.g. AbstractWildcardMatcher and AbstractProcessingPipeline. The parameters object is the only one that is related to a particular usage of a component in a sitemap statement, and therefore the only place where this information can be stored. Now I understand the problem Lars encountered, and I'm sorry to have missed that when I implemented that feature (I don't use these parameter-iterating actions). So how do we solve this? I do want to keep this information which is an important means to provide more help to the developper in case of problem. So here's a proposal (I should have thought about it way earlier...): let's use a LocatedParameters, subclass of Parameters with an additional getLocation() method. It has no impact on components that iterate on parameters, and yet still provide location whenever it's needed. Does it make sense to narrow the location down even more by passing the parameter name with that method? location = parameters.getLocation(name); I am surprised this isn't part of the Parameters interface already. Unico
Re: Instrumentation, anyone?
-Mensagem original- De: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] But this gets pretty hairy with CVS and a distributed workgroup, believe me. Well, we use CVS. The two basic rules was: - You do not upload generated code to CVS - You do not upload generated code to CVS!! :-) But it wasn't a distributed workgroup, I must say. I do see the value of aspect orientation, especially in this context, but no java technology for AOP is mature enough for us to use, I fear. Sad but true :-( -- hammett
calling from a component made by my own to a transformer.
I can't figure out how to call another component. In my case, I want to
call xmlhttp component, but It's the same for any transformer, I
guess
Here is my code.
package myGenerators;
import org.apache.avalon.excalibur.pool.Poolable;
import org.apache.cocoon.components.parser.Parser;
import org.apache.avalon.framework.component.ComponentException;
import org.apache.cocoon.ProcessingException;
import org.apache.cocoon.environment.Source;
import org.apache.cocoon.transformation.Transformer;
import org.apache.cocoon.generation.ComposerGenerator;
import org.apache.avalon.framework.component.Component;
import com.clsw.cocoon.XmlHttpTransformer;
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;
import java.io.ByteArrayInputStream;
import java.io.IOException;
public class ZipGenerator extends ComposerGenerator implements Poolable{
private XmlHttpTransformer trans = null;
public void generate()
throws SAXException, IOException, ProcessingException {
String xmlURI = this.source;
Source archive = null;
Parser parser= null;
try {
archive = this.resolver.resolve( xmlURI
);
InputSource inputSource =
archive.getInputSource();
parser = (Parser) this.manager.lookup
(Parser.ROLE);
//parser.setConsumer( this.xmlConsumer
); //con xmlConsumer no funca
trans = (XmlHttpTransformer)
this.manager.lookup (XmlHttpTransformer.ROLE);
trans.setContentHandler(this.contentHandler);
parser.setContentHandler((xmlConsumer)trans);
parser.parse( inputSource );
}
catch (ComponentException ce) {
throw new
ProcessingException(Component Parser not found., ce);
}
finally {
if (archive != null)
archive.recycle();
}
}
}
-Mensaje original-
De: beyaRecords - The home Urban music [mailto:[EMAIL PROTECTED]
Enviado el: jueves, 04 de marzo de 2004 13:35
Para: [EMAIL PROTECTED]
Asunto: Re: Passing values into an XSP logic sheet
Christopher,
that works fine now ;-)
many thanks
Andrew
On 4 Mar 2004, at 16:00, Christopher Painter-Wakefield wrote:
xsl:template match=artistDetails:get-details
xsp:logic
int artistID = Integer.parseInt(xsl:apply-templates
select=artistDetails:id/node()/);
Artist artist = Artist.getArtist(artistID);
String artist_name = artist.getArtistName();
/xsp:logic
artist-details
namexsp:exprartist_name/xsp:expr/name
/artist-details
/xsl:template
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Instrumentation, anyone?
On 04.03.2004 20:10, Stefano Mazzocchi wrote: Just keep in mind that everytime you do code generation IDEs that need to compile classes to operate (like Eclipse or Idea) choke big time. Haven't had this experience. All the time things got out-of-date I ran an Ant script to exec xdoclet. Eclipse saw the 'gensrc' as a source dir and compiled everything without choking. We did the same thing in our last project (the ConWeb project) using Netbeans, for MBeans, for the CMP layer and some session beans. But this gets pretty hairy with CVS and a distributed workgroup, believe me. We also had no problems with it. As Hamilton said you just must not commit generated code, but I think that's obvious. Do you have something else in mind? What does distributed workgroup change on the issue? Joerg
Re: [JCS] Test drive
Corin Moss wrote: Hiya, Someone may have gotten to this first - it means that the properties file for the JCS config isn't in your classpath. I thought I tried that. Must be because I running from within Eclipse. It does not make much sense to me though. Why first do JCS.setConfigFilename() with the exact path location and then also requiring it to be on the classpath later on? I see why Carsten changed it to be directly under WEB-INF. When running in developement mode under the eclipse classpath WEB-INF/classes is not in scope for the classloader. Unico It's always the little things :) -Original Message- From: Unico Hommes [mailto:[EMAIL PROTECTED] Sent: Friday, 5 March 2004 2:06 a.m. To: [EMAIL PROTECTED] Subject: Re: [JCS] Test drive Antonio Gallardo wrote: Hi: How to test drive the current JCS store implementation? Hmm, I can't seem to get past this NPE: Caused by: java.lang.NullPointerException at java.io.Reader.init(Unknown Source) at java.io.InputStreamReader.init(Unknown Source) at java.util.Properties.load(Unknown Source) at org.apache.jcs.engine.control.CompositeCacheManager.configure(CompositeC acheManager.java:203) at org.apache.jcs.JCS.ensureCacheManager(JCS.java:141) at org.apache.jcs.JCS.getInstance(JCS.java:101) at org.apache.cocoon.components.store.AbstractJCSStore.setup(AbstractJCSSto re.java:118) I verified that the config file it tries to load from exists. Suggestions? Unico CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. For more information on the Television New Zealand Group, visit us online at http://www.tvnz.co.nz
RE: [JCS] Test drive
Hiya, I agree with you there - this is the default behaviour of setConfigFilename - it just wraps a properties reader (well, a method is subsequently calls does), which of course requires the file to be in the classpath. When I first implemented that bit I didn't realise that it was a properties reader - I was trying to do (as close as I could) a line for line reimplementation of the AbstractJisp store. The absolute path thing is a bit of a red herring as they say (left over from the directory set part of the JISP store.) I suspect we should comment this part appropriately, so as not to continue confusion. Hope I didn't cause you too many hours of frustration ;) Corin -Original Message- From: Unico Hommes [mailto:[EMAIL PROTECTED] Sent: Friday, 5 March 2004 10:11 a.m. To: [EMAIL PROTECTED] Subject: Re: [JCS] Test drive Corin Moss wrote: Hiya, Someone may have gotten to this first - it means that the properties file for the JCS config isn't in your classpath. I thought I tried that. Must be because I running from within Eclipse. It does not make much sense to me though. Why first do JCS.setConfigFilename() with the exact path location and then also requiring it to be on the classpath later on? I see why Carsten changed it to be directly under WEB-INF. When running in developement mode under the eclipse classpath WEB-INF/classes is not in scope for the classloader. Unico It's always the little things :) -Original Message- From: Unico Hommes [mailto:[EMAIL PROTECTED] Sent: Friday, 5 March 2004 2:06 a.m. To: [EMAIL PROTECTED] Subject: Re: [JCS] Test drive Antonio Gallardo wrote: Hi: How to test drive the current JCS store implementation? Hmm, I can't seem to get past this NPE: Caused by: java.lang.NullPointerException at java.io.Reader.init(Unknown Source) at java.io.InputStreamReader.init(Unknown Source) at java.util.Properties.load(Unknown Source) at org.apache.jcs.engine.control.CompositeCacheManager.configure(Composit eC acheManager.java:203) at org.apache.jcs.JCS.ensureCacheManager(JCS.java:141) at org.apache.jcs.JCS.getInstance(JCS.java:101) at org.apache.cocoon.components.store.AbstractJCSStore.setup(AbstractJCSS to re.java:118) I verified that the config file it tries to load from exists. Suggestions? Unico CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. For more information on the Television New Zealand Group, visit us online at http://www.tvnz.co.nz CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. For more information on the Television New Zealand Group, visit us online at http://www.tvnz.co.nz
Re: Instrumentation, anyone?
Joerg Heinicke wrote: We also had no problems with it. As Hamilton said you just must not commit generated code, but I think that's obvious. Do you have something else in mind? What does distributed workgroup change on the issue? that there is more chance of people making mistakes ;-) we *did* have problems with this in the past and we moved away from it. not that I'm stopping people, just making sure they know there is a problem there. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANN] GUIapplication for Offline Processing
On Thu, 04 Mar 2004 09:06:17 +
Upayavira [EMAIL PROTECTED] wrote:
Okay, Simon, sorry for my delay in replying.
Here's my idea of what I'd like to see.
Firstly, I'd ___love___ to see a really thin GUI, with no
editors (or a really cut down notepad style editor) living
within Cocoon CVS, and packaged with Cocoon .This GUI
should make use of as much of Cocoon's code as poss, e.g.
its loader, Avalon, etc, to minimise the amount of new
code that is added because of it.
If that can be pluggable (preferably using an Avalon style
component system), that would be great.
I think that this GUI, if it can be simple enough so that
it will be easily maintainable by other Cocoon committers
as well as Simon, would significantly reduce the entry
barrier to using Cocoon in offline mode, and could
increase its use in that area quite substantially.
Anything more, e.g. OpenOffice editor plugins, etc, that
might require more significant library dependencies, etc,
can live in the to be created Cocoon-Tools CVS
repository. Maybe it could be the thing that causes that
repository to be set up.
What do you all make of this as an approach?
Regards, Upayavira
Hi Upayavira,
well, so i unterstand it should show the uri-list an
options/Dialogs to edit the main CocoonBean settings and
Uri-elements.
At the moment I'm on thinking over how i should rewrite the
application to more flexibility. I tried a Component System
on some parts and would use such thing more and before
imitate a Avalon framework, maybe it is better to use it.
For what I have in mind it is important to be separated from
Cocoon and I wont like to give up this, but if I switch to
usable Component-system it might be possible to use Dialogs
and Import/Export-filter and the same BeanCofigurationHolder
for a pure CLIgui. A BeanConfigurationHolder is necessary,
because the current Bean has all setters, but only some
getters, but to configure all options and storing back to
cli.xconf getters are needed.
In many cases my application and a pure CLIgui will use the
same components, so if is interest there is a way.
I would call my app just more a cocoon-tool and would be
glad if some will use it (but not yet, I will change many
things)
Ok, some other things I have in mind during looking at
the CLI today. The current CLI-loader has the option to add
more then one jar.repository to the classloader. Is there
a reasen why it not point to tools/jetty/lib and have
servlet.jar in the classpath?
The following change to cocoon.sh
CLI_LIBRARIES=-Dloader.jar.repositories=$COCOON_LIB${PATHS
EP}${COCOON_HOME}/tools/jetty/lib
solves the often first problem in using the CLI,without
copy ;-).
I have separated the Cocoon-processing and publishing for me
and looked which jars are needed for CLIgui, I got just the
idea why not put jsch.jar (scp) and commons-net.jar (ftp) to
the ant libs and give so the possibility to use publishing
with ant and processing with your ant-task. The CLIgui could
setup the publishsettings and write a ant-buildfile. If the
CLIgui should publish to it can simple use the same libs and
then there would only be on more jar for the GUI (i would
suggest to use jgoodies- Formlayout and Looks for esay and
better GUi-building, if so the there where +2 jars
(BSD-license)).
I'm interested in the GUI thing,
Best Regards,
Simon
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Unico Hommes wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
snip/
But then you have to change every component that currently iterates
over the parameters and every component has to filter.
We actually really introduced an incompatible feature and to be
honest, I don't even know where it is used and if it's useful at all.
I'm the one who introduced this feature: it allows every sitemap
component to know the location from where it is invoked, which allows
more meaningful messages to be produced by these components. You can
find some example usage of this in e.g. AbstractWildcardMatcher and
AbstractProcessingPipeline.
The parameters object is the only one that is related to a particular
usage of a component in a sitemap statement, and therefore the only
place where this information can be stored.
Now I understand the problem Lars encountered, and I'm sorry to have
missed that when I implemented that feature (I don't use these
parameter-iterating actions).
So how do we solve this? I do want to keep this information which is
an important means to provide more help to the developper in case of
problem.
So here's a proposal (I should have thought about it way earlier...):
let's use a LocatedParameters, subclass of Parameters with an
additional getLocation() method. It has no impact on components
that iterate on parameters, and yet still provide location whenever
it's needed.
Does it make sense to narrow the location down even more by passing
the parameter name with that method?
location = parameters.getLocation(name);
I am surprised this isn't part of the Parameters interface already.
Although individual parameter location may be useful, the location
parameter I'm talking about is that of the statement. This makes me
think SitemapParameters with a getStatementLocation() is better than
LocatedParameters I suggested above.
Let's consider the following snippet:
10 ...
11 map:generate src=foo.xml
12 map:parameter name=bar value=baz/
13 /map:parameter
14 ...
((SitemapParameters)parameters).getStatementLocation() --
sitemap.xmap:11:2
parameters.getLocation(bar) -- sitemap.xmap:12:4
getLocation(name) can be useful to notify a problem about a particular
parameter, while getStatementLocation() relates to the whole statement.
getLocation(name) can also be useful for Parameterizable components, as
it replaces Configuration.getLocation() which is no more available.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: cvs commit: cocoon-2.1/lib jars.xml
Vadim Gritsenko dijo: [EMAIL PROTECTED] wrote: antonio 2004/03/03 23:01:56 Modified:lib jars.xml Log: Updated POI to 2.5-final-20040302 Is name of the JAR file coming from POI project? It's weird to see poi-2.5-final-20040302 instead of poi-2.5 as for other projects. Yep. In this case I just did a copy paste. This weird names is the names they are using since 2.0-final. You can download the binaries and see it. Best Regards, Antonio Gallardo
[cforms] Woody template transformer eating namespaced element tags?
Hey folks -- I just upgraded my web application from 2.1.3 to 2.1.4 and I am now seeing some strange behavior from the woody template transformer. It seems that elements in the xhtml namespace come out the other side of the woody template transformer without their names! To reproduce this, edit this sample file: src/blocks/woody/samples/forms/registration_template.xml And add the default namespace xmlns=http://www.w3.org/1999/xhtml; to the document. When you run the sample, the returned page source looks like: xmlns=http://www.w3.org/1999/xhtml; Registration/ form ... ... all normal in here ... /form / / Notice that all the elements from the template file no longer have names. Removing the woody template transformer from the pipeline causes the names to reappear. Anyone have a quick patch for this? It is a real show stopper for me since I need some of the woody functionality from 2.1.4. cheers, -steve
files in root dir (was: cvs commit: cocoon-2.1 appendcp.bat build.bat)
On 04.03.2004 08:53, [EMAIL PROTECTED] wrote: antonio 2004/03/03 23:53:55 Modified:.build.bat Added: .appendcp.bat Log: Don't copy endorsed jars to lib/tools Cool, his avoids finally the useless copying of the XML jars into tools/lib. Thanks, Antonio. I just moved the appendcp.bat into tools/bin directory to avoid files in the root. BTW, can we move even more files from root dir to other locations. For example announcement.xml, which is not needed there, but only copied by the build system. Or cli.xconf. Or mount-table.xml.sample. We should keep the root dir clean if possible, shouldn't we? Joerg
DO NOT REPLY [Bug 27456] New: - [PATCH] BetwixtTransformer output twice the startDocument. Fix.
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=27456. 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=27456 [PATCH] BetwixtTransformer output twice the startDocument. Fix. Summary: [PATCH] BetwixtTransformer output twice the startDocument. Fix. Product: Cocoon 2 Version: 2.1.4 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: blocks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When trying to use the BetwixtTransformer you obtain the following results: - If the serializer that ends the pipeline is map:serialize type=xml/. We get : ?xml version=1.0 encoding=ISO-8859-1 ? page xmlns:xsp=http://apache.org/xsp; example xmlns:betwixt=http://apache.org/cocoon/betwixt/1.0; ?xml version=1.0 encoding=ISO-8859-1 ? - If the serializer that ends the pipeline is map:serialize/. We get: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; page xmlns:xsp=http://apache.org/xsp; example xmlns:betwixt=http://apache.org/cocoon/betwixt/1.0; !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; ... In any case. It's wrong. We get twice what should appear at the start of the document. see thread: http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=107676749217407w=2
DO NOT REPLY [Bug 27456] - [PATCH] BetwixtTransformer output twice the startDocument. Fix.
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=27456. 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=27456 [PATCH] BetwixtTransformer output twice the startDocument. Fix. --- Additional Comments From [EMAIL PROTECTED] 2004-03-04 22:53 --- Created an attachment (id=10669) Fixes the bug by call callDocumentEvents(false) on the underlying SAXBeanWriter.
DO NOT REPLY [Bug 27457] New: - Errors in documentation XML
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=27457. 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=27457 Errors in documentation XML Summary: Errors in documentation XML Product: Cocoon 2 Version: 2.1 Platform: All URL: http://cocoon.apache.org/2.1/userdocs/transformers/cincl ude- transformer.html#Including+External+XML+%28advanced%29 OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] For the section, Including External XML (advanced) The Corrected XML should be: ?xml version=1.0? data xmlns:cinclude=http://apache.org/cocoon/include/1.0; cinclude:includexml cinclude:srchttp://itsunshine/tamino/blah/cinclude:src cinclude:configuration cinclude:parameter cinclude:namemethod/cinclude:name cinclude:valuePOST/cinclude:value /cinclude:parameter /cinclude:configuration cinclude:parameters cinclude:parameter cinclude:namemessage/cinclude:name cinclude:valueHi there/cinclude:value /cinclude:parameter cinclude:parameter cinclude:name_Process/cinclude:name cinclude:valuenamematti/nameage36/age/cinclude:value /cinclude:parameter /cinclude:parameters /cinclude:includexml /data
Re: [cforms] Woody template transformer eating namespaced element tags?
I did a little more poking around, and it turns out that even though the woody template transformer mangles the xml document, the problem does not appear unless you run the document through the identity xslt transform. Simple example: test.xml html xmlns=http://www.w3.org/1999/xhtml; body Hello World /body /html test.xsl ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:template match=@*|node() priority=-1 xsl:copy xsl:apply-templates select=@*|node()/ /xsl:copy /xsl:template /xsl:stylesheet pipeline map:match pattern=test map:generate src=test.xml/ map:transform type=woody/ map:transform src=test.xsl/ map:serialize/ /map:match Will produce xmlns=http://www.w3.org/1999/xhtml; Hello World / / But if you remove the woody transform or the xslt, you get ~~ html xmlns=http://www.w3.org/1999/xhtml; body Hello World /body /html
DO NOT REPLY [Bug 27457] - Errors in documentation XML
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=27457. 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=27457 Errors in documentation XML [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 00:05 --- Blind developers love a diff to see what exactly has changed - it took some time until I found the param = parameter. Hope it was the only difference ... Thanks for spotting. Joerg
[Woody] Button Focus
If I have a form which contains a repeater, example being the sample form in the woody blocks, focus goes to the first submit button on the form. In the sample XMLBinding form, for instance, if I enter an email address and then hit enter it will submit the Add Contact button. Adding a contact row rather than submitting the form. This is a bug as far as our users are concerned (we have many forms with repeaters and mutliple buttons). There are times where we have only a Remove type button. Therefore when a user hits enter a row is removed, when they expected the form to be submitted. Joe
Re: [CForms] Support for multipe unique-row-id in Repeater
On 04.03.2004 05:04, Antonio Gallardo wrote: Joerg Heinicke dijo: wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath wb:unique-row wb:unique-field id=myId1 path=myId1/ wb:unique-field id=myId2 path=myId2/ /wb:unique-row wb:on-bind wb:value id=myId1 path=myId1/ wb:value id=myId2 path=myId2/ wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater It was a good idea to replace the both attributes with a more sophisticated XML structure, but it is a bad realization in my opinion. I posted a proposal for changes before I started to code it. Nobody answer (a silent aproval?), then I started the coding. Only Tim answered and give me his OK. The good news is it is not too hard to change the code and/or tag names. I agree with you: we can do it far better. But how to start if nobody cares about this change? On the other way I don't wanted to have this as another aproved change without implementation. Seems like coding is a good tool to put little pressure on other committers to review a proposal. Your comments are very welcomed. ;-D This was why I ended my rant with Unfortunately not many Woody developers are really active on the list at the moment. It was not a criticism to the maybe lazy people, but a real regret, that discussions on CForms are missing at the moment. On the other hand the proposal came in a thread without any relevance (TempRepeater vs. SimpleRepeater), so I for example just didn't read it at the weekend as I still had to read things about conjoint measurement and analysis of variances. A simple [proposal] in the subject and a bit more time to react on it would have helped I think. rant The above is redundant, irritating (unique-field is not really correctly named, is it?) Not sure, we can change it, I don't got long time thinking in the right name. I am willing to change it for a more descriptive name. Can you give us a suggestion? I will get to this topic later in the mail. and (because of the more java code we need) bloated. ^^^ (Don't understand the word). No dictionary at hand? Bloating a balloon ... bloating our code ... On the one hand the redundancy above is obvious, The redundancy was always there (using the old attributes you will see it), maybe now it is more clear (evident) than before No, I don't see this in the samples and in my code. The binding is already done by just @unique-row-id and @unique-path. That this binding is completely differently specified than the other ones was the most irritating on these attributes. Therefore I like the move to the sophisticated XML structure as I called it. on the other hand sentences like This unique-field element ... The id and path attributes have the same meaning as in wb:value. ... The wd:convertor ... For more info see the description of this element in wb:value. will get me suspicious. Why the §$% we need an additional XML element if we have already one that seems to be perfect for it: wb:value as the frequent references above show? I thought about this too. The wb:unique-field description don't need all the attributes of a wb:value element. Sample for which of the attributes are not needed? After thinking on it, I thought it would be better (even from a descriptive POV) to have another tag describing clearly what the wb:unique-field is intendend for. It is a striped down version of wb:value and conceptually they are diferent. Here I don't agree. It's exactly the same. You bind a value to a field. But the binding does not know anything about the concept field - one reason for not calling it wb:unique-field. So we would have wb:unique-value. But this particular value is not needed to be unique, only the aggregation of all childs of wb:unique-row. That's wb:unique-value is also still irritating. Now we were back to wb:value. On the other side I don't mean to change the binding to much to allow a back compatibility with the old approach. Don't get your point here. Using wb:value does not change anything in relation to back compatibility or am I wrong? Why do we have to specify @id and @path twice for those identifying elements? And so on. Not necesary at all. Note, sometime you don't define (or want to define) a wb:value inside the wb:on-binding the key values. So it is valid too: wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath wb:unique-row wb:unique-field id=myId1 path=myId1/ wb:unique-field id=myId2 path=myId2/ /wb:unique-row wb:on-bind wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater I hope I don't miss anything important. This does look much better of course, but for which cases would you add it to wb:on-bind and for which cases not? And the latter we do this the more we will break. Unfortunately not many Woody developers are really active on the list at
Re: cvs commit: cocoon-2.1 build.bat build.sh
On 05.03.2004 01:54, Antonio Gallardo wrote: [EMAIL PROTECTED] dijo: joerg 2004/03/04 16:44:50 Modified:.build.bat build.sh Log: removed the output of the very temporary classpath I think it is a good info for users. Often the problems are related to the usage of any of this endorsed libs. That way we can show them what version they are running while building Cocoon. At least an output line on a console does not hurt anybody. That's true of course, but this very temporary classpath is further modified by Ant and has nothing to do with endorsed libs. If you have an endorsed libs problem, this won't fix it. Furthermore we know that this script works and that it just uses the libs from lib/endorsed. The user can just look there. For making sure that you do not have an endorsed libs problem you can only test it on run time, e.g. by using Xalan's environment check. I fear this line irritates more than it clearifies. Joerg
Re: [CForms] Support for multipe unique-row-id in Repeater
Hi Joerg: If the problem is just to change a name: from wb:unique-field to wb:value Then, no problem from my side. If you agree, I will change the code and this issue can be closed, right? :-D Best Regards, Antonio Gallardo.
Re: [CForms] Support for multipe unique-row-id in Repeater
On 05.03.2004 02:10, Antonio Gallardo wrote: Hi Joerg: If the problem is just to change a name: from wb:unique-field to wb:value Then, no problem from my side. If you agree, I will change the code and this issue can be closed, right? :-D No, please don't do another fast shot. I would like to have this discussed by a few more people. And it was more than just the name: - the additional binding classes (bloated Java) - the @direction - wb:unique-row/wb:value vs. wb:on-bind/wb:value/@unique So it's not just the name, but the binding to be used (ValueJXPathBinding vs. UniqueFieldJXPathBinding). And we need agreement on wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath wb:unique-row wb:value id=myId1 path=myId1/ wb:value id=myId2 path=myId2/ /wb:unique-row wb:on-bind wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater or wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath wb:on-bind wb:value id=myId1 path=myId1 unique=true/ wb:value id=myId2 path=myId2 unique=true/ wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater What do the other people think? Joerg
Re: FOP with embeded SVG doesn't render at correct size in Cocoon
On 03.03.2004 22:20, J.Pietschmann wrote: Joerg Heinicke wrote: It's the 0.20.5 release, but built with our Batik 1.5. I guess the FOP people must clarify if this made any sense or not. IIRC we had the released Fop jar in our CVS and got complaints for problems with Batik after Batik update. So we rebuilt Fop with this new Batik and the problems seemed to be gone. Odd. If it compiles, it shouldn't complain about missing methods at run time. There may be behaviour changes though, has someone checked the Batik change log? I guess no, at least I didn't it. But our CVS contains a sample with an image and this works for me after my recent commit for the image path that was wrong: http://127.0.0.1:/samples/fop/misc/minimal.pdf. Probably it happens only for embedded SVG? I searched for some more messages on this issue, but they always end at the same place: http://archives.real-time.com/pipermail/cocoon-devel/2003-September/thread.html#19117 http://koala.ilog.fr/batik/mlists/batik-dev/archives/threads.html#03368 Batik has changed an interface and broke the dependency of FOP on it. The Cocoon dev thread ended with the question of downgrading. But as you said: If it compiles, it shouldn't complain about missing methods at run time. Joerg
Re: FOP with embeded SVG doesn't render at correct size in Cocoon
Joerg, Sorry for the delay in replying... On 28.02.2004 19:18, Steve Schwarz wrote: Thanks for the info. I tried replacing the Cocoon jars: batik-all-1.5.jar fop-0.20.5.jar with the FOP 0.20.5 jars (fop.jar batik.jar) in that case no SVG is rendered at all because there is a problem with use and url(#), even though the reference is resolved within the same svg element (and resolves correctly when using FOP standalone...must be relying on different behavior than the Cocoon URI resolving provides?). That's strange as no Cocoon URI resolving does not take part here. Sylvain tried to replace the resolver with the Cocoon one for usage of Cocoon pseudo protocols, but this broke the local URIs (#), so it was reverted. It lived from Feb, 4th, to Feb 8th - I hope your Cocoon is not from that time. Cocoon 2.1.4 does not contains this. I am using Cocoon 2.1.2 with the Cocoon 2.1.4 batik/fop jars (looks like they didn't change since 2.1.2 anyway). If I just try to use the FOP version of Batik (Cocoon fop-0.20.5.jar) I What does it mean? No Batik at all? Cocoon's fop JAR as standalone? Sorry for the confusion. I meant (fop-0.20.5.jar and batik.jar). That is, the Batik from the FOP release and the Cocoon FOP jar. get a No Such Method in Batik. java.lang.NoSuchMethodError: org.apache.batik.bridge.UnitProcessor.createContext(Lorg/apache/batik/bridge/BridgeContext;Lorg/w3c/dom/Element;)Lorg/apache/batik/parser/UnitProcessor$Context; So it looks like Cocoon's version of FOP is using a different (newer?) version of Batik. But that raises the question, was the Cocoon version of FOP taken from CVS and is really post 0.20.5 release? It's the 0.20.5 release, but built with our Batik 1.5. I guess the FOP people must clarify if this made any sense or not. IIRC we had the released Fop jar in our CVS and got complaints for problems with Batik after Batik update. So we rebuilt Fop with this new Batik and the problems seemed to be gone. The FOP 0.20.5 release uses Batik 1.5 beta 4. I also tried with the maintenance branch CVS head of FOP with no difference. Hmm, head *or* branch :) I guess you mean the recent stuff from the branch. Yep. latest from the FOP maintenance branch. I think I'll look into writing a Serializer that invokes the standalone FOP as though it was an external program so I can pickup the versions of FOP/Batik I need to make this work. Not a very integrative solution ... I agree it's really nasty...but I can seem to make these play together otherwise. From: J.Pietschmann Can anyone tell me how the Cocoon fop and batik jar files are generated and how that is different from the jars supplied with FOP? THere were some Cocoon releases which shipped with a different Batik jar than the corresponding FOP release, partly due to interface changes in Batik which forced FOP to use a CVS snapshot. I don't know of the current state, but the latest Batik was released after the latest FOP release, if Cocoon grabbed the latest Batik jar, there are certainly some differences. After Batik 1.5 b 2 we had b5 and the 1.5 release in use. The latter two are newer then FOP 0.20.5 and its Batik 1.5 b4. I would like to see this solved for Cocoon finally. For Steve it should work to use Fop 0.20.5's jar and its batik.jar (the 1.5 b4) and to replace the Cocoon's versions of these two jars. I spent a lot of time trying to work around the svg:use bug, but to no avail. It looks like for these specfic SVG input files the PDF document processing will always be write once on file upload so I can use an action to generate them via exec'ing an external FOP and they will never change for the document life. Then I can serve them up through map:read. Thanks again for your help. Steve _ Fast. Reliable. Get MSN 9 Dial-up - 3 months for the price of 1! (Limited-time Offer) http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/
DO NOT REPLY [Bug 27456] - [PATCH] BetwixtTransformer output twice the startDocument. Fix.
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=27456. 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=27456 [PATCH] BetwixtTransformer output twice the startDocument. Fix. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 01:59 --- Patch applied. Please test it and close the bug afterwards. Thanks, Joerg
DO NOT REPLY [Bug 27302] - jena throws xml parse exception on tomcat startup
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=27302. 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=27302 jena throws xml parse exception on tomcat startup --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 02:02 --- I thought this was already fixed: http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/deli/WEB-INF/deli/config/namespaceConfig.xml. After applying the patch I also tried it and it worked for me. Can you please test if you have the fixed version of the file in use? Joerg
Turning off default MRU store
Title: Turning off default MRU store Hi Guys, I might be getting ahead of myself a bit here, but I'm going to try and turn off the default MRU store, in favour of the JCS based persistent store. I'd like to try some tests on performance without the default MRU - has anyone else tried anything similar? I've simply set the core store's role to point to the JCS store implementation. The rationale behind this is that JCS implements a MRU store all on its own - this simplifies things a bit as far as I'm concerned Any thoughts? :) Corin Corin Moss Lead Developer TVNZ Interactive +64 9 916 7367 +64 21 403 054 [EMAIL PROTECTED] CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. For more information on the Television New Zealand Group, visit us online at http://www.tvnz.co.nz
DO NOT REPLY [Bug 27254] - Loader.java does not work well in Windows environment
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=27254. 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=27254 Loader.java does not work well in Windows environment [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 02:27 --- Fixed in both 2.1 and 2.2 CVS. Thanks for the patch. Please check and close the bug afterwards. Joerg
Re: FOP with embeded SVG doesn't render at correct size in Cocoon
Joerg, Here's an example xml that produces the problems (svg:use url failure for FOP versions of fop/batik jars and scaling problem for Cocoon versions of fop/batik jars): if you call it bar.xml: ?xml version=1.0 encoding=UTF-8? fo:root xmlns:svg=http://www.w3.org/2000/svg; xmlns:xlink=http://www.w3.org/1999/xlink; xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master margin-right=0.5in margin-left=0.5in margin-bottom=0.5in margin-top=0.5in page-width=8.5in page-height=11.5in master-name=all fo:region-body margin-bottom=0.25in margin-top=0.25in/ fo:region-before extent=0.25in/ fo:region-after extent=0.25in//fo:simple-page-master/fo:layout-master-set fo:page-sequence master-reference=all fo:flow flow-name=xsl-region-body fo:block text-align=center fo:instream-foreign-object text-align=center svg:svg xmlns:xlink=http://www.w3.org/1999/xlink; width=6in height=6in viewBox=0 0 1400 1400 svg:defs svg:g style=stroke:green;fill:green id=greenRectsvg:rect x=0 y=0 width=100 height=100//svg:g svg:g id=yellowGreenRect svg:rect x=0 y=0 width=200 height=200 style=stroke:yellow;fill:yellow/ svg:use transform=translate(400,400) xlink:href=#greenRect/ /svg:g /svg:defs svg:rect x=0 y=0 width=1600 height=1600 style=stroke-width:1;stroke:black;fill:red/ svg:use xlink:href=#yellowGreenRect/ /svg:svg /fo:instream-foreign-object /fo:block /fo:flow /fo:page-sequence /fo:root sitemap: map:match pattern=bar.pdf map:generate src=bar.xml/ map:serialize type=fo2pdf / /map:match Thanks, Steve On 03.03.2004 22:20, J.Pietschmann wrote: Joerg Heinicke wrote: It's the 0.20.5 release, but built with our Batik 1.5. I guess the FOP people must clarify if this made any sense or not. IIRC we had the released Fop jar in our CVS and got complaints for problems with Batik after Batik update. So we rebuilt Fop with this new Batik and the problems seemed to be gone. Odd. If it compiles, it shouldn't complain about missing methods at run time. There may be behaviour changes though, has someone checked the Batik change log? I guess no, at least I didn't it. But our CVS contains a sample with an image and this works for me after my recent commit for the image path that was wrong: http://127.0.0.1:/samples/fop/misc/minimal.pdf. Probably it happens only for embedded SVG? I searched for some more messages on this issue, but they always end at the same place: http://archives.real-time.com/pipermail/cocoon-devel/2003-September/thread.html#19117 http://koala.ilog.fr/batik/mlists/batik-dev/archives/threads.html#03368 Batik has changed an interface and broke the dependency of FOP on it. The Cocoon dev thread ended with the question of downgrading. But as you said: If it compiles, it shouldn't complain about missing methods at run time. Joerg _ Learn how to help protect your privacy and prevent fraud online at Tech Hacks Scams. http://special.msn.com/msnbc/techsafety.armx
Re: Turning off default MRU store
Corin Moss dijo: Hi Guys, I might be getting ahead of myself a bit here, but I'm going to try and turn off the default MRU store, in favour of the JCS based persistent store. I'd like to try some tests on performance without the default MRU - has anyone else tried anything similar? I've simply set the core store's role to point to the JCS store implementation. The rationale behind this is that JCS implements a MRU store all on its own - this simplifies things a bit as far as I'm concerned Any thoughts? :) Hi Corin: I am +1 on that. In fact we agreed to integrate JCS as the Cocoon Cache System. If MRU store is just a part of the current cache system, we can repleace it. AFAIK, from the user POV will be easy to switch. I am glad to see you working on this issue. :-D Best Regards, Antonio Gallardo.
Re: Turning off default MRU store
Corin Moss wrote: Hi Guys, I might be getting ahead of myself a bit here, but I'm going to try and turn off the default MRU store, in favour of the JCS based persistent store. I'd like to try some tests on performance without the default MRU - has anyone else tried anything similar? I've simply set the core store's role to point to the JCS store implementation. I guess I already got ahead of you when I renamed JCSPersistentStore JCSStore just now :-) (And merged it with the AbstractJCSStore BTW). It seems to me that JCS is both and it could replace all three stores: DefaultStore, TransientStore and PersistentStore. The rationale behind this is that JCS implements a MRU store all on its own - this simplifies things a bit as far as I'm concerned Does it back memory stores with persistent stores in the same way that DefaultStore is doing? That is, a memory store upfront and a background task moving out items into a more persistent region when memory runs low? Unico
Re: [CForms] Support for multipe unique-row-id in Repeater
On Fri, Mar 05, 2004 at 02:32:21AM +0100, Joerg Heinicke wrote: wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath wb:unique-row wb:value id=myId1 path=myId1/ wb:value id=myId2 path=myId2/ /wb:unique-row wb:on-bind wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater or wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath wb:on-bind wb:value id=myId1 path=myId1 unique=true/ wb:value id=myId2 path=myId2 unique=true/ wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater What do the other people think? I do not like this option, because it implies that the two wb:value's are individually unique. The first example above (with wb:unique-row) gives the right implication, that the values when combined identify a unique row. I have mixed feelings about using wb:unique-row, wb:key, or wb:unique-key, but I might be leaning toward wb:key. --Tim Larson
Re: Turning off default MRU store
Unico Hommes wrote: Corin Moss wrote: Hi Guys, I might be getting ahead of myself a bit here, but I'm going to try and turn off the default MRU store, in favour of the JCS based persistent store. I'd like to try some tests on performance without the default MRU - has anyone else tried anything similar? I've simply set the core store's role to point to the JCS store implementation. I guess I already got ahead of you when I renamed JCSPersistentStore JCSStore just now :-) (And merged it with the AbstractJCSStore BTW). It seems to me that JCS is both and it could replace all three stores: DefaultStore, TransientStore and PersistentStore. I have to add that this is not the whole story. We do actually need to distinguish between persistent and transient storage. Some components explicitly want to persist some data instead of just cache it for speed. But as far as caching is concerned I think it we can leave it completely up to JCS. Unico
RE: Turning off default MRU store
---BeginMessage--- Hiya, It does exactly that. The MRU store can be figured for max objects in the same way as our current MRU. As far as differenciating what is stored in persistent as opposed to transient, that could be done through configuration of different store regions. I'm fairly confident that this could be done with no change to the current code - just specifying a different region param in the xconf. It really is a beautifully flexibile caching system! Cool, Corin -Original Message- From: Unico Hommes [mailto:[EMAIL PROTECTED] Sent: Fri 5/03/2004 4:00 p.m. To: [EMAIL PROTECTED] Cc: Subject: Re: Turning off default MRU store Corin Moss wrote: Hi Guys, I might be getting ahead of myself a bit here, but I'm going to try and turn off the default MRU store, in favour of the JCS based persistent store. I'd like to try some tests on performance without the default MRU - has anyone else tried anything similar? I've simply set the core store's role to point to the JCS store implementation. I guess I already got ahead of you when I renamed JCSPersistentStore JCSStore just now :-) (And merged it with the AbstractJCSStore BTW). It seems to me that JCS is both and it could replace all three stores: DefaultStore, TransientStore and PersistentStore. The rationale behind this is that JCS implements a MRU store all on its own - this simplifies things a bit as far as I'm concerned Does it back memory stores with persistent stores in the same way that DefaultStore is doing? That is, a memory store upfront and a background task moving out items into a more persistent region when memory runs low? Unico winmail.dat---End Message--- CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. For more information on the Television New Zealand Group, visit us online at http://www.tvnz.co.nz
Re: Instrumentation, anyone?
XDoclet is a good generator, but the license is wrong for Apache. Using straight Introspection can and will expose things that you do not wish to allow users to alter on the fly. Unfortunately I'm completely snowed under until March 29th. After that date I will get back to working on JMX for cocoon. I suggested using the MX4J libraries as they are under an Apache license already, but haven't heard any thoughts here. Aside: We used some of the AdventNet products and they all seemed to work very well. I only used their SNMP libraries, so I can't comment on their other tools. I used XDoclet to generate MBeans instead. We could use XML Descriptors that could be used to create dynamic MBeans. As for generation, we could generate MBeans directly, or XML descriptors from comments in the code (a'la XDoclet), the downside to this requires having access to (and modifying) the source code. Carsten, if your offering to answer questions on Avalon, that would be way cool. Let me know which way you think will fit in the best way for cocoon'ers and I can start on that in April. Cheers, Thor HW On 4-Mar-04, at 1:42 PM, Stefano Mazzocchi wrote: Joerg Heinicke wrote: We also had no problems with it. As Hamilton said you just must not commit generated code, but I think that's obvious. Do you have something else in mind? What does distributed workgroup change on the issue? that there is more chance of people making mistakes ;-) we *did* have problems with this in the past and we moved away from it. not that I'm stopping people, just making sure they know there is a problem there. -- Stefano.
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Le Jeudi, 4 mars 2004, à 22:56 Europe/Zurich, Sylvain Wallez a écrit : Although individual parameter location may be useful, the location parameter I'm talking about is that of the statement. This makes me think SitemapParameters with a getStatementLocation() is better than LocatedParameters I suggested above. Let's consider the following snippet: 10 ... 11 map:generate src=foo.xml 12 map:parameter name=bar value=baz/ 13 /map:parameter 14 ... ((SitemapParameters)parameters).getStatementLocation() -- sitemap.xmap:11:2 parameters.getLocation(bar) -- sitemap.xmap:12:4 getLocation(name) can be useful to notify a problem about a particular parameter, while getStatementLocation() relates to the whole statement. getLocation(name) can also be useful for Parameterizable components, as it replaces Configuration.getLocation() which is no more available. Sounds good, having both is certainly useful for error reporting. Just a detail, how about casting to a SitemapLocation interface instead of classes? ((SitemapLocation)parameters).getStatementLocation() -- sitemap.xmap:11:2 And assuming you get plain Parameters ((SitemapLocation)parameters).getParameterLocation(bar) - sitemap.xmap:12:4 -Bertrand
RE: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Sylvain Wallez wrote: So here's a proposal (I should have thought about it way earlier...): let's use a LocatedParameters, subclass of Parameters with an additional getLocation() method. It has no impact on components that iterate on parameters, and yet still provide location whenever it's needed. WDYT? +1, I had the same this night :) Carsten
RE: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Carsten Ziegeler wrote: Sylvain Wallez wrote: So here's a proposal (I should have thought about it way earlier...): let's use a LocatedParameters, subclass of Parameters with an additional getLocation() method. It has no impact on components that iterate on parameters, and yet still provide location whenever it's needed. WDYT? +1, I had the same this night :) idea Grmpf Carsten
RE: Instrumentation, anyone?
Thor Heinrichs-Wolpert wrote: Carsten, if your offering to answer questions on Avalon, that would be way cool. Sure. You know the rules: one beer for each answer :) (PS: That's just a joke) Carsten
JSPGenerator Error for map:aggregate
Title: Message Hi, I am facing this problem for a long time and is not able to solve it. When I aggregate a jsp file within the map:aggregate, I can get the following error: org.apache.cocoon.ProcessingException: Failed to execute pipeline.: org.apache.cocoon.ProcessingException: Exception JSPGenerator.generate(): java.lang.StringIndexOutOfBoundsException: String index out of range: -1 cause:java.lang.StringIndexOutOfBoundsException: String index out of range: -1 The following is my code in the sitemap.xmap map:match pattern="login" map:generate type="jsp" src=""/ map:transform src=""/ map:serialize type="html"/ /map:match map:match pattern="*.xsp" map:aggregate element="site" map:part src="" / map:part src="" / map:part src="" / map:part src="" label="content" / /map:aggregate map:transform src="" map:parameter name="use-request-parameters" value="true" / map:parameter name="base-url" value="/clearinghouse" / /map:transform map:serialize / /map:match I am using cocoon 2.1.4. Thanks for your help and looking forward to your reply soon. Regards Lau Sze SzeTechnical ConsultantE-Learning Competency CentreNational Institute of Education1 Nanyang WalkSingapore 637616Tel: (65) 6790 3745 Fax: (65) 6861 7374www.ecc.org.sgwww.elearninghouse.com
