Hey all,
I've got an updated stab at a JAX-RS integration using Jersey:
https://github.com/apache/solr/pull/975. That PR solves most of the
concerns mentioned above (authc/authz integration, per-core API
registration). It's still definitely in "draft" territory: logging
needs cleaned up, it need
Yes that's true, if you only want to generate clients and not the server
then you can definitely have an easier time of things.
On Tue, 9 Aug 2022 at 14:21, Jason Gerlowski wrote:
> Thanks for the insight Colvin! Spec-driving-the-code sounds appealing
> in a lot of ways (I'd love to have default
Thanks for the insight Colvin! Spec-driving-the-code sounds appealing
in a lot of ways (I'd love to have defaults handled uniformly across
Solr, for instance), but I think Jan's right that it's probably
infeasible for Solr.
And "point taken" about expecting some issues with the tooling!
Best,
Ja
I have recent experience from a SpringBoot / Kotlin application where we use
code-first annotation driven OpenAPI definition. I think that will be the only
feasible way for Solr.
The sweet thing about that approach is that the OpenAPI definitions and
documentation is all done inline with the co
I spent the first few months of this year adopting OpenAPI 3 spec in our
product, which has a fairly large API.
We previously generated a Swagger 1.0 spec from our Java code, now we're
generating our POJOs and JAX-RS endpoints from the OA3 spec.
Aside from needing to get off outdated Swagger 1 to
Makes sense to explore at this point to figure out best order of development.
And with the door open to slightly adapt some URL patterns in v2, should it be
required, it's less likely that roadblocks would derail the entire effort.
Jan
> 8. aug. 2022 kl. 18:10 skrev Jason Gerlowski :
>
> Hey a
I'm excited to see what this looks like!
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, Aug 8, 2022 at 12:11 PM Jason Gerlowski
wrote:
> Hey all,
>
> I spent some time last week digging into OpenAPI and spiking out how
> it could be integrate
Hey all,
I spent some time last week digging into OpenAPI and spiking out how
it could be integrated into Solr. I came away very impressed. It
opens a lot of really cool doors: auto-generated clients and docs,
"Swagger UI", backcompat/api-breakage detection, etc. There's a LOT
to gain.
Another
I wanted to share that our hack day did happen, but it went a bit sideways as
we spent the first half of the day experimenting with how to support CORS in
Solr. So API related, but not JAX-RS API specific. The second half of the
day got consumed by $dayjob.
We’re going to pick it up again n
Thank everyone for the input, it’s been a productive conversation!
Jason and I are planning on another hack day Jan 7th to take some of the
feedback, and work more on how our spike can help meet some concerns/show
promise, so we’ll report back then!
We’re planning on zooming during US East Coas
Two cents from the peanut gallery:
I’ve looked at this before. My opinion:
Our stuff was a just terrible, take your pick on the api version. Reasons
are numerous.
Custom end points is an anti feature. Even worse for cloud.
JAX-RS looked ridiculously sensible.
--
- MRM
some thoughts inline...
On Mon, Dec 6, 2021 at 2:04 PM Noble Paul wrote:
> I'm +1 for modernization
> I just wanted to highlight the hurdles we need to overcome to reach there
>
> SolrRequestHandler is the current framework that serves all requests in
> Solr. This also has associated ways to
>
>
Hey all,
Thanks for all the feedback since I last chimed in here; a lot to
think through for sure.
> This also has associated ways to: register end points and configuration,
> manage lifecycle, collect metrics, enforce security, logging, tracing, etc.
Thanks Noble - this list is super helpful i
I'm +1 for modernization
I just wanted to highlight the hurdles we need to overcome to reach there
SolrRequestHandler is the current framework that serves all requests in
Solr. This also has associated ways to
- register end points and configuration
- manage lifecycle
- collect metrics
FYI, I misspelt "Amazon Ion" to "Amazon Eon". I meant this:
https://en.wikipedia.org/wiki/Ion_(serialization_format)
On Mon, Dec 6, 2021 at 6:56 PM Eric Pugh
wrote:
> I was actually poking around trying to find out who actually in the Ruby
> world uses the wt=ruby, and all the projects that inte
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 wrote:
>
> I'm happy to see that there is agreement in a shift towards standard..
>
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://is
> We don't even know what framework to use yet ;-)
We should define what we want to achieve before picking the framework. PoCs
are fine at this point for evaluating various options, but we shouldn't let
any framework dictate what we should or shouldn't do for our users.
On Mon, 6 Dec, 2021, 12:41
Just a simple +1 of support to modernization efforts in general. It's
encouraging to see that Jason & Eric had some fun together on this.
Modernization, I think, helps with the fun of any open-source project, and
thus helps keep everyone interested in continuing and reviewing interest in
Solr. If
On Sat, Dec 4, 2021 at 3:32 AM Timothy Potter wrote:
> 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
Hi Tim,
You bring up great suggestions for improvement to Solr, I really think we
should do something to address all of those as soon as possible. However,
you misunderstand the comments here and mischaracterize Noble's intentions
here.
This discussion was about Jason discussing "Solr's custom an
+1 to pretty much everything Tim said, especially not re-inventing wheels.
Let's use the light weight drop forged aluminum ones that come with steel
belted tubeless radials from the store, not the ones we carve out of our
own block of rubber attached to a bit of steel plate with assorted screws.
We
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
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 A
> 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
a
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
> 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
On Thu, Dec 2, 2021 at 2:46 AM Jason Gerlowski
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 d
> 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 suppo
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 ge
Looks like Jersey can build endpoints and APIs programmatically too, see
https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest3x/resource-builder.html
So I guess it can be done by hooking in at the right places if we want.
It would be really encouraging if we could modernize this pa
On Tue, Nov 30, 2021 at 8:44 PM Jason Gerlowski
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
>
> 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
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 wrote:
> Also keep in mind that the same endpoint ca
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 wrote:
> True Gus, Almost every framework works outside of SolrDispatchFilter+
> HttpSolrCall. A lot of our initializations occur there.
>
> We nee
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
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 MD
> 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 -
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 wrote:
>
>
> On Fri,
On Fri, Nov 26, 2021 at 1:03 AM Jason Gerlowski
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
>
> 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).
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
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
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 ju
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
wrote:
> Solr's custom annotation framework ('@Endpoint', '@Com
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,
45 matches
Mail list logo
