Joerg Heinicke pisze:
If so performance loss would at the most two times slower.
What does this mean? This sentence makes no sense to me ;)
It was late here when writing this sentence. I meant:
if T is time needed for particular pipeline to execute without ScopeChanger, just ouf of reading
On 8/19/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote:
snip/
Same goes for all other SAX events. It's actually one extra get and two puts
calls on Map. Rather
lightweight, yes?
I don't really have time to dive into all the details of the
discussion, but Map calls themselves are not
Peter Hunsberger pisze:
On 8/19/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote:
snip/
Same goes for all other SAX events. It's actually one extra get and two puts
calls on Map. Rather
lightweight, yes?
I don't really have time to dive into all the details of the
discussion, but Map
Grzegorz Kossakowski pisze:
Hello,
Joerg Heinicke asked[1] me to provide summary of the issue that Daniel
raised[2] and outline
possible solutions so we can discuss them.
I think we should do the same for Object Model. I proposed[5] to create
new Spring scope (or reuse
sitemap scope that
On 19.08.2007 10:03 Uhr, Grzegorz Kossakowski wrote:
Same goes for all other SAX events. It's actually one extra get and two
puts calls on Map. Rather lightweight, yes?
But as you say it has to happen for EACH SAX event. I don't think it's
lightweight. It happens hundreds times even for
Grzegorz Kossakowski skrev:
[Snipping lots of technical details]
I want to create dynamic proxies around pipeline components. Actual
wrapping would be performed by class implementing BeanPostProcessor
interface. Taking one perspective one could say that this it's almost
the way as discussed
On 19.08.2007 16:30 Uhr, Daniel Fagerstrom wrote:
We could do something similar for sitemap components and
maybe go further and have convention based autoviring so e.g. a set
method that takes a ServletRequest automatically get the one from the
call injetcted.
No auto-wiring in Spring -
On 17.08.2007 2:45 Uhr, Grzegorz Kossakowski wrote:
Not entirely true. ObjectModel can be modified during component's
execution at random times, really. It happens all the time in template
generator where Object Model is passed almost everywhere and it depends
on incoming SAX events if OM
Joerg Heinicke pisze:
On 19.08.2007 10:03 Uhr, Grzegorz Kossakowski wrote:
Same goes for all other SAX events. It's actually one extra get and
two puts calls on Map. Rather lightweight, yes?
But as you say it has to happen for EACH SAX event. I don't think it's
lightweight. It happens
On 19.08.2007 18:12 Uhr, Grzegorz Kossakowski wrote:
But as you say it has to happen for EACH SAX event. I don't think it's
lightweight. It happens hundreds times even for simple HTML pages -
per component!
Correct me if I'm wrong but I thought that every pipeline component
handles (even if
Joerg Heinicke pisze:
On 14.08.2007 12:26 Uhr, Grzegorz Kossakowski wrote:
The problem is that Object Model is a signleton object (more
precisely, with call scope defined in cocoon-servlet-service-impl)
So the problem is not with internal pipelines at all since they are
scoped anyway? Or
On 14.08.2007 12:26 Uhr, Grzegorz Kossakowski wrote:
The problem is that Object Model is a signleton object (more precisely,
with call scope defined in cocoon-servlet-service-impl)
So the problem is not with internal pipelines at all since they are
scoped anyway? Or does this apply only for
We should first think of the intended behaviour and then think of the
implementation.
I would expect that the ObjectModel stays the same during one single
request which might end up to be served through a pipeline consisting of
several pipeline components.
If a sub request is started (internal
Carsten Ziegeler pisze:
We should first think of the intended behaviour and then think of the
implementation.
I would expect that the ObjectModel stays the same during one single
request which might end up to be served through a pipeline consisting of
several pipeline components.
If a sub
Hello,
Joerg Heinicke asked[1] me to provide summary of the issue that Daniel
raised[2] and outline
possible solutions so we can discuss them.
The problem is that Object Model is a signleton object (more precisely, with
call scope defined in
cocoon-servlet-service-impl) and is passed to the
15 matches
Mail list logo
