On 14/02/2012 17:17, Nigel Deakin wrote:
>
> In the course of working on the Early Draft a number of issues have come to mind, or have been brought to my attention.
> We don't necessarily need to resolve all these issues before the early draft. For the "major issues" below it might be
> better if we left things as they are and asked for comments. The the "minor issues" below are more straightforward and I
> am tempted to try to address them before the early draft.
>
I've made a few small changes to the early draft to address the relatively minor issues I raised in this email. Here's a
summary.
A few comments have come in whilst I've been writing this, which I'll respond to separately (otherwise I'll never manage
to send this email)
>
> MAJOR ISSUES
> ============
>
> * Simplified API: How should message consumers be represented?
> --------------------------------------------------------------
(snip)
> * Injecting a MessagingContext
> ------------------------------
>
> Do we need to define what the lifecycle (scope) of the underlying MessagingContext is? If so, how should this be specified?
(snip)
> * Batch message delivery
> ------------------------
(snip)
I *haven't* made any changes to address these issues. We've been discussing these three issues and I think the
discussion needs to continue. I'm not sure we need to delay the Early Draft until we resolve them.
However I have made changes to address the other issues below:
>
> What do people think?
>
> * Send payload/receive payload messages
> ---------------------------------------
>
> The simplified API proposes new methods to send a message payload directly, with the JMS provider wrapping it in an
> appropriate JMS message. It also proposes two messages to synchronously receive a message payload directly, with the JMS
> provider automatically extracting it from the JMS message.
>
> These proposals currently cover String (TextMessage) and Serializable (ObjectMessage) payloads only.
>
> I'd be particular interested in comments on the API proposed for this, and suggestions as to what the API might look
> like for other payload types.
There is no particular reason these cover TextMessage and ObjectMessage and not MapMessage and BytesMessage, so I've
extended the API to support those message types as well.
I've added new methods on MessagingContext to send the Map and byte[] payloads directly as MapMessage and BytesMessage,
and extended the existing methods on SyncMessagingContext that receive message payloads directly to support MapMessage
and BytesMessage.
>
> MINOR ISSUES
> ============
>
> * Specifying user and password for an injected MessagingContext
> ---------------------------------------------------------------
>
> I've missed out any way to set the user and password that are used when creating the MessagingContext. My immediate
> thought is to add a new annotation JMSCredentials:
>
> @Inject
> @JMSCredentials(user,password)
> private MessagingContext context;
I've now added this. It actually looks like this:
@Inject
@JMSConnectionFactory("jms/connectionFactory")
@JMSPasswordCredential(userName="admin",password="mypassword")
private MessagingContext context;
I'm not sure how much use this is, but given that the JMS API allows a user and password to be specified it seems
reasonable to extend the injection API to support this. There's a Java EE initiative to allow passwords in annotations
to be aliased, to avoid the use of plain text passwords, and I would expect we would make use of this.
>
> * MessagingContext: setClientID(String clientID)
> ------------------------------------------------
>
> It has been pointed out that the above method would attempt to set clientID on a connection that has already been used
> to create a session. This would violate section 4.3.2 of the spec which states "If a client explicitly does the set it
> must do this immediately after creating the connection and before any other action on the connection is taken."
>
> We should clarify the spec to make it clear that calling setClientID on a newly-created MessagingContext is permitted
>
> To implement this, the MessagingContext implemention would either need to set clientId using a private API or it would
> need to create the session lazily.
The spec doesn't really need to say anything about this, though I have extended the section on client identifier to
mention MessagingContext.setClientID.
> * MessagingContext: automatically starting a connection
> -------------------------------------------------------
>
> The current proposal is that the connection's start method will be called automatically when setMessageListener,
> setBatchMessageListener (for async) or createSyncMessageConsumer (for sync) are called on the MessageContext object.
>
> It has been pointed out that there are sometimes good reasons for wanting to defer starting a connection until a later
> time, such to give time for an asynchronous consumer to be fully initialised. Section 4.3.3 already discusses this
> possibility.
>
> I was wondering whether we should cater for this by allowing the application should disable the "auto-start"
> functionality. We could leave autostarting as the default behaviour, but allow it to be switched off:
>
> messagingContext.autoStart(false)
>
> You'd need to call this before calling setMessageListener, setBatchMessageListener (for async) or
> createSyncMessageConsumer (for sync))
>
> Where the MessagingCOntext was injected, we could add a new annotation
>
> @Inject
> @JMSAutoStart(false)
> MessagingContext context;
I've now added this. Although this could be considered an "advanced" feature, it's simple enough to add. So there's no
need for users to revert to the standard API just for this.
Nigel