This page is part of a set of pages aimed at DWR developers. If this isn't you, then you probably want the documentation index.
DWR is comprised of a number of components that are designed to be as separate as possible. They are:
These components are registered in an IoC container (which is itself abstracted via a Container interface)
The first step is to initialize the IoC container. This must be the first step because it is expected that some usages of DWR (like Spring for example) will use an external IoC container, so IoC container setup may be outside the control of DWR.
It is recognized that there are some limitations in simply leaving that to be the only part of the configuration process. In the Spring case it would require a very verbose config file since DWR needs to provide a default config that users then build upon.
The Converter implementations MUST do the push/pop of context even though it would be more of help if the framework could do it for us. This is because the MapConverter needs to push/pop for the name AND the value.
Converters can't work by being told just the type to convert to because collection converters still need to ask because they recur down into other converters. Context is key to knowing how to convert so we need to keep a track of the type conversion context as it evolves.
Creators need both getType and newImplementation methods even though you can derive the type by creating an implementation. This is because we need to know the Method before we call newImplementation, because if the method is static we don't need a 'this'. But we need the type before we can get the method.