You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Luca Morandini <lu...@tin.it> on 2004/02/05 00:18:25 UTC
[BUG ?] "ModuleHelper is not setup correctly"
Today I tried to switch from 2.1.2 to 2.1.3.
After the compilation and installation, I fired up an application of
mine (which worked perfectly under 2.1.2)... which seemed to work still
fine, but... when I re-loaded the same URI, Cocoon gave me an "Internal
server error" and the following on error.log:
(2004-02-04) 23:08.23:045 : Internal Cocoon Problem
org.apache.cocoon.ProcessingException: Exception in
ServerPagesGenerator.generate(): java.lang.RuntimeException:
ModuleHelper is not setup correctly.
at
org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGenerator.java:274)
...
Caused by: java.lang.RuntimeException: ModuleHelper is not setup correctly.
at
org.apache.cocoon.components.language.markup.xsp.XSPModuleHelper.getInputModule(XSPModuleHelper.java:105)
at
org.apache.cocoon.components.language.markup.xsp.XSPModuleHelper.get(XSPModuleHelper.java:152)
at
org.apache.cocoon.components.language.markup.xsp.XSPModuleHelper.getAttribute(XSPModuleHelper.java:233)
at
org.apache.cocoon.components.language.markup.xsp.XSPModuleHelper.getAttribute(XSPModuleHelper.java:244)
at
org.apache.cocoon.www.file_.c_.web.noria.noriadev.xsp.presentation.locate_index_html_xsp.generate(org.apache.cocoon.www.file_.c_.web.noria.noriadev.xsp.presentation.locate_index_html_xsp:123)
at
org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGenerator.java:262)
This behaviour is consistent: when I re-start the Servlet container
(Jetty), first time the app works (I mean, the page is loaded
correctly), second time (and subsequent) it crashes.
Could someone shed some light on this ?
Regards,
---------------------------
Luca Morandini
lmorandini@ieee.org
http://www.lucamorandini.it
---------------------------
Re: [BUG ?] "ModuleHelper is not setup correctly"
Posted by Andreas Hartmann <an...@apache.org>.
Geoff Howard wrote:
> Luca Morandini wrote:
>
>> Geoff Howard wrote:
>>
>>> 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.
>>
>>
>>
>> I've added it as bug bug #26754. Thanks for your reply :)
>>
>
> fixed now in cvs - will be in 2.1.4 release.
Great - and thanks again for your support on IRC!
-- Andreas
Re: [BUG ?] "ModuleHelper is not setup correctly"
Posted by Geoff Howard <co...@leverageweb.com>.
Luca Morandini wrote:
> Geoff Howard wrote:
>
>> 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.
>
>
> I've added it as bug bug #26754. Thanks for your reply :)
>
fixed now in cvs - will be in 2.1.4 release.
Geoff
Re: [BUG ?] "ModuleHelper is not setup correctly"
Posted by Luca Morandini <lu...@tin.it>.
Geoff Howard wrote:
> 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.
I've added it as bug bug #26754. Thanks for your reply :)
Regards,
---------------------------
Luca Morandini
lmorandini@ieee.org
http://www.lucamorandini.it
---------------------------
Re: [BUG ?] "ModuleHelper is not setup correctly"
Posted by Geoff Howard <co...@leverageweb.com>.
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
Re: [BUG ?] "ModuleHelper is not setup correctly"
Posted by Luca Morandini <lu...@tin.it>.
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.
Thanks a lot.
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 ?
Regards,
---------------------------
Luca Morandini
lmorandini@ieee.org
http://www.lucamorandini.it
---------------------------
Re: [BUG ?] "ModuleHelper is not setup correctly"
Posted by Andreas Hartmann <an...@apache.org>.
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.
-- Andreas
Re: [BUG ?] "ModuleHelper is not setup correctly"
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann wrote:
> Luca Morandini wrote:
>
>> Today I tried to switch from 2.1.2 to 2.1.3.
>>
>> After the compilation and installation, I fired up an application of
>> mine (which worked perfectly under 2.1.2)... which seemed to work
>> still fine, but... when I re-loaded the same URI, Cocoon gave me an
>> "Internal server error" and the following on error.log:
>
>
> I get the same error (upgraded from 2.1.2 to 2.1.4-dev).
> Did you already find a solution?
>
> It seems to be related to the XSPGenerator and the input.xsl
> logicsheet.
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.
input.xsl logicsheet:
<xsp:init-page>
// create module cache
[when the page is requested the second time, this is not
executed because the module helper is not null]
if (this._xsp_module_helper == null) {
this._xsp_module_helper = new XSPModuleHelper();
this._xsp_module_helper.setup(manager);
}
</xsp:init-page>
<xsp:exit-page>
// clear module cache
if (this._xsp_module_helper != null)
this._xsp_module_helper.releaseAll();
</xsp:exit-page>
Why is the generator object not re-created?
Thanks in advance!
-- Andreas
Re: [BUG ?] "ModuleHelper is not setup correctly"
Posted by Andreas Hartmann <an...@apache.org>.
Luca Morandini wrote:
> Today I tried to switch from 2.1.2 to 2.1.3.
>
> After the compilation and installation, I fired up an application of
> mine (which worked perfectly under 2.1.2)... which seemed to work still
> fine, but... when I re-loaded the same URI, Cocoon gave me an "Internal
> server error" and the following on error.log:
I get the same error (upgraded from 2.1.2 to 2.1.4-dev).
Did you already find a solution?
It seems to be related to the XSPGenerator and the input.xsl
logicsheet.
-- Andreas