> [Nigel] I've read your comments on that proposal (in the Java EE EG).
> Do you think this would address the issues you mention?
> [Reza] Sort of, but I figured I'll leave it alone for now.
> It still feels a bit too high level for me. I would have expected settings more in line with data sources.
> For example, here are some configuration examples for ActiveMQ:
> http://activemq.apache.org/connection-factory-properties.html.
Since this is a separate topic from how to improve the JMS API, I thought I'd move this to a separate thread.
The issue here is some proposals currently presented to the Java EE platform EG which would allow applications to
specify in some XML config file how the application server should create the JMS resources (connection factories and
destinations) needed by the application.
Currently the Java EE spec says nothing about how such resources are created, leaving this up to the person deploying
the application to do using app server-specific tools. (Standalone JMS adopts a similar position, saying nothing about
how administered objects are created).
I think the requirement to be able to define how JMS (and other) resources are created in the app server has come from
the needs of PaaS applications, for which an application may need to be deployed without any human intervention.
For this reason, Linda DeMichiel, co spec lead for Java EE, has (in conjucntion with me) produced the following "straw
man" proposal:
http://java.net/attachments/lists/javaee-spec/jsr342-experts/2011-07/36/ResourceConfiguration.pdf
This covers both destination resources and connection factories. The latter is of the most interest. The document
proposes that a connection factory in an application server can be defined in terms of
* description: description of the resource
• name: the jndi name of the resource being defined (required)
• resource-adapter-name: resource adapter name
• resource-type: JMS connection factory, e.g., javax.jms.QueueConnectionFactory. If not specified, this defaults to
javax.jms.ConnectionFactory.
• user: User name to use for connection authentication.
• password: Password to use for connection authentication.
• clientId: JMS client identifier to be associated with a Connection
• max-pool-size: Maximum number of connections that should be concurrently allocated for a connection pool.
• property: resource property. This may be a vendor-specific property. Any number of properties may be specified.
Reza compares this with the ActiveMQ list of resource adapter connection factory properties:
http://activemq.apache.org/connection-factory-properties.html.
* ServerUrl
* user
* password
* clientId
* UseInboundSession
These both agree about the need to be able to define user, password and clientId. Let's consider the differences:
The ActiveMQ list doesn't mention JNDI name. This is technically correct since JNDI name isn't actually a property of
the connection factory itself. However a JNDI name is still needed when the application server actually creates it,
since that's how the application will subsequently locate it.
UseInboundSession seems to be a specific feature of the ActiveMQ RA.
Linda's/my proposal includes resource-adapter-name. Obviously that wouldn't be appropriate in the list of ActiveMQ RA
connection factories, given that by definition that list is for the ActiveMQ RA!
Linda's/my proposal includes max-pool-size. A data source definition also contains several other conneciton pool
properties. It's arguable whether an application needs to be able to specify all the behaviour of the connection pool.
max-pool-size was the only one I thought essential, since if clientId is set, max-pool-size needs to be restricted to 1.
So I think the only significant difference is that Linda's/my proposal doesn't mention ServerURL or any other equivalent
connection string. I left this out because there's no such concept in JMS, it would not be portable, and that it wasn't
needed anyway when using the JMS provider included in the platform. However the JMS EG may want to discuss recognising
the concept of an opaque connection string that is used by the connection factory when creating a connection (Julien
mentioned this). In that case it would make sense to allow that to be defined along the other properties listed in
Linda's document.
However, the document presented to the Java EE EG is intended to be a "straw man" for discussion. Comments can be passed
back either via the two members of the JMS 2.0 EG who are also on the Java EE EG, or via me.
Nigel