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<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 <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<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
>
>