Having extended GetJMS*/PutJMS* myself to use another JMS vendor, I think we can make this much easier than it currently is.
Right now, the provider's ConnectionFactory creation is buried in the NiFi JmsFactory class which the GetJMS*/PutJMS* processors use. This JmsFactory class doesn't implement an interface or extend a base class, so it cannot be easily replaced or extended. I ended up copying it and the GetJMS*/PutJMS* source into my own project in order to extend them. Not ideal. If we can move provider ConnectionFactory creation into the processors themselves, then doing this would be as simple as extending the GetJMS*/PutJMS* processors and overriding the ConnectionFactory creation method. This is on my list of things that I wanted to work on and contribute, but haven't allocated time for. -- Mike On Mon, May 18, 2015 at 6:35 AM, Toivo Adams <[email protected]> wrote: > Joe, > > You are right, creating special GetJms*/PutJms* version for other vendor is > not difficult. > And yes more specifically I have interested to have only SonicMQ support > because its used heavily. > > I was hoping to have some general solution which helps more easily to start > using any JMS vendor. > > When each user create its own GetJms*/PutJms* version, such version is much > less battle tested than Nifi standard processors (much smaller user base). > > But creating some kind of general JMS solution requires much more effort > than separate version for one vendor. > So it's boils down how big is the demand. > It seems there are not (yet?) many different JMS vendor users in NiFiland? > > > Thanks > Toivo > > > > > -- > View this message in context: > http://apache-nifi-incubating-developer-list.39713.n7.nabble.com/JMS-vendors-tp1558p1567.html > Sent from the Apache NiFi (incubating) Developer List mailing list archive > at Nabble.com. >
