2009/9/14 Jonathan Robie <jonathan.ro...@redhat.com>: > Martin Ritchie wrote: >> >> Have you thought how the configuration can still be performed via JNDI? >> >> I have mentioned this before on the list so will be brief (well that >> was the aim). I really don't see any advantage to adding new a API (of >> any sort) on the java side. Allowing 100% compliant JMS code to just >> work with JNDI configuration changes for Qpid is the best thing we can >> do for our users. If they have spent the time to write to the JMS API >> and stay away from vendor locks then we should reward them by just >> working. Asking them to rewrite some of their code when moving to a >> product that is based on AMQP, which is attempting to fight against >> the vendor lock ins in the messaging world, sends the wrong message. >> > > I agree that there's an advantage to this approach. > > I don't think of AMQP as a vendor, and I don't think of an AMQP > configuration API as a vendor lock, especially if we create it together. > Ideally, if we can create sufficiently good high level and configuration > APIs, I'd like to see them become a standard. > > Java is the one language with a well-established messaging API, and I don't > think we should compete with Java JMS, but we do need a good story for > configuring systems used with Java JMS. I'm agnostic whether JNDI is going > to be sufficient in the long run. If we see users configure their systems > using other languages that have APIs for this, or using tools written in > these languages, it might be worth asking whether a configuration API for > Java also makes sense. But I think we can also sit back and see if that need > evolves. > > Suppose we see that need. How is an AMQP-specific configuration API worse > than AMQP-specific JNDI configuration? Neither one gives interop for > configuring non-AMQP systems. (I really do mean this as a question, it's > quite likely that there are advantages I don't yet see.) > > Jonathan
I guess I aways saw code changes as a bigger issue than configuration file changes. Arguable having a compile time error when you change client libraries is better than randomly having a runtime error when the JNDI configuration doesn't work. It may be worse if it just works but the routing sematics introduce a subtile change that isn't easily detectable. As has been pointed out this is AMQP which is not a vendor so swapping Brokers will still work just fine. The issue I was thinking of was swapping client libraries. If we have Qpid APIs then a developer can't swap client libraries as easily. Hence my 'vendor lock in' concern where Qpid is the vendor. That said, when/if AMQP specifies an API for configuration then org.amqp.configuration classes will be portable so that issue goes away. Having a consistent story across all the Qpid components would go a long way to valiating any API/approach which could be adopted by others. I'd be interested in knowing more about what Rafi/Gordon had in mind for reasonable text based syntax. Sounds like a good a approach. Have you/Could you put your thoughts up on the wiki? Cheers Martin > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Martin Ritchie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
