Package Access Issues / Extending FacetComponent

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Package Access Issues / Extending FacetComponent

wojtekpia
I'm creating a FacetComponent that is a simple extension of the regular one (I'm creating numeric ranges for some fields). I would like to preserve most of the original functionality, and only override the default behavior for some specific cases. The problem I'm facing is that a lot of the core behavior uses package-restricted classes that I don't have access to from my own jar. The classes are:

FieldFacet
DistribFieldFacet
FacetInfo
ShardFacetCount

And the ResponseBuilder's _facetInfo member variable.

Recently, the ShardResponse class became public for a similar need (http://www.nabble.com/ShardResponse-IllegalAccessError-to18461917.html#a18507845). I looked through its object model, and all the data I need is contained there. I could override just the finishStage method using the ShardResponse data, but it means I'd also have to also re-write all the functionality in the classes listed above.

What's the best way for me to proceed? The options I've considered:

1. Copy all those classes into my own package, copy the FacetComponent into my own package, and then override as I intended (there might still be some issues with accessing ResponseBuilder._facetInfo).
2. Re-write the entire component using only the ShardResponse.
3. Make those classes publicly accessible.

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Package Access Issues / Extending FacetComponent

hossman

: 1. Copy all those classes into my own package, copy the FacetComponent into
: my own package, and then override as I intended (there might still be some
: issues with accessing ResponseBuilder._facetInfo).
: 2. Re-write the entire component using only the ShardResponse.
: 3. Make those classes publicly accessible.

short term 1&2 are your best bets ... long term submit a patch that
makes things public/protected as you think are warranted.  We'll use the
Jira issue to discuss wether those are APIs that we want to really expose
to plugin developers, or if we want to refactor the APIs to clean them up.

(many things tend to be private or package-protected initally to protect
against people using half baked APIs ... it's discussions like this theat
help shake them out and make them more robust and usable)



-Hoss

Reply | Threaded
Open this post in threaded view
|

Re: Package Access Issues / Extending FacetComponent

wojtekpia
Thanks, I'll do that. I'll wait until 1.3 has been released to submit a patch. (This will be my first one, so bear with me!)

hossman wrote
: 1. Copy all those classes into my own package, copy the FacetComponent into
: my own package, and then override as I intended (there might still be some
: issues with accessing ResponseBuilder._facetInfo).
: 2. Re-write the entire component using only the ShardResponse.
: 3. Make those classes publicly accessible.

short term 1&2 are your best bets ... long term submit a patch that
makes things public/protected as you think are warranted.  We'll use the
Jira issue to discuss wether those are APIs that we want to really expose
to plugin developers, or if we want to refactor the APIs to clean them up.

(many things tend to be private or package-protected initally to protect
against people using half baked APIs ... it's discussions like this theat
help shake them out and make them more robust and usable)



-Hoss
Reply | Threaded
Open this post in threaded view
|

Re: Package Access Issues / Extending FacetComponent

wojtekpia
I've created SOLR-748 for this issue and attached a patch:

https://issues.apache.org/jira/browse/SOLR-748


wojtekpia wrote
Thanks, I'll do that. I'll wait until 1.3 has been released to submit a patch. (This will be my first one, so bear with me!)

hossman wrote
: 1. Copy all those classes into my own package, copy the FacetComponent into
: my own package, and then override as I intended (there might still be some
: issues with accessing ResponseBuilder._facetInfo).
: 2. Re-write the entire component using only the ShardResponse.
: 3. Make those classes publicly accessible.

short term 1&2 are your best bets ... long term submit a patch that
makes things public/protected as you think are warranted.  We'll use the
Jira issue to discuss wether those are APIs that we want to really expose
to plugin developers, or if we want to refactor the APIs to clean them up.

(many things tend to be private or package-protected initally to protect
against people using half baked APIs ... it's discussions like this theat
help shake them out and make them more robust and usable)



-Hoss