[ 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
