I've checked in an initial stab at this issue with updates that decouple DWR's core so it doesn't require remoted objects to be made of reflectable concrete Java classes accessible through DWR's classloader, but instead get a logical representation that may be customized by integration code.
This has been done by adding these classes:
Module and ModuleManager interfaces,
that provide a more generic integration point in DWR's conversion pipeline, compared to Creators that are hard-coded to reflection.
that is the representation of a logical method, not necessarily backed by reflection.
and these new injection points in the DWR conversion pipeline (in defaults.properties):
a MasterModuleManager that delegates to customModuleManager and fallbackModuleManager in that order
empty by default and may be configured by applications to activate custom integrations
a CreatorModuleManager that interfaces against the standard Creator infrastructure (including some required internal DWR services)
Changes to existing code:
There are small changes to many files, but the major part of the code changes are in the following modified interfaces:
and core classes:
The new interfaces may be considered experimental, and this work should be continued in follow-up activities after 3.0.