Weblogic Container Support
What's supported?
Terracotta is supported with Weblogic 8.1 SP 6 and is being tested with Weblogic 9.2 MP2.
Weblogic container support includes regular DSO clustered roots and clustered sessions. There is no special setup (beyond regular DSO client setup) required to enable DSO within Weblogic server. For a Weblogic deployment using managed servers, only the managed nodes need to be DSO enabled (Weblogic admin servers and node managers need not be modified)
Classloader Naming
Classloader naming is already implemented by Weblogic's classloader annotations. There are two adapters applied to grab these annotations and make these named classloaders known:
- ServerAdapter - modifies weblogic.Server.main() (see below)
- GenericClassLoaderAdapter - modifies the weblogic GenericClassLoader to use the annotation name as the Terracotta classloader name and implements the NamedClassLoader interface.
ServerAdapter moves the prior main() method into a new __tc_main() method and installs a new main() that calls it like this:
SessionsHelper.injectClasses(Class.forName("weblogic.Server").getClassLoader());
try {
__tc_main(args);
} finally {
try {
ClassProcessorHelper.shutdown();
} catch(Throwable throwable) {
throwable.printStackTrace();
}
}
This ensures that SessionsHelper gets called at the start and that ClassProcessorHelper.shutdown() is called at the end.
Session filters
Session support is implemented as a servlet filter under Weblogic. The filter is inserted automatically with instrumentation. The servlet filter uses a custom factory for generating the wrapped servlet request and response instances. Weblogic internals interrogate the concrete types of the requests in certain places and without subclassing weblogic types, things like redirects and authentication do not work correctly.
This diagram shows how the session filter is automatically installed in Weblogic 9:
The WebAppServletContext is the main holder of servlet state. That state was largely held directly in WebAppServletContext in Weblogic 8, but has been split out in Weblogic 9 into a series of managers. The ones with state that we care about are EventsManager, FilterManager, and SessionConfigManager.
In Weblogic 9, the FilterManager manages servlet filters and filter mappings. We instrument FilterManager to automatically insert our SessionFilter into the filter chain by adding a new DSOFilterBean and DSOFilterMappingBean. The DSOFilterBean inserts the SessionFilter as the first filter when the WebAppServletContext sets up the filter chain.
The following instrumentation is involved in setting this up:
- WebAppServletContextAdapter - adds WebAppConfig interface to WebAppServletContext and implements all methods on that interface by retrieving information from the various managers
- EventsManagerAdapter - adds methods to EventsManager to expose info needed by the WebAppConfig interface
- FilterManagerAdapter - adds methods to FilterManager to expose a hook back to WebAppServletContext (used by SessionAspectWL9)
- SessionAspectModule - applies an aspect to FilterManager that adds around advice in registerServletFilters() around calls to getFilters() and getFilterMappings(). The advice itself is implemented in SessionAspectWL9.
- SessionAspectWL9 - checks whether the session is a DSO session by looking at the context path in the original servlet and consulting ClassProcessorHelper. If so, insert a DSOFilterBean and DSOFilterMappingBean, which are hard-coded to return SessionFilter.
Once the SessionFilter is installed, this diagram shows the classes involved in modifying the way requests/responses flow through the filter chain:
The SessionFilter uses a custom WeblogicRequestResponseFactory (extending the Terracotta BaseRequestResponseFactory) which modifies the response object. In general, SessionFilter's job is to intercept the request before reaching the normal Weblogic session filters, determine whether the session is filtered, and fault in the session information from the cluster (via the SessionManager).
- ServletResponseImplAdapter - makes ServletResponseImpl non-final and the constructor protected, so it can be subclassed
- TerracottaServletResponseImplAdapter - dynamically creates a wrapper in TerracottaServletResponseImpl that wraps a ServletResponseImpl and proxies calls to it. In general, the TerracottaServletResponseImpl behaves the same as the normal Weblogic ServletResponse but it also has access to the request and answers certain methods by consulting the request rather than the original response object.
A lot of the ASM work is supported by dummy weblogic stub classes that stand-in at compile time for the real Weblogic classes. These stubs all exist in the dso-weblogic-stubs project. In general they are highly incomplete copies of Weblogic classes with just the methods provided that are actually needed by the ASM code. In addition, most of the ASM methods in the adapters were created using the ASM Bytecode plugin on methods added to these classes. Because these are just dummy classes and not used at runtime, the methods that will be generated by ASM code were left in the code for maintenance. In general, these methods all start with "_tc" and reference the code being used to generate them.
Runtime Considerations
Weblogic 8 requires JDK 1.4. Weblogic 9 requires at least JDK 1.5 and has not been run successully with JDK 1.6.
