John, Rüdiger
On 10/04/2012 16: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)
Thanks for the comments, which are perfectly reasonable (of course). I'd like to explain in more detail why I made the
proposal I did:
*destination without a connection factory*
The main use case for having a destination without a connection factory (and one I definitely have in mind) is if
someone is developing a generic resource adapter that works with any JMS provider (there are several in existence,
including several from Sun/Oracle). In this case, the resource adapter needs to be able to define its "generic"
administered objects in terms of the administered objects of the underlying JMS provider.
Currently the only way to achieve this in a portable manner is for the "generic" ConnectionFactory, Queue or Topic
object to contain the JNDI name of the "actual" ConnectionFactory, Queue or Topic object, which may be in a totally
different JNDI store. So each administered object, in one JNDI store, needs to point to another administered object in
another JNDI store.
However if there was a standard way to create a ConnectionFactory, Queue or Topic object then the need for this
double-lookup could be removed.
The ConnectionFactory would simply need to hold connectionFactoryclassName and URL, and the Queue or Topic would simply
need to hold queueClassName/topicClassName, destinationType and the queue or topic name.
The API you suggest above would still make this possible, though the Queue or Topic name would now need to hold
connectionFactoryclassName, queueClassName/topicClassName, destinationType and the queue or topic name, which wouldn't
be quite as simple and make Queue and Topic objects dependent on a ConnectionFactory in a way which they weren't before.
*getDestination*
I think having getDestination(String) may be problematical since it suggests that a JMS provider uses a single namespace
for both queues and topic names. However there is nothing in JMS 1.1 that requires this currently (there is no method
session.createDestination(name)) , and indeed at least one JMS provider (GlassFish MQ uses separate namespaces for queue
and topics).
*general*
I agree that it would be perfectly feasible to have createQueue and createTopic methods on ConnectionFactory. However I
wonder whether this is somewhat mis-using this object, given its name.
I am really just looking for a way to bootstrap the creation of provider-specific objects, where these objects may be
connection factories, queues or topics.
I agree my proposal for a DestinationCreator may seem a little complicated - another possibility might be to combine
ConnectionFactoryCreator and DestinationCreator into a single factory, perhaps a AdministrativeObjectCreator.
*simplified API*
> (I would also add that similar methods should be added to the new simplified API to avoid needing a connection factory)
There are already createQueue and createTopic methods on JMSContext. Is that what you meant?
On 11/04/2012 06:51, Rüdiger zu Dohna wrote:
> This would also limit the namespace of the destination names to the JMS provider behind the connection factory!
Only if we define it to be so. I am not proposing any change to the existing createQueue/createTopic behaviour which is
to return a provider-specific object which encompasses a provider-specific queue or topic name. This is (already) a
lightweight process which has no need to contact the JMS server.
>
> 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.
That wasn't a direction I was trying to go in. I was simply trying to provide a portable way to create Queue or Topic
objects without the need for a Session object rather than define methods with new administrative behaviour such as
"throw an exception if queue/topic does not already exist".
However if you like, we could start a new JIRA issue for an API to create a physical queue or topic. Since this would
typically need to support dozens of non-standard properties we would probably want to discourage its use directly from
portable applications and put it in a separate administrative API.
Nigel
>
>
>
> John
>
> On Tue, Apr 10, 2012 at 10:53 AM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto: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
>
>