John +1
This would also limit the namespace of the destination names to the JMS provider behind the connection factory!
Maybe we should also add getOrCreateQueue/Topic to make it 100% clear what's happening... and getQueue/Topic/Destination would throw an exception if no queue/topic of that name already existed.
On 2012-04-10, at 17:27, John D. Ament wrote:
> Nigel,
>
> I think the process is too complicated for the factory approach and the constructor approach. I would prefer adding two methods (or maybe one or three) to the connection factory (along the lines of):
>
> - getQueue(String)
> - getTopic(String)
> - getDestination(String)
>
> There is little use of having a destination without the underlying connection factory.
>
> (I would also add that similar methods should be added to the new simplified API to avoid needing a connection factory)
>
> John
>
> On Tue, Apr 10, 2012 at 10:53 AM, Nigel Deakin <nigel.deakin_at_oracle.com> wrote:
> On 27/03/2012 15:30, Nigel Deakin wrote:
> > I have logged this issue
> > http://java.net/jira/browse/JMS_SPEC-90
> > in order to capture the issue raised by Ruediger's thread "Why are Destinations resources and not Strings?"
>
> I think there are several directions this particular issue could go, but one that comes to mind is to provide a factory method for Queue and Topic objects similar to that which I have separately proposed for ConnectionFactory objects in JMS_SPEC-89 (http://java.net/jira/browse/JMS_SPEC-89)
>
> This would provide a mechanism for creating Queue and Topic objects which did not require the use of JNDI and did not require the use of Session.createTopic/createQueue. Given that there's no affinity of the Queu or Topic with the Session (as we've already clarified in http://java.net/jira/browse/JMS_SPEC-52), it would seem natural to provide a factory method which does not require a Session.
>
> To be consistent with JMS_SPEC-89 we would declare that this API was for use by Java SE applications, and for Java EE container code (including resource adapters) only, but not for Java EE applications, though, unlike the proposed API to create connection factories, there is no technical reason for this restriction.
>
> Note that this API would, like, Session.createTopic/createQueue, only be concerned with creating a valid Queue or Topic object. They would not require the physical destination to be created though this would not be forbidden.
>
> I would like to suggest two possible variants. I prefer (B). Comments please, together with any preference...
>
> (A) The first approach copies the properties-based approach of JMS_SPEC-89:
> --------------------------------------------------------------------------
>
> When the class name is declared in the code:
>
> Properties props = new Properties();
> props.setProperty("javax.jms.destinationType","javax.jms.Queue"};
> ConnectionFactory cf = new com.acme.jms.AcmeQueue(properties props);
>
> When the class name is a String:
>
> Properties props = new Properties();
> props.setProperty("javax.jms.queueClassName","com.acmejms.AcmeQueue"};
> props.setProperty("javax.jms.destinationType","javax.jms.Queue"};
> Destination queue = javax.jms.DestinationCreator.create(properties props);
>
> However this looks like overkill when the only properties that that a Queue or Topic object needs to have are destinationType and destinationName,.
>
> (B) The second approach is much simpler, and is restricted to speciying destinationType and destinationName directly
> --------------------------------------------------------------------------------------------------------------------
>
> When the class name is declared in the code:
>
> Queue queue = new com.acme.jms.AcmeQueue(String destinationName);
>
> When the class name is a String:
>
> Destination dest = javax.jms.DestinationCreator.create("com.acmejms.AcmeQueue", destinationName);
>
> Nigel
>
>