You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Nick Goupinets <ng...@openskysolutions.ca> on 2005/07/20 19:01:17 UTC
[Portal] Cocon 2.1.7 upgrade breaks CachingURICoplets
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
Re: [Portal] Cocon 2.1.7 upgrade breaks CachingURICoplets
Posted by Nick Goupinets <ng...@openskysolutions.ca>.
Hi Jean-Christophe,
Thank you very much for your reply. The thread, link to which you
included, solves the problem completely.
Sincerely,
Nick.
Jean-Christophe Kermagoret wrote:
> I have the following in my forms in the cocoon portal :
> <form action="portal" ...>
> <input type="hidden" name="cocoon-portal-event" value="19">
> <input type="hidden" name="cocoon-portal-action" value="1">
>
> cocoon-portal-event and cocoon-portal-action are hidden fields, not a
> query string that seems to be ignored.
>
> I followed this code snippet :
> http://www.mail-archive.com/users@cocoon.apache.org/msg24454.html
>
> HTH
>
> Nick Goupinets a écrit :
>
>> 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:
>> =============================================================
>> <form enctype="multipart/form-data" name="toolBrokerForm"
>> method="post" onsubmit="forms_onsubmit(); "
>> action="portal?cocoon-portal-action=5&cocoon-portal-event=8">
>> <div>
>> <input name="forms_submit_id" type="hidden">
>> </div>
>> ....
>> =============================================================
>>
>> 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
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [Portal] Cocon 2.1.7 upgrade breaks CachingURICoplets
Posted by Jean-Christophe Kermagoret <jc...@babelobjects.com>.
I have the following in my forms in the cocoon portal :
<form action="portal" ...>
<input type="hidden" name="cocoon-portal-event" value="19">
<input type="hidden" name="cocoon-portal-action" value="1">
cocoon-portal-event and cocoon-portal-action are hidden fields, not a
query string that seems to be ignored.
I followed this code snippet :
http://www.mail-archive.com/users@cocoon.apache.org/msg24454.html
HTH
Nick Goupinets a écrit :
> 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:
> =============================================================
> <form enctype="multipart/form-data" name="toolBrokerForm" method="post"
> onsubmit="forms_onsubmit(); "
> action="portal?cocoon-portal-action=5&cocoon-portal-event=8">
> <div>
> <input name="forms_submit_id" type="hidden">
> </div>
> ....
> =============================================================
>
> 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
>
--
Jean-Christophe Kermagoret
jck@BabelObjects.Com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [Portal] Cocon 2.1.7 upgrade breaks CachingURICoplets
Posted by Nick Goupinets <ng...@openskysolutions.ca>.
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:
=============================================================
<form enctype="multipart/form-data" name="toolBrokerForm" method="post"
onsubmit="forms_onsubmit(); "
action="portal?cocoon-portal-action=5&cocoon-portal-event=8">
<div>
<input name="forms_submit_id" type="hidden">
</div>
....
=============================================================
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