So, I think for me the worry is that building a JMS layer on top of the Messaging API is a key part of our future strategy for the Java/JMS client. As such I really don't want to try to rush to get this in to 0.18 before we've all had a chance to properly review things.
In particular I would rather have the Java development community 1) review and agree the translation of the messaging API into Java 2) build (or utilise an existing) comprehensive test suite of Messaging API functionality which completely defines the responsibilities of this layer 3) agree how the JMS layer will layer on top of the Messaging API, clearly defining where responsibilities lie 4) build a JMS layer with an accompanying comprehensive unit test suite that again completely defines the expected functionality uysing a mock Messaging API to ensure we are isolating testing *only* to the JMS layer. My concern about landing the work on trunk too early is that we neglect the necessary design discussion and clarification, and instead we run head first into accelerated bug-fix and maintenance cycles that have proved so costly for us in the past. I think that we need to avoid repeating our past mistakes and concentrate on building the quality into the client up front. As such I'd personally rather hold off on landing the experimental code just yet, but I do think it makes sense to make these artefacts available to people who are interested in them. Cheers, Rob On 18 June 2012 17:37, Rajith Attapattu <rajit...@gmail.com> wrote: > 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 <rob.j.godf...@gmail.com> 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 <rajit...@gmail.com> 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: dev-unsubscr...@qpid.apache.org >>> For additional commands, e-mail: dev-h...@qpid.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >> For additional commands, e-mail: dev-h...@qpid.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
