|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
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
Method s and
Field s 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). |
ObjectFactory wrappers to provide proxied components to the container.
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.
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.
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.
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:
public interface HelloWorldComponent { String sayHello(); }
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 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.
|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |