cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: Objects inherited in subrequests
Date Fri, 18 Jul 2008 12:27:17 GMT
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.

-- 
Best regards,
Grzegorz Kossakowski

Mime
View raw message