Package org.apache.avalon.fortress.impl.factory

ObjectFactory wrappers to provide proxied components to the container.

See:
          Description

Interface Summary
WrapperClass The interface WrapperClass provides a means of asking a dynamically created wrapper for a given object for said wrapped object.
 

Class Summary
AbstractObjectFactory AbstractObjectFactory does XYZ
BCELCodeGenerator BCELCodeGenerator creates implementations for the Methods and Fields needed in creating a WrapperClass.
BCELCodeGenerator.MethodDesc  
BCELWrapperGenerator Create the BCELWrapper for the component.
NoopObjectFactory NoopObjectFactory is used in situations where no proxied objects are desired.
PassThroughInvocationHandler InvocationHandler that just passes on all methods to target object.
ProxyManager ProxyManager is used to abstract away the plumbing for the underlying proxy generator.
ProxyObjectFactory An ObjectFactory that delegates to another ObjectFactory and proxies results of that factory.
WrapperObjectFactory An object factory that delegates all calls to another object factory and wraps the returned object into another object that exposes only the wrapped object's work interface(s).
 

Package org.apache.avalon.fortress.impl.factory Description

ObjectFactory wrappers to provide proxied components to the container.

Proxy Factories

There are currently two types of factories available with Fortress: BCEL enabled, and traditional JDK 1.3 proxies. Jakarta BCEL is a library to directly generate Java class bytecode. You do not have to include this library for Fortress to function, however if it is present Fortress will use it.

The Need

Proxies are used both for the protection of the component's lifecycle methods, and for backwards compatibility with Composable components. The proxy automatically adds the Component interface to any component (even if it did not have it in the source code) so that it can be used with your old legacy components. As everyone upgrades, the backwards compatibility concern becomes less of an issue--however protecting a component is still very important.

JDK 1.3 Proxy Code

The Java Proxy code uses reflection to do its dirty work, so despite all the advances in JDK 1.4 introspection code you will still incur a substantial performance bottleneck using this approach. A user did a micro-benchmark and reported that the performance hit is around 4:1 vs. just using the component directly. If your components are not repeatedly called several times in rapid succession as is the case with micro-benchmarks then you probably will barely notice the change. Nevertheless, in some environments (most notably when you are working with Servlets) that performance hit will begin to add up.

BCEL Enabled Proxy Code

The BCEL enabled proxy code creates a wrapper class that directly calls the methods on your component as if you wrote it yourself. As an example, the following two code snippets will show you how the component is proxied:

Component's Interface

public interface HelloWorldComponent
{
    String sayHello();
}

Wrapper Class

public final class HelloWorldComponent$BCELWrapper
{
    private final HelloWorldComponent m_component;

    public HelloWorldComponent$BCELWrapper(HelloWorldComponent base)
    {
        m_component = base;
    }

    public String sayHello()
    {
        return m_component.sayHello();
    }
}

The Benefit

The resulting code is much easier for the JVM to use, and does not pose a serious threat to the performance of the component. All you have to do is include the BCEL.jar file, and the choice will be made for you.