cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: svn commit: r552371 - trunk broken, help needed
Date Mon, 02 Jul 2007 11:35:34 GMT
Grzegorz Kossakowski wrote:
> pisze:
>> Author: gkossakowski
>> Date: Sun Jul  1 16:13:44 2007
>> New Revision: 552371
>> URL:
>> Log:
>> COCOON-2082: Getting rid of Avalon dependencies, it includes:
>> * conversion JS, JXPath and JEXL compilers to Spring beans
>> * conversion DefaultExpressionFactory to Spring bean, it collects 
>> language compilers by using bean-map from Spring configurator
> As you see, I'm in between of Avalon->Spring conversion process for 
> expression languages. I have not moved and adjusted tests (thus build 
> will fail) because I came across very obscure problem.
> First of all I would like you to ask to do svn up and mvn clean install 
> -Dmaven.test.skip=true for trunk, run cocoon-webapp, access 
> http://localhost:8888/blocks/cocoon-template-sample/view/caching2
> and check if you get following error:
> TypeError: Cannot read property "parameters" from undefined (#1)

AFAICS the problem is that we want to support the syntax

to access request parameters. For some reason this isn't supported anymore after 
your refactorings though I can't see from your commits where this could be 
caused. (Well actually I don't have an idea where this feature is implemented at 

> I would be grateful for any reports to be sure if it's not a JDK issue 
> or so. Also, any help with sorting this out is really appreciated 
> because I'm really out of ideas how to track such a weird problem. 
> Details below.
> After conversion (changes in r552371) ExpressionContext creation is 
> slightly broken. Take a look at 
> TemplateObjectModelHelper#getTemplateObjectModel method, the most 
> interesting fragment is line:
> cocoon.put("settings", 
> (Settings)WebAppContextUtils.getCurrentWebApplicationContext().getBean(Settings.ROLE));

> Cocoon object is normal Java's HashMap, so it seems that there should 
> happen nothing fancy. As you guess, something weird happens, though ;)
> More specifically, this put breaks completely cocoon object. Inspection 
> in debugger of this object shows that before put operation mentioned 
> above everything looks ok and just after keys of HashMap are getting out 
> of sync of values (table). In a fact, the table of values contains 3 
> items (and is lacking request object, that explains an exception) and 
> keySet contains 4 items (including request). Moreover, if I change key 
> from "settings" to something else like "test", cocoon object is less 
> broken (table includes request) but if you iterate the cocoon object you 
> will never reach the request object.

 From using the debugger I came to the conclustion that the cocoon object is 
setup correctly (at least for me). I don't see this weird behaviour.

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


View raw message