OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-bindings] ISSUE 1 - JMS binding, definition of headers


Michael Rowley wrote:
> I believe I've changed the subject heading according to the guidelines
> in the issue process.  Perhaps it would be best if Eric, as issue
> editor, changes the subject line on the email that announces the issue
> number to use.
> 

+1

> I'm OK with one JIRA "component" per spec.  Not sure a formal decision
> is necessary for this (do we really want to spend conf call time on such
> things?).
> 

No we don't. Power to the Issues editor.

> Regarding this specific issue... I believe the proposed solution should
> be accepted.
> 
> Perhaps the bindings TC can be the first TC to close an issue!
> 

That would be good. +1 to accepting the proposed solution.

-Anish
--

> Michael
> 
> -----Original Message-----
> From: Eric Johnson [mailto:eric@tibco.com] 
> Sent: Monday, October 01, 2007 12:13 PM
> To: sca-bindings@lists.oasis-open.org
> Subject: Re: [sca-bindings] NEW ISSUE: JMS binding, definition of
> headers
> 
> Created issue: http://www.osoa.org/jira/browse/BINDINGS-1
> 
> -Eric
> 
> P.S. I took the liberty of defining a "component" for the individual
> specifications (well, at least JMS so far). Perhaps this is an approach
> that we need to formally approve?
> 
> P.P.S. Someone with more Jira experience - should I be putting in the
> reporter as the person who filed the issue? If so, how, since I don't
> know their JIRA system user names?
> 
> 
> Peshev, Peter wrote:
>> TARGET: 
>>
>> JMS Binding Specification , section 4 (JMS Binding Schema), version
> 1.1
>> (sca-jmsbinding-draft-20070925)
>>
>> DESCRIPTION: 
>>
>> The JMS binding schema defines in two places JMSDeliveryMode as
>> "string", JMSTimeToLive as "int" and JMSPriority as "string". However
> in
>> the JMS API those are defined respectively as int, long and int. 
>>
>> Since TimeToLive is defined as milliseconds the SCA limitation to int
>> forces the developer to provide  expiration times smaller than ~25
> days
>> which may be too small for some long running processes. 
>> The definition of the other two values (string) raises the question
>> whether something else besides int values will be accepted by SCA
>> Runtimes and how it will affect the produced JMS message.
>>
>> PROPOSAL:
>>
>> In both the defined places JMSTimeToLive should be changed to long,
>> JMSPriority should be changed to enumerated type from 0 to 9 (only
>> allowed values by the JMS spec) and JMSDeliveryMode should be changed
> to
>> enumerated type - "PERSISTENT, NON_PERSISTENT". (The names of the two
>> int constants in javax.jms.DeliveryMode which seems to be commonly
>> used). 
>>
>>
>>   


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]