cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Fortress Migration Strategy
Date Wed, 15 Oct 2003 13:19:45 GMT
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?


>>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?

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.

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.

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.

>>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.

We might have to set up a SourceResolver with a hint for each mounted sitemap.
That way, when a sitemap looks up the SourceResolver it would look it up with
the hint for the path to the mount point.  The relative URI can then be
established for that.

Hmm.  I'll need to think on that a little more.  I will probably have to
leverage the hacks in the CocoonComponentManager for the time being.



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


Mime
View raw message