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 > <mailto: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 > <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 > > <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 > <https://github.com/gerlowskija/solr/tree/jersey_jaxrs_jackson_solr_apis>. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > <mailto:dev-unsubscr...@solr.apache.org> > For additional commands, e-mail: dev-h...@solr.apache.org > <mailto:dev-h...@solr.apache.org> > _______________________ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
