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
