: After a lot of debugging I found out that you cannot extend Solr/Lucene
: classes and override package protected methods, it will silently us the
: super class' method.
        ...
: Has anyone happened to come across this and know if there is a fix for
: extending & overriding package protected methods?

That's a rule of Java - not anything special about Solr/Lucene.

package protected means it's only visible to classes in the same package 
-- jus because you (a human) can read that method, doesn't mean your code 
has any knowledge of it's existence -- you can't override it in a 
subclass, nor can you call it.  The compiler will fail hard if you try the 
later, and warn you of the former if you use the "@Override" annotation 
(it can't warn you of anything w/o the annotation, because it can't even 
see the method to know that there is anything to warn you of - you have to 
explicitly say you are epxecting to override something for it to be able 
to tell you "Hey, wait a minute - no you aren't")

"package protected" is generally used either as an alternative to 
"public" (when we only want other solr code in the same pacakge to access 
it) or as an alterantive to "private" (in cases where ideally no one 
outside the class should call that method, but we still want to be able to 
unit test it).  In either case the objective is to minimize the surface 
area of the API and hide implementation details.

: For a little context, I came across this issue because a client requires
: some slightly modified merge logic within the DistributedUpdateProcessor.

Off the top of my head, i'm not sure what the motivation was here in this 
specific case, or if/why RequestReplicationTracker shouldn't be public -- 
but my suggestion would be to open a jira proposing the specific access
changes you think make sense (to the method in question, and/or 
the new inner class) to make the code more re-usable and see what folks 
think about exposing that bit of the API as "supported"

First though, you may want to take a step back, and instead focus on a 
discussion/jira of what the "slightly modified merge logic" is that you 
are currently using, and propose new hooks for you to do that in the most 
optimal way (not sure if the answer's are the same ... don't want to 
assume this isn't the birth of an XY problem)



-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to