[
https://issues.apache.org/jira/browse/SOLR-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666193#action_12666193
]
Kay Kay commented on SOLR-972:
------------------------------
I agree with the comment regarding a custom scope for a Context . For those
Context-s that need to be reused this could still be in scope before fetching
to avoid recreating them again but I am more concerned about recreating
EventListener-s .
| It is still possible for you to share Objects in a static variable in your
EventListener.
| The design is modeled like the servlet API. This is akin to storing and
retrieving data from the servletContext,session,request etc .
Sharing via static variables does not seem to be the cleanest way to design .
(What if there are 2 eventListeners one for start and another for end
inheriting from a common class that has shared attributes. Sharing via static
variables ( in the base class) brings unpredictable behavior / and a code
difficult to maintain . )
Imagine a requesthandler in the Servlet having no state and being instantiated
every time for every request. By recreating EventListener-s , we have a similar
analogy . That would make (it already does and I am working on patched version
of Solr) development harder to share any state between successive calls.
> 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.
