Jerry, it's not a big work at all, besides I'm doing custom PU for my own purposes and can do this modification as well.
Any special instructions about committing changes other than described on UIMA Apache web? Thanks. -----Original Message----- From: Jaroslaw Cwiklik [mailto:uim...@gmail.com] Sent: Monday, May 11, 2009 7:11 AM To: uima-dev@incubator.apache.org Subject: Re: [jira] Commented: (UIMA-1338) Custom plugable ProcessingUnit for CPMEngine Ahh, now I understand. Yes, I agree that the ProcessingUnit as an interface would be a better choice to provide cleaner approach for customizing the code. The customization of PUs was added late in the development cycle of the CPM, specifically to support single threaded Processing. The initial design did not allow for customization of PUs. So the current ProcessingUnit class should probably be renamed to ProcessingUnitImpl and a new ProcessingUnit interface should be added. Does not seem like a lot of work. Jerry Cwiklik On Fri, May 8, 2009 at 6:39 PM, <maksim.likha...@thomsonreuters.com> wrote: > Jerry, > Let see what I mean: > > CPMEngine is references 'ProcessingUnit' which is in turn not the > interface, but a class > > - 1: In order to plug custom 'ProcessingUnit' you have to subclass from > 'ProcessingUnit' > - 2: A good candidate to override is 'processNext', but it this calls: > private handleEOFToken(), even if one what to duplicate this > handleEOFToken calls cpm.processingUnitShutdown, package scope > function in CPMEngine. > - 3: There are no good clean point to override without to be exposed to all > that processing code. > > Ideally it needs well defined points that can be easily overridden with the > maximum control over the CAS/CasData flow, that is > CAS/CasData,CasData/CAS conversions and calling CasProcessor. > > > -----Original Message----- > From: Jerry Cwiklik (JIRA) [mailto:uima-...@incubator.apache.org] > Sent: Friday, May 08, 2009 7:56 AM > To: uima-dev@incubator.apache.org > Subject: [jira] Commented: (UIMA-1338) Custom plugable ProcessingUnit for > CPMEngine > > > [ > https://issues.apache.org/jira/browse/UIMA-1338?page=com.atlassian.jira. plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707361# action_12707361] > > Jerry Cwiklik commented on UIMA-1338: > ------------------------------------- > > Not sure what you mean by > > "... boundaries between CPMEngine and ProcessingUnit not clearly defined." > > The custom ProcessingUnit can be plugged in (as you noted) via a system > param. The CPMEngine creates as many instances of custom ProcessingUnits as > there are processing threads defined in the CPE descriptor: > > > if (System.getProperty("PROCESSING_PIPELINE_IMPL") != null) { > String puClass = System.getProperty("PROCESSING_PIPELINE_IMPL"); > try { > processingUnits[i] = producePU(puClass); > processingUnits[i].setInputQueue(workQueue); > processingUnits[i].setOutputQueue(outputQueue); > processingUnits[i].setCPMEngine(this); > } catch (Exception e) { > > All PUs share the same Input and Output queues. Think of PUs as Worker > threads that share the load. CPMEngine creates them and manages lifecycle of > PUs. > > > > Custom plugable ProcessingUnit for CPMEngine > > -------------------------------------------- > > > > Key: UIMA-1338 > > URL: https://issues.apache.org/jira/browse/UIMA-1338 > > Project: UIMA > > Issue Type: Improvement > > Components: Collection Processing > > Reporter: Maksim Likharev > > Priority: Minor > > Original Estimate: 504h > > Remaining Estimate: 504h > > > > Kind of intended this way through "PROCESSING_PIPELINE_IMPL" system > param, but boundaries between CPMEngine and ProcessingUnit not clearly > defined. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > >
