Mike, I absolutely agree. I was conceptualizing it working a bit differently in my head, but I think the solution that you laid out here is better than what I was picturing. Excellent.
We will have to be a bit careful here, though. We will need the abstract processor to be pulled into the standard-services-api-nar, I think, so that others can easily extend it. But we don't want to pull any libraries into that nar that aren't absolutely critical, because a lot of nars will be pulling that one in as the parent. Thanks -Mark ---------------------------------------- > Date: Mon, 18 May 2015 10:01:41 -0400 > Subject: Re: JMS vendors > From: [email protected] > To: [email protected] > > 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. >>
