This change has now been made,
in both the JMS 2.0 API
http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/javax/jms/JMSConnectionFactoryDefinition.html
and in the corresponding Java EE 7 schema
https://svn.java.net/svn/glassfish~svn/trunk/schemas/javaee7/src/javaee_7.xsds
Nigel
On 14/01/2013 15:55, Nigel Deakin wrote:
> I would like to suggest one further and final change to the <jms-connection-factory> deployment descriptor element and
> the corresponding javax.jms.JMSConnectionFactoryDefinition annotation. This is to remove the <max-idle-time> element /
> maxIdleTime attribute.
>
> As you may have noticed by now, I have been trying to avoid this element/annotation having standard properties which are
> not clearly defined and widely supported.
>
> Currently, the JMSConnectionFactoryDefinition annotation (which was proposed by the Java EE spec leads)
> defines the following pooling-related attributes:
>
> minPoolSize
> maxPoolSize
> maxIdleTime
>
> The JCA EG is currently reviewing the corresponding general-purpose annotation for JCA connection factories,
> ConnectorConnectionFactoryDefinition. They have taken the view that the only pooling-related properties which should be
> standardised are minPoolSize and maxPoolSize. They decided that maxIdleTime (and initialPoolSize, which we have already
> dropped) were too provider-specific, especially as Java EE itself does not define how connections should be pooled.
>
> I am therefore negotiating with the Java EE spec leads to drop maxIdleTime from both the <jms-connection-factory>
> deployment descriptor element and the corresponding javax.jms.JMSConnectionFactoryDefinition annotation.
>
> (Remember that there is nothing to prevent a vendor supporting maxIdleTime as a vendor-specific property.)
>
> This would leave the full list of standard attributes of JMSConnectionFactoryDefinition as:
>
> clientId
> description
> maxPoolSize
> minPoolSize
> user
> password
> properties
> resourceAdapterName
> transactional
>
> Of these, I think the meaning of "transactional" (whether the connection should participate in JTA transactions) needs
> to be formally defined in JMS, though this may have to wait until JMS 2.1.
>
> Nigel
>
>