I was actually poking around trying to find out who actually in the Ruby world 
uses the wt=ruby, and all the projects that intersect with Solr seems to do 
wt=json ;-)


> On Dec 6, 2021, at 8:17 AM, Jan Høydahl <jan....@cominvent.com> wrote:
> 
> I'm happy to see that there is agreement in a shift towards standard..
> 
> Bwt - in v3, lets get rid of "wt" parameter and instead use standard HTTP 
> Accept header to tell Solr whether you want the response as JSON or XML. 
> Maybe we are even ready to deprecate XML, PYTHON, XSLT, Excel..
> See https://issues.apache.org/jira/browse/SOLR-10998
> 
> Jan
> 
>> 3. des. 2021 kl. 17:31 skrev Timothy Potter <thelabd...@gmail.com>:
>> 
>> 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
>> 
> 
> 
> ---------------------------------------------------------------------
> 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 <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.

Reply via email to