Document best practices for implementing ParameterResolvers

[sbrannen]

Overview

Based on discussions in #1184 and weld/weld-testing#3, it is apparent that we need to document best practices for implementing ParameterResolver, particularly with regard to "playing nicely" with other registered ParameterResolver implementations.

Proposed Categories

After having put a bit more thought into the subject, I am tossing around the idea of categorizing ParameterResolver implementations by behavior as follows.

• explicit: support requires an annotation for disambiguation.
• implicit: support is automatic for types owned by the resolver.
• speculative: a resolver claims it can support a given parameter even if it potentially should not (a.k.a., greedy or eager).

Deliverables

• Document best practices for ParameterResolver implementations in JavaDoc.
  • more succinct than the documentation in the User Guide
• Document best practices for ParameterResolver implementations in the User Guide.
  • including examples and explanations of how to avoid conflicts

[sbrannen]

Update: added Proposed Categories section to issue.

[rumpfc]

Can you also provide examples for error/exception handling within ParameterResolver which are actually not ParameterResolutionExceptions (i.e. resolveParameter() reads a File where an IOException is thrown)?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. Thank you for your contribution.

[stale]

This issue has been automatically closed due to inactivity. If you have a good use case for this feature, please feel free to reopen the issue.