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

[Eric Johnson <eric@tibco.com>]

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