RE: error handling
Vadim Gritsenko wrote: IIRC, last first friday we had a chat with Carsten about adding an attribute to the handle-errors/ or to the pipeline/ which will indicate what behavior is needed in case of internal request: throw exception or process handle-errors/. Carsten? Yes, nothing of that is implemented yet. The discussion started because of internal redirects. Now, in general the error handlers are never called for internal requests - that was a design decision. Starting with 2.1.5 we have one exception, internal redirects, so if you do a map:redirect-to uri=cocoon:/something/ then - and only then - the error handler of the internal pipeline is called. HTH? Carsten
Re: cvs commit: cocoon-2.1/legal util.concurrent-1.3.3.jar.license.txt
[EMAIL PROTECTED] dijo: crossley2004/06/03 23:38:52 Modified:legalutil.concurrent-1.3.3.jar.license.txt Log: Point to Doug Lea website and let him explain the issues. Hmm. This is pointing the the current version. In this case to 1.3.4. We use 1.3.3 The point is: The file is not mantained by us and without notice it can be changed and broke our license. (I will update the library to 1.3.4). Best Regards, Antonio Gallardo
Re: Upgrade to cocoon 2.1.5
Nicola Ken Barozzi wrote: Over at Forrest, an upgrade to Cocoon 2.1.5 has brought us with these issues... ideas? Juan Jose Pablos wrote: Hi, I am nearly there, I have got a couple of issues, both related to JCS: First, there is a lot of output like this one: = [INFO] CompositeCacheConfigurator - -setting defaults to DC [INFO] CompositeCacheConfigurator - -setting defaultCompositeCacheAttributes to [ useLateral = true, useRemote = true, useDisk = true, maxObjs = 1 00, maxSpoolPerRun = -1 ] How can I remove These info messages? I think it depends on log4j not being configured. We should ship with a proper log4j config, as all those messages from JCS and other libraries that use log4j, like Quartz, are really bothersome. I don't have any hint rearding the second problem. Ugo
RE: error handling
Carsten Ziegeler dijo: Vadim Gritsenko wrote: IIRC, last first friday we had a chat with Carsten about adding an attribute to the handle-errors/ or to the pipeline/ which will indicate what behavior is needed in case of internal request: throw exception or process handle-errors/. Carsten? Yes, nothing of that is implemented yet. The discussion started because of internal redirects. Now, in general the error handlers are never called for internal requests - that was a design decision. Starting with 2.1.5 we have one exception, internal redirects, so if you do a map:redirect-to uri=cocoon:/something/ then - and only then - the error handler of the internal pipeline is called. Hi Carsten: Can you post more about it? Seems like many people, including me ;-), is having troubles with the cocoon:/ protocol. Best Regards, Antonio Gallardo.
DO NOT REPLY [Bug 28834] - [PATCH] flow example for supersonic tutorial
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28834. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28834 [PATCH] flow example for supersonic tutorial [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED
Re: cvs commit: cocoon-2.1/src/webapp/samples/hello-world/style/xsl page2swf.xsl
Le 4 juin 04, à 07:59, Joerg Heinicke a écrit : ... 1.1 cocoon-2.1/src/webapp/samples/hello-world/style/swf/hello.fla Binary file 1.1 cocoon-2.1/src/webapp/samples/hello-world/style/swf/hello.swf Binary file Are they really binary? fla and swf are definitely binary files, aren't they? -Bertrand
Re: cvs commit: cocoon-2.1/src/webapp/samples/hello-world/style/xsl page2swf.xsl
#-[dependency]: apples depends on forms (for samples). -#include.block.apples=false +include.block.apples=false #-[dependency]: asciiart is needed by mail. ups! ...that wasn't intended *torsten rushing away fixing it* Apples should not be excluded by default. 1.1 cocoon-2.1/src/webapp/samples/hello-world/style/swf/hello.fla Binary file 1.1 cocoon-2.1/src/webapp/samples/hello-world/style/swf/hello.swf Binary file Are they really binary? They are! Thanks for the cross check! cheers -- Torsten
Re: error handling
IIRC, last first friday we had a chat with Carsten about adding an attribute to the handle-errors/ or to the pipeline/ which will indicate what behavior is needed in case of internal request: throw exception or process handle-errors/. Carsten? Sounds like a good plan. In fact I think it would be a good default behavior but anyway. Yes, nothing of that is implemented yet. The discussion started because of internal redirects. Now, in general the error handlers are never called for internal requests - that was a design decision. Starting with 2.1.5 we have one exception, internal redirects, so if you do a map:redirect-to uri=cocoon:/something/ then - and only then - the error handler of the internal pipeline is called. HTH? Well, it clarifies... ;) Thanks! ...but - I think we definitely need a way to handle errors inside internal pipeline calls! Otherwise there is just no way to handle errors in an aggregation appropriately. I am happy to do it ...if there are no objections. But where to place it? I reckon we either need to make the interal pipeline calls go through the same hook inside the treeprocessor or move the error handling further down into the pipeline code. WDYT? cheers -- Torsten
Re: cvs commit: cocoon-2.1/legal util.concurrent-1.3.3.jar.license.txt
Antonio Gallardo wrote: crossley2004/06/03 23:38:52 Modified:legalutil.concurrent-1.3.3.jar.license.txt Log: Point to Doug Lea website and let him explain the issues. Hmm. This is pointing the the current version. In this case to 1.3.4. We use 1.3.3 The point is: The file is not mantained by us and without notice it can be changed and broke our license. (I will update the library to 1.3.4). Ah, good idea, thanks for doing that. --David
RE: error handling
Antonio Gallardo wrote: Carsten Ziegeler dijo: Vadim Gritsenko wrote: IIRC, last first friday we had a chat with Carsten about adding an attribute to the handle-errors/ or to the pipeline/ which will indicate what behavior is needed in case of internal request: throw exception or process handle-errors/. Carsten? Yes, nothing of that is implemented yet. The discussion started because of internal redirects. Now, in general the error handlers are never called for internal requests - that was a design decision. Starting with 2.1.5 we have one exception, internal redirects, so if you do a map:redirect-to uri=cocoon:/something/ then - and only then - the error handler of the internal pipeline is called. Hi Carsten: Can you post more about it? Seems like many people, including me ;-), is having troubles with the cocoon:/ protocol. Are you talking about 2.1.5 or CVS Head? CVS Head has a rewritten internal request handling that simply might have bugs, so we have to fix these bugs first before its really usable. Carsten
Re: swf block
+1 since Spark is dead and not featured enough for some serious work. Too bad though :-/ But the need to produce Flash exists (opposed to having the Flash fetching XML data) : we're using it to display animated diagrams on small devices (PDAs phones) where SVG is not available. In order to save bandwidth and CPU, we send the diagram as a Flash movie (generated by Cocoon), and XML fetching is only used for animation (changing colors, moving objects, etc). We've investigating KineticFusion (commercial, [1]) which does a nice job. Anybody else having some experience with it or some other equivalent tool? Looks interesting! I could not find any information about the pricing though!? Would you share your code for the cocoon integration? cheers -- Torsten
Re: FirstFriday happening now!
The Chat channel is getting active already. If anyone wants to join in, then get the IRC details at [1]. --David Bertrand Delacretaz wrote: Hi Cocoonistas, Tomorrow is FirstFriday [1], and the cross-posting is intentional: you don't necessarily need to be a committer to participate, there are plenty of bugs and patches waiting for our collective squashing and patching [2]. See you there! (on and off tomorrow for me) [1] http://wiki.cocoondev.org/Wiki.jsp?page=FirstFriday [2] http://wiki.cocoondev.org/Wiki.jsp?page=ProjectManagement
RE: error handling
Torsten Curdt wrote: IIRC, last first friday we had a chat with Carsten about adding an attribute to the handle-errors/ or to the pipeline/ which will indicate what behavior is needed in case of internal request: throw exception or process handle-errors/. Carsten? Sounds like a good plan. In fact I think it would be a good default behavior but anyway. Yes, nothing of that is implemented yet. The discussion started because of internal redirects. Now, in general the error handlers are never called for internal requests - that was a design decision. Starting with 2.1.5 we have one exception, internal redirects, so if you do a map:redirect-to uri=cocoon:/something/ then - and only then - the error handler of the internal pipeline is called. HTH? Well, it clarifies... ;) Thanks! ...but - I think we definitely need a way to handle errors inside internal pipeline calls! Otherwise there is just no way to handle errors in an aggregation appropriately. I am happy to do it ...if there are no objections. But where to place it? I reckon we either need to make the interal pipeline calls go through the same hook inside the treeprocessor or move the error handling further down into the pipeline code. I think we can use the available things. We discussed two solutions: specifying it at the call, like: cocoon:handle-error:/something or cocoon:/something?cocoon:handle-error=true (Note the ':' in the second example which is not allowed for usual request parameters). and specifying it in the called pipeline: map:pipeline handle-errors-for-internal-calls=true/ The names of the attributes/request-parameters I used have not been set in the discussions. I just used here some to show the principle. Now, implementing this should be a two or three liner :) I already had it implemented but lost the code... Carsten
RE: error handling
Carsten Ziegeler dijo: Are you talking about 2.1.5 or CVS Head? CVS Head has a rewritten internal request handling that simply might have bugs, so we have to fix these bugs first before its really usable. Yep.!!! it tortures now for 2 days now! :( Best Regards, Antonio Gallardo
Re: error handling
I think we can use the available things. We discussed two solutions: specifying it at the call, like: cocoon:handle-error:/something or cocoon:/something?cocoon:handle-error=true Uaaahh maybe the first one - but this looks dead ugly and feels more like hack for what should be the default. ...or how would you explain a user that a pipeline behaves differenlty whether it's been called from the browser or from cocoon? (Note the ':' in the second example which is not allowed for usual request parameters). Noted - still ugly ;) and specifying it in the called pipeline: map:pipeline handle-errors-for-internal-calls=true/ This looks much better The names of the attributes/request-parameters I used have not been set in the discussions. I just used here some to show the principle. :-) What about... map:pipeline handle-errors=always|external|internal/ our current behaviour would be external. I would like to have always andt the internal option might be FS ;) Now, implementing this should be a two or three liner :) I already had it implemented but lost the code... You can also give me a hand ...up to you. cheers -- Torsten
[VOTE] new Cocoon PMC chair
Dear all, a nice set of people volunteered for taking on the PMC chair job and it's time we conclude this vote. :-) I'd suggest to end this vote 72 hours from now - on Monday morning European time. We decided this to be a public vote. Please remind yourself that only PMC members can bindingly vote, but votes of support from both developers and users are appreciated as well, of course. For reasons of administration, please post your vote on the dev list. I want to thank all of the volunteers, and also want to thank all of you for the kind support I received during my term. Here's the current list of nominations - people who already clearly declined are not on the list anymore. Sort order alphabetic on first name. - Andrew Savory - Matthew Langham - Sylvain Wallez - Vadim Gritsenko Cheers, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Bug in jx:set?
Hi list,
I recently posted the following message on the user list, but didn't
get an answer. I believe it is a bug, and I verified that this
behaviour is still the same with cocoon 2.1.5, so maybe one of you
could have a quick look at it. It should be easy to reproduce.
Thanks,
Jan Harms
Von: Jan Harms [EMAIL PROTECTED]
Datum: 13. Mai 2004 15:38:36 MESZ
An: [EMAIL PROTECTED]
Betreff: JXTemplateGenerator: strange behaviour with jx:set
Hi,
I just found out that jx:set does not quite behave like I expected.
Please consider the following JXTemplate snippets:
!-- 1 --
element attr=${request.getAttribute('foo')}/
!-- 2 --
jx:set var=foo value=${request.getAttribute('foo')}/
element attr=${foo}/
1 and 2 should be equivalent, shouldn't they? Everything is fine as
long as the request attribute 'foo' is available. However, if this is
not the case (i.e. request.getAttribute('foo') evaluates to null) then
the first snippet is transformed into
element attr= /
while the latter is transformed into
element attr=[Lorg.w3c.dom.Node;@6e3dee /
Am I doing something wrong? Or is this a bug? I couldn't find anything
about it in the mail archives.
I could imagine that the JXTemplateGenerator uses an empty DOM-Node as
some kind of NullObject-Pattern. This would work inside xml element
nodes (i.e. element${foo}/element works fine in the second
example), but would fail inside attributes.
Any ideas?
Regards,
Jan Harms
P.S. I use cocoon 2.1.4.
Re: [portal] Form-Coplet communication
On Friday 04 June 2004 05:52, Alex Romayev wrote: Another form coplet -- another problem ;-) Problem --- Here is what I'm trying to do. I have a Search coplet, which is a form with lots of search criteria (about 15 fields). It has 2 buttons: Search and Save Search. If Search button is pressed, 2 things need to happen: - Search Results coplet (on the same page) needs to use the criteria to run a query and display the results. - Search coplet needs to pre-populate itself with the entered criteria. If Save Search button is pressed, another portal page (Save Search) needs to be presented, the name of the search needs to be entered, the search saved and the Search page displayed with appropriate results and pre-populated Search coplet. Questions - 1. Using Forms doc (http://cocoon.apache.org/2.1/developing/portal/forms.html) shows how to implement a form using CachingURICoplet. This would allow me to use form binding to bind form to/from SearchCriteria object, which then can be used to run search or be saved to the database. However, I think CachingURICoplet only works when the coplet does *not* need to communicate with other coplets. In my case, SearchCriteria object needs to be passed to Search Results coplet or possibly to Save Search coplet on another portal page. This is similar to my previous problem with login coplet, which needed to communicate outside of its own context. snip I know, this problem keeps coming up in one form or another must be my luck :-( In general, though, it seems that coplet to coplet or coplet to portal communication is allowed via events, however, it would be great to see it extended to use flow as well. Given that flow is now the primary place to put controller type logic, it seems inconsistent having to do it in two places: flow and events. Especially it becomes tough when the two are not well integrated. Ideally, it would be nice to be able to do all of it in flow with simple sendPage/sendPageAndWaits, but Im not sure how well they would fit into the portal model. /snip 2. Not using CachingURICoplet, in conjunction with temporary:application-uri attibute, would allow the Search coplet to communicate with other coplets (I think), however, the fact that request parameters will not be available to it, means I cannot use Cforms for binding. Now, say I could pass all 15 of my search parameters to my Search Results via coplet attributes (a bit painful, but can be done). How would I pass the events to other coplets/pages? Event Handling doc, has the following paragraph: Imagine a form coplet where the user can enter a city. When this form is processed by the form coplet, it can generate one (or more) CopletJXPathEvents and push the entered city information to a weather coplet and a hotel guide coplet. So, these two coplets display the information about the selected city. Sounds like what I need. How does the form generate these events and how do these events get passed on to other coplets? Is there a way I need to tag input fields? Anything I need to add to my submit buttons? Thanks, -Alex If you want to communicate with the coplets from outside then the best way to accomplish this task is to use the bookmark feature of the portal engine. Have a look at: http://wiki.cocoondev.org/Wiki.jsp?page=PortalEngineBookmarks I had similiar problems which were driving me mad, after starting to use bookmarks, it got a lot easier to control the portal. -- lg, Chris
Re: error handling
Le 4 juin 04, à 09:59, Torsten Curdt a écrit : ...What about... map:pipeline handle-errors=always|external|internal/ our current behaviour would be external. I would like to have always andt the internal option might be FS ;) +1 for the declaration, looks clean enough! -Bertrand
Re: [VOTE] new Cocoon PMC chair
Here's my +1 for - Sylvain Wallez A tough choice to make: I'd vote for all of you guys, but we have to select someone. I understand this is meant for one year as previously discussed. With mucho thanks to Steven for doing his part! -Bertrand
Re: swf block
Torsten Curdt wrote:
+1 since Spark is dead and not featured enough for some serious work.
Too bad though :-/
But the need to produce Flash exists (opposed to having the Flash
fetching XML data) : we're using it to display animated diagrams on
small devices (PDAs phones) where SVG is not available. In order to
save bandwidth and CPU, we send the diagram as a Flash movie
(generated by Cocoon), and XML fetching is only used for animation
(changing colors, moving objects, etc).
We've investigating KineticFusion (commercial, [1]) which does a nice
job. Anybody else having some experience with it or some other
equivalent tool?
Looks interesting! I could not find any information about the pricing
though!?
There's themselves not very sure about it :-)
Would you share your code for the cocoon integration?
The software is currently a command-line tool only, and they're working
to make it a library. So the integration is really ugly as it forks a
new JVM... Slow and hungry.
But I'll keep you posted on progress.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: swf block
We've investigating KineticFusion (commercial, [1]) which does a nice job. Anybody else having some experience with it or some other equivalent tool? Looks interesting! I could not find any information about the pricing though!? There's themselves not very sure about it :-) hehe ...well, they could make it open source :-P Would you share your code for the cocoon integration? The software is currently a command-line tool only, and they're working to make it a library. So the integration is really ugly as it forks a new JVM... Slow and hungry. ok... I see But I'll keep you posted on progress. cool bananas! cheers -- Torsten
Caching strategy
I stumbled across this paper about ARC [1] and wondered if this was something that could be useful as a caching strategy in Cocoon. I remember Stefano talked about adaptive caching several years ago on this list [2] but I don´t remember the result. [1] Adaptive Replacement Cache. http://www.almaden.ibm.com/StorageSystems/autonomic_storage/ARC/arcfast.pdf [2] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=100820114404337w=2 /Mats
Re: Caching strategy
A better url: http://www.almaden.ibm.com/StorageSystems/autonomic_storage/ARC/index.shtml Mats Norén wrote: I stumbled across this paper about ARC [1] and wondered if this was something that could be useful as a caching strategy in Cocoon. I remember Stefano talked about adaptive caching several years ago on this list [2] but I don´t remember the result. [1] Adaptive Replacement Cache. http://www.almaden.ibm.com/StorageSystems/autonomic_storage/ARC/arcfast.pdf [2] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=100820114404337w=2 /Mats
DO NOT REPLY [Bug 28834] - [PATCH] flow example for supersonic tutorial
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28834. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28834 [PATCH] flow example for supersonic tutorial [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|ASSIGNED|NEW --- Additional Comments From [EMAIL PROTECTED] 2004-06-04 09:23 --- Patch applied with slight modifications (simpler Flow code), please cross-check. Thanks very much for your contribution!
DO NOT REPLY [Bug 28834] - [PATCH] flow example for supersonic tutorial
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28834. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28834 [PATCH] flow example for supersonic tutorial --- Additional Comments From [EMAIL PROTECTED] 2004-06-04 10:06 --- don't forget CC ;-)
This morning's IRC discussion about Flow
Hi all, Here's a short summary of this morning's discussion on #cocoon, about Sylvain's proposal, which is to instrument javascript code to enable continuations using the official Rhino javascript interpreter. This would allow us to use the official Rhino distribution instead of the fork that we're using now. In summary: 1) Stephan sees a technical solution to implement sylvain's proposal, based on the javaflow continuations stuff and a custom classloader for Rhino code. 2) Shipped flowscript languages would be javascript (already tested in the field) and java (using javaflow, experimental ATM) 3) To stay focused, we're not going to support other flow languages at this time, although it would be technically possible. Thanks to all who participated to this discussion! -Bertrand
Re: [CVS-SVN] Cocoon switching to SVN
Brian W. Fitzpatrick wrote: On Wed, 2004-05-26 at 04:04, Nicola Ken Barozzi wrote: The Cocoon project has decided to move to subversion, so we need your help, along with an indication about when it can be done. TIA quick-summary We need to export cocoon-2.1 cocoon-2.2 cocoon-site Nicola, Thanks for the fantastic roadmap! Can we plan on doing this sometime on Monday the 31st? I'd like to do a test-run sometime between now and then to make sure that the conversion on Monday runs smoothly (and that you get exactly what you want in your repository). Fitz, any status update on this? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [VOTE] new Cocoon PMC chair
Bertrand Delacretaz dijo: Here's my +1 for - Sylvain Wallez +1 for Sylvain. Best Regards, Antonio Gallardo
Re: [VOTE] new Cocoon PMC chair
+1 for Vadim Gritsenko -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: cvs commit: cocoon-2.1/src/webapp/samples/hello-world/style/xsl page2swf.xsl
On 04.06.2004 10:59, Torsten Curdt wrote: Hmm, but then it has not much to do with Cocoon ... Well, people are interested in using Cocoon with with flash. So we show them how to use it with flash. Anything wrong with that?! No, it only has nothing to do with Cocoon's capabilities. Especially since we agreed on removing the swf block with this replacement I don't understand your concerns. No, it's absolutely ok. Don't know if I voted, at least I was and am also pro the removal due to missing maturity and community. It's only some sadness about having nothing for flash. And due to binary flash files we can not claim flash capabilities. Joerg
Re: [VOTE] new Cocoon PMC chair
On 04.06.2004 10:42, Bertrand Delacretaz wrote: Here's my +1 for - Sylvain Wallez A tough choice to make: I'd vote for all of you guys, but we have to select someone. I understand this is meant for one year as previously discussed. With mucho thanks to Steven for doing his part! +1 complete agreement Joerg
RE: [CVS] Flow bug in redirections? Test case inside.
Hi Antonio, just to be sure: did B to D work in 2.1.4/2.1.5 as you expect or do they produce they same error? Carsten -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Thursday, June 03, 2004 4:13 PM To: [EMAIL PROTECTED] Subject: [CVS] Flow bug in redirections? Test case inside. Hi: I have 2 days with this problem. Here is a test case of the redirection problem in flow: 1-Build Cocoon with samples. 2-Run ./cocoon.sh servlet 3-Copy $COCOON_HOME/build/webapp/samples/flow to $COCOON_HOME/build/webapp/samples/flowbug (we need it because we will make a call from flowbug to flow. 4-Change line 38 in $COCOON_HOME/build/webapp/samples/flowbug/jxcalc/calc.js to any of: A-var uri = samples/flow/jxcalc/page/getNumber + name.toUpperCase(); B-var uri = /samples/flow/jxcalc/page/getNumber + name.toUpperCase(); C-var uri = //samples/flow/jxcalc/page/getNumber + name.toUpperCase(); D-var uri = ///samples/flow/jxcalc/page/getNumber + name.toUpperCase(); 5- On a browser, connect to: http://localhost:/samples/flowbug/jxcalc/ You will get: -- A-No pipeline matched request: samples/flowbug/jxcalc/samples/flow/jxcalc/page/getNumberA org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: samples/flowbug/jxcalc/samples/flow/jxcalc/page/getNumberA COMMENT: It is OK. There does not exist in relative path. -- B-No pipeline matched request: samples/flow/jxcalc/page/getNumberA org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: samples/flow/jxcalc/page/getNumberA COMMENT: Why? It must go to the redirection in flow directory using the sitemap that is in flow dir! -- C-No pipeline matched request: /samples/flow/jxcalc/page/getNumberA org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: /samples/flow/jxcalc/page/getNumberA COMMENT: Again, why? As above, the link exists! -- D-No pipeline matched request: //samples/flow/jxcalc/page/getNumberA org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: //samples/flow/jxcalc/page/getNumberA COMMENT: Again, why? As above, the link exists! -- It will never go to the requested path! If it works, it would be the same as: http://localhost:/samples/flow/jxcalc/page/getNumberA And we would need to receive a diferent error: org.apache.cocoon.ProcessingException: Failed to execute pipeline.: file:/home/agallardo/workspace/cocoon-2.1/build/webapp/samples /flow/jxcalc/screens/getNumberA.xml:30:72:org.apache.commons.j xpath.JXPathException: No value for xpath: $cocoon/continuation/id Now the question is what is affecting that? Best Regards, Antonio Gallardo
Re: Upgrade to cocoon 2.1.5
Il giorno 04/giu/04, alle 09:07, Ugo Cei ha scritto: I think it depends on log4j not being configured. We should ship with a proper log4j config, as all those messages from JCS and other libraries that use log4j, like Quartz, are really bothersome. I tried to fix this by providing a default log4j.properties file, but there is one thing that is bothering me. In the file I have put: log4j.appender.file.File=build/webapp/WEB-INF/logs/log4j.log but this only works as long as you are running under the bundled Jetty (i.e. cocoon servlet). Is there a way to specify a path relative to the webapp context dir that works across all containers? Ugo -- Ugo Cei - http://beblogging.com/
RE: [VOTE] new Cocoon PMC chair
Steven Noels wrote: Here's the current list of nominations - people who already clearly declined are not on the list anymore. Sort order alphabetic on first name. - Andrew Savory - Matthew Langham - Sylvain Wallez - Vadim Gritsenko This statement from Bertrand characterize my own opinion very nicely: A tough choice to make: I'd vote for all of you guys, but we have to select someone. So, as Andrew, Matthew and Sylvain are Orixo members like myself, I vote: +1 for Vadim Carsten
RE: [CVS] Flow bug in redirections? Test case inside.
Carsten Ziegeler dijo: Hi Antonio, just to be sure: did B to D work in 2.1.4/2.1.5 as you expect or do they produce they same error? I think yes. In our an application we have a similar model. We have shared dialogs. The dialogs are called from others flows (similar as the sample). Some days ago it works from the CVS, but know it does not work. BTW, we don't touched nothing on the application. So it must work as expected. Please see the problem I am going crazy with that. I guess the problem is related to switching contexts. I will post more info soon. Best Regards, Antonio Gallardo Carsten -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Thursday, June 03, 2004 4:13 PM To: [EMAIL PROTECTED] Subject: [CVS] Flow bug in redirections? Test case inside. Hi: I have 2 days with this problem. Here is a test case of the redirection problem in flow: 1-Build Cocoon with samples. 2-Run ./cocoon.sh servlet 3-Copy $COCOON_HOME/build/webapp/samples/flow to $COCOON_HOME/build/webapp/samples/flowbug (we need it because we will make a call from flowbug to flow. 4-Change line 38 in $COCOON_HOME/build/webapp/samples/flowbug/jxcalc/calc.js to any of: A-var uri = samples/flow/jxcalc/page/getNumber + name.toUpperCase(); B-var uri = /samples/flow/jxcalc/page/getNumber + name.toUpperCase(); C-var uri = //samples/flow/jxcalc/page/getNumber + name.toUpperCase(); D-var uri = ///samples/flow/jxcalc/page/getNumber + name.toUpperCase(); 5- On a browser, connect to: http://localhost:/samples/flowbug/jxcalc/ You will get: -- A-No pipeline matched request: samples/flowbug/jxcalc/samples/flow/jxcalc/page/getNumberA org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: samples/flowbug/jxcalc/samples/flow/jxcalc/page/getNumberA COMMENT: It is OK. There does not exist in relative path. -- B-No pipeline matched request: samples/flow/jxcalc/page/getNumberA org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: samples/flow/jxcalc/page/getNumberA COMMENT: Why? It must go to the redirection in flow directory using the sitemap that is in flow dir! -- C-No pipeline matched request: /samples/flow/jxcalc/page/getNumberA org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: /samples/flow/jxcalc/page/getNumberA COMMENT: Again, why? As above, the link exists! -- D-No pipeline matched request: //samples/flow/jxcalc/page/getNumberA org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: //samples/flow/jxcalc/page/getNumberA COMMENT: Again, why? As above, the link exists! -- It will never go to the requested path! If it works, it would be the same as: http://localhost:/samples/flow/jxcalc/page/getNumberA And we would need to receive a diferent error: org.apache.cocoon.ProcessingException: Failed to execute pipeline.: file:/home/agallardo/workspace/cocoon-2.1/build/webapp/samples /flow/jxcalc/screens/getNumberA.xml:30:72:org.apache.commons.j xpath.JXPathException: No value for xpath: $cocoon/continuation/id Now the question is what is affecting that? Best Regards, Antonio Gallardo
Re: [portal] Form-Coplet communication
If you want to communicate with the coplets from outside then the best way to accomplish this task is to use the bookmark feature of the portal engine. Have a look at: http://wiki.cocoondev.org/Wiki.jsp?page=PortalEngineBookmarks I had similiar problems which were driving me mad, after starting to use bookmarks, it got a lot easier to control the portal. -- lg, Chris Hi Chris, I think this is an option that might work, however, a couple of questions: - Since request parameters are not available to to coplets, I assume it still isn't possible to use CForms for binding? - Again, assuming CForms binding cannot be use, I have about 15 parameters that I need to pass. Does this meant I have to create 15 attributes in coplet configuration, 15 events in bookmarks.xml, and 15 entries in sitemap to pass coplet/attribute to the coplet, or have you been able to find a better way? Thanks, -Alex
Re: [BUG] Registering of JavaFlow fails (was: [JavaFlow] java.lang.VerifyException)
Stephan Michels wrote: Am Do, den 03.06.2004 schrieb Stephan Michels um 15:00: Am Di, den 01.06.2004 schrieb Stephan Coboos um 20:23: Hello, I have a problem using Objects in JavaFlow before a while loop. Please see my first posting [JavaFlow] java.lang.VerifyException. In my opinion it can be a bug in the JavaFlow block. Because my fist posting was not so clear, I had tried to reproduce the error for a while and I had discovered the following code which creates such an error (you need the packages of Lucene): java.lang.VerifyError: (class: foo/bar/TestFlow, method: doTest signature: ()V) Incompatible object argument for function call Is it really a bug? Why is it not possible to declare these three line within the method doTest? What can I do? Yes, it seems to be a bug. I guess its a problem the following line query = QueryParser.parse(foo, bar, new StandardAnalyzer()); I had many problem in the past with uninitialized objects and saving the continuation. I will take a look into it. It was a problem with null objects, which were stored into the continuation. If the frame will be restored, the null object cannot be casted into the right type. So, at the end the correct signatur couldn't be found. Hits hits; IndexSearcher searcher = null; sendPageAndWait(foo); hits = searcher.search(query); I have fixed it now. Stephan. Wow, what a quick work! Thank you very much! Regards Stephan
RE: [CVS] Flow bug in redirections? Test case inside.
Hi: I setted this breakpoints: 1-o.a.c.components.flow.javascript.fom.FOM_Cocoon.java at line 261. 2- o.a.c.components.flow.javascript.fom.FOM_JavaScriptInterpreter.java at line 837 3-o.a.c.components.flow.AbstractInterpreter.java at line 171 I posted the 3 breakpoints to draft the route the problem follow. It is a problem in the sendPage from Javaflow. I think, the last breakpoint is the most important because until it all is OK. I wonder if the problem is in the hint we post store for the redirector (3 file at line 179). I choosed to don't touch nothing, because I don't know enough how it works and I don't want to break other things around. I hope this helps to discover the bug. Best Regards, Antonio Gallardo Carsten Ziegeler dijo: Hi Antonio, just to be sure: did B to D work in 2.1.4/2.1.5 as you expect or do they produce they same error? Carsten -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Thursday, June 03, 2004 4:13 PM To: [EMAIL PROTECTED] Subject: [CVS] Flow bug in redirections? Test case inside. Hi: I have 2 days with this problem. Here is a test case of the redirection problem in flow: 1-Build Cocoon with samples. 2-Run ./cocoon.sh servlet 3-Copy $COCOON_HOME/build/webapp/samples/flow to $COCOON_HOME/build/webapp/samples/flowbug (we need it because we will make a call from flowbug to flow. 4-Change line 38 in $COCOON_HOME/build/webapp/samples/flowbug/jxcalc/calc.js to any of: A-var uri = samples/flow/jxcalc/page/getNumber + name.toUpperCase(); B-var uri = /samples/flow/jxcalc/page/getNumber + name.toUpperCase(); C-var uri = //samples/flow/jxcalc/page/getNumber + name.toUpperCase(); D-var uri = ///samples/flow/jxcalc/page/getNumber + name.toUpperCase(); 5- On a browser, connect to: http://localhost:/samples/flowbug/jxcalc/ You will get: -- A-No pipeline matched request: samples/flowbug/jxcalc/samples/flow/jxcalc/page/getNumberA org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: samples/flowbug/jxcalc/samples/flow/jxcalc/page/getNumberA COMMENT: It is OK. There does not exist in relative path. -- B-No pipeline matched request: samples/flow/jxcalc/page/getNumberA org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: samples/flow/jxcalc/page/getNumberA COMMENT: Why? It must go to the redirection in flow directory using the sitemap that is in flow dir! -- C-No pipeline matched request: /samples/flow/jxcalc/page/getNumberA org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: /samples/flow/jxcalc/page/getNumberA COMMENT: Again, why? As above, the link exists! -- D-No pipeline matched request: //samples/flow/jxcalc/page/getNumberA org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: //samples/flow/jxcalc/page/getNumberA COMMENT: Again, why? As above, the link exists! -- It will never go to the requested path! If it works, it would be the same as: http://localhost:/samples/flow/jxcalc/page/getNumberA And we would need to receive a diferent error: org.apache.cocoon.ProcessingException: Failed to execute pipeline.: file:/home/agallardo/workspace/cocoon-2.1/build/webapp/samples /flow/jxcalc/screens/getNumberA.xml:30:72:org.apache.commons.j xpath.JXPathException: No value for xpath: $cocoon/continuation/id Now the question is what is affecting that? Best Regards, Antonio Gallardo
Removing sitemap's check-reload attribute
Working on the TreeProcessor, I noticed check-reload that exists on
map:mount whose existence I nearly forgot about, and was wondering
about its actual usefulness, furthermore considering that it defaults to
true (i.e. reload when needed)
There are lots and lots of places in Cocoon where automatic reload
occurs with no way to disable it: XSLT, XSP, JXTG, CForms to name a few.
So I propose to remove this feature, and have automatic sitemap reload
always be turned on, as everywhere else.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
JSR 170 Public Review
After long awaiting, I'm happy to annouce the public availability of the JSR 170 Java Content API Specification for public review. Find it here: http://jcp.org/aboutJava/communityprocess/review/jsr170/index.html Note that the review ends July 19, so if you have any feedback please send it to me or to [EMAIL PROTECTED] Hope this helps. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
RE: [CVS] Flow bug in redirections? Test case inside.
Antonio Gallardo [mailto:[EMAIL PROTECTED] Hi: I setted this breakpoints: 1-o.a.c.components.flow.javascript.fom.FOM_Cocoon.java at line 261. 2- o.a.c.components.flow.javascript.fom.FOM_JavaScriptInterpreter .java at line 837 3-o.a.c.components.flow.AbstractInterpreter.java at line 171 I posted the 3 breakpoints to draft the route the problem follow. It is a problem in the sendPage from Javaflow. I think, the last breakpoint is the most important because until it all is OK. I wonder if the problem is in the hint we post store for the redirector (3 file at line 179). Hmm, this hint is in 2.1.5 as well, so as it worked there for you, I think this is not the problem. I think I found the problem it seems to be in the tree processor. Give me some minutes to verify this. Carsten
RE: Removing sitemaps check-reload attribute
-1 :) Turning off this checking improves performance (no time
stamp checking anymore).
Carsten
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Friday, June 04, 2004 3:14 PM
To: cocoon-dev
Subject: Removing sitemaps check-reload attribute
Working on the TreeProcessor, I noticed check-reload that
exists on map:mount whose existence I nearly forgot about,
and was wondering about its actual usefulness, furthermore
considering that it defaults to true (i.e. reload when needed)
There are lots and lots of places in Cocoon where automatic
reload occurs with no way to disable it: XSLT, XSP, JXTG,
CForms to name a few.
So I propose to remove this feature, and have automatic
sitemap reload always be turned on, as everywhere else.
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] Flow bug in redirections? Test case inside.
Carsten Ziegeler dijo: Antonio Gallardo [mailto:[EMAIL PROTECTED] Hi: I setted this breakpoints: 1-o.a.c.components.flow.javascript.fom.FOM_Cocoon.java at line 261. 2- o.a.c.components.flow.javascript.fom.FOM_JavaScriptInterpreter .java at line 837 3-o.a.c.components.flow.AbstractInterpreter.java at line 171 I posted the 3 breakpoints to draft the route the problem follow. It is a problem in the sendPage from Javaflow. I think, the last breakpoint is the most important because until it all is OK. I wonder if the problem is in the hint we post store for the redirector (3 file at line 179). Hmm, this hint is in 2.1.5 as well, so as it worked there for you, I think this is not the problem. I think I found the problem it seems to be in the tree processor. Give me some minutes to verify this. Thanks! BTW, I found a simpler test case: 1- Replace line 171 in cocoon-2.1/build/webapp/samples/flow/jxcalc/calc.js with: var uri = /samples/flow/jxcalc/page/getNumber + name.toUpperCase(); It must work. Best Regards, Antonio Gallardo.
Re: Removing sitemaps check-reload attribute
Carsten Ziegeler wrote:
-1 :) Turning off this checking improves performance (no time stamp checking anymore).
Do you think there's a real difference if the sitemap is checked _at
most_ once per second (the default delay), when so much other files are
checked at _every_ request?
Sylvain
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Friday, June 04, 2004 3:14 PM
To: cocoon-dev
Subject: Removing sitemaps check-reload attribute
Working on the TreeProcessor, I noticed check-reload that
exists on map:mount whose existence I nearly forgot about,
and was wondering about its actual usefulness, furthermore
considering that it defaults to true (i.e. reload when needed)
There are lots and lots of places in Cocoon where automatic
reload occurs with no way to disable it: XSLT, XSP, JXTG,
CForms to name a few.
So I propose to remove this feature, and have automatic
sitemap reload always be turned on, as everywhere else.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Removing sitemap's check-reload attribute
On 04.06.2004 15:14, Sylvain Wallez wrote: Working on the TreeProcessor, I noticed check-reload that exists on map:mount whose existence I nearly forgot about, and was wondering about its actual usefulness, furthermore considering that it defaults to true (i.e. reload when needed) There are lots and lots of places in Cocoon where automatic reload occurs with no way to disable it: XSLT, XSP, JXTG, CForms to name a few. So I propose to remove this feature, and have automatic sitemap reload always be turned on, as everywhere else. WDYT? +1 I never switched it off. IIRC there is also such a setting in cocoon.xconf for the root sitemap. Does it make sense to switch reload on or off for each subsitemap individually or is the one setting in cocoon.xconf satisfying enough for all sitemaps? Joerg
RE: [CVS] Flow bug in redirections? Test case inside.
Should work now - please cross-check. Thanks Carsten -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Friday, June 04, 2004 3:25 PM To: [EMAIL PROTECTED] Subject: RE: [CVS] Flow bug in redirections? Test case inside. Carsten Ziegeler dijo: Antonio Gallardo [mailto:[EMAIL PROTECTED] Hi: I setted this breakpoints: 1-o.a.c.components.flow.javascript.fom.FOM_Cocoon.java at line 261. 2- o.a.c.components.flow.javascript.fom.FOM_JavaScriptInterpreter .java at line 837 3-o.a.c.components.flow.AbstractInterpreter.java at line 171 I posted the 3 breakpoints to draft the route the problem follow. It is a problem in the sendPage from Javaflow. I think, the last breakpoint is the most important because until it all is OK. I wonder if the problem is in the hint we post store for the redirector (3 file at line 179). Hmm, this hint is in 2.1.5 as well, so as it worked there for you, I think this is not the problem. I think I found the problem it seems to be in the tree processor. Give me some minutes to verify this. Thanks! BTW, I found a simpler test case: 1- Replace line 171 in cocoon-2.1/build/webapp/samples/flow/jxcalc/calc.js with: var uri = /samples/flow/jxcalc/page/getNumber + name.toUpperCase(); It must work. Best Regards, Antonio Gallardo.
RE: Removing sitemaps check-reload attribute
Forgot to add:
The default is true anyways, so you can just ignore this feature.
But it might be useful for people that want to fine tune their
setup. So in the end it doesn't hurt if you have the possibility.
Carsten
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: Friday, June 04, 2004 3:20 PM
To: [EMAIL PROTECTED]
Subject: RE: Removing sitemaps check-reload attribute
-1 :) Turning off this checking improves performance (no time
stamp checking anymore).
Carsten
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Friday, June 04, 2004 3:14 PM
To: cocoon-dev
Subject: Removing sitemaps check-reload attribute
Working on the TreeProcessor, I noticed check-reload that
exists on
map:mount whose existence I nearly forgot about, and was
wondering
about its actual usefulness, furthermore considering that
it defaults
to true (i.e. reload when needed)
There are lots and lots of places in Cocoon where automatic reload
occurs with no way to disable it: XSLT, XSP, JXTG, CForms to name a
few.
So I propose to remove this feature, and have automatic sitemap
reload always be turned on, as everywhere else.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Removing sitemaps check-reload attribute
Sylvain Wallez dijo: Carsten Ziegeler wrote: -1 :) Turning off this checking improves performance (no time stamp checking anymore). Do you think there's a real difference if the sitemap is checked _at most_ once per second (the default delay), when so much other files are checked at _every_ request? Instead of removing it. Let move it to other location and add the support for the other places you posted above. Then we can have a global parameter in cocoon.xconf that will allow switch to a production mode by disabling all this checks at once. WDYT? Best Regards, Antonio Gallardo
Re: Removing sitemap's check-reload attribute
Sylvain Wallez wrote: Working on the TreeProcessor, I noticed check-reload that exists on map:mount whose existence I nearly forgot about, and was wondering about its actual usefulness, furthermore considering that it defaults to true (i.e. reload when needed) There are lots and lots of places in Cocoon where automatic reload occurs with no way to disable it: XSLT, XSP, JXTG, CForms to name a few. Actually, you can turn off XSP reloading. PS -1 on removing in cocoon.xconf, 0 on removing in map:mount Vadim
Re: [VOTE] new Cocoon PMC chair
+1 for Vadim Gritsenko /leo
RE: [CVS] Flow bug in redirections? Test case inside.
Hi Carsten: It works now! Many thanks! I think another beer is on the way. Perhaps with this the count reach 3! :-D PS: Antonio started to think seriously to open a bank account to store money to buy Carsten beers. ;-) Best Regards, Antonio Gallardo
Re: Removing sitemap's check-reload attribute
Sylvain Wallez wrote: So I propose to remove this feature, and have automatic sitemap reload always be turned on, as everywhere else. WDYT? +1 Ugo
Re: Removing sitemap's check-reload attribute
Sylvain Wallez wrote: Working on the TreeProcessor, I noticed check-reload that exists on map:mount whose existence I nearly forgot about, and was wondering about its actual usefulness, furthermore considering that it defaults to true (i.e. reload when needed) There are lots and lots of places in Cocoon where automatic reload occurs with no way to disable it: XSLT, XSP, JXTG, CForms to name a few. So I propose to remove this feature, and have automatic sitemap reload always be turned on, as everywhere else. WDYT? I like the fact that auto-reloading should be consistent and global, but I would also like to have the ability to turn it off, especially in production environments because this removes some performance overhead in the checking (even if it's asynchronous). Comments? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
RE: Removing sitemaps check-reload attribute
Sylvain Wallez wrote: Carsten Ziegeler wrote: -1 :) Turning off this checking improves performance (no time stamp checking anymore). Do you think there's a real difference if the sitemap is checked _at most_ once per second (the default delay), when so much other files are checked at _every_ request? This depends on your setup, you can e.g. use expires caching where the files are not checked at every request or you can use custom components that have a smarter check etc. So, yes, I think there is a major difference. Carsten
RE: [CVS] Flow bug in redirections? Test case inside.
Antonio Gallardo wrote: Hi Carsten: It works now! Many thanks! I think another beer is on the way. Perhaps with this the count reach 3! :-D PS: Antonio started to think seriously to open a bank account to store money to buy Carsten beers. ;-) Great idea! What about a PayPal account were people can make donations? Ok, let's get serious again: are there any other problems with internal pipeline calls or redirects? Carsten
Re: [portal] Form-Coplet communication
On Friday 04 June 2004 14:09, Alex Romayev wrote:
Hi Chris,
I think this is an option that might work, however, a
couple of questions:
- Since request parameters are not available to to
coplets, I assume it still isn't possible to use
CForms for binding?
I did not find a way :-(
- Again, assuming CForms binding cannot be use, I have
about 15 parameters that I need to pass. Does this
meant I have to create 15 attributes in coplet
configuration, 15 events in bookmarks.xml, and 15
entries in sitemap to pass coplet/attribute to the
coplet, or have you been able to find a better way?
I'm using this feature to pass one value to many coplets...
You won't need 15 entries in the sitemap if you want to pass 15 attributes to
the coplet. You can use uris like
bookmark?coplet-att1=value#38;coplet-att2=value#38;coplet-att3=value#38;coplet-att3=value#38;coplet-att4=value#38;coplet-att5=value#38;coplet-att6=value#38;coplet-att7=value#38;coplet-att8=value#38;coplet-att9=value#38;coplet-att10=value#38;coplet-att11=value#38;coplet-att12=value#38;coplet-att1=value#38;coplet-att13=value#38;coplet-att14=value#38;coplet-att15=value#38;
in the sitemap. The bookmark action will generate a {uri} consisting of all
coplet events.
The values in the url must be uri-encoded and I don't know how big
internal cocoon url's can grow.
15 parameters are many, maybe the best thing would be to store them as session
attributes, using the session-propagator action or flowscript.
The bookmark feature would be useful for layout control.
The session-attr input module or flowscript could be used to retrieve those
values stored in the session.
I think this way CachingURICoplet's could still be used for cform's.
Note: I have not tried this myself. Do session-attr's survive between coplets?
--
lg, Chris
Re: [VOTE] new Cocoon PMC chair
Too many good choices ... +1 for Vadim Gritsenko --David
Re: Removing sitemaps check-reload attribute
Carsten Ziegeler wrote:
Forgot to add:
The default is true anyways, so you can just ignore this feature. But it might be useful for people that want to fine tune their setup. So in the end it doesn't hurt if you have the possibility.
Sure, and I won't insist much for this reason. I just find this feature
rather useless and inconsistent with Cocoon's general behaviour.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] new Cocoon PMC chair
On 04 Jun 2004, at 10:32, Steven Noels wrote: - Vadim Gritsenko +1 /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: error handling
...What about... map:pipeline handle-errors=always|external|internal/ our current behaviour would be external. I would like to have always andt the internal option might be FS ;) +1 for the declaration, looks clean enough! Carsten, I'd really like to takle this ASAP. We are currently using a *very* ugly work around. WDYT? cheers -- Torsten
RE: error handling
Torsten Curdt [EMAIL PROTECTED] writes: snipsort of ugly solution/snip and specifying it in the called pipeline: map:pipeline handle-errors-for-internal-calls=true/ This looks much better The names of the attributes/request-parameters I used have not been set in the discussions. I just used here some to show the principle. :-) What about... map:pipeline handle-errors=always|external|internal/ our current behaviour would be external. I would like to have always andt the internal option might be FS ;) Hmmm, just wondering, if I have: map:pipeline internal-only=true and I define a map:handle-errors within it, would that now work? And if it did, would I have to specify handle-errors=internal or would that be the default for such a pipeline? I realize, most people would likely only want a single handle-errors section so that you don't have to specify the same error handling in two different places. However, if someone did have a reason for having different handling for the two cases I'd expect that they'd want to add the handle-errors to the internal-only pipeline and not specify anything else. As such, handle-errors=internal does not seem necessary? Now, implementing this should be a two or three liner :) I already had it implemented but lost the code... You can also give me a hand ...up to you. cheers -- Torsten
Re: error handling
Hunsberger, Peter wrote: Torsten Curdt [EMAIL PROTECTED] writes: snipsort of ugly solution/snip and specifying it in the called pipeline: map:pipeline handle-errors-for-internal-calls=true/ This looks much better The names of the attributes/request-parameters I used have not been set in the discussions. I just used here some to show the principle. :-) What about... map:pipeline handle-errors=always|external|internal/ our current behaviour would be external. I would like to have always andt the internal option might be FS ;) Hmmm, just wondering, if I have: map:pipeline internal-only=true and I define a map:handle-errors within it, would that now work? And if it did, would I have to specify handle-errors=internal or would that be the default for such a pipeline? I realize, most people would likely only want a single handle-errors section so that you don't have to specify the same error handling in two different places. However, if someone did have a reason for having different handling for the two cases I'd expect that they'd want to add the handle-errors to the internal-only pipeline and not specify anything else. As such, handle-errors=internal does not seem necessary? It is necessary in case you don't want error handling in this internal pipeline -- meaning you want behavior as it is now. Now, if you want to change current default, you'll have to add this attribute. Vadim
Re: [VOTE] new Cocoon PMC chair
+1 for Vadim Gritsenko -- Unico
Re: JXTG and caching - IT'S DONE
Leszek Gawron wrote:
Upayavira wrote:
It seems to me that Sylvains suggested extension of jxt has a great
deal of power in it.
OK. Then I'll continue my work and try to provide the appropriate
patch as I have already started to make needed changes.
Great. I'd love to see a cacheable jxt.
Regards, Upayavira
You can test the first implementation if you fetch this file :
http://ouzo.wlkp.org/cjxtg.zip
Fab.
The below all reads okay to me. It would seem reasonable that the
template must be read in setup now. [As an aside, is the jxt file
cached? Or does it need to be read with every request? Maybe the parsed
jxt could be put into the transient store or something?]
I would suggest:
(a) patch the JXTemplateGenerator itself, rather than creating a new class.
(b) Post this as a patch to Bugzilla. Then, hopefully someone'll get the
chance to check it and commit it.
Regards, Upayavira
it contains :
CachingJXTemplateGenerator.java which you should put to the same
directory as JXTG.java and rebuild your cocoon.
There also is a simple test case in test directory. Put it into your
webapp root and then issue this url:
http://localhost:/test/test.do?key=something
if I got it right the view is generated once for each key and cached
so the date on the page won't change if you refresh your page.
How it works:
1. every attribute in http://apache.org/cocoon/templates/jx/1.0;
namespace get stripped from attributes and end up in StartDocument
event in templateProperties map (which I added). This is something
that could be used for providing additional parameters to template in
the future.
These attributes are not generated to output. They are only stored in
map. This was the simplest solution. I think it's acceptable. How
about you?
2. In template's root element (or any element really) you put:
page jx:cache-key=${biz.getKey()}
jx:cache-validity=${biz.getValidity()}
The key should be Serializable and the Validity should be
SourceValidity of course.
Voilla .. the page gets cached.
What changed:
1. CachingJXTemplateGenerator implements CacheableProcessingComponent
of course :)
2. StartDocument.templateProperties added
3. I had to move template parsing from generate to setup(). Otherwise
that happened:
- fetch http://localhost:/test/test.do?key=abc
- setup() called
- getKey() called - template not parsed yet, cannot compute key - no view
caching will be done
- generate() - template gets parsed and generated, template cached
- refresh browser
- setup() called
- getKey() - got parsed template, can evaluate cache-key
- lookup from cache fails as the first response was not cached
- generate() - template already parsed
- response cached, getValidity() called somewhere of course
The response gets cached after second page hit because getKey() first
time is called before template is parsed. When parsing is moved to
setup() this happens:
- fetch http://localhost:/test/test.do?key=abc
- setup() called, template gets parsed
- getKey() called, template accessible, key computed
- cache lookup falils
- generate() called
- response cached!
This class can become standard JXTemplateGenerator as if you do not
provide caching attributes the page never gets cached so it works like
it did before.
Please make your comments
RE: error handling
Vadim Gritsenko [EMAIL PROTECTED] writes: Hunsberger, Peter wrote: Torsten Curdt [EMAIL PROTECTED] writes: snipsort of ugly solution/snip and specifying it in the called pipeline: map:pipeline handle-errors-for-internal-calls=true/ This looks much better The names of the attributes/request-parameters I used have not been set in the discussions. I just used here some to show the principle. :-) What about... map:pipeline handle-errors=always|external|internal/ our current behaviour would be external. I would like to have always andt the internal option might be FS ;) Hmmm, just wondering, if I have: map:pipeline internal-only=true and I define a map:handle-errors within it, would that now work? And if it did, would I have to specify handle-errors=internal or would that be the default for such a pipeline? I realize, most people would likely only want a single handle-errors section so that you don't have to specify the same error handling in two different places. However, if someone did have a reason for having different handling for the two cases I'd expect that they'd want to add the handle-errors to the internal-only pipeline and not specify anything else. As such, handle-errors=internal does not seem necessary? It is necessary in case you don't want error handling in this internal pipeline -- meaning you want behavior as it is now. Huh? If you don't want error handling in an internal pipeline then just don't specify it. It doesn't work at the moment, so we're not taking anything away... Even if it did work, why would you want to handle external errors in an internal only pipeline? Now, if you want to change current default, you'll have to add this attribute. Now that seems like FS to me...
Re: [VOTE] new Cocoon PMC chair
Steven Noels wrote:
- Sylvain Wallez
Well, just like Matthew, +1 for me!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] new Cocoon PMC chair
Sylvain Wallez wrote: Steven Noels wrote: - Sylvain Wallez Well, just like Matthew, +1 for me! Sylvain Difficult choice, but: +1 for Sylvain. Upayavira
Re: error handling
Hunsberger, Peter wrote: Vadim Gritsenko [EMAIL PROTECTED] writes: ... Now, if you want to change current default, you'll have to add this attribute. Now that seems like FS to me... No, it's called backward compatibility ;-) Vadim
Re: [VOTE] new Cocoon PMC chair
Steven Noels wrote: - Andrew Savory +1. PS I don't feel right voting for myself, so my vote goes to Andrew. Vadim
RE: error handling
Vadim Gritsenko [EMAIL PROTECTED] writes: Hunsberger, Peter wrote: Vadim Gritsenko [EMAIL PROTECTED] writes: ... Now, if you want to change current default, you'll have to add this attribute. Now that seems like FS to me... No, it's called backward compatibility ;-) Unless something has changed I don't think so: handle-errors does nothing in an internal-only pipeline, it doesn't work. So being backwards compatible with something that doesn't work isn't going to help anyone.
Re: Removing sitemap's check-reload attribute
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Working on the TreeProcessor, I noticed check-reload that exists on
map:mount whose existence I nearly forgot about, and was wondering
about its actual usefulness, furthermore considering that it defaults
to true (i.e. reload when needed)
There are lots and lots of places in Cocoon where automatic reload
occurs with no way to disable it: XSLT, XSP, JXTG, CForms to name a few.
So I propose to remove this feature, and have automatic sitemap
reload always be turned on, as everywhere else.
WDYT?
I like the fact that auto-reloading should be consistent and global,
but I would also like to have the ability to turn it off, especially
in production environments because this removes some performance
overhead in the checking (even if it's asynchronous).
Comments?
There were some talks related to this when we discussed store cleanup,
as reload is often related to compiling the contents of a Source (e.g.
building a TreeProcessor, a form definition, a stylesheet, etc) and
caching that compiled form for later use. Caching also possibly meaning
purging no more used entries, contrarily to what happens today with
private Maps to store these objects.
There's an initial attempt at this in the scratchpad (util.SourceCache)
which we may build upon.
That may also be a service provided at a lower level by SourceUtil (but
then relying on an ugly static setting) or by the SourceResolver itself.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] new Cocoon PMC chair
Here's my +1 for: - Andrew Savory -marc= (waking up and seeing the original was replied to the wrong list...) -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [VOTE] new Cocoon PMC chair
On Fri, 2004-06-04 at 10:32, Steven Noels wrote: - Sylvain Wallez +1 -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [VOTE] new Cocoon PMC chair
On Jun 4, 2004, at 4:32 AM, Steven Noels wrote: - Vadim Gritsenko +1 -pete
Re: JXTG and caching - IT'S DONE
Upayavira wrote: Fab. The below all reads okay to me. It would seem reasonable that the template must be read in setup now. [As an aside, is the jxt file cached? Or does it need to be read with every request? Maybe the parsed jxt could be put into the transient store or something?] The parsed template model is being put into local cache - a map. That should go to transient store - I do not know the purpose of current solution. I would suggest: (a) patch the JXTemplateGenerator itself, rather than creating a new class. Sure, this is what I am about to do. I just prepared the initial version that does not affect any existing sources. (b) Post this as a patch to Bugzilla. Then, hopefully someone'll get the chance to check it and commit it. OK One more thing: The jx transformer will never be cacheable - not possible. LG
Re: [VOTE] new Cocoon PMC chair
On Fri, Jun 04, 2004 at 10:32:41AM +0200, Steven Noels wrote: All good, so roll the dice to choose: +1 Sylvain Wallez --Tim Larson
JSPGenerator in Weblogic 8.1
Part of our development team wants to use JavaHelp (http://java.sun.com/products/javahelp/). Unfortunately, it uses JST tag libraries which requier JSP support. They have been able to get it to work under Tomcat, but not under WebLogic 8.1. It appears that the JSPGenerator (or rather the JSPEngine implementations) do not work in WebLogic 8.1. Does anyone have any information on what I need to do to make JSPEngineImplWLS work in current versions of WebLogic? Ralph
RE: error handling
Torsten Curdt wrote: ...What about... map:pipeline handle-errors=always|external|internal/ our current behaviour would be external. I would like to have always andt the internal option might be FS ;) +1 for the declaration, looks clean enough! Carsten, I'd really like to takle this ASAP. We are currently using a *very* ugly work around. Yes, yes, do it - you don't have to wait for my +1, I'm just a little committer who likes it when everyone ignores him. Silence always means: I'm not against it. Carsten
TestCronJob
Hi All
I am playing with o.a.c.components.cron.TestCronJob.
I am using it to call a pipeline once per day that runs a FlowScript
that scours a database for jobs that need doing and sending out email
reminders.
The FlowScript calls one pipeline to generate the email body via
'cocoon.processPipelineTo' and another pipeline to generate the cron
log written by TestCronJob via 'cocoon.sendPage'.
It works really well, many thanks !!
Before starting this, I was expecting to have to write my own CronJob,
but I found that TestCronJob did everything I needed (call a pipeline,
log the output).
However, there is something I do not understand about TestCronJob.
It sleeps after it has done the job, for a configurable amount of time.
try {
Thread.sleep(m_sleep);
} catch (final InterruptedException ie) {
//getLogger().error(CronJob + name + interrupted, ie);
}
Is it doing this because it is a test class and this is providing some
kind of debug information, or is it doing it because this is something
that a CronJob needs to do, and I would need to take care to set the
sleep parameter appropriately.
Thanks for any suggestions
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: TestCronJob
Jeremy Quinn wrote: Is it doing this because it is a test class and this is providing some kind of debug information, or is it doing it because this is something that a CronJob needs to do, and I would need to take care to set the sleep parameter appropriately. This is just a test functionality. It's not needed at all. Leszek Gawron
Redesigning the Samples
As some of you may have seen, I've been poking around in the CSS of the samples lately. I've been playing around with the design in Photoshop, and I've come up with a design that I think is Pretty Damn Good(tm) Screenshot at: http://rose.ce.umn.edu/images/misc/cocoon-mockup.gif If nobody objects, I will commit the changes Monday, suggestions are welcome. Regards, Tony, who had an itch big enough to scratch.
Re: Redesigning the Samples
Tony Collen wrote: As some of you may have seen, I've been poking around in the CSS of the samples lately. I've been playing around with the design in Photoshop, and I've come up with a design that I think is Pretty Damn Good(tm) Screenshot at: http://rose.ce.umn.edu/images/misc/cocoon-mockup.gif If nobody objects, I will commit the changes Monday, suggestions are welcome. Looks good, and logo is especially good :-) Should footer also have a background? Just asking... Vadim
Re: Redesigning the Samples
Vadim Gritsenko wrote: Tony Collen wrote: As some of you may have seen, I've been poking around in the CSS of the samples lately. I've been playing around with the design in Photoshop, and I've come up with a design that I think is Pretty Damn Good(tm) Screenshot at: http://rose.ce.umn.edu/images/misc/cocoon-mockup.gif If nobody objects, I will commit the changes Monday, suggestions are welcome. Looks good, and logo is especially good :-) Cool, I'll have a slightly cleaner version once I crack open Illustrator. Should footer also have a background? Just asking... Nope, didn't touch it Vadim Tony
Re: Redesigning the Samples
On 04.06.2004 23:40, Vadim Gritsenko wrote: As some of you may have seen, I've been poking around in the CSS of the samples lately. I've been playing around with the design in Photoshop, and I've come up with a design that I think is Pretty Damn Good(tm) Screenshot at: http://rose.ce.umn.edu/images/misc/cocoon-mockup.gif If nobody objects, I will commit the changes Monday, suggestions are welcome. Looks good, and logo is especially good :-) It's really cool! Should footer also have a background? Just asking... Yes, I would like it. Joerg
Re: JSPGenerator in Weblogic 8.1
On 04.06.2004 19:46, Ralph Goers wrote: Part of our development team wants to use JavaHelp (http://java.sun.com/products/javahelp/). Unfortunately, it uses JST tag libraries which requier JSP support. They have been able to get it to work under Tomcat, but not under WebLogic 8.1. It appears that the JSPGenerator (or rather the JSPEngine implementations) do not work in WebLogic 8.1. Does anyone have any information on what I need to do to make JSPEngineImplWLS work in current versions of WebLogic? In theory only two things must be set: 1. the JSPEngine impl: http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/jsp/conf/jsp.xroles?rev=1.2view=auto 2. the JSP engine servlet class: http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/jsp/conf/jsp.xconf?rev=1.3view=auto Joerg
Re: Redesigning the Samples
Tony Collen wrote: Vadim Gritsenko wrote: Should footer also have a background? Just asking... Nope, didn't touch it I get -1 for reading comprehension. I should have said, I'll try it out :) ATC
DO NOT REPLY [Bug 29401] New: - xslt extension functions with bsf broken due to xalan-2.6 / bsf-2.3 conflict
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29401. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29401 xslt extension functions with bsf broken due to xalan-2.6 / bsf-2.3 conflict Summary: xslt extension functions with bsf broken due to xalan- 2.6 / bsf-2.3 conflict Product: Cocoon 2 Version: 2.1.5 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] xsl comprising extension functions implemented through BSF will throw an error indicating that the required com.ibm.bsf class cannot be found. In fact, the namespace of bsf has changed from com.ibm.bsf to org.apache.bsf in the switch from bsf-2.2.jar, which was in cocoon-2.1.4 and bsf-2.3.jar, which is provided in the bsf block of cocoon-2.1.5 It seems that xalan-2.6, a core component of cocoon-2.1.5, was compiled against the com.ibm.bsf version, and this causes the error. Temporary solution is to add a bsf-2.2.jar file to build/webapp/WEBINF/lib. In the future, perhaps testing should be done for extension functions in xslt.
Re: Redesigning the Samples
Tony Collen wrote: Screenshot at: http://rose.ce.umn.edu/images/misc/cocoon-mockup.gif If nobody objects, I will commit the changes Monday, suggestions are welcome. The top banner seems to waste space. At one stage in the past we had it like this - with everything centred. Then it evolved to have three columns to try to give more space for the important content. IMO this new banner design is a backward step. I don't like the rounded-corners. The presentation would be sharper without them. They also seem to be cramping the start of the headings text. The font style for the headings seems to be too blocky, not as crisp as it should be. The footer i like as it is. Erk, i do not want to pour water on your efforts, but i was already really happy with the original design. The only thing that i would have changed would be to make the top part of the page be even more compact. --David
DO NOT REPLY [Bug 29401] - xslt extension functions with bsf broken due to xalan-2.6 / bsf-2.3 conflict
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29401. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29401 xslt extension functions with bsf broken due to xalan-2.6 / bsf-2.3 conflict --- Additional Comments From [EMAIL PROTECTED] 2004-06-05 02:41 --- There is a RFE for Xalan: bug #27708
Re: JSPGenerator in Weblogic 8.1
Thanks, Joerg. I have been told that they have tried both JSPEngines using the 2.1.5 sample site and neither of them work in Weblogic 8.1. However, I'm short on details and haven't tried it myself. There was a thread a while ago where it was stated that JSPEngineImplWLS only works with Weblogic 5. They said they tried using jasper but got a class cast exception. Ralph At 6/4/2004 02:58 PM, Joerg Heinicke wrote: On 04.06.2004 19:46, Ralph Goers wrote: Part of our development team wants to use JavaHelp (http://java.sun.com/products/javahelp/). Unfortunately, it uses JST tag libraries which requier JSP support. They have been able to get it to work under Tomcat, but not under WebLogic 8.1. It appears that the JSPGenerator (or rather the JSPEngine implementations) do not work in WebLogic 8.1. Does anyone have any information on what I need to do to make JSPEngineImplWLS work in current versions of WebLogic? In theory only two things must be set: 1. the JSPEngine impl: http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/jsp/conf/jsp.xroles?rev=1.2view=auto 2. the JSP engine servlet class: http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/jsp/conf/jsp.xconf?rev=1.3view=auto Joerg
