avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Component Sharing
Date Tue, 17 Sep 2002 21:20:54 GMT
On Wed, 18 Sep 2002 02:28, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Tue, 17 Sep 2002 00:10, Berin Loritsch wrote:
> > > > + per-application
> > >
> > > Unless the component is in the root container, that should be
> > > "per-container".
> >
> > Kool - I was thinking of having a "per-partition"but I could not find any
> > examples of it in practice. For sub sitemaps, does Cocoon reuse parents
> > "ThreadSafe" components or recreate its' own?
> It uses the Parent ComponentManager pattern set forth in Framework.
> A ComponentManager will check its parent if it cannot resolve the
> component.  Now, I have screwed with the ComponentSelector patterns a
> bit in that they also delegate back to the parent.  It was the only way
> to have sub sitemaps reuse selector hint mappings.

Right. Thats what I thought which is why I was reluctent to add in 
per-partition. I want to see some sort of example of per-partition in use 
before we add it is an option.

> > per-access means that everytime you do a lookup() you get a new instance.
> > Where per-request means anyytime you do a lookup in same "Component
> > Transaction" you get the same component.
> Ok.  So "per-transaction" would be better terminology.  


> The problem with
> the transaction access layer is that it is an application specific
> concept.  Not all applications have a concept of a transaction.  If we
> consider "per-transaction" we would also have to consider "per-session".

hadn't though of that ... I guess so. Unless we support "nested" transactions 
in which case session would just be a long running transaction .... then 
again thats a kinda goofy model ;)

> Maybe that is something that needs to be thought out better.  Do we want
> to represent application access points to be valid Avalon concepts>  If
> so, how do we represent this in code with a generic enough
> implementation?  What is more important is how do we determine when each
> of those scopes are finished?  Unless we pass in some artifact like a
> Transaction/Context object, we will have no way of knowing in a
> framework level way when we have reached the boundaries of application
> specific access points.

Yep - it ends up being container specific when the transaction scopes are 
applied and client code can't control it directly (at least not in container 
independent way). Still it would be useful enough in places like Cocoon and 
other request based systems that we should at least experiment with it ;)

> > Two things. It means we can "assemble" lifestyle out of more primitive
> > tags. This will make it sooo much easier to extend this in the future.
> > And yes - I have a very practical reason in mind.
> >
> :)  I'm curious now.
> I guess I have to review all the M$ docs on attribute driven programming?

Naah. This will use that attribute driven programming to provide the metadata 
but it is not necessary to look into that. I am not sure if there is any 
Interceptor 101 docs about - anyone else? Until then you can probably follow 
the link I sent and it should allow give at least a basic idea on the 
"invoke" style Interceptors.

> > Those ideas I was trying to figure out in containerkit (and previously in
> > atlantis/camelot) are all WRONG WRONG WRONG. I have seen a very very very
> > nice future and it is when everything is written using interceptors.
> They do provide a starting point.  


atlantis/camelot went the "framework" approach where you had to extend the 
classes to make them useful. This sucked - was too inflexible and too much 

containerkit went the "component" approach where you use components are wire 
them together. Better than above but still too much damn work and too 

The next generation follows the "aspect" approach, allows easy assembly of 
containers. Makes it easy to customize your own extentions (Maybe even too 
easy) to do what you want to do. And if written well enough will be able to 
integrate into existing containers with 0 side-effects.

> The fact that they are "rigid" makes
> it easier for people to grasp what they do.  I want to be careful that
> we don't go too far down a path that will cause us issues in maintenance
> and evangelism later.  When I have a light bulb go off, I will probably
> support you 100%.  We also have to consider what are we going to do
> right now.

It wont be done now but it will be done in next month or two - hopefully that 
will be enough to convince you ;)

> > That way you want to extend/change the container then it is simple as
> > 1-2-3, A-B-C. For example if you wanted to write an lifestyle that said
> > "I pool between times 3-5 each day and recreate all other times" that
> > would be near impossible with all the current containers. With this new
> > architecture all you need do is create a new interceptor, update the
> > container config and bang! you are done.
> >
> > Interceptors are the future. For my initial thoughts on them see
> You are looking at Interceptors to replace the experimental Extensions?

sorta. Where Extensions "extend" the lifecycle in some way, Interceptors will 
*be* the lifecycle. (Or at least the Access/Release chains can be). 

Interceptors can also do runtime stuff like log each method call on a 
particular service interface or whatever.


Peter Donald
Why does everyone always overgeneralize?

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message