[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]