On Aug 26, 2008, at 3:59 AM, Thorsten Scherler wrote:
On Mon, 2008-08-25 at 20:23 -0400, Vadim Gritsenko wrote:
On Aug 25, 2008, at 6:40 AM, Thorsten Scherler wrote:
...
Yes, ObjectModelHelper.REQUEST_OBJECT object is always unique. It is
actually unique in any environment. And since it is
On Thu, 2008-08-28 at 07:44 -0400, Vadim Gritsenko wrote:
On Aug 26, 2008, at 3:59 AM, Thorsten Scherler wrote:
On Mon, 2008-08-25 at 20:23 -0400, Vadim Gritsenko wrote:
On Aug 25, 2008, at 6:40 AM, Thorsten Scherler wrote:
...
Yes, ObjectModelHelper.REQUEST_OBJECT object is always
On Mon, 2008-08-25 at 20:23 -0400, Vadim Gritsenko wrote:
On Aug 25, 2008, at 6:40 AM, Thorsten Scherler wrote:
...
Yes, ObjectModelHelper.REQUEST_OBJECT object is always unique. It is
actually unique in any environment. And since it is unique, it does
not make sense to lock on it at all -
On Fri, 2008-08-22 at 10:34 -0400, Vadim Gritsenko wrote:
On Aug 22, 2008, at 8:57 AM, Thorsten Scherler wrote:
On Fri, 2008-08-22 at 08:18 -0400, Vadim Gritsenko wrote:
On Aug 22, 2008, at 3:35 AM, Thorsten Scherler wrote:
How about:
} else {
-
On Aug 22, 2008, at 11:26 AM, Rainer Pruy wrote:
Hi,
sorry for intruding this discussion.
Not intruding at all :)
just from what I can take from this discussion:
Wouldn't it be easier to enclose this into a generalized Environment
implementation
that does support
On Aug 25, 2008, at 6:40 AM, Thorsten Scherler wrote:
On Fri, 2008-08-22 at 10:34 -0400, Vadim Gritsenko wrote:
On Aug 22, 2008, at 8:57 AM, Thorsten Scherler wrote:
So which object you would suggest to lock?
You wrote Suitable alternative would be to lock against top most
command line
On Thu, 2008-08-21 at 19:40 -0400, Vadim Gritsenko wrote:
On Aug 21, 2008, at 8:18 AM, Thorsten Scherler wrote:
still updating forrest to use cocoon-2.1.x and I found a problem in
the
AbstractCachingProcessingPipeline.
I am not sure whether someone is using the cocoon cli ATM.
On Fri, 2008-08-22 at 09:35 +0200, Thorsten Scherler wrote:
On Thu, 2008-08-21 at 19:40 -0400, Vadim Gritsenko wrote:
On Aug 21, 2008, at 8:18 AM, Thorsten Scherler wrote:
still updating forrest to use cocoon-2.1.x and I found a problem in
the
AbstractCachingProcessingPipeline.
On Aug 22, 2008, at 3:35 AM, Thorsten Scherler wrote:
How about:
} else {
-Object lock =
env.getObjectModel().get(HttpEnvironment.HTTP_REQUEST_OBJECT);
+Object lock =
env.getObjectModel().get(ObjectModelHelper.REQUEST_OBJECT);
On Fri, 2008-08-22 at 08:18 -0400, Vadim Gritsenko wrote:
On Aug 22, 2008, at 3:35 AM, Thorsten Scherler wrote:
How about:
} else {
-Object lock =
env.getObjectModel().get(HttpEnvironment.HTTP_REQUEST_OBJECT);
+Object lock =
On Aug 22, 2008, at 8:57 AM, Thorsten Scherler wrote:
On Fri, 2008-08-22 at 08:18 -0400, Vadim Gritsenko wrote:
On Aug 22, 2008, at 3:35 AM, Thorsten Scherler wrote:
How about:
} else {
-Object lock =
Hi,
sorry for intruding this discussion.
just from what I can take from this discussion:
Wouldn't it be easier to enclose this into a generalized Environment
implementation
that does support Environment.getTopRequest() and is stored with ObjectModel in
place of those different
Hi all,
still updating forrest to use cocoon-2.1.x and I found a problem in the
AbstractCachingProcessingPipeline.
I am not sure whether someone is using the cocoon cli ATM. Forrest is
based around this component.
On Aug 21, 2008, at 8:18 AM, Thorsten Scherler wrote:
still updating forrest to use cocoon-2.1.x and I found a problem in
the
AbstractCachingProcessingPipeline.
I am not sure whether someone is using the cocoon cli ATM. Forrest is
based around this component.
14 matches
Mail list logo
