Looks good.
On 2/17/2012 1:13 PM, Nigel Deakin wrote:
>
> 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
>
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2112/4815 - Release Date: 02/17/12
>
>