Looks good.
On 3/30/2012 9:58 AM, 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
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2114/4903 - Release Date: 03/29/12
>
>