[ 
https://issues.apache.org/jira/browse/QPID-8045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lorenz Quack updated QPID-8045:
-------------------------------
    Attachment: QPID-8045_contextVars_WIP.tar.gz

This is an old attempt of mine at refactoring the context variables. The patch 
has not been updated in a while.

General approach I took:
* Declare a getter method on the interface and annotate it.
* The annotation carries the default value, the name, and a description.
* Annotation processing then auto-generates a subclass with a variable for the 
materialized value (the type can be deduced from the getter's return type), the 
implementation of the getter, and a postResolve to materialize the context 
variable.
* all code should be using the getter and not refer to the materialized value 
directly nor use {{getContextValue()}}. This is why I chose to annotate getter 
methods rather than the default value.

Some problems I encountered with the above approach and which have not been 
addressed yet in the patch:
* The developer written implementation (as opposed to the auto generated one) 
needs to have a stub for the method or be declare abstract.
* Since the materialization happens in the auto-generated subclasses the 
dev-written implementations are not fully functional. This is mainly a problem 
for testing. The tests would have to subclass the tests in question and mock 
the getters for the context variables.

> [Broker-J] Refactor context variables
> -------------------------------------
>
>                 Key: QPID-8045
>                 URL: https://issues.apache.org/jira/browse/QPID-8045
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Broker-J
>            Reporter: Lorenz Quack
>         Attachments: QPID-8045_contextVars_WIP.tar.gz
>
>
> Context variables are heavily used in Qpid Broker-J.
> Over the years their implementation and use has grown organically.
> Maybe it is time they are refactored.
> Some reasons for considering a refactor:
>  * boilerplate: Currently a context variable requires quite a lot of 
> boilerplate code. A variable for the name and the {{\@ManagedContextDefault}} 
> annotated default value, a {{\@DerivedAttribute}} annotated getter for the 
> materialized value, a variable to hold the materialized value, the code to 
> materialize the context variable.
>  * inconsistency: Some context variables are materialized others aren't 
> (i.e., change takes effect after restart vs immediately). The point of 
> materialization is inconsistent (popular choices being {{onOpen}} and 
> {{postResolve}}). Some expose the materialized value through a 
> {{\@DerivedAttribute}} others do not. The names of the context variables are 
> sometimes directly on the scattered around {{\@ManagedContextDefault}} 
> sometimes on a separate variable.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to