ISSUE 1 - JMS binding, definition of headers

["Michael Rowley" <mrowley@bea.com>]

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.

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?).

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!

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). 
>
>
>