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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to