Re: Fortress Migration Strategy

2003-10-16 Thread Berin Loritsch
Stefano Mazzocchi wrote: Question out of simple curiosity and/or ignorance: is the instrumentation JMX aware? No, it uses the Avalon instrumentation package. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Ben

Re: Fortress Migration Strategy

2003-10-16 Thread Stephen McConnell
Carsten Ziegeler wrote: Stephen McConnell wrote: 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 th

Re: Fortress Migration Strategy

2003-10-16 Thread Stefano Mazzocchi
On Thursday, Oct 16, 2003, at 16:29 Europe/Rome, Berin Loritsch wrote: Berin Loritsch wrote: The core reason for this approach was a performance/resource issue. With a pooled component, we run into the problem of having several copies of this component for the same request for some reason. In

Re: Fortress Migration Strategy

2003-10-16 Thread Stephen McConnell
Leo Sutic wrote: From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] So in this sax streaming we have a class called EnvironmentChanger that takes care that the current collection used is the correct one. So if the sub request sends an event to the main request, a pointer is set pointing to

Re: Fortress Migration Strategy

2003-10-16 Thread Berin Loritsch
Berin Loritsch wrote: The core reason for this approach was a performance/resource issue. With a pooled component, we run into the problem of having several copies of this component for the same request for some reason. In some ways this is unavoidable. However the overhead of looking it up and

Re: Fortress Migration Strategy

2003-10-16 Thread Berin Loritsch
Stephen McConnell wrote: 1. Cocoon defines this as a service (i.e. a SessionThingFactory dependency), or 2. Avalon defines a standard "custom" lifestyle policy tag in the avalon-meta package (and the coresponding backend) Any other solution will result in the specialization of Fortress for Co

RE: Fortress Migration Strategy

2003-10-16 Thread Leo Sutic
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > > > Could this not be realized via interceptors? > > > What do you mean by this? > > Ususally A would stream directly to B, with the changer > A streams to the changer and this streams to B. An interceptor is the general form of a changer.

RE: Fortress Migration Strategy

2003-10-16 Thread Carsten Ziegeler
Stephen McConnell wrote: > >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 define

RE: Fortress Migration Strategy

2003-10-16 Thread Carsten Ziegeler
Leo Sutic wrote: > > > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > > > > So in this sax streaming we have a class called > > EnvironmentChanger that takes care that the current collection > > used is the correct one. > > So if the sub request sends an event to the main request, >

RE: Fortress Migration Strategy

2003-10-16 Thread Leo Sutic
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > > So in this sax streaming we have a class called > EnvironmentChanger that takes care that the current collection > used is the correct one. > So if the sub request sends an event to the main request, > a pointer is set pointing to t

RE: Fortress Migration Strategy

2003-10-16 Thread Carsten Ziegeler
Stephen McConnell wrote: > Some questions: > > 1. Based on the current implementation - how do you declare a > ParentAware strategy? It's a marker interface. > 2. How do you seperate functional service dependency from the > implementation aware hierarchy solution? The ParentAware interface defines

RE: Fortress Migration Strategy

2003-10-16 Thread Carsten Ziegeler
Leo Sutic wrote: > > Stephen, Berin, > > I think Cocoon uses a stack-based scheme that can be implemented by the > container, > although it can't be exposed to those that only see the > Component/ServiceManager > interface. > > This is pretty much how it works: > > 1. Define a method called be

RE: Fortress Migration Strategy

2003-10-15 Thread Leo Sutic
oktober 2003 04:57 > To: [EMAIL PROTECTED] > Subject: Re: Fortress Migration Strategy > > > > > Carsten Ziegeler wrote: > > >Berin Loritsch wrote: > > > > > >>Carsten Ziegeler wrote: > >> > >> > >> >

Re: Fortress Migration Strategy

2003-10-15 Thread Stephen McConnell
Carsten Ziegeler wrote: 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,

Re: Fortress Migration Strategy

2003-10-15 Thread Stephen McConnell
Carsten Ziegeler wrote: Berin Loritsch wrote: Initial comments about CocoonComponentManager--to make sure I don't forget anything it is currently doing: The CocoonComponentManager handles several aspects including: * Request scoped components * Source Resolver specifics for a processor/reque

Re: Fortress Migration Strategy

2003-10-15 Thread Stephen McConnell
Berin Loritsch wrote: Stephen McConnell wrote: Berin: A couple, of notes in-line... Berin Loritsch wrote: Request Scoped Components: Create a new lifestyle handler for Fortress. Is this equivalent to the creation of a new component instance for each invocation against the service manage

RE: Fortress Migration Strategy

2003-10-15 Thread Carsten Ziegeler
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 i

Re: Fortress Migration Strategy

2003-10-15 Thread Berin Loritsch
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 lo

Re: Fortress Migration Strategy

2003-10-15 Thread Berin Loritsch
Stephen McConnell wrote: Berin: A couple, of notes in-line... Berin Loritsch wrote: Request Scoped Components: Create a new lifestyle handler for Fortress. Is this equivalent to the creation of a new component instance for each invocation against the service manager? No, this is having one

RE: Fortress Migration Strategy

2003-10-15 Thread Carsten Ziegeler
Berin Loritsch wrote: > > Initial comments about CocoonComponentManager--to make sure I don't forget > anything it is currently doing: > > The CocoonComponentManager handles several aspects including: > > * Request scoped components > * Source Resolver specifics for a processor/request > * SitemapC

Re: Fortress Migration Strategy

2003-10-14 Thread Stephen McConnell
Berin: A couple, of notes in-line... Berin Loritsch wrote: Request Scoped Components: Create a new lifestyle handler for Fortress. Is this equivalent to the creation of a new component instance for each invocation against the service manager? Steve. -- Stephen J. McConnell mailto:[EMAIL P

Re: Fortress Migration Strategy

2003-10-14 Thread Berin Loritsch
Initial comments about CocoonComponentManager--to make sure I don't forget anything it is currently doing: The CocoonComponentManager handles several aspects including: * Request scoped components * Source Resolver specifics for a processor/request * SitemapConfigurable components I believe I can

Fortress Migration Strategy

2003-10-14 Thread Berin Loritsch
I have the Cocoon 2.2 repository checked out now, and I have printed out all the code for the Cocoon processor and the CocoonComponentManager and ExtendedServiceSelector, and all the other classes in the org.apache.cocoon.components package (not all the child packages though). I am going to look o