: I don't quite agree. Actually my particular use case would be easier to : achieve if QueryComponent was subclassable and overridable in the query/docset
making existing components easier to subclass and customize should be a goal ... better ot have people wriging small little subclasses then cut/paste big chunks of code into new components. : > In my mind, the response isn't officially the response until it leaves Solr : > (or at least not until it leaves the component handling part.) : : Yeah, but that gets messy if components are just tossed in to mess with work : other components did. It would make more sense to replace the components : rather than add a MuckingComponent to the end. Making QueryComponent more : easily subclassable will make my life easier at least. There's a difference between "allowing" mucking, "encouraging" mucking, and "practicing" mucking. Components that are included in Solr releases shouldn't do any overt mucking themselves, and they should be easily subclassed to discourage people from mucking by offering easy ways to achieve the same goal -- but i don't see a need for Solr to try and prevent third party components from mucking with things if people really want them to. (which falls in the: if they want to take hte rope we give them and hang themselves fine, but we shouldn't tie it into a noose for them in advance) -Hoss
