@inner interfaces/inner classes:
I never would use inner interfaces as I frequently find myself searching for them. The only exception for me is if one have been lazy enough to use such constructs in a public specification (e.g. in JAXB).
About the same applies for inner classes with the exception of simple value objects without additional responsibilities (e.g. Map.Entry).
You defined DescriptorCache interface in ResolverStrategy while its implementation is in XMLClassDescriptorResolverImpl. The interface is used at CastorXMLStrategy as intended but in addition it is used by XMLClassDescriptorResolverImpl which does not implement ResolverStrategy. Having said that I would throw away the interface in that case and move DescriptorCacheImpl out of XMLClassDescriptorResolverImpl.
@split of XMLClassDescriptorResolver / Strategy / Command:
@handling of configuration:
As XMLClassDescriptorResolverImpl is responsible for instantiating ResolverStrategies as well as ResolverCommands we should pass a Configuration instance (the one I'm working at at another issue) from XMLClassDescriptorResolverImpl to each strategy and command. Each of these classes can hold a reference to this Configuration if it needs to access some of its properties.
I don't think CastorXMLResolver should offer get/setProperties methods nor is there a need to pass the Configuration to each Command.resolve() method call (at least as far as I understand the code ATM). I also would not put things like a DescriptorCache or MappingLoader instance into the Configuration. The keys of the properties in the Configuration should be defined as constants at one place (e.g. in an XMLConfiguration class). This omits typos and allows for easier search of places where they are used with a bit of more work to maintain them.