Just a suggestion and a nod to Joshua Bloch's Item 16, Favor Composition over Inheritance.
This might arguably be a better design if the processor didn't have to be extended at all. Instead, let the JMS processor pull in a ConnectionFactory via the Java ServiceLoader or from a NiFi service. We would provide a standard interface which the processor would use to find valid implementations. Vendor specific JMS setup could be isolated as individual jars or service nars and loaded when needed. To make this really nice, the processor would provide a PropertyDescriptor with a set of allowable values coming from the service loader. When a user configures the JMS, he would be able to have a dropdown of available JMS providers, such as ActiveMQ, SonicMQ, Tibco, etc. (similar to SSL Context Service configuration). In general, I think it would be much more powerful to create final processors of certain families and let them defer to a pluggable lookup service rather than having to extend an abstract processor. Adam On Mon, May 18, 2015 at 11:01 AM, Mark Payne <[email protected]> wrote: > 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. > >>>> > >> > >> > >
