I've just committed some refactorings to the JMS block to provide more generic support for using JMS in cocoon. Previously the JMSConnection component was specifically geared towards topic subscription and publishing but did not have support for JMS queuing. Also, it provided a mix of threadsafe (Connection objects) and singlethreaded (Session, Publisher) objects. Instead I've introduced a JMSConnectionManager component that configures, starts, stops and closes JMS Connection objects. This component therefore replaces the JMConnection component.


According to our versioning manifesto: "An unstable block has an API that can change without notice." , since the JMS block is unstable we could remove the JMSConnection component. But perhaps people using it in their own code currently or have otherwise objections (I also still need to rewrite some component in the Slide block). So please let me know your opinion about it if you have any. Perhaps it is better to go through deprecation period before first.

--
Unico

Reply via email to