Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 62485 invoked from network); 22 Jul 2005 13:20:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 22 Jul 2005 13:20:16 -0000 Received: (qmail 63218 invoked by uid 500); 22 Jul 2005 13:20:12 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 63138 invoked by uid 500); 22 Jul 2005 13:20:11 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 63124 invoked by uid 99); 22 Jul 2005 13:20:11 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jul 2005 06:20:11 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [216.221.81.25] (HELO fep2.cogeco.net) (216.221.81.25) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jul 2005 06:20:04 -0700 Received: from [192.168.1.102] (d57-197-80.home.cgocable.net [24.57.197.80]) by fep2.cogeco.net (Postfix) with ESMTP id BD50D25B9 for ; Fri, 22 Jul 2005 09:20:06 -0400 (EDT) Message-ID: <42E0F28C.5040807@openskysolutions.ca> Date: Fri, 22 Jul 2005 09:20:12 -0400 From: Nick Goupinets User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: [Fwd: Re: [Portal] Cocon 2.1.7 upgrade breaks CachingURICoplets] Content-Type: multipart/mixed; boundary="------------060903060007030305060403" X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. --------------060903060007030305060403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi everybody, I tried mailing users list, but there was not much activity there. I described the problem in all details in 2 previous posts. In its core there is the fact that cocoon-portal-action and cocoon-portal-events parameters are not available when calling Request.getParameter method if enctype attribute is present on the submitted form. However, those 2 parameters can be found in the string returned by Request.getQueryString(). Is it a bug, or normal behavior and I am doing something wrong? Thank you very much. Sincerely, Nick Goupinets. PS. WindowsXP Cocoon 2.1.7 Tomcat 5.0.28 Java 1.4.2_08 --------------060903060007030305060403 Content-Type: message/rfc822; name="Re: [Portal] Cocon 2.1.7 upgrade breaks CachingURICoplets" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: [Portal] Cocon 2.1.7 upgrade breaks CachingURICoplets" X-Account-Key: account2 Return-Path: X-Original-To: ngoupinets@cogeco.net Delivered-To: ngoupinets@cogeco.net Received: from storm.easydns.com (smtp.easydns.com [205.210.42.52]) by fep5.cogeco.net (Postfix) with ESMTP id AF775149D for ; Thu, 21 Jul 2005 13:02:54 -0400 (EDT) Received: from mail.apache.org (hermes.apache.org [209.237.227.199]) by storm.easydns.com (Postfix) with SMTP id E376C52343 for ; Thu, 21 Jul 2005 13:02:52 -0400 (EDT) Received: (qmail 3417 invoked by uid 500); 21 Jul 2005 17:02:29 -0000 Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: users@cocoon.apache.org List-Id: Delivered-To: mailing list users@cocoon.apache.org Received: (qmail 3389 invoked by uid 99); 21 Jul 2005 17:02:29 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Jul 2005 10:02:29 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [216.221.81.25] (HELO fep3.cogeco.net) (216.221.81.25) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Jul 2005 10:02:20 -0700 Received: from [192.168.1.102] (d57-197-80.home.cgocable.net [24.57.197.80]) by fep3.cogeco.net (Postfix) with ESMTP id 4974D10FA for ; Thu, 21 Jul 2005 13:02:23 -0400 (EDT) Message-ID: <42DFD51F.9010305@openskysolutions.ca> Date: Thu, 21 Jul 2005 13:02:23 -0400 From: Nick Goupinets User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: users@cocoon.apache.org Subject: Re: [Portal] Cocon 2.1.7 upgrade breaks CachingURICoplets References: <42DE835D.4060907@openskysolutions.ca> In-Reply-To: <42DE835D.4060907@openskysolutions.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hello, After going through some more debugging, I think I figured out why continuation is not resumed: coplet content is taken from cache. That's not much of a relief because now I am faced with the question why cache is not refreshed. I've done some more debugging in order to resolve this new issue. It looks like when portal event processing chain is started, ActionCounterEventAspect class can not locate "cocoon-portal-action" request parameter when processing the problematic coplet. This forces it not to continue processing chain. Thus coplet is not refreshed :(. I attempted to check if this parameter is present in the request object. It looks like it's not, in case there is enctype="multipart/form-data" attribute present in the form tag ("cocoon-portal-action" parameter can be found however in the string returned by Request.getRequestQuery() method). In case I remove this enctype attribute from the form, coplet starts working like charm, except file uploads will not be functional. Is is a bug or am I doing something wrong? Some (any?) feedback to this problem is greatly appreciated. Thank you very much in advance. Sincerely, Nick Goupinets. P.S. Request parameters for coplet that works fine (no enctype): ============================================================= Request URI : /TaporMain/portal/portal Request Query : null cocoon-portal-action : 1 cocoon-portal-event : 7 useToolOnText - Use Tool on Source Text cocoon-portal-event - 7 link - continuation-id - 3b265b105b5167651d3a5a29266f7d6d4668837d forms_submit_id - texts - 1 tools - 3 cocoon-portal-action - 1 ============================================================= Request parameter for the coplet that doesn't work (enctype present): ============================================================= Request URI : /TaporMain/portal/portal Request Query : cocoon-portal-action=2&cocoon-portal-event=8 cocoon-portal-action : null cocoon-portal-event : null forms_submit_id - selectForClientSide selectForClientSide - bench_htmlInput htmlTag - body optionSeletion - mytexts_htmlInput - 1 sorting - 1 continuation-id - 4042555c305f6f6369091a02604c313c2e71415e resultWindow - true listOption - all outFormat - html ============================================================= Form snippet for the coplet that doesn't work: =============================================================
.... ============================================================= If I remove enctype attribute from the form, everything starts working just fine. Here are the request parameters for the coplet that didn't work (cocoon-portal-action and cocoon-portal-event are present) ============================================================= Request URI : /TaporMain/portal/portal Request Query : null cocoon-portal-action : 6 cocoon-portal-event : 8 forms_submit_id - selectForClientSide - upload_htmlInput context - 1 contextLength - 5 htmlTag - body continuation-id - 12777d5936373c6e76086d4811332a0a16287b77 cocoon-portal-action - 6 toolBrokerSubmit - Submit pattern - a upload_htmlInput - view-deschampsxlii.xml cocoon-portal-event - 8 resultWindow - true outFormat - html ============================================================= Nick Goupinets wrote: > Hi everybody, > > I am trying to upgrade our project that is based on the portal block > from Cocoon 2.1.5 to Cocoon 2.1.7. Right now I run into a very annoying > problem which I have no idea how to solve: All of CachingURICoplets that > use CForms stop functioning after form gets shown. It just looks as if > continuation is not resumed. > > Here is an example. When the following code is executed: > > ===================================================== > cocoon.load("resource://org/apache/cocoon/forms/flow/javascript/Form.js"); > > var toolBrokerInst = null; > > // called from the sitemap > function toolBroker(userID, toolID, showDataBench, textUrl) { > print("STARTED ToolBroker"); > if (toolID == '' || toolID == null) { > toolID = cocoon.session.getAttribute("toolID"); > ... > } > if (toolID != null){ > try { > toolBrokerInst = cocoon.getComponent( .... ); > cocoon.session.removeAttribute("toolID"); > showFormForTool(userID, toolName, newWin, showDataBench, textUrl); > } finally { > cocoon.releaseComponent(toolBrokerInst); > } > } else { > print("CALLING SEND PAGE"); > cocoon.sendPage("selectATool"); > } > } > > function showFormForTool(userID, > toolName, > newWin, > showDataBench, > textUrl){ > > print("STARTED ShowFormForTool"); > ... > var form = new Form("cocoon:/" > +toolName+"-definition?inputType=" > +inputType+"&textTypes=" > +textTypes+"&showDataBench=" > +showDataBench); > > var textID = cocoon.session.getAttribute("textID"); > form.lookupWidget("resultWindow").setValue(true); > print("SHOWING FORM FROM ShowFormForTool"); > form.showForm(toolName+"-display?inputType=" > +inputType+"&addSourceText=" > +addSourceTextFlag+"&newWin="+newWin); > print("RETRUNED TO ShowFormForTool SUCCESSFULLY"); > ... > } > > ===================================================== > > It produces this output: > > ===================================================== > STARTED ToolBroker > CALLING SEND PAGE > STARTED ToolBroker > STARTED ShowFormForTool > SHOWING FORM FROM ShowFormForTool > ===================================================== > > Initially, when portal tab containing the coplet is displayed, first 2 > lines are printed: > > STARTED ToolBroker > CALLING SEND PAGE > > After that, when the session var's are set properly, the remaining 3 > lines are printed. However, at this point it doesn't matter what happens > inside of the coplet, nothing else gets printed (where there should be > "RETRUNED TO ShowFormForTool SUCCESSFULLY") on the console or changes in > the coplet. > > Logs don't show any errors or give any clues what can go wrong. > Additionally, the same version of the coplet works perfectly fine on > Cocoon 2.1.5. > > If there was anybody who had similar problems when upgrading, I would > appreciate it very much if you can share the solution or at least point > me in the right direction. > > Thank you very much in advance. > > Sincerely, > Nick Goupinets. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org > For additional commands, e-mail: users-help@cocoon.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org For additional commands, e-mail: users-help@cocoon.apache.org --------------060903060007030305060403--