You are viewing a plain text version of this content. The canonical link for it is here.

Posted to solr-dev@lucene.apache.org by wojtekpia <wo...@hotmail.com> on 2008/08/25 19:29:24 UTC

Package Access Issues / Extending FacetComponent

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.
-- 
View this message in context: http://www.nabble.com/Package-Access-Issues---Extending-FacetComponent-tp19148122p19148122.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

Re: Package Access Issues / Extending FacetComponent

Posted by wojtekpia <wo...@hotmail.com>.

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
>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Package-Access-Issues---Extending-FacetComponent-tp19148122p19280476.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

Re: Package Access Issues / Extending FacetComponent

Posted by wojtekpia <wo...@hotmail.com>.

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
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Package-Access-Issues---Extending-FacetComponent-tp19148122p19206872.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

Re: Package Access Issues / Extending FacetComponent

Posted by Chris Hostetter <ho...@fucit.org>.

: 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