avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: lifecycle questions
Date Thu, 13 Mar 2003 13:20:58 GMT

Jakob Praher wrote:

>hi all,
>I have followed the last lifecycle thread, and as I am very interested
>in these topics, have thought about it:
>I view the Creator and Accessor interfaces in the lifecycle package as
>contracts between a Lifecycle extension implementator and the container.


>In this sense a lifecycle extension, like for instance a Transaction
>lifecycle manager, registers itself with the container, to get notified
>when certain components are created/distroyed and accessed/released


>What it lacks is the interception of calls from the client to the
>component, since, once the reference is out of the container, the
>container can't control the use (except in an micro kernel design, but
>that is suboptimial here).

I personally don't see this as a problem. The lifecycle
interface deal with the defintion of the contract for an extension
implementation under the creation and access phases. The subject
of both of these phases is a component implementation and the
relationship between the container and extensions introduced into
the containement environment. Things like interception of method
invocations is a seperate subject. For example, I use the
extensions to implement aspects of a system that are related to
deployment - I use interceptors for things like principal identity
propergation and establishment. The issues dealt with are quite

>So the notion of a call interceptor get's introduced, the client get's a
>proxy back that intercepts the method call and does some extra magic. 

Yes - possible (but in my opinion its orthoginal to the container
extension architecture).

>To support proxies, as Leo pointed out, one could change the interface
>void created( Object object, Context context )
>Object created( Object object, Context context )

I'm still wondering about this. Guess I need to talk some more to Leo.
Suffice to say that I'm not convinced of the need for proxies during the
container side management phases. I have the impression that there is
mixup of concerns - lifecycle extensions are dealing with extension to
the deployment lifecycle which is a container concern unrelated to
extensions dealing with an invocation against a service.

>but what I am missing here is how to state which kind of aspect the
>object supports, for isntance, take the example of a componetn
>configuration with a "standardized" transaction support:
><component class="..." role="..." >
>   <ts:transaction-supported>auto</ts:transaction-supprted>
>if you change the Method and add a configuration instance, or something
>like that, it would be much more interesting:
>Object created( Obejct object, Context context, Configuration config ) ;
>so you can transparently use a proxy to implement the invocation handler
>and *know* which kind of transaction logic should be used.
>(naive question: is this the kind of transaction demarcation support
>Peter asked?)

Honestly I don't know what the Fortress implementation approach is to
configuration of a extension handler - however, I can explain why this
is not needed within Merlin. In the Merlin environment an extension
handler is a component and as such, it configured during its deployment.
Any supplementary information can be supplied to the handler using the
existing signature via the context argument.

>I hope I have explained my ideas understandable, and bear with me since
>I am currently trying to get a handle on all of the AOP, Call
>interception things. As Leo pointed out the implementation of AOP in
>Java using bytecode transformation, custom proxies and the like is
>relatively easy and well documented, but for me it is sometimes hard to
>transform the topic to practical use, so any discussion is appreciated.

Take a couple of example.

Let's imagine I want to introduce a different initialize signature
into my component. Perhaps it takes a ServletConfig as an argument
and throws a ServletException. This is perfect case for use of the
lifecycle extensions package. In this scenario that handler could
be constructing the config instance - perhaps based on service that
the handler has acquired from its own dependencies. The handler
simply builds the config argument and applies this to the supplied
component. No need for proxies - good isolation of the extension
from the container - and clear separation of container / component
concerns between the extension handler and the target component.

Another scenario - access control based on a principal identity.
This information is unavailable at deployment time. It's a runtime
concern. A proxy can intercept an invocation and do stuff like
unmarchal a principal identifier or whatever, pass the argument to
some code to handle the business logic (e.g. an access decision),
and then apply the invocation to the target. The extendibility
issue here concerns the ability to "plug-in" a handler for access
control which can be used by the proxy implementation. This is
where interceptor chains come into play.

In the Merlin environment the object that actually exposes a proxy
is the Appliance (a.k.a. the component deployment handler). An
appliance is a component and as such it can have multiple dependencies,
context, configuration, etc. This immediately eliminates a bunch of
classic problems related to intercept style management - namely the
ordering and synchronization of multiple interceptors. However - at
least in Merlin, there isn't a way for the container to acquire an
interceptor or interceptors without introducing a specialized
appliance (but its is an interesting through).

Cheers, Steve.


Stephen J. McConnell

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

View raw message