[ https://issues.apache.org/jira/browse/SOLR-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kay Kay updated SOLR-972: ------------------------- Summary: EventListener-s creation changed from a per request ( full / delta-imports) scenario to once through the lifetime of the DIH plugin. (was: EventListener are not created per request ( full / delta-imports) but rather instantiated once per lifetime of the application - maintaining state + efficient ) > EventListener-s creation changed from a per request ( full / delta-imports) > scenario to once through the lifetime of the DIH plugin. > ------------------------------------------------------------------------------------------------------------------------------------ > > Key: SOLR-972 > URL: https://issues.apache.org/jira/browse/SOLR-972 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler > Environment: Java 6, Tomcat 6 > Reporter: Kay Kay > Fix For: 1.4 > > Attachments: SOLR-972.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > The EventListener plugin for notification of start / end import events > (SOLR-938) creates an instance of EventListener before every notification. > This has 2 drawbacks. > * No state is stored between successive invocations of events as it is a new > object > * When writing plugins for delta imports - it is very inefficient to do a > class loader lookup by reflection / instantiate an instance and call a method > on the same. > Attached patch has one EventListener through the lifetime of the DIH plugin . > Also EventListener is changed to an interface rather than an abstract class > for better decoupling (especially painful when the start/end eventlistener > has an independent hierarchy by itself ). > By default, a no-op listener is registered to avoid boiler plate code to > check if there is a start / end listener specified. Efficient JRE impls > should be able to optimize the no-op for minimum overhead compared to > checking the reference for null and branching out. > Specifying an onImportStart / onImportEnd overrides the default handler > though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.