cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From imran <ipariy...@triplemind.com>
Subject Re: Objects inherited in subrequests
Date Tue, 22 Jul 2008 00:03:45 GMT
Grzegorz Kossakowski wrote:
> Grzegorz Kossakowski pisze:
>>
>> It's not thread-specific but request-specific but here request means 
>> the one coming from browser and handled by servlet container and not 
>> those internal requests that Cocoon is doing when cocoon: or servlet: 
>> protocols are being used.
>>
>>> in the setup method of the generator class we replace the 
>>> objectmodel injected by spring with the one passed with that method 
>>> ... after doing this the errors are not that frequent .. but they 
>>> are still there :( .. its still being modified by some other threads 
>>> ...
>>>
>>>
>>> Could you please let us know how do u intend to implement ur 
>>> proposed solution
>>
>> The idea is to introduce a new implementation of a Spring scope that 
>> will work in a following way:
>> 1. if requested object (like OM) exists in current context then just 
>> return it
>> 2. if requested object does not yet exist in current context then 
>> find out if this context is derived from root one:
>>    a) if the context is derived then ask the root for the object, 
>> clone it and store cloned version in current context
>>    b) if the context is not derived one so itself is a root then just 
>> ask Spring to create a new instance of requested object and again 
>> store it in current context
>>
>> The introduction of new contexts should happen only in two cases:
>> 1. new thread is being invoked (for multi-thread scenarios)
>> 2. new internal request is being invoked (in case of using 
>> servlet/cocoon protocols)
>>
>>
>> Even if this may sound scary, the implementation of this idea should 
>> be very simple. It's only a few lines of code are needed to handle 
>> everything. Of course, the problem is where to inject this code.
>> Actually, today I was so busy with other work that I hadn't enough 
>> time to look into Cocoon itself but tomorrow I'll do so and give you 
>> more detailed instructions how to implement this.
>>
>> Hopefully, proposed solution should fix this problem once and for 
>> ever (at least I fail to imagine any situation when this wouldn't work)
>
> Imran, after taking a closer look at our code I can see that there are 
> little bit more issues that need to be fixed before I can fix this one.
>
> I guess it's going to be much easier if I take care of a whole work 
> because it's really non-trivial stuff and you really need to know all 
> the internals of Cocoon in order to properly fix the problem you have.
>
> Therefore I suggest that you provide me a simple application that 
> exhibits this problem so I can test my fixes and track the whole bug. 
> I suggest creation of two different scenarios where one will use 
> cocoon: protocol and another will use servlet: protocol.
>
> The most preferred way of providing me this test-cases would be to 
> prepare two ITs as it's done in
> http://svn.eu.apache.org/viewvc/cocoon/trunk/blocks/cocoon-it/
> http://svn.eu.apache.org/viewvc/cocoon/trunk/core/cocoon-webapp/src/test/java/org/apache/cocoon/it/

>
>
> In the first location you add sitemap entries and other resources that 
> you usually at to your block, and in the webapp you create a test-case 
> that tests expected behavior.
>
> As soon as you provide me such test-cases (as a patch in JIRA) I'll 
> start working on this problem.
>

Grzegorz, i have attached the testcase to the issue

https://issues.apache.org/jira/browse/COCOON-2216

i have attached three files .. test-block is the main block .. webapp is 
for running that block .. before that u will have to apply the patch 
cocoon-trunk.patch to cocoon other wise it wont work at all ...
for both the block perform mvn install .. and then from webapp block mvn 
jetty:run

so the page

http://localhost:8888/test-block/index.html

is generated using the parallel generator .. if ur lucky and dont get 
the error the first time then just refresh and am sure the error will be 
there .. there are five components included in that page ... out of 
which 4 are normal jx components and the fifth one is cforms component 
... all the jx component have been assigned different instance of the 
same object but still the properties displayed on the page shows the 
same value(they should be different) .. if u execute query for these 
components individually then they appear without any error .. links for 
querying them individually

[jx components .. shows xml output .. forgot to add the pipeline to 
serialize it to html.. u can add one]
http://localhost:8888/test-block/showjx
http://localhost:8888/test-block/showjx1
http://localhost:8888/test-block/showjx2
http://localhost:8888/test-block/showjx3

[cforms component]
http://localhost:8888/test-block/form2bean.flow

most of the time we get the error
Caused by: org.apache.commons.jxpath.JXPathException: No value for 
xpath: $cocoon/continuation/id
its because the objectmodel is being changed by all the components 
simultaneously ....the error is there on the logs not on the page .. on 
the page it will just ignore that component

u can change the line 427 in the class TestContentAggregator in the main 
block ... this.parameters.setParameter("parallel", "true");  change that 
to false and it will execute them in sequential and then the errors are 
gone ...

Would greatly appreciate it if you could have a look and try to resolve 
it ..

Thanks and regards

Imran


Mime
View raw message