Java Client strategy

[Rajith Attapattu <ra...@gmail.com>]

Hi Folks,

I think we've gotten to the point that we have rough consensus, and it's
clear how to move forward.

I think there is broad agreement on the following goals:

1. We should have a low level client API that maps directly to the AMQP
protocol across all language implementations.
This will make it easier to keep language bindings consistent and to test
them.

2. Early adopters can work with the low level client API, with the explicit
understanding that this API is likely to change until the protocol
    stabilizes.

  3. The JMS implementation should be built on the Java AMQP client, which
will make it easier to keep it consistent with the other language
bindings and to test.

4. The existing Java client code needs to be re-factored.
The current prototype available has reused and rearranged existing code as
much as possible.

5. We should consider how to provide AMQP functionality beyond what JMS
offers.
Several strategies were explored, including extending JMS and designing the
low level AMQP client so that it can be used together with JMS using
casting.

Based on this, I think we should do the following:

  1. Refactor the existing Java client code so that it implements JMS
functionality on top of a low level AMQP API.

  2. Identify a list of key bug fixes/JMS extensions in the M2 branch,and
reflect these in the new Java client code.

Unless I hear otherwise, this is the plan I intend to pursue.

Rajith

Re: Java Client strategy

[Rupert Smith <ru...@googlemail.com>]

Absolutely.

On 13/06/07, Jonathan Robie <jo...@redhat.com> wrote:
>
> I like the directions Rajith proposes.
>
> Rupert - I think you are basically saying that the new client needs to
> pass existing tests and future tests (based on JIRAS for M2), and needs
> to pass existing requirements for the Java client, right? And that you'd
> like to make sure this is the case before the refactored code becomes
> the working branch?
>
> Jonathan
>
> Rupert Smith wrote:
> > Please add:
> >
> > 0. Ensure the existing client unit test suite, sys tests, integration
> > tests
> > and performance tests, runs against the refactored client code before
> the
> > existing client code is 'broken'.
> > If necessary/possible convert some tests that use the existing Java
> > AMQP API
> > to run through the JMS API.
> >
> > 0.5. Identify any JIRAs for M2 that it would be sensible to write
> > tests for,
> > and make sure tests for them exist for M2 and the new client code.
> >
> > 0.9. Ensure that any existing requirements for the current client code
> > are
> > going to be carried forward to the refactoring. At the moment, I can
> > think
> > of:
> > - Ensure retrotranslation to Java 1.4 will work.
> >
> > On 13/06/07, Rajith Attapattu <ra...@gmail.com> wrote:
> >>
> >> Hi Folks,
> >>
> >> I think we've gotten to the point that we have rough consensus, and
> it's
> >> clear how to move forward.
> >>
> >> I think there is broad agreement on the following goals:
> >>
> >> 1. We should have a low level client API that maps directly to the AMQP
> >> protocol across all language implementations.
> >> This will make it easier to keep language bindings consistent and to
> >> test
> >> them.
> >>
> >> 2. Early adopters can work with the low level client API, with the
> >> explicit
> >> understanding that this API is likely to change until the protocol
> >>     stabilizes.
> >>
> >>   3. The JMS implementation should be built on the Java AMQP client,
> >> which
> >> will make it easier to keep it consistent with the other language
> >> bindings and to test.
> >>
> >> 4. The existing Java client code needs to be re-factored.
> >> The current prototype available has reused and rearranged existing
> >> code as
> >> much as possible.
> >>
> >> 5. We should consider how to provide AMQP functionality beyond what JMS
> >> offers.
> >> Several strategies were explored, including extending JMS and designing
> >> the
> >> low level AMQP client so that it can be used together with JMS using
> >> casting.
> >>
> >> Based on this, I think we should do the following:
> >>
> >>   1. Refactor the existing Java client code so that it implements JMS
> >> functionality on top of a low level AMQP API.
> >>
> >>   2. Identify a list of key bug fixes/JMS extensions in the M2
> >> branch,and
> >> reflect these in the new Java client code.
> >>
> >> Unless I hear otherwise, this is the plan I intend to pursue.
> >>
> >> Rajith
> >>
> >
>
>

Re: Java Client strategy

[Jonathan Robie <jo...@redhat.com>]

I like the directions Rajith proposes.

Rupert - I think you are basically saying that the new client needs to 
pass existing tests and future tests (based on JIRAS for M2), and needs 
to pass existing requirements for the Java client, right? And that you'd 
like to make sure this is the case before the refactored code becomes 
the working branch?

Jonathan

Rupert Smith wrote:
> Please add:
>
> 0. Ensure the existing client unit test suite, sys tests, integration 
> tests
> and performance tests, runs against the refactored client code before the
> existing client code is 'broken'.
> If necessary/possible convert some tests that use the existing Java 
> AMQP API
> to run through the JMS API.
>
> 0.5. Identify any JIRAs for M2 that it would be sensible to write 
> tests for,
> and make sure tests for them exist for M2 and the new client code.
>
> 0.9. Ensure that any existing requirements for the current client code 
> are
> going to be carried forward to the refactoring. At the moment, I can 
> think
> of:
> - Ensure retrotranslation to Java 1.4 will work.
>
> On 13/06/07, Rajith Attapattu <ra...@gmail.com> wrote:
>>
>> Hi Folks,
>>
>> I think we've gotten to the point that we have rough consensus, and it's
>> clear how to move forward.
>>
>> I think there is broad agreement on the following goals:
>>
>> 1. We should have a low level client API that maps directly to the AMQP
>> protocol across all language implementations.
>> This will make it easier to keep language bindings consistent and to 
>> test
>> them.
>>
>> 2. Early adopters can work with the low level client API, with the
>> explicit
>> understanding that this API is likely to change until the protocol
>>     stabilizes.
>>
>>   3. The JMS implementation should be built on the Java AMQP client, 
>> which
>> will make it easier to keep it consistent with the other language
>> bindings and to test.
>>
>> 4. The existing Java client code needs to be re-factored.
>> The current prototype available has reused and rearranged existing 
>> code as
>> much as possible.
>>
>> 5. We should consider how to provide AMQP functionality beyond what JMS
>> offers.
>> Several strategies were explored, including extending JMS and designing
>> the
>> low level AMQP client so that it can be used together with JMS using
>> casting.
>>
>> Based on this, I think we should do the following:
>>
>>   1. Refactor the existing Java client code so that it implements JMS
>> functionality on top of a low level AMQP API.
>>
>>   2. Identify a list of key bug fixes/JMS extensions in the M2 
>> branch,and
>> reflect these in the new Java client code.
>>
>> Unless I hear otherwise, this is the plan I intend to pursue.
>>
>> Rajith
>>
>

Re: Java Client strategy

[Rupert Smith <ru...@googlemail.com>]

On 13/06/07, Rajith Attapattu <ra...@gmail.com> wrote:
>
> As I mentioned, any important modifications/improvements should be
> accomadated in the new client where is makes sense.
> Some of these changes might not be applicable due to protocol
> changes/improvements and/or new client architecture.


Yeah, some work-around stuff will be dropped because it won't be needed for
the new protocol.

[RA] It's a reasonable request. How are u guys supporting it currently? Are

> u using a retrotranslator jars?
>

We're using the retrotranslator, which has a maven plugin from the codehaus
mojo project. There is a working example in the existing client/pom.xml,
that can be copied accross. There is also a client-java14 package, which
exists to re-pacakge the client for 1.4 and to run its tests under 1.4. Also
common and integrationtests are also retrotranslated.

To turn on retrotranslator verification you need to add some properties, for
example to a profile in your maven settings.xml. Here's an example from
mine:

        <profile>
            <id>inject-properties-qpid</id>
            <properties>

                <!-- No python tests. -->
                <skip.python.tests>true</skip.python.tests>

                <!-- Configure log4j stuff. -->
                <log4j.configuration
>file:/c:/home/rupert/qpid/trunk/qpid/java/etc/mylog4j.xml</log4j.configuration>
                <log4j.perftests
>file:/c:/home/rupert/qpid/trunk/qpid/java/etc/mylog4j.xml</log4j.perftests>

                <!-- Configure retrotranslator verification stuff. -->
                <retrotranslator.verify>true</retrotranslator.verify>
                <retrotranslator.1.4-rt-path>c:/Program
Files/Java/j2re1.4.2_12/lib/rt.jar</retrotranslator.1.4-rt-path>
                <retrotranslator.1.4-jce-path>c:/Program
Files/Java/j2re1.4.2_12/lib/jce.jar</retrotranslator.1.4-jce-path>
                <retrotranslator.1.4-jsse-path>c:/Program
Files/Java/j2re1.4.2_12/lib/jsse.jar</retrotranslator.1.4-jsse-path>
                <retrotranslator.1.4-sasl-path>c:/Program
Files/Java/j2re1.4.2_12/lib/ext/sasl.jar</retrotranslator.1.4-sasl-path>

                <!-- Configure 1.4 jvm location for testing 1.4 client
builds. -->
                <!--<jvm.1.4.bin>c:/Program
Files/Java/j2re1.4.2_12/bin/java.exe</jvm.1.4.bin>-->

            </properties>
        </profile>

The systests/integrationtests modules are a little confusing because at
first it seems they should be the same thing. The intention is that systests
contains non-unit tests, where java client is run against the java broker
(could be in-vm or standalone broker). The test the java client/broker
together as a system. Integration tests, tests the java client through *any*
broker. They tests its integration with the Qpid Java broker or other
products; the interop tests are in this module.

You are right, in that some stuff does need to be moved out of
client/src/tests into systests.

Rupert

Re: Java Client strategy

[Rajith Attapattu <ra...@gmail.com>]

Rupert,

As Jonathon pointed out, we should have both clients in the trunk in
parallel until the new client has reached a stage of maturity that is
satisfactory to all parties.
Comments inline

Regards,

Rajith

On 6/13/07, Rupert Smith <ru...@googlemail.com> wrote:
> Please add:
>
> 0. Ensure the existing client unit test suite, sys tests, integration
tests
> and performance tests, runs against the refactored client code before the
> existing client code is 'broken'.

[RA] We should make a consious effort to ensure that all sys tests,
integrations and perf tests are converted to run against the new client.
However this is also a good time to have some meaningful discussion on how
we should organize our unit,sys test and perf test.
Some of the current unit tests are not strictly unit tests and are more
integration tests. Therefore I plan to include more unit tests.
Thank you Rupert for highlighting this very important issue.

> If necessary/possible convert some tests that use the existing Java AMQP
API
> to run through the JMS API.
>
> 0.5. Identify any JIRAs for M2 that it would be sensible to write tests
for,
> and make sure tests for them exist for M2 and the new client code.
>
As I mentioned, any important modifications/improvements should be
accomadated in the new client where is makes sense.
Some of these changes might not be applicable due to protocol
changes/improvements and/or new client architecture.

> 0.9. Ensure that any existing requirements for the current client code are
> going to be carried forward to the refactoring. At the moment, I can think
> of:
>  - Ensure retrotranslation to Java 1.4 will work.

[RA] It's a reasonable request. How are u guys supporting it currently? Are
u using a retrotranslator jars?

>
> On 13/06/07, Rajith Attapattu <ra...@gmail.com> wrote:
> >
> > Hi Folks,
> >
> > I think we've gotten to the point that we have rough consensus, and it's
> > clear how to move forward.
> >
> > I think there is broad agreement on the following goals:
> >
> > 1. We should have a low level client API that maps directly to the AMQP
> > protocol across all language implementations.
> > This will make it easier to keep language bindings consistent and to
test
> > them.
> >
> > 2. Early adopters can work with the low level client API, with the
> > explicit
> > understanding that this API is likely to change until the protocol
> >     stabilizes.
> >
> >   3. The JMS implementation should be built on the Java AMQP client,
which
> > will make it easier to keep it consistent with the other language
> > bindings and to test.
> >
> > 4. The existing Java client code needs to be re-factored.
> > The current prototype available has reused and rearranged existing code
as
> > much as possible.
> >
> > 5. We should consider how to provide AMQP functionality beyond what JMS
> > offers.
> > Several strategies were explored, including extending JMS and designing
> > the
> > low level AMQP client so that it can be used together with JMS using
> > casting.
> >
> > Based on this, I think we should do the following:
> >
> >   1. Refactor the existing Java client code so that it implements JMS
> > functionality on top of a low level AMQP API.
> >
> >   2. Identify a list of key bug fixes/JMS extensions in the M2
branch,and
> > reflect these in the new Java client code.
> >
> > Unless I hear otherwise, this is the plan I intend to pursue.
> >
> > Rajith
> >
>

Re: Java Client strategy

[Rupert Smith <ru...@googlemail.com>]

Please add:

0. Ensure the existing client unit test suite, sys tests, integration tests
and performance tests, runs against the refactored client code before the
existing client code is 'broken'.
If necessary/possible convert some tests that use the existing Java AMQP API
to run through the JMS API.

0.5. Identify any JIRAs for M2 that it would be sensible to write tests for,
and make sure tests for them exist for M2 and the new client code.

0.9. Ensure that any existing requirements for the current client code are
going to be carried forward to the refactoring. At the moment, I can think
of:
 - Ensure retrotranslation to Java 1.4 will work.

On 13/06/07, Rajith Attapattu <ra...@gmail.com> wrote:
>
> Hi Folks,
>
> I think we've gotten to the point that we have rough consensus, and it's
> clear how to move forward.
>
> I think there is broad agreement on the following goals:
>
> 1. We should have a low level client API that maps directly to the AMQP
> protocol across all language implementations.
> This will make it easier to keep language bindings consistent and to test
> them.
>
> 2. Early adopters can work with the low level client API, with the
> explicit
> understanding that this API is likely to change until the protocol
>     stabilizes.
>
>   3. The JMS implementation should be built on the Java AMQP client, which
> will make it easier to keep it consistent with the other language
> bindings and to test.
>
> 4. The existing Java client code needs to be re-factored.
> The current prototype available has reused and rearranged existing code as
> much as possible.
>
> 5. We should consider how to provide AMQP functionality beyond what JMS
> offers.
> Several strategies were explored, including extending JMS and designing
> the
> low level AMQP client so that it can be used together with JMS using
> casting.
>
> Based on this, I think we should do the following:
>
>   1. Refactor the existing Java client code so that it implements JMS
> functionality on top of a low level AMQP API.
>
>   2. Identify a list of key bug fixes/JMS extensions in the M2 branch,and
> reflect these in the new Java client code.
>
> Unless I hear otherwise, this is the plan I intend to pursue.
>
> Rajith
>