qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kim van der Riet <kim.vdr...@redhat.com>
Subject Re: Multi-AMQP-version generator (Java) now availalbe for evaluation
Date Thu, 19 Oct 2006 12:30:02 GMT
Hi Hiram,

Thank you for your comments.

I have looked (briefly) at your code. As you point out, it is a
reimplementation of the XSLT generator with the primary objective of
separating marshaling from command details. However, I do not see how
this implementation allows the broker to *simultaneously* support more
than one version of the AMQ protocol. While it is true that the
marshaling code is created in a version-specific directory so that
various versions do not overwrite each other, this only solves part of
the problem. Since the AMQP specification files can also change the
classes, methods and fields as well as their index numbers, the
MethodBody classes in your command directory also needs to be
version-specific. Currently the MethodBody classes in your command
directory are not version-aware, and cannot (for example) change the
class and method IDs or any of the attributes or their types based on
the version of the protocol negotiated at the start of the session.
Having the class and method IDs declared static final when these could
change from version to version is one of several problems that you will
need to solve.

I hope that I have not missed anything and understood your code rightly.

I apologize that I have not yet not completed the Wiki pages that
describe the new code generator I have checked into the Qpid repository
in more detail. It reads in and compares all the AMQP versions to be
supported up front, then based on the differences between these
versions, it generates code which can support any one of these versions
at runtime based only on the initial protocol negotiation. Differences
include the addition and removal from one version to the next of
classes, methods and fields, changes in the class and method IDs,
changes to fields and their order in the XML file (which defines their
order on the wire) and/or their types. The resulting MethodBody classes
are able to represent and handle these differences at runtime, depending
only on the protocol version with which its instance is instantiated.

Kim

On Wed, 2006-10-18 at 17:24 -0500, Hiram Chirino wrote:

> Hi Kim,
> 
> In your http://wiki.apache.org/qpid/AMQPVersion%2e1 section.  I think you
> missed the solution approach that amq took when re-implementing the qpid
> code generator.  And that is to have 1 set of MethodBody classes and n set
> of Encoder/Decoders.  The native amq openwire protocol has been using this
> approach with success for a while now.
> 
> In case you missed the previous email, this has already been implemented and
> checked in here:
> http://svn.apache.org/repos/asf/incubator/activemq/sandbox/qpid/
> 
> This implementation puts all the MethodBody classes in a ....command.*
> package and all the logic for the different encoder/decoders are placed in a
> .....wireformat.v${version}.* package.
> 
> On 10/18/06, Kim van der Riet <kim.vdriet@redhat.com> wrote:
> >
> > The first crack at a code-generator which is capable of providing
> > support for multiple AMQP versions in the broker is now available in
> > subversion under the trunk in the directory gentools. At this stage,
> > only Java generation is functional; C++ is to follow. I am not planning
> > to integrate this into Qpid until C++ is complete as well. While that
> > work is in progress, I invite anyone who is interested to take a look
> > and kick the tires in a stand-alone configuration - i.e. it won't touch
> > the existing build.  I look forward to any comments and suggestions you
> > may have.
> >
> > There is a README file containing some instructions. I will also be
> > working on updating the Wiki (http://wiki.apache.org/qpid/AMQPVersion)
> > in the next few days.
> >
> > Kim
> >
> >
> 
> 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message