On Wed, Feb 25, 2009 at 8:02 PM, Benjamin Liles <bli...@library.tamu.edu>wrote:
> I was looking at adding support to the XPathEntityProcessor for a > DeltaImport by adding a new parameter, deltaUrl, in order to support > harvesting from an OAI-PMH server into SOLR. I wasn't planning on bothering > with getting commit access to the repository so I was looking to extend the > XPathEntityProcessor in my own package. I ran into a problem because most > of the methods on the class are private instead of protected. I only want to > override a methods and not all of them. Cool, does OAI-PMH expose a method identify deltas and deletions? Just a thought, would adding a deltaUrl confuse users because most APIs do not support delta? Another option (for your use-case) could be to add another root entity specific for delta import only. DIH supports indexing one or more root entities independently of others. > Should I just modify the XPathEntityProcessor to add the functionality and > submit a patch instead of trying to write my own class that extends the > XPathEntityProcessor? > > Was there a reason for making the methods be private? Public methods come with a baggage because changes have to be back-compatible across releases. But we can make methods public which can be useful to a large number of use-cases. -- Regards, Shalin Shekhar Mangar.
