You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Christian Schneider (JIRA)" <ji...@apache.org> on 2006/11/12 15:22:02 UTC
[jira] Created: (SM-745) Allow usage of other JMS providers than
ActiveMQ
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] Commented: (SM-745) Allow usage of other JMS providers than
ActiveMQ
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-745?page=comments#action_37429 ]
Guillaume Nodet commented on SM-745:
------------------------------------
The main problem will come from the discovery mechanism.
Currently, the jms / jca flow uses the ActiveMQ feature called "Advisory Topics".
See http://www.activemq.org/site/advisory-message.html
This feature is used so that a new node in the cluster will be detected by receiving
a message in onAdvisoryMessage method. This one will send messages to
broadcast its internal activated endpoints. This will need to be rewritten to use
standard topics.
> 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
>
>
> 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] Resolved: (SM-745) Allow using Tibco for the JMSFlow
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet resolved SM-745.
--------------------------------
Resolution: Fixed
Thanks a lot for this patch Christian !
I have just slightly modified it to keep the old class name for ActiveMQ and to use reflection for Tibco,
as the tibco jars are not public.
Could you check it still works for you ?
Author: gnodet
Date: Thu Mar 8 05:59:26 2007
New Revision: 516044
URL: http://svn.apache.org/viewvc?view=rev&rev=516044
Log:
SM-745: Allow using Tibco for the JMSFlow
Added:
incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/nmr/flow/jms/AbstractJMSFlow.java (with props)
incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/nmr/flow/jms/JMSFlowTibco.java (with props)
Modified:
incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/nmr/flow/jms/JMSFlow.java
> Allow using Tibco for the JMSFlow
> ---------------------------------
>
> Key: SM-745
> URL: https://issues.apache.org/activemq/browse/SM-745
> Project: ServiceMix
> Issue Type: New Feature
> Components: servicemix-core
> Affects Versions: 3.0.1
> Reporter: Christian Schneider
> Assigned To: Guillaume Nodet
> Fix For: 3.2
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-745) Allow usage of other JMS providers than
ActiveMQ
Posted by "Christian Schneider (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-745?page=comments#action_37492 ]
Christian Schneider commented on SM-745:
----------------------------------------
I have found a feature in tibco ems that is similar to activemq´s advisory topics. They call it montor topics.
So it should be possible to write a special JMSFlow for Tibco ems. I think I will do so later this winter.
I also think jms and jca flows could share a common base class. The handling of endpoint publishing is quite similar.
> 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.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
[jira] Commented: (SM-745) Allow usage of other JMS providers than
ActiveMQ
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-745?page=comments#action_37445 ]
Guillaume Nodet commented on SM-745:
------------------------------------
Maybe one way would be to just publish a message to a topic when a node is started.
(which is what ActiveMQ does actually).
The problem is mainly to discover failed nodes (and this is the main reason to use
ActiveMQ advisories iirc).
I was also thinking of making the jms / jca flows inherit a common base classes,
as there is some commong logic in both.
> 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
[jira] Commented: (SM-745) Allow usage of other JMS providers than
ActiveMQ
Posted by "Christian Schneider (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-745?page=comments#action_37548 ]
Christian Schneider commented on SM-745:
----------------------------------------
Dynamic creation of queues is also possible in Tibco EMS so we should have no problem with this.
I only wonder how security is achieved with dynamic queues. As far as I know everyone can listen and write to a dynamic queue.
Can you tell me how the security in servicemix works. I have seen the authorization map is used to authorize users. But I have not yet understood how the authentication works. I know that you can use username/password to access the JMS server but how is this user token transported to the destination? Do I have to do anything special for Tibco EMS to achieve good authentication?
> 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.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
[jira] Updated: (SM-745) Allow usage of other JMS providers than
ActiveMQ
Posted by "Christian Schneider (JIRA)" <ji...@apache.org>.
[ 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
Posted by "Christian Schneider (JIRA)" <ji...@apache.org>.
[ 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
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-745?page=all ]
Guillaume Nodet updated SM-745:
-------------------------------
Fix Version/s: 3.1
(was: 3.0.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
> Fix For: 3.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
[jira] Commented: (SM-745) Allow usage of other JMS providers than
ActiveMQ
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-745?page=comments#action_37542 ]
Guillaume Nodet commented on SM-745:
------------------------------------
I agree with the common shared class.
Another thing which is specific to ActiveMQ, is the fact that queues are created dynamically.
The jms / jca flows uses lots of different destinations ... and ActiveMQ does not need them
to be created through an admin console.
> 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.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
[jira] Updated: (SM-745) Allow usage of other JMS providers than
ActiveMQ
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ 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
Posted by "Christian Schneider (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (SM-745) Allow usage of other JMS providers than
ActiveMQ
Posted by "Christian Schneider (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-745?page=all ]
Christian Schneider updated SM-745:
-----------------------------------
Attachment: jmsflow2.patch
This patch creates a new Class JMSFlowActiveMQ and makes the JMSFlow abstract.
All references to activemq are removed from JMSFlow and put into JMSFlowActiveMQ.
RemoteServiceMixClient is changed to be configurable. So the specific JMSFlow can be set.
Some tests are changed to use JMSFlowActiveMQ instead of JMSFlow.
> 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
>
>
> 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 using Tibco for the JMSFlow
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet updated SM-745:
-------------------------------
Component/s: servicemix-core
Fix Version/s: 3.2
Assignee: Guillaume Nodet
Issue Type: New Feature (was: Improvement)
Summary: Allow using Tibco for the JMSFlow (was: Allow usage of other JMS providers than ActiveMQ)
> Allow using Tibco for the JMSFlow
> ---------------------------------
>
> Key: SM-745
> URL: https://issues.apache.org/activemq/browse/SM-745
> Project: ServiceMix
> Issue Type: New Feature
> Components: servicemix-core
> Affects Versions: 3.0.1
> Reporter: Christian Schneider
> Assigned To: Guillaume Nodet
> Fix For: 3.2
>
> 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.
-
You can reply to this email to add a comment to the issue online.