Why do we keep talking about Restlet here? Restlet is a stale (at best) project, so not sure why it keeps coming up in a discussion about modernizing our API? Integration with it in Solr was introduced nearly 10 years ago, time to move on and stop using that as an excuse to block adoption of other API frameworks.
Surely anyone committed to this effort, after doing even the most cursory due diligence, will not land on Restlet as the way forward. Jersey is a likely candidate, I'm sure there are others? I actually don't care all that much about which annotations we use to describe our APIs (of course standards are better). What's more important for me, is that we can auto-generate an OpenAPI spec for our APIs. That opens up a world of automated tooling for our users to interact with our APIs. Using JAX-RS / Jersey probably helps get us closer to an automated way to generate an OpenAPI spec but there are other ways to get there as well. In general, it sounds like the objections to modernizing our API fall into three buckets: 1) our bad experience with Restlet, 2) performance is better with our homegrown code, 3) security is too complicated with another framework. Performance overhead added by a framework like Jersey (if there is any) for Admin APIs is mostly irrelevant. You think Jersey is going to be slower at mapping requests to Java method calls? Pretty sure they have that part figured out at this point. As for Solr's security, it also needs to be replaced with a modern framework like Shiro or pac4j or similar. The permissions are basically impossible to understand, even for most committers. This whole idea of allow by default instead of deny by default goes against every security best practice in the industry. So arguing that we need some homegrown API framework to support Solr's obscure authz scheme seems a bit backwards to me. Once you start using standard API frameworks like JAX-RS, you start getting security integration too, e.g. https://github.com/pac4j/jax-rs-pac4j. Moreover, we can't keep up with all the innovation around security; heck, SolrJ doesn't even support OIDC yet. I'm all for scraping both homegrown frameworks and starting fresh with mature open source frameworks that have all the kinks worked out over many years with many projects using them. If you want to talk about stress, try building a non-trivial app with Solr's current API's, that'll induce some stress for sure! Tim On Thu, Dec 2, 2021 at 10:35 PM Noble Paul <noble.p...@gmail.com> wrote: > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
