qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rupert Smith" <rupertlssm...@googlemail.com>
Subject Re: on how to use the qpid java client
Date Tue, 05 Jun 2007 11:02:14 GMT
On 04/06/07, Rajith Attapattu <rajith77@gmail.com> wrote:
>
> > Rather than having to remember the format of this URL scheme, I'd
> > prefer (overloaded) method arguments for the constitutent parts. E.g.
> > con.connect("localhost", 5672, "test", "guest", "guest"). Or perhaps a
> > properties object with some defined keys (i.e. similar to how JDBC
> > connections are often configured).


The existing AMQConnection class provides such a method...


> > or (probably even more controversially!):
> >
> > session.exchangeDeclare(false, false ...);
> > session.queueDeclare(false, false, ...);
> > session.queueBind(QpidConstants.DIRECT_EXCHANGE_NAME, ...);


The existing AMQSession does it this way... Length of the class is not the
problem, undocumented code, lack of clean encapsulation of responsibilies,
several classes all tightly bound together is. This can all be solved with
my refactoring axe! The session implementation is always going to be long,
just by the number of methods defined in javax.jms.Session, that by itself
does not make it bad.

Gordon, see my above comment. Creating messages can be hidden behind
> factories.


Like the existing set of message factories?

I would like to ask my question again, about what is the reason for writing
a new client from scratch? and what is the plan for integrating it into the
existing code? Is it just an experiment with a new design that will be used
to influence the existing client, or is the intention that the existing
client is to be completely scrapped and replaced?

I don't want to try and defend the existing code too heavily, as already
pointed out, it is ugly in places but it seems to me that there is
re-invention going on when there is already an adequate solution for the
problem. Rather than have an API that I can call in a slightly different way
to what is there already, I think I'd prefer some javadoc to explain what
all the existing parameters are for. What concerns me about throwing away
the existing solution is the time spend re-solving the same problems again,
and the danger of throwing out bug fixes that have been put in as feedback
from customers required them.

The existing client is maturing. Probably it was coded for the success
pathway first, where things could go wrong the original authors just threw
an AMQException or JMSException and forgot about it. Then some of these
failure pathways have been examined more closely, in response to testing and
bug reports and time spent thinking. There are still ways this client can
fail in unexpected ways, but it is getting there, and I feel more than
anything it is in need of completion, by closing off these existing
failures, and fully testing the expected error pathways as well as the
success ones (even better, by simply removing some of the error pathways
that cannot occurr), and by writing the javadoc. Starting from scratch means
undergoing this maturation process again.

One of the disadvantages of implementing a new client from scratch in a
completely new package is that existing code, tests for example, will not be
refactored along at the same time. If you refactor, using say intellij, you
will keep this code up-to-date as you go. For example, if I safe delete a
method, I will have to go through the tests and refactor to the new API to
get things to compile again, then re-run the tests keeping the test suite
up-to-date with developments.

Going off on a tangent, here's a simple scheme I have used succesfully in
the past, for regression testing old bugs as code evolves - bug report goes
in Jira Qpid-203, so you write a test called testQpid203 to expose the bug,
so long as the test is passing the bug remains solved.

Here is a list of things that are buried somewhere in the existing code,
that a complete re-implementation might forget about, or have to re-invent
in a very similar fashion:

Hashed password implementation for SASL.
The ability to turn off prefetch on new connections to work with MULE (MULEs
fault and a pitty we have to have stuff like this in our code, but thats the
real world creeping in).
ConnectionListener to listen for failovers (unfortunately we have an
existing customer using this non-JMS feature... their risk to bear for being
non-JMS, I suppose).
Existing system properties such as amq strict flag.
Synchronous request/response that can be interrupted by fail-over. The way
fail-over works will change for the new protocol, because it supports it
better, but a similar solution involving interruptable tasks and some sort
of retry will inevitably be invented.

This is just stuff that I know of, I haven't fully examined the existing
code, so there are probably other things too.

The danger is leaving existing customers behind on an old branch, and not
being able to bring them easily onto the new branch, for fear of
re-introducing old bugs, or incompatible API changes. I did post about APIs
months ago, to make the point that an API needs to be decided early and
preferably set in stone from then on (things are a bit different for the
.Net because there are less people using it in the wild yet). Unfortunately,
you need to give some carefull consideration before changing a public API
method, and the nice way to do it is to mark the old one @deprecated for a
while, before removing it.

Rupert

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