AggregateContext.getAggregate()

[Jeremy Boynes <jb...@apache.org>]

I have issues with this addition as it creates a reference from the
runtime to the logical model and we were trying to avoid those.

The only place that this used is in the Axis1 servlet that, during
processing of the first request, configures the Axis engine by
retrieving the logical model using this method and then digging around
inside it to find the web services entry points.

This function is the responsibility of the builders not the runtime and
especially not a request handler. This could have been done by having
the builder create the EngineConfiguration (or even the actual Engine)
during initialization and passed it to the servlet by binding into the
servlet context. Or, if integrated into the web container, specifically
initialized the servlet during auto-creation.

When done up front, the configuration processing is deterministic - it
occurs when the application starts rather at some arbitrary time when
the first request comes in. This makes troubleshooting the configuration
in a production environment much simpler. It also means you avoid an
arbitrary but extended delay on first invoke as the configuration
information gets processed.

It also means that all configuration and wiring is done by the builder
framework which has more knowledge about the whole configuration than
the binding does. For example, it can make the distinction about where
to apply policy handlers (e.g. in the web services binding or as
interceptors on the entry point itself).

This is all from the Axis1 implementation. When we do the Axis2 version,
please can we set up the engine during startup and avoid the need for
the main processing flow to interact with the logical model.

I will open a JIRA to track this and deprecate the getAggregate() method
until we can remove it.

--
Jeremy

Re: AggregateContext.getAggregate()

[Jim Marino <jm...@myroma.net>]

Can we open this discussion? My inclination is to agree that most  
"processing flow", as opposed to "configuration", code should not  
rely on model objects (I'm assuming builders are "configuration"  
code). It may be useful though to provide a management interface that  
exposes the model, but this should only be used for introspection  
purposes only. Do people have objections to this approach?

Jim

On Feb 28, 2006, at 5:02 PM, Jeremy Boynes wrote:

> I have issues with this addition as it creates a reference from the
> runtime to the logical model and we were trying to avoid those.
>
> The only place that this used is in the Axis1 servlet that, during
> processing of the first request, configures the Axis engine by
> retrieving the logical model using this method and then digging around
> inside it to find the web services entry points.
>
> This function is the responsibility of the builders not the runtime  
> and
> especially not a request handler. This could have been done by having
> the builder create the EngineConfiguration (or even the actual Engine)
> during initialization and passed it to the servlet by binding into the
> servlet context. Or, if integrated into the web container,  
> specifically
> initialized the servlet during auto-creation.
>
> When done up front, the configuration processing is deterministic - it
> occurs when the application starts rather at some arbitrary time when
> the first request comes in. This makes troubleshooting the  
> configuration
> in a production environment much simpler. It also means you avoid an
> arbitrary but extended delay on first invoke as the configuration
> information gets processed.
>
> It also means that all configuration and wiring is done by the builder
> framework which has more knowledge about the whole configuration than
> the binding does. For example, it can make the distinction about where
> to apply policy handlers (e.g. in the web services binding or as
> interceptors on the entry point itself).
>
> This is all from the Axis1 implementation. When we do the Axis2  
> version,
> please can we set up the engine during startup and avoid the need for
> the main processing flow to interact with the logical model.
>
> I will open a JIRA to track this and deprecate the getAggregate()  
> method
> until we can remove it.
>
> --
> Jeremy
>