John,
Over in JMS_SPEC-89 I proposed:
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);
Meanwhile in the simplified API we have four methods on ConnectionFactory to create a JMSContext:
|JMSContext <cid:part1.00060005.02090905_at_oracle.com>| |*createContext <cid:part2.02000006.07080003_at_oracle.com>*()|
Creates a JMSContext with the default user identity and an unspecified sessionMode.
|JMSContext <cid:part1.00060005.02090905_at_oracle.com>| |*createContext
<cid:part4.04040808.06010605_at_oracle.com>*(int sessionMode)|
Creates a JMSContext with the default user identity and the specified session mode.
|JMSContext <cid:part1.00060005.02090905_at_oracle.com>| |*createContext <cid:part6.06030109.03070807_at_oracle.com>*(String
<
http://download.oracle.com/javase/6/docs/api/java/lang/String.html?is-external=true> userName, String
<
http://download.oracle.com/javase/6/docs/api/java/lang/String.html?is-external=true> password)|
Creates a JMSContext with the specified user identity and an unspecified sessionMode.
|JMSContext <cid:part1.00060005.02090905_at_oracle.com>| |*createContext <cid:part8.05030201.02070905_at_oracle.com>*(String
<
http://download.oracle.com/javase/6/docs/api/java/lang/String.html?is-external=true> userName, String
<
http://download.oracle.com/javase/6/docs/api/java/lang/String.html?is-external=true> password, int sessionMode)|
Creates a JMSContext with the specified user identity and the specified session mode.
Are you suggesting we combined these to provide a single method which creates a JMSContext directly?
That's a good question. I think the main issue with doing that is that JMS_SPEC-89 the proposed ConnectionFactoryCreator
was not intended to be used in Java EE applications. That's because in a Java EE application the connection factory
needs to be created by the resource adapter, and there's already an API defined to do this (involving the app server's
ConnectionManager being passed in as a parameter). This means that any new methods which created a JMSContext would also
need to be restricted to Java SE only. My feeling is that we want to keep the differences between the Java EE and Java
SE JMS API to a minimum and that they shouldn't go further than a simple method to instantiate a connection factory.
Once the connection factory is obtained, the way that a JMSContext is created is then the same for both SE and EE
applications.
Nigek
On 04/04/2012 14:46, John D. Ament wrote:
> Nigel,
>
> I was thinking about the simplified API with regard to the new method added for creating connection factories. Would
> it be worthwhile to have a utility method .createMessagingContext(Properties p) that creates the equivalent messaging
> context for the given property set (since messaging context can be created with no arguments from a connection factory).
>
> John
>
> On Fri, Mar 30, 2012 at 11:31 AM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>> wrote:
>
> Thanks for the endorsement. I have now removed this.
>
> Updated javadocs are here:
> The "draft" Early Draft Javadocs are in the usual place:
> http://java.net/projects/jms-spec/sources/repository/content/jms2.0/target/jms-2.0-javadoc.jar
>
> No spec changes were needed.
>
> Nigel
>
>
> On 29/03/2012 12:56, Nigel Deakin wrote:
>
> I have spotted one further possible change that we may want to consider making to the simplified API. This is the
> "subscribe" method, for creating a durable subscription but not a consumer.
>
> context.subscribe(inboundTopic, "mysub", messageSelector, noLocal);
>
> I added this initially because the only alternative was to use createSyncConsumer to create a
> SyncMessageConsumer and
> immediately close it.
>
> SyncMessageConsumer consumer = context.createSyncDurableSubscriber(inboundTopic, "mysub");
> consumer.close();
>
> I thought this was particularly inappropriate because an application which subsequently intended to consume
> messages
> asynchronously would need to create a SyncMessageConsumer.
>
> However following the recent changes, an application which wants to create a durable subscription but not actually
> consume messages from it can do the following:
>
> JMSConsumer consumer = context.createDurableSubscriber(inboundTopic, "mysub");
> consumer.close();
>
> This is identical to how this would be done using the standard JMS 1.1 API.
>
> This suggests that perhaps we don't need
>
> void subscribe(Topic topic, String name, String messageSelector, boolean noLocal);
>
> after all. Applications have managed without it for a decade, and in any case this caters for a pretty rare
> use case
> anyway: in most cases, an application which created a durable subscription would want to go on and consume
> messages from
> it.
>
> So: is the subscribe method on JMSContext unnecessary bloat? Or is it a useful addition to the API? I'm not sure.
>
> Any views?
>
> Nigel
>
>