> > > I find it strange though because it is like JMS in a parallel universe: > > JMS Qpid > Connection Connection > Session Session > MessageListener MessageListener > ExceptionListener ExceptionListener > Message Message > BytesMessage ByteBufferMessage > ? FileMessage (why in terms of files? could be > more abstract in terms of InputStream?) >
Quick clarification to go along with my other email. I am very very glad that u bought this up. Infact would have been extreamly happy if u stated this in your very first email. Connection and Session are classes directly from AMQP - so no argument there. Message interface is a true reflection of the AMQP spec. Nothing to do with JMS. Note the distinction. AMQP defines different message properties, DeliveryProperties, ApplicationProperties ..and can extend. In 0-11 we might have MsgGroupProperties. read(), appendData() is obviously common to any message model. So nothing to claim that it looks like JMS. The broker sends replies asynchronously and that includes errors too. ExceptionListener is a generic way of notifying errors asynchronously. It's nothing JMS specific. Do you agree? If u notice. MessageListener is just suger, not part of the core API. I am moving it to the util package as u can only use it with the utility adapter class. BytesMessage is a utiility class that belongs to the implementation not the API. So why the fuss ? If u are not happy with the name u can implement the message API with any name u want. I actually had an inline implementation for the message interface, only reason I moved it was to allow reuse for Arnaud. FileMessage : Another utility class - not part of the API. >>(why in terms of files? could be more abstract in terms of InputStream? Did u look at the code or at the least read the java doc? I am using the FileChannel from nio to make use of the map function which mapps regions of a file into memory. Does this explanation help u? Regards, Rajith
