[
https://issues.apache.org/jira/browse/SOLR-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666042#action_12666042
]
Noble Paul commented on SOLR-972:
---------------------------------
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.
