Attempted autowired approach.  Still no luck.
Eclipse project updates associated with attempt to update Spring dependency to 4.0.0
Pom maintenance to add dependencies for unit testing (eventually) and to work around Spring Restlet's CgLib dependency blocking Spring 4.0.0 usage.  So far the configuration issue remains a block to seeing if this is viable, but if it isn't, the fault will likely manifest in the SpringFinder being unable to locate the resource its due to prototype out.
Checkpointing further failed progress at the presumably simple task of binding configuration properties.  Interestingly, the unused RootConfiguration.java file, while lacking Servlet beans needed to be viable, IS capable of binding Environment!  This is in-line with the perception that AuthtoyConfiguraion _was_ previously able to read the authtoy.properties content via an injected Environment, but subsequently stopped.\n\nCurrent best guess is that SpringBeanRouter is the entity that broke configurability--this bean involves a BeanFactoryPostProcessor.  Next steps are to see if removing the SpringRouter yields a configurable but non-functional context and, if so, explore alternatives for working around the limitation of @Configuration and BeanFactoryPostProcessing.
Whatever.  Making the application a @Component.  Not relevant since component-scanning is not currently in use.
Incrmenetal progress towards working configurability.  Replacing the SpringBeanRouter with a SpringRouter seems to have been a crucial change.  SpringRouter is not a SpringBeanFactoryPostProcessor and so is more compatiible with a @Configuration bean.  The issue now is a series of circular dependencies originating in the desire to set the Router as the inboundRoot of out application while every component of the application needs to depend on the application to acquire its Context.  The solution is to let the Application be instantiated and registered in a non-wired state and reply on contributing the Router and routed Resource Prototypes and/or Restlet Singletons to instantiate and wire themselves correctly.  It is Ok for the Router to depend on the routed elements and the application, then attach the routed elements to itself and itself to the application.
Purging two dead end files that turned out to be unnecessary.
Server is now starting with a Java configuration.  The SpringBeanRouter was indeed the culprit--it is a BeanFactoryPostProcessor and has a dependency chain that leads to the StormpathClient where configuration data is consumed.  Because Spring Java Configurations also rely on a BeanFactoryPostProcessor in order to wire in the services it provides, such as Environment, those services are unavailable when any dependency of a SpringBeanRouter has to be instantiated and wired before other Spring PostProcessor services become available.
Moving two files that are being used to test a Directory filesystem component for static content to their configured place.
Some front end interface work
Removing Angular docs and minified Javascript from depot.
Removing unused reference material from old Ruby demo app
Cheking in a Shiro/Restlet authentication example code base for reference
Cleanup
Checkpointing client module work
Relocated assets directory under WEB-INF to attempt to reach it using war:// URL.  Incremental progress extracting a functional Shiro layer inspired by the non-functional Skysail code base.
Checkpointing progress on Restlet Shiro layer
Checkpointing progress on Restlet Shiro layer
Adding Shiro libraries to project pom and derived Eclispe project
Application configuration changes.  Currently non-functional again, but worth checkpointing.  The Application's Context, not the Component's, _is_ the right one to use after all, but it must be wired to a Virtual Host before being extracted--the allocation to the Virtual Host is what triggers instantiation of the Application's Context, a child of the Component's contet.  I guess that means the Virtual Host must also be wired to the Component.