Rob,

Let me clarify a few points. Perhaps my initial message wasn't clear.

(*) At this point there is no plan to add a JMS layer for 0.18

(*) The JMS layer would be a generic implementation over the messaging
API, and independent of any API implementation.

(*) When we do add a JMS layer (likely in 0.20) on top of messaging,
then this layer could be *equally* used by both a pure Java version or
the cpp binding, as the JMS layer would be independent of any of it.
There want be (and should not be) a JMS layer specific to the C++
client or any other implementation..

(*) The cpp binding is going to be just another implementation
parallel to the pure Java implementation. And a user should be able to
pick a specific impl with something like,
     
-Dqpid.connection-factory=org.apache.qpid.messaging.cpp.CppConnectionFactory

I'm only requesting this to be landed on the trunk similar to the way
we have "amqp-1-0-client" "amqp-1-0-common" ..etc
I totally agree that we should not be publishing this as a release
artefact. We should only mention this in the notes as "experimental
work".
And people who want to try it out, do so with the understanding that
it's experimental at best.

Regards,

Rajith

On Mon, Jun 18, 2012 at 11:13 AM, Rob Godfrey <[email protected]> wrote:
> Hi Rajith,
>
> I know you've been working on getting a "JMS client over messaging
> API" working, but this is the first I realized that the intention was
> to add *another* Java client for 0.18.
>
> the goal of JMS on top of messaging on top of proton makes a lot of
> sense... I'm less convinced that JMS on top of the current C++ client
> makes a lot of sense - especially without a wider discussion on the
> list amongst all the Java developers.
>
> Perfectly happy to have this in some sort of sandbox for people to
> download and try out (if they really need a JMS over RDMA client or
> something)... but I think adding it to the main release artefacts for
> 0.18 would be confusing and likely to leave us with more future
> support problems.
>
> -- Rob
>
> On 18 June 2012 17:00, Rajith Attapattu <[email protected]> wrote:
>> Hi All,
>>
>> I've been working on providing a Java version of the Qpid API (QPID-4001)
>> For starters I have experimented on implementing this API over the
>> existing C++ client via SWIG/JNI until we get a pure Java
>> implementation based on Rob Godfrey's proton-j work.
>>
>> There are some unique benefits provided by the above approach.
>> 1. Allow us to leverage the arguable more performant and stable c++ client.
>> 2. If we get a JMS layer over this, it can provide a reasonable
>> alternative for the current JMS client, until we rework the client
>> properly.
>> 3. RDMA support for the Java client.
>>
>> The work I have done lives in the following branch [1]
>> At the moment it has full support for message headers, String, List
>> and Map messages.
>> I have a working example here [2] that demonstrates the above.
>> Instructions on how to run the example is here [3].
>>
>> I'm hoping to get this on trunk in time for 0-18 provided the
>> following goals are met.
>>
>> 1. Successful review of the c++ components [will post the details shortly].
>> 2. Agreement on QPID-4001 (will post the latest shortly)
>> 3. Successful  review of the common java code in the implementation
>> layer [need to think on how best to put this up for review].
>> 4. Adding a reasonable amount of unit tests for the java side.
>>
>> I would really appreciate if interested parties have a look at the
>> review requests and provide feedback/suggestions to make this a
>> reality.
>> I will be posting relative performance numbers once I get the chance
>> to do a reasonable performance evaluation comparing this work with the
>> current c++ client and JMS client.
>>
>> Regards,
>>
>> Rajith
>>
>> [1] https://svn.apache.org/repos/asf/qpid/branches/address-refactor2/
>> [2] 
>> https://svn.apache.org/repos/asf/qpid/branches/address-refactor2/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/cpp/CppTest.java
>> [3] 
>> https://svn.apache.org/repos/asf/qpid/branches/address-refactor2/qpid/java/client-api/README
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to