Re: Objects inherited in subrequests

[imran <ip...@triplemind.com>]

imran wrote:
> 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
>
>
Hi Grzegorz,

Any luck with the implementation of the objectmodel for the new scope .. 
were u able to execute the sample application i provided if yes then 
were u able to reproduce the error ? .. please do let me know .. if you 
are busy with something else then can you please point me to the right 
direction with basic idea of how to implement a new objectmodel which is 
thread specific ..

thanks and regards