The javadocs say this method is creating the topic identity, i.e. the
It explicitly excludes the creation of the physical destination.
CreateTopic public Topic createTopic(java.lang.String topicName) throws JMSException Creates a topic identity given a Topic name. This facility is provided for the rare cases where clients need to dynamically manipulate topic identity. This allows the creation of a topic identity with a provider-specific name. Clients that depend on this ability are not portable. Note that this method is not for creating the physical topic. The physical creation of topics is an administrative task and is not to be initiated by the JMS API. The one exception is the creation of temporary topics, which is accomplished with the createTemporaryTopic method.
You bring up an excellent point however I must say that requiring the user to administratively create topics to enable them to establish topic's of interest makes for an unsound architecture. In many architectures dynamic topic's need to be created that cannot be known ahead of time. The only solution then is to create these topic's by remote administration such as JMX or the URL approach provided in many JBoss examples. This breaks down the standardization of the JMS API that should allow the same code to be used with different providers.
While TemporaryTopic's can be used to establish true dynamic topic's they may not always be practical as the topic's may be dynamic but might need to confirm to some specific naming structure. What are the architectural reasons for not allowing createTopic() to create the logical representation of the Topic on the server side? Many JMS providers automatically create the topic without requireing the need for customization to the provider. Maybe we can get some other feedback as to the architectural disadvantages to automatically creating the topic. I believe if the topic's can be administratively added through outside means it can only furthur the ease of use and abilities of JBoss to allow the automatic creation of the Topics in the server through createTopic.
Andrew T. Finnell
There are no architectural considersations. It is purely a case of following the spec.
I have little interest in how other jms implementations break the spec, especially
on a method that is explicity described as non-portable.
I don't see how it can be made portable. Although most vendors implement the JMS spec
in a fairly literal manner, the jms api can be used to wrap disparate messaging systems.
e.g. it could wrap an e-mail system, then you could have:
Queue queue = session.createQueue("firstname.lastname@example.org");
Topic mailingList = session.createTopic("MyMailingList@acme.com");
My prefered solution would be for the spec to standardize on a set of jms messages that
could be sent to a spec defined destination (e.g. JMS_ADMIN) to configure the server.
... QueueSender sender = session.createSender(jmsAdmin); AdminMessage adminMessage = session.createAdminMessage(); adminMessage.setType(AdminMessage.CREATE_TOPIC); adminMessage.setName("MyTopic"); adminMesasge.setProperty(...); adminMessage.setRoles(...); sender.send(adminMessage);
But I guess that suggestion will have to wait until work starts on JMS2.0,
there are no plans for such a review that I'm aware of.
I agree that an administration set of commands would be an excellent addition to JMS to provide for a more portable solution across providers. Until then I support we all will make due with what we have. Possibly a standarized JMX solution could be brought into JMS for configuration of queue's and topic's.
This discussion was enlightening as to the reasons createTopic does not create a physical representation of the Topic. It's reassuring to know that JBoss was following the spec and didnt drop the ball on creating topics. I was having doubts as to JBossMQ's viability until our discussion. Thanks.
Andrew T. Finnell