You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Kim van der Riet (JIRA)" <qp...@incubator.apache.org> on 2007/01/08 17:58:27 UTC

[jira] Created: (QPID-261) Remove fixed version leterals in code, replace with version information obtained from the ProtocolInitiation for the current session.

Remove fixed version leterals in code, replace with version information obtained from the ProtocolInitiation for the current session.
-------------------------------------------------------------------------------------------------------------------------------------

                 Key: QPID-261
                 URL: https://issues.apache.org/jira/browse/QPID-261
             Project: Qpid
          Issue Type: Sub-task
          Components: Java Broker, Java Client
            Reporter: Kim van der Riet


The first stage of conversion to multi-protocol code is to make the framing classes version sensitive, which means that the version of the current session must be passed to the constructors of all MethodBody classes. Incorporating these new (mostly genreated) classes into the code is achieved by "hard-wiring" the version to 0-8 (major=8, minor=0) in all places where a version must be supplied.

The second phase (this task) is to configure a fixed location to store the version of each session obtained from the ProtocolInitialtion object for that physical connection, and make that version information available to all locations within the broker and client where it is required. Some refactoring may be requried.

A secondary goal would be to refactor so as to isolate version-specific code within the handler classes as far as possible. Doing so will minimize the inevitable impact of adding additional AMQP version(s) in the future to an isolated group of classes in both the client and broker.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Assigned: (QPID-261) Remove fixed version leterals in code, replace with version information obtained from the ProtocolInitiation for the current session.

Posted by "Rob Godfrey (JIRA)" <qp...@incubator.apache.org>.
     [ https://issues.apache.org/jira/browse/QPID-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rob Godfrey reassigned QPID-261:
--------------------------------

    Assignee: Rob Godfrey

> Remove fixed version leterals in code, replace with version information obtained from the ProtocolInitiation for the current session.
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: QPID-261
>                 URL: https://issues.apache.org/jira/browse/QPID-261
>             Project: Qpid
>          Issue Type: Sub-task
>          Components: Java Broker, Java Client
>            Reporter: Kim van der Riet
>            Assignee: Rob Godfrey
>             Fix For: M2.1
>
>
> The first stage of conversion to multi-protocol code is to make the framing classes version sensitive, which means that the version of the current session must be passed to the constructors of all MethodBody classes. Incorporating these new (mostly genreated) classes into the code is achieved by "hard-wiring" the version to 0-8 (major=8, minor=0) in all places where a version must be supplied.
> The second phase (this task) is to configure a fixed location to store the version of each session obtained from the ProtocolInitialtion object for that physical connection, and make that version information available to all locations within the broker and client where it is required. Some refactoring may be requried.
> A secondary goal would be to refactor so as to isolate version-specific code within the handler classes as far as possible. Doing so will minimize the inevitable impact of adding additional AMQP version(s) in the future to an isolated group of classes in both the client and broker.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (QPID-261) Remove fixed version leterals in code, replace with version information obtained from the ProtocolInitiation for the current session.

Posted by "Rob Godfrey (JIRA)" <qp...@incubator.apache.org>.
     [ https://issues.apache.org/jira/browse/QPID-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rob Godfrey resolved QPID-261.
------------------------------

       Resolution: Fixed
    Fix Version/s: M2.1

> Remove fixed version leterals in code, replace with version information obtained from the ProtocolInitiation for the current session.
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: QPID-261
>                 URL: https://issues.apache.org/jira/browse/QPID-261
>             Project: Qpid
>          Issue Type: Sub-task
>          Components: Java Broker, Java Client
>            Reporter: Kim van der Riet
>             Fix For: M2.1
>
>
> The first stage of conversion to multi-protocol code is to make the framing classes version sensitive, which means that the version of the current session must be passed to the constructors of all MethodBody classes. Incorporating these new (mostly genreated) classes into the code is achieved by "hard-wiring" the version to 0-8 (major=8, minor=0) in all places where a version must be supplied.
> The second phase (this task) is to configure a fixed location to store the version of each session obtained from the ProtocolInitialtion object for that physical connection, and make that version information available to all locations within the broker and client where it is required. Some refactoring may be requried.
> A secondary goal would be to refactor so as to isolate version-specific code within the handler classes as far as possible. Doing so will minimize the inevitable impact of adding additional AMQP version(s) in the future to an isolated group of classes in both the client and broker.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.