[jira] Updated: (SM-745) Allow usage of other JMS providers than ActiveMQ
[ https://issues.apache.org/activemq/browse/SM-745?page=all ] Christian Schneider updated SM-745: --- Attachment: jmsFlowActiveMQandTibco.zip I have finished the abstract JmsFlow and the implementations for ActiveMQ and Tibco. What do you think can this be included in the servicemix sources ? I guess the Tibco class should not be included in the package. As it introduces a dependency on tibco packages. Perhaps it could exist in a separate module. But then it could also be interesting to remove all dependencies on ActiveMQ from the core and introduce a module for ActiveMQ jms flows. // Setup for Tibco AbstractJMSFlow flow = new JMSFlowTibco(); flow.setJmsURL(tcp://localhost:7222); flow.setUserName(admin); flow.setPassword(); container.setFlow(flow); // Setup for ActiveMQ AbstractJMSFlow flow = new JMSFlowActiveMQ(); flow.setJmsURL(tcp://localhost:61616); container.setFlow(flow); Allow usage of other JMS providers than ActiveMQ Key: SM-745 URL: https://issues.apache.org/activemq/browse/SM-745 Project: ServiceMix Issue Type: Improvement Affects Versions: 3.0.1 Reporter: Christian Schneider Attachments: jmsflow.patch, jmsflow.patch, jmsflow2.patch, jmsflow3.patch, jmsFlowActiveMQandTibco.zip JMSFlow and JCA flow are too tightly bound to ActiveMQ. Instead of ActiveMQ specific classes jms Interfaces should be used where possible. I have attached a patch that replaces ActiveMQConnection and ActiveMQConnectionFactory by the jms equivalents. There is one possible issue with my patch. The getConnectionFactory now returns a ConnectionFactory instead of a ActiveMQConnectionFactory. I don´t know if any other part of the sources depends on the specific class. My patch is of course only the first step. The next could be having a specific subclass JMSFlowActiveMQ that does all stuff that is ActiveMQ specific. I will deliver a second patch for this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-745) Allow usage of other JMS providers than ActiveMQ
[ https://issues.apache.org/activemq/browse/SM-745?page=all ] Guillaume Nodet updated SM-745: --- Fix Version/s: (was: 3.1) Allow usage of other JMS providers than ActiveMQ Key: SM-745 URL: https://issues.apache.org/activemq/browse/SM-745 Project: ServiceMix Issue Type: Improvement Affects Versions: 3.0.1 Reporter: Christian Schneider Attachments: jmsflow.patch, jmsflow.patch, jmsflow2.patch, jmsflow3.patch JMSFlow and JCA flow are too tightly bound to ActiveMQ. Instead of ActiveMQ specific classes jms Interfaces should be used where possible. I have attached a patch that replaces ActiveMQConnection and ActiveMQConnectionFactory by the jms equivalents. There is one possible issue with my patch. The getConnectionFactory now returns a ConnectionFactory instead of a ActiveMQConnectionFactory. I don´t know if any other part of the sources depends on the specific class. My patch is of course only the first step. The next could be having a specific subclass JMSFlowActiveMQ that does all stuff that is ActiveMQ specific. I will deliver a second patch for this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-745) Allow usage of other JMS providers than ActiveMQ
[ https://issues.apache.org/activemq/browse/SM-745?page=all ] Christian Schneider updated SM-745: --- Attachment: jmsflow.patch Same patch with license grant Allow usage of other JMS providers than ActiveMQ Key: SM-745 URL: https://issues.apache.org/activemq/browse/SM-745 Project: ServiceMix Issue Type: Improvement Affects Versions: 3.0.1 Reporter: Christian Schneider Fix For: 3.0.1 Attachments: jmsflow.patch, jmsflow.patch JMSFlow and JCA flow are too tightly bound to ActiveMQ. Instead of ActiveMQ specific classes jms Interfaces should be used where possible. I have attached a patch that replaces ActiveMQConnection and ActiveMQConnectionFactory by the jms equivalents. There is one possible issue with my patch. The getConnectionFactory now returns a ConnectionFactory instead of a ActiveMQConnectionFactory. I don´t know if any other part of the sources depends on the specific class. My patch is of course only the first step. The next could be having a specific subclass JMSFlowActiveMQ that does all stuff that is ActiveMQ specific. I will deliver a second patch for this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-745) Allow usage of other JMS providers than ActiveMQ
[ https://issues.apache.org/activemq/browse/SM-745?page=all ] Christian Schneider updated SM-745: --- Attachment: jmsflow3.patch That is right. I would guess that other JMS Providers have a similar mechanism to publish new nodes. So what we should do is provide a base class that does the common things. When I look at the patch I sent and your explanations I think I can extract even more code into the base class JMSFlow. I have added another patch that moves the adding and removing of nodes into the base class. I also added some documentation. Of course there will be some code to implement for each JMS Provider. But I think we can keep this code small. Allow usage of other JMS providers than ActiveMQ Key: SM-745 URL: https://issues.apache.org/activemq/browse/SM-745 Project: ServiceMix Issue Type: Improvement Affects Versions: 3.0.1 Reporter: Christian Schneider Fix For: 3.0.1 Attachments: jmsflow.patch, jmsflow.patch, jmsflow2.patch, jmsflow3.patch JMSFlow and JCA flow are too tightly bound to ActiveMQ. Instead of ActiveMQ specific classes jms Interfaces should be used where possible. I have attached a patch that replaces ActiveMQConnection and ActiveMQConnectionFactory by the jms equivalents. There is one possible issue with my patch. The getConnectionFactory now returns a ConnectionFactory instead of a ActiveMQConnectionFactory. I don´t know if any other part of the sources depends on the specific class. My patch is of course only the first step. The next could be having a specific subclass JMSFlowActiveMQ that does all stuff that is ActiveMQ specific. I will deliver a second patch for this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
