cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: Fortress Migration Strategy
Date Wed, 15 Oct 2003 13:41:03 GMT
Berin Loritsch wrote:
> Carsten Ziegeler wrote:
> > Berin Loritsch wrote:
> >
> > Yes, I think this is basically our extension together with the
> ParentAware
> > support.
> >
> > * ParentAware
> >   A selector (or any other component) can declare that it is
> ParentAware,
> > which
> > means if you have a hierarchy of component managers and a component is
> > looked up
> > in a child CM it get's a reference to a component looked up in
> the parent
> > CM.
> > This is useful for nested selector e.g.
> Please elaborate a bit more.  First, what problem does ParentAware solve,
> and why can't it be done with normal component resolution semantics?

When you have a hierarchy of component managers (I still call them
component managers :) ), and you lookup a selector on the child CM
and then try to lookup a component using a hint that is not defined
in this selector but in a selector with the same role defined at
the parent CM, then the selector of the child CM can forward the
lookup to the parent one.
Actually this is used in Cocoon for all sitemap components resp.
for the selectors for these components. So a selector for a generator
in a sub sitemap gets via ParentAware a handler (locator) to get
the selector defined in the parent sitemap.

> >>I believe I can solve these in the following manner:
> >>
> >>Request Scoped Components:  Create a new lifestyle handler for Fortress.
> >
> >
> > Yes, should work, but we currently have this in two flavors:
> > The RequestLifeCycleComponent and the GlobalRequestLifeCycleComponent.
> > The GlobalRequestLifeCycleComponent is one instance per global request
> > comming
> > into Cocoon. Even if this request creates sub requests (using the
> > cocoon protocol), it's still one instance.
> > The RequestLifeCycleComponent is oen instance per request. So, each
> > internal request gets its own set of RequestLifeCycleComponents.
> > Example:
> > a) main request looks up a component of role A
> > b) main request invokes sub request (cocoon protocol)
> > c) sub request looks up a component of role A
> > d) main request looks up a component of role A again
> >
> > I) The component is a GlobalRequestLifecycleComponent
> > a) main request gets instance ONE
> > c) sub request gets instance ONE
> > d) main request gets instance ONE
> >
> > II) The component is a RequestLifecycleCOmponent
> > a) main request gets instance ONE
> > c) sub request gets instance TWO
> > d) main request gets instance ONE
> Help me to understand the need for the difference a bit better.
> Am I correct
> in thinking that this is largely a performance type of
> "enhancement", or was
> there a technical issue driving this solution?
Yes, basically. The typical use case is that you have *data*
the component works on that is tied to the current request
(or subrequest). So the usual way would be to use a poolable
component and tie the data to the request.
But this is bad for performance, because if e.g. this component
is looked up at three different places, you get three
instances and each component has to do a lookup in the
request attributes to get the data.

> I am happy to help make this a possibility, but in many ways what
> we have in
> the "CocoonComponentManager", the use of statics is scary.  With
> those things
> you have to ensure proper synchronization, which can in turn reduce the
> scalability of Cocoon.
Yes, agreed. I'm trying to get rid off these statics but haven't found
a way yet. If we somehow can manage this, I'm absolutely happy!

> It would be easy enough to support a Request lifestyle by binding
> the component
> to the HTTP request being serviced at the time.  That solution
> would generally
> be a GlobalRequest lifestyle.

> The distinction between the two
> makes me think
> that the request lifestyle might be better served by other means.
> Fortress and Merlin both have a PerThread lifestyle, which can
> also satisfy the global request.

> If each sub-request has its own "request context", then we can convert the
> Global Request to a PerThread type of component.
Yes, each sub request has an own "request context", so yes this could work.

But what happens if I process one request with multiple threads?
We have, e.g. content aggregation that can be processed to some
extend in parallel. Now, you want to have the same components for
both threads as this is the same request. Is this possible?

> However, things will break down when someone comes out with a
> Servlet container
> that can handle multiple requests in one thread, and the
> component in question
> has a particular order imposed for method calls (i.e. SAX content
> handler style
> components).
> Help me to understand the issue so that my "quick and dirty" can
> be turned into
> something that scales better.

Yes, that would be great - now, basically I really hope that we
can loose all the static things and make a cleaner approach. But
currently I see no way for the request lifecycle component, but
perhaps it is?

> >>SourceResolver specifics:  I need some input on how exactly you
> >>are extending
> >>                            this.  I might be able to handle it with an
> >>                            Accessor lifecycle extension.
> >
> > The SourceResolver component uses a base directory to resolve relative
> > URIs.
> > The SourceResolver in Cocoon always resolves relative URIs to the
> > current sitemap, so during the processing of a request this information
> > changes. But the component itself is e.g. looked up at the
> initialization
> > phase of the action etc.
> I see.  So if we have each mounted Sitemap/Block being encapsulated in a
> sub-container, we can have a new SourceResolver per container....
>  Of course,
> the ServiceManager supplied to a component will only be for the
> container that
> set up the component.  That won't work reliably.

Hmmm, no it won't work. Here is one problem:

Imagine a thread safe component that has a service method
that gets in a uri as a string and is used from various
Now this thread safe component looks up a source resolver
on initialization, but it should resolve the uri provided
from a client of this component look up relative to the
sitemap the client was looked up.


View raw message