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