[jira] Issue Comment Edited: (SOLR-972) EventListener-s creation changed from a per request ( full / delta-imports) scenario to once through the lifetime of the DIH plugin.

["Noble Paul (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666042#action_12666042 ] 

noble.paul edited comment on SOLR-972 at 1/21/09 8:04 PM:
----------------------------------------------------------

bq.I am not sure if we can apply such generality since Context is bound to be different for different invocations 

The Context itself will not be same for different invocations but the behavior of the new one is going to be consistent

imagine we have a scope "dataimporter" and you can set an attribute at that scope by calling
{code}
context.setAttribute("any_name",the_value,"dataimporter");
//some time later you can get back the same object
Object the_value =  context.getAttribute("any_name","dataimporter");
//do my ops here
{code}

It is still possible for you to share Objects in a static variable in your EventListener. 







      was (Author: noble.paul):
    bq.I am not sure if we can apply such generality since Context is bound to be different for different invocations 

The Context itself will not be same for different invocations but the behavior of the new one is going to be consistent

imagine we have a scope "dih" and you can set an attribute at that scope by calling
{code}
context.setAttribute("any_name",the_value,"dih");
//some time later you can get back the same object
Object the_value =  context.getAttribute("any_name""dih");
//do my ops here
{code}

It is still possible for you to share Objects in a static variable in your EventListener. 






  
> 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.