I do not deny that a standardized framework may be helpful. I'm already suffering from the PTSD of restlet integration. The integration code was extremely complex and a security nightmare.It was added without any perf tests too. It took many years to get rid of that
On Fri, Dec 3, 2021 at 1:37 AM Jason Gerlowski <gerlowsk...@gmail.com> wrote: > > 99% of Solr users never see the java code that implements an API let > alone writing a new API. > > We may be talking past each other here a bit Noble. The JAX-RS > benefits I've been trying to describe are to benefit us developers, > not Solr users. I agree that 99% of our users won't know or care > about it, but who cares. The goal is to make _our_ lives as > maintainers easier going into the future. Jan described it in a word > better than I've been struggling to: it's about "modernization". > > Best, > > Jason > > On Thu, Dec 2, 2021 at 3:34 AM Jan Høydahl <jan....@cominvent.com> wrote: > > > > Agree, Ishan. > > > > Let's welcome and cheer initiatives to modernize this old codebase. > > Diving in deep and un-tangling DispatchFilter like Gus is attempting is > brave. > > And testing JAX-RS to modernize APIs and make the codebas easier to grok > is also not for the faint hearted. > > > > I hope both initiatives end up as a breath of fresh air for Solr > developers. And perhaps users may get their hands on auto-generated > OpenAPI docs for Solr as well! > > Theoretically foundations like this may make it feasible in the future > to auto-generate client code from the spec,so that full Admin API client > support in e.g. Go or Rust may be achievable without hand-coding. But that > is still far away :) > > > > Jan > > > > 2. des. 2021 kl. 05:52 skrev Ishan Chattopadhyaya < > ichattopadhy...@gmail.com>: > > > > > We are discussing this as if moving to an external framework is going > to be smooth. It's not. > > > > Noble, we won't know before someone has given it a try. My hunch > suggests it won't be smooth, but we can decide on that once we see a > concrete solution that 1) works well for all existing APIs (per core or > global) without hacks/workarounds, and 2) has no security implications, and > 3) doesn't clutter our codebase, and 4) doesn't affect our runtime > performance. > > > > On Thu, Dec 2, 2021 at 4:22 AM Noble Paul <noble.p...@gmail.com> wrote: > >> > >> > >> > >> On Thu, Dec 2, 2021 at 2:46 AM Jason Gerlowski <gerlowsk...@gmail.com> > wrote: > >>> > >>> > There are no known issues with the current system > >>> > >>> Maybe you're using hyperbole to emphasise a point, but let's steer > >>> this discussion away from straw-men and caricatures. I mentioned > >>> specific known issues in a previous reply as a direct response to your > >>> question about them. The incomplete support for data types > >>> (SOLR-15619 and SOLR-15796). The inflexible PermissionNameProvider > >>> integration (SOLR-15823). If you consider those "minor", fair enough, > >>> and you're welcome to that opinion. But saying that they don't exist > >>> is a mischaracterization that wastes time and muddies water. > >> > >> > >> We are discussing this as if moving to an external framework is going > to be smooth. It's not. I have seen how hard the Restlet integration was > and how it stood out like a sore thumb. The amount of code required to > integrate Solr APIs into restlet components was 10x more than the amount of > code written for the new framework and it still was incomplete . > Integrating anything to Solr is not simple and it's going to be an ongoing > effort to ensure that all of the functionalities of a SolrRequestHandler > are exposed to the new framework. Every single component that we have today > has ongoing improvements and bug fixes. Using that as an excuse to do a > complete rewrite is probably unwise. > >> > >> > >>> > >>> > Solr is not a general purpose web server where people write APIs > every day > >>> > >>> Totally agree - 99% of the time someone opens an API file in Solr, > >>> they're reading, not writing. So if JAX-RS didn't help that case, it > >>> wouldn't be worth the effort of switching. But IMO it helps that > >>> "read" case a lot. > >> > >> > >> 99% of Solr users never see the java code that implements an API let > alone writing a new API. They wouldn't care if an API is implemented using > a Servlet API, a custom framework or something else. They only care about > the input and output. New end points are rare. > >>> > >>> > >>> JAX-RS defined APIs expose inputs as strongly-typed parameters > >>> (compare to the weakly-typed SolrQueryRequest/SolrParams used today). > >>> JAX-RS enumerates every input to the API in one place. JAX-RS APIs > >>> can return any serializable type as a response (compare to the > >>> near-omnipresent NamedList today). > >>> > >>> (The annotation framework's PayloadObj class gets us a bit of this > >>> benefit, but not all of it and only on POST requests afaik.) > >>> > >>> This is all nice stuff at API-write time, but where it really helps is > >>> in making the code clearer and simpler whenever someone goes to read > >>> it later. No wondering what parameters an API actually takes. No > >>> puzzling out what a bunch of NamedList operations spread throughout > >>> API execution actually produce in the end. etc. > >>> > >>> > The only reason why anyone would need to use this framework is to > write a custom request handler. > >>> > >>> ...except for the majority of people who come in contact with the > >>> framework by reading an existing Solr API? This ties into your point > >>> above about APIs being written infrequently but read all the time. > >>> Improving readability is the big gain here, and I think JAX-RS offers > >>> real improvements in that regard. > >> > >> > >> We had no framework for the last 15+ years and V1 API (the only > actually used API) still uses no frameworks. Even the annotation framework > is not used much even though readability is a lot better in the annotation > based system. Readability has not been an overriding concern for V1 APIs > for sure > >> > >>> Also, to clarify, I'm not asserting that no one configures custom > >>> requestHandlers. I was wondering aloud how common it was, as an open > >>> question. > >>> > >> Your point IS right. IRL, most of our users do not write request > handlers . They write search components , query parsers and other plugins. > Because we are a search engine and not a web server. I have never seen a > user complaining about the V1 API of writing a request handler. They may > actually complain about how hard it is to deploy one. Our users are much > smarter than we give them credit for. > >> > >> > >>> > >>> > We did not fork Jackson. We are using Jackson itself. > >>> > >>> Ah, maybe you're right, "fork" is probably an unfair word. I looked > >>> for the serialization code, and I'll admit there is less than I > >>> thought involved here and I misunderstood how it works. So that's my > >>> bad. The JSON serialization/deserialization discussion is prob a > >>> digression from the core contention about whether JAX-RS would be > >>> helpful. I was curious about your earlier response and couldn't > >>> resist following up here but I should've done so elsewhere to avoid > >>> the distraction. > >>> > >>> Best, > >>> > >>> > >>> Jason > >>> > >>> On Tue, Nov 30, 2021 at 4:12 PM Noble Paul <noble.p...@gmail.com> > wrote: > >>> > > >>> > The annotation framework is just a single class and it is made to > work well with Solr instead of changing Solr to suit the needs of some > external framework. There are no known issues with the current system and > there are unknown issues that you'll face introducing a new framework. > >>> > > >>> > Solr is not a general purpose web server where people write APIs > every day. It's a finished product where people use the publicly available > APIs . We should focus our efforts on making our APIs work well . > >>> > > >>> > On Wed, Dec 1, 2021, 2:14 AM Jason Gerlowski <gerlowsk...@gmail.com> > wrote: > >>> >> > >>> >> > We need to make an API work on a per core basis and cores can > come up and go down randomly > >>> >> > >>> >> Ah, yeah. I'll admit I was overlooking some of the wrinkles around > >>> >> custom request handlers etc. That is a problem for switching to > some > >>> >> off-the-shelf framework for sure. It may still be possible, but > it's > >>> >> definitely a big hurdle. I wonder how commonly users still take > >>> >> advantage of the custom requestHandler stuff these days? I haven't > >>> >> run across many customers who used them extensively, but maybe > that's > >>> >> self-selecting in some way? > >>> > > >>> > > >>> > The only reason why anyone would need to use this framework is to > write a custom request handler. You're also saying nobody writes custom > request handlers. So, what problem are you trying to solve if you think > nobody uses them? > >>> > > >>> > > >>> >> > >>> >> > If SolrJ has a Jackson dependency, it can have a conflict > (different versions) with the Jackson used by the client app > >>> >> > >>> >> SolrJ has a handful of dependencies - is there a reason we take this > >>> >> approach with Jackson, but not with any of SolrJ's other deps? > >>> >> (apache-httpcomponents, apache-commons, zookeeper-client, etc.) > >>> >> > >>> >> Granted, I get that we want SolrJ to be as painless as possible for > >>> >> its users, and jar-conflicts are a part of that and really suck. > But > >>> >> there are good tools out there for handling jar conflicts, and > >>> >> reimplementing chunks of library functionality just to avoid a > >>> >> gradle-dep strikes me as unsustainable from a maintenance/community > >>> >> perspective. Not to mention that forking/mimicking Jackson code > >>> >> deprives our users of any efficiency/security improvements that > >>> >> Jackson might get tomorrow or next week or next year. > >>> > > >>> > > >>> > We did not fork Jackson. We are using Jackson itself. Jackson > supports custom annotations. There was a huge discussion why we should do > it this way. > >>> >> > >>> >> > >>> >> Unless there's some reason specific to Jackson I guess I just don't > >>> >> get it. But if I'm the minority opinion on that, fair enough I > guess. > >>> >> > >>> >> On Tue, Nov 30, 2021 at 5:05 AM Noble Paul <noble.p...@gmail.com> > wrote: > >>> >> > > >>> >> > The @JsonProperty annotations are added because it's a dependency > in SolrJ as well > >>> >> > If SolrJ has a Jackson dependency, it can have a conflict > (different versions) with the Jackson used by the client app. > >>> >> > > >>> >> > On Tue, Nov 30, 2021, 5:21 PM Noble Paul <noble.p...@gmail.com> > wrote: > >>> >> >> > >>> >> >> Also keep in mind that the same endpoint can be accessed with a > core name and a collection name prefixes. > >>> >> >> > >>> >> >> On Tue, Nov 30, 2021 at 3:55 PM Noble Paul <noble.p...@gmail.com> > wrote: > >>> >> >>> > >>> >> >>> True Gus, Almost every framework works outside of > SolrDispatchFilter+ HttpSolrCall. A lot of our initializations occur there. > >>> >> >>> > >>> >> >>> We need to make an API work on a per core basis and cores can > come up and go down randomly. So we need to register these endpoints on a > core. > >>> >> >>> > >>> >> >>> I'm not sure if any framework can achieve the same. > >>> >> >>> > >>> >> >>> On Tue, Nov 30, 2021 at 5:39 AM Gus Heck <gus.h...@gmail.com> > wrote: > >>> >> >>>> > >>> >> >>>> IIRC last time I looked restlet had the unsavory property of > existing outside of the SolrDispatchFilter, unlike everything else which > made for special cases because several things that probably ought to be > their own siervlet filters are glommed into SolrDispatchFilter, like > security, tracing and MDC setup/teardown per request. Restlet wouldn't be > so bad if one could just wrap such filters around it too... > >>> >> >>>> > >>> >> >>>> On Mon, Nov 29, 2021 at 9:42 AM Jason Gerlowski < > gerlowsk...@gmail.com> wrote: > >>> >> >>>>> > >>> >> >>>>> > These are minor improvements compared to a full rewrite of > the entire framework > >>> >> >>>>> > >>> >> >>>>> If you think data type support is minor, fair enough. But to > clarify > >>> >> >>>>> I'm not suggesting a rewrite - I'm suggesting using something > that > >>> >> >>>>> already exists off the shelf. Jersey (e.g.) itself provides > the > >>> >> >>>>> framework - there would be no "rewrite". > >>> >> >>>>> > >>> >> >>>>> re: past restlet use > >>> >> >>>>> > >>> >> >>>>> > It was not playing well with our security framework. The > framework was not working well with Solr APIs > >>> >> >>>>> > >>> >> >>>>> Ah, very interesting! Security isn't something Eric or I > tackled in > >>> >> >>>>> our little spike branch, but it's definitely a concern. Do > you > >>> >> >>>>> remember the specific concerns? Or recall where any of the > discussion > >>> >> >>>>> around this happened? > >>> >> >>>>> > >>> >> >>>>> Without the context of that past discussion, it seems like the > >>> >> >>>>> "PermissionNameProvider" interface could be implemented just > as well > >>> >> >>>>> by a class with (e.g.) Jersey annotations as one with our own > custom > >>> >> >>>>> annotations. Certainly there'd need to be some > >>> >> >>>>> RuleBasedAuthorizationPlugin changes or other integration > code, but > >>> >> >>>>> nothing that feels insurmountable. > >>> >> >>>>> > >>> >> >>>>> Maybe I can try spiking it out soon and find the issues > myself, but > >>> >> >>>>> it'd be much easier if someone happens to remember and can > save me the > >>> >> >>>>> trouble :-p > >>> >> >>>>> > >>> >> >>>>> Best, > >>> >> >>>>> > >>> >> >>>>> Jason > >>> >> >>>>> > >>> >> >>>>> On Fri, Nov 26, 2021 at 12:05 AM Noble Paul < > noble.p...@gmail.com> wrote: > >>> >> >>>>> > > >>> >> >>>>> > The Annotations framework was written after playing with > other frameworks. There were many shortcomings which were hard to overcome. > >>> >> >>>>> > > >>> >> >>>>> > The best example is a per collection API . How do you > register an endpoint for a collection/core ? > >>> >> >>>>> > > >>> >> >>>>> > On Fri, Nov 26, 2021 at 3:42 PM Noble Paul < > noble.p...@gmail.com> wrote: > >>> >> >>>>> >> > >>> >> >>>>> >> > >>> >> >>>>> >> > >>> >> >>>>> >> On Fri, Nov 26, 2021 at 1:03 AM Jason Gerlowski < > gerlowsk...@gmail.com> wrote: > >>> >> >>>>> >>> > >>> >> >>>>> >>> > Is there some problem with our annotations that we hope > to solve using third party dependencies? > >>> >> >>>>> >>> > >>> >> >>>>> >>> I guess so yeah. Third-party deps are just fuller, more > robust > >>> >> >>>>> >>> solutions, whereas our annotations still need support > added now and > >>> >> >>>>> >>> then for even primitive data types like "long" (see > SOLR-15619). > >>> >> >>>>> >> > >>> >> >>>>> >> These are minor improvements compared to a full rewrite of > the entire framework > >>> >> >>>>> >> > >>> >> >>>>> >> > >>> >> >>>>> >>> > >>> >> >>>>> >>> Every JIRA spent doing basic stuff like that is time away > from > >>> >> >>>>> >>> improving Solr in some other way. > >>> >> >>>>> >>> > >>> >> >>>>> >>> So there are feature-gap/capabilities arguments for > moving to a > >>> >> >>>>> >>> third-party dep, sure. But, even if our annotations did > everything > >>> >> >>>>> >>> Jersey+Jackson do today, I think switching would still be > worth it. > >>> >> >>>>> >>> Every LOC in our code base brings along with it some > maintenance cost: > >>> >> >>>>> >>> it might have bugs, needs tested, takes time for new > contributors to > >>> >> >>>>> >>> "grok", etc. Using off-the-shelf here would nuke a whole > bunch of > >>> >> >>>>> >>> that. If off-the-shelf is available for some given > functionality, we > >>> >> >>>>> >>> should need a compelling reason to NOT use it. > >>> >> >>>>> >>> > >>> >> >>>>> >>> Lastly, I think there's an "approachability" argument for > using > >>> >> >>>>> >>> off-the-shelf. Thousands of developers out there are > familiar with > >>> >> >>>>> >>> (e.g.) Jersey, compared to maybe 15 or 20 (in the world) > familiar with > >>> >> >>>>> >>> Solr's custom annotations. Using a well-known technology > like Jersey > >>> >> >>>>> >>> would make Solr all the easier to approach and contribute > to for that > >>> >> >>>>> >>> pool of developers. > >>> >> >>>>> >>> > >>> >> >>>>> >>> > By the way, we have used Restlet in the past and that > has been a regrettable decision. > >>> >> >>>>> >> > >>> >> >>>>> >> > >>> >> >>>>> >>> > >>> >> >>>>> >>> Ah, yeah, that's just the context I'm missing. Anyone > have a pointer > >>> >> >>>>> >>> to related discussions, or remember what made this > "regrettable"? All > >>> >> >>>>> >>> the theoretical benefits in the world don't matter much > if we've > >>> >> >>>>> >>> already tried something like this in the past and decided > against it. > >>> >> >>>>> >> > >>> >> >>>>> >> > >>> >> >>>>> >> It was not playing well with our security framework. The > framework was not working well with Solr APIs > >>> >> >>>>> >> > >>> >> >>>>> >>> > >>> >> >>>>> >>> (Unrelated - Happy Thanksgiving all!) > >>> >> >>>>> >>> > >>> >> >>>>> >>> Best, > >>> >> >>>>> >>> > >>> >> >>>>> >>> Jason > >>> >> >>>>> >>> > >>> >> >>>>> >>> On Thu, Nov 25, 2021 at 7:32 AM Noble Paul < > noble.p...@gmail.com> wrote: > >>> >> >>>>> >>> > > >>> >> >>>>> >>> > Have you gone through an API written using the > @EndPoint annotation? > >>> >> >>>>> >>> > > >>> >> >>>>> >>> > I strongly recommend that you do > >>> >> >>>>> >>> > > >>> >> >>>>> >>> > On Thu, Nov 25, 2021, 11:30 PM Eric Pugh < > ep...@opensourceconnections.com> wrote: > >>> >> >>>>> >>> >> > >>> >> >>>>> >>> >> I have found our V2 API code to be very impenetrable > to understand. Part of it is how the code is intertwined with support for > V1, however it’s also because there aren’t really resources to go look at > to understand how it should work! Maintaining the API should be very > simple work, as they just exist as a translation. The home grown stuff > may make sense if you are a super knowledgable Solr developer, but if you > are just a new person, it’s a lot harder to contribute. > >>> >> >>>>> >>> >> > >>> >> >>>>> >>> >> I was interested in the Jersey stuff because I’ve seen > lots of projects use it very successfully, and if I want to implement > something, well, there are lots of blogs and resources out there! > >>> >> >>>>> >>> >> > >>> >> >>>>> >>> >> Can anyone recap briefly why we dropped RESTlet? And > what lessons learned there might apply to adopting Jersey for API support? > Looking at https://issues.apache.org/jira/browse/SOLR-14659, it was > partly deprecated because we were not using it to support all the API, only > the ManagedResource ones, and > https://issues.apache.org/jira/browse/SOLR-14766 suggests that RESTlet > maybe was no longer being updated? One reason why we spiked out Jersey > was because of the broad support in the Java world! Looking at how much > work we have to do in the V2 API world, we need a much broader pool of > developers contributing to get there! > >>> >> >>>>> >>> >> > >>> >> >>>>> >>> >> Related, are there specific features/aspects of our > annotations that enable things in Solr that couldn’t be done otherwise? > >>> >> >>>>> >>> >> > >>> >> >>>>> >>> >> On Nov 25, 2021, at 2:12 AM, Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >>> >> >>>>> >>> >> > >>> >> >>>>> >>> >> Is there some problem with our annotations that we > hope to solve using third party dependencies? > >>> >> >>>>> >>> >> By the way, we have used Restlet in the past and that > has been a regrettable decision. > >>> >> >>>>> >>> >> > >>> >> >>>>> >>> >> On Thu, Nov 25, 2021 at 10:10 AM Jason Gerlowski < > gerlowsk...@gmail.com> wrote: > >>> >> >>>>> >>> >>> > >>> >> >>>>> >>> >>> Solr's custom annotation framework ('@Endpoint', > '@Command', etc.) has > >>> >> >>>>> >>> >>> cropped up a few times over the past week or two. [1] > [2]. Having them > >>> >> >>>>> >>> >>> on top of mind, I've been wondering - is there a > reason we use our own > >>> >> >>>>> >>> >>> annotations here instead of something off the shelf? > >>> >> >>>>> >>> >>> > >>> >> >>>>> >>> >>> What we have works well enough, but anything > homegrown comes with more > >>> >> >>>>> >>> >>> maintenance burden than we'd have if we used > something off the shelf. > >>> >> >>>>> >>> >>> There are plenty of well-used, active projects out > there whose whole > >>> >> >>>>> >>> >>> purpose is facilitating the whole "annotation based > API" thing > >>> >> >>>>> >>> >>> (Jersey, Restlet, RESTEasy, etc.) - why not use one > of them? > >>> >> >>>>> >>> >>> > >>> >> >>>>> >>> >>> Does anyone know of any technical reasons why we > can't go this route? > >>> >> >>>>> >>> >>> Or have any subjective reasons why we shouldn't? Or > any context on > >>> >> >>>>> >>> >>> why we wrote our own Endpoint, Command, JsonProperty > annotations > >>> >> >>>>> >>> >>> originally? > >>> >> >>>>> >>> >>> > >>> >> >>>>> >>> >>> FWIW, Eric Pugh and I spiked out a small POC > recently, and got > >>> >> >>>>> >>> >>> Jersey+Jackson working for a few simple APIs without > too much trouble. > >>> >> >>>>> >>> >>> [3] Obviously nothing production-ready there, and > there's still a lot > >>> >> >>>>> >>> >>> of open questions (e.g. how would javabin be > supported?), but we both > >>> >> >>>>> >>> >>> came away convinced that it seemed feasible, at > least. Best of all, > >>> >> >>>>> >>> >>> APIs using our current homegrown annotation framework > the switchover > >>> >> >>>>> >>> >>> seems blessedly straightforward, and it doesn't look > like Jersey > >>> >> >>>>> >>> >>> (which we chose mostly arbitrarily) bloats our dist > all that much. > >>> >> >>>>> >>> >>> > >>> >> >>>>> >>> >>> Curious if anyone has thoughts or context on how we > ended up with the > >>> >> >>>>> >>> >>> annotation setup we use today! > >>> >> >>>>> >>> >>> > >>> >> >>>>> >>> >>> Best, > >>> >> >>>>> >>> >>> > >>> >> >>>>> >>> >>> Jason > >>> >> >>>>> >>> >>> > >>> >> >>>>> >>> >>> [1] https://issues.apache.org/jira/browse/SOLR-15182 > (and children) > >>> >> >>>>> >>> >>> [2] > http://mail-archives.apache.org/mod_mbox/solr-dev/202111.mbox/%3CCABEwPvENL41Pm6%2BOmjXb6Sx5N2XjUtnbWhgKOZSrnLjWBA8tcA%40mail.gmail.com%3E > >>> >> >>>>> >>> >>> [3] > https://github.com/gerlowskija/solr/tree/jersey_jaxrs_jackson_solr_apis. > >>> >> >>>>> >>> >>> > >>> >> >>>>> >>> >>> > --------------------------------------------------------------------- > >>> >> >>>>> >>> >>> To unsubscribe, e-mail: > dev-unsubscr...@solr.apache.org > >>> >> >>>>> >>> >>> For additional commands, e-mail: > dev-h...@solr.apache.org > >>> >> >>>>> >>> >>> > >>> >> >>>>> >>> >> > >>> >> >>>>> >>> >> _______________________ > >>> >> >>>>> >>> >> Eric Pugh | Founder & CEO | OpenSource Connections, > LLC | 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy > >>> >> >>>>> >>> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > >>> >> >>>>> >>> >> This e-mail and all contents, including attachments, > is considered to be Company Confidential unless explicitly stated > otherwise, regardless of whether attachments are marked as such. > >>> >> >>>>> >>> >> > >>> >> >>>>> >>> > >>> >> >>>>> >>> > --------------------------------------------------------------------- > >>> >> >>>>> >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >>> >> >>>>> >>> For additional commands, e-mail: dev-h...@solr.apache.org > >>> >> >>>>> >>> > >>> >> >>>>> >> > >>> >> >>>>> >> > >>> >> >>>>> >> -- > >>> >> >>>>> >> ----------------------------------------------------- > >>> >> >>>>> >> Noble Paul > >>> >> >>>>> > > >>> >> >>>>> > > >>> >> >>>>> > > >>> >> >>>>> > -- > >>> >> >>>>> > ----------------------------------------------------- > >>> >> >>>>> > Noble Paul > >>> >> >>>>> > >>> >> >>>>> > --------------------------------------------------------------------- > >>> >> >>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >>> >> >>>>> For additional commands, e-mail: dev-h...@solr.apache.org > >>> >> >>>>> > >>> >> >>>> > >>> >> >>>> > >>> >> >>>> -- > >>> >> >>>> http://www.needhamsoftware.com (work) > >>> >> >>>> http://www.the111shift.com (play) > >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> -- > >>> >> >>> ----------------------------------------------------- > >>> >> >>> Noble Paul > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> -- > >>> >> >> ----------------------------------------------------- > >>> >> >> Noble Paul > >>> >> > >>> >> > --------------------------------------------------------------------- > >>> >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >>> >> For additional commands, e-mail: dev-h...@solr.apache.org > >>> >> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >>> For additional commands, e-mail: dev-h...@solr.apache.org > >>> > >> > >> > >> -- > >> ----------------------------------------------------- > >> Noble Paul > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > > -- ----------------------------------------------------- Noble Paul
