cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: [BUG ?] "ModuleHelper is not setup correctly"
Date Sat, 07 Feb 2004 13:39:01 GMT
Luca Morandini wrote:
> Andreas Hartmann wrote:
> 
>> Andreas Hartmann wrote:
>>
>>> OK, I narrowed down the problem. The XSPGenerator object is not
>>> re-created when the page is requested the second time. So, the
>>> XSPModuleHelper isn't re-initialized. Because its input modules
>>> were released at the end of the previous generate() execution,
>>> the inputModules map is null and the exception is thrown.
>>>
>>
>> BTW, as a workaround you can add
>>
>>   <xsp:logic>
>>     _xsp_module_helper = null;
>>   </xsp:logic>
>>
>> at the bottom of your logicsheet.
>> This way, the module helper is initialized the second
>> time generate() is called.

I tracked the problem down to a refactoring that took place apparently 
before 2.1.3, so this was broken in that release IIUC.

Basically, the XSPModuleHelper was changed so that it assumed it needed 
to be setup() again before each use.  Probably the right assumption, but 
does not appear to have been assumed before and input.xsl was not 
changed accordingly.  Because there is no sample using input.xsl, this 
was only noticed by people who use the input module logicsheet and 
attempted to use 2.1.3.

The following simple patch fixes the problem:

Index: input.xsl
===================================================================
RCS file: 
/home/cvs//cocoon-2.1/src/java/org/apache/cocoon/components/language/markup/xsp/java/input.xsl,v
retrieving revision 1.1
diff -u -r1.1 input.xsl
--- input.xsl	9 Mar 2003 00:08:56 -0000	1.1
+++ input.xsl	7 Feb 2004 13:29:12 -0000
@@ -79,8 +79,8 @@
          // create module cache
          if (this._xsp_module_helper == null) {
             this._xsp_module_helper = new XSPModuleHelper();
-           this._xsp_module_helper.setup(manager);
          }
+        this._xsp_module_helper.setup(manager);
        </xsp:init-page>

        <xsp:exit-page>

I can commit this change for 2.1.4 release (thursday) but would like 
Carsten to confirm this is what should happen since he's the one that 
refactored the module helper.

Geoff

> I explored another workaround, by substituting:
> <input:get-attribute ../>
> with:
> <util:get-sitemap-parameter .../>
> 
> Of course I have to pass parameters via sitemap to the XSP... which has 
> taken me a while to do, but the result was cleaner (I know which 
> parameters are used by an XSP just by looking at the sitemap); hence, 
> I'm moderately happy with the outcome
> 
> Anyway, this is a bug... who's going to add it to bugzilla, me or you ?

I don't have time right now, but it would be good if this was officially
entered in bugzilla so the record is there, and so it doesn't get lost.

Geoff


Mime
View raw message