Any further comments (especially from JMS vendors)?
So far, Reza and John A have registered support (John suggested some small amendments), and I think this is a good idea too.
Nigel
On 30/03/2012 14:58, Nigel Deakin wrote:
> Thanks for the comments so far (only received from John).
>
> Recap: this is for an API to create a ConnectionFactory for Java SE clients and the Java EE container itself only:
>
> When the class name is declared in the code:
>
> Properties props = new Properties();
> props.setProperty("javax.jms.url","jms://localhost:1234"};
> props.setProperty("javax.jms.user","admin"};
> props.setProperty("javax.jms.password",password);
> ConnectionFactory cf = new com.acme.jms.AcmeConnectionFactory(properties props);
>
> When the class name is a String:
>
> Properties props = new Properties();
> props.setProperty("javax.jms.connectionFactoryClassName","com.acmejms.AcmeConnectionFactory"};
> props.setProperty("javax.jms.url","jms://localhost:1234"};
> props.setProperty("javax.jms.user","admin"};
> props.setProperty("javax.jms.password",password);
> ConnectionFactory cf = javax.jms.ConnectionFactoryCreator.create(properties props);
>
> I've discussed this in more detail here (within Oracle) and have made a few small changes to the proposal. Please see
> http://java.net/jira/browse/JMS_SPEC-89 for the updated version.
>
> 1. I've stayed with using a java.util.Properties rather than a java.util.Map<String,String> because the Properties
> object offers various useful methods for reading properties from a file. Although Properties pre-dates generics and is
> not so typesafe it is a long-established part of Java SE, and has long been used in the JNDI API for a similar purpose.
> This new feature could be criticising for encouraging applications to hard-code provider-specific properties in their
> code which is why I want to make it as easy as possible for applications to read these properties from a file or from
> some other central property storage.
>
> 2. I've kept the name of the method for creating a connection factory to "create" (as in
> javax.jms.ConnectionFactoryCreator.create(properties props)). This reflects the fact that in most cases this method is
> instantiating a lightweight object. I took advice from the WebLogic team who supported the use of "create" rather than
> "getReference".
>
> 3. I've prefixed the property names with javax.jms to avoid any possible name clash with any other properties which may
> be defined in the same file or property storage. I've also clarified the purpose of the user, password, clientId and url
> properties.
>
> 4. I've defined string constants such as ConnectionFactoryCreator.USER for the cases where these properties are set in
> the code, which hopefully will mostly apply to tools.
>
> I've received suggestions for other standard connection factory properties, such as the default delivery mode and
> priority. However I've kept the list of properties very short so we can focus on the API rather than get bogged down
> discussing what properties we want to make standard. We can always add more properties later.
>
> Further comments welcome.
>
> Nigel