Mike, I remember a while back a handful of us discussing renaming nifi-standard-services-api-nar to something more generic like nifi-standard-component-api-nar or something like that, specifically for this reason. I'd be very hesitant to ask people to inherit nifi-standard-nar, just because there are a lot of dependencies that would be pulled in, so conflict resolution could potentially get hairy.
We should also probably pull BinFiles into the api nar, and refactor MergeContent to have an AbstractMergeContent processor. This allows a developer to very easily extend AbstractMergeContent and provide their own Merge Formats, without dealing with the complexity of the merging code. But these are separate tickets for sure. ---------------------------------------- > Date: Mon, 18 May 2015 10:51:13 -0400 > Subject: Re: JMS vendors > From: [email protected] > To: [email protected] > > There is no JIRA ticket yet. Perhaps we can agree on an approach before > writing the ticket. > > Mark, I was thinking the custom nar would inherit from the > nifi-standard-nar instead of the standard-services-api-nar. A processor > isn't a service, so I didn't even think of standard-services-api-nar. Then > just "class MyPutJMS extends PutJMS" inside my custom nar and go. > > I'm sure there are all kinds of approaches we could take here, so if the > community wants to implement something fancier, that's cool. > > -- Mike > > > On Mon, May 18, 2015 at 10:20 AM, Mark Payne <[email protected]> wrote: > >> 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. >>>> >> >>
