I'd prefer to not add a new Solr module specific interface, as you originally proposed. Even though we don't yet add Solr-specific Jetty modules, I think your websocket proposal thing sounds like a nice one. Maybe Solr modules should be converted to Jetty modules instead; I'm not sure exactly on the implications but I'd like to embrace Jetty and not, as you say, run away from it.
On Mon, Oct 14, 2024 at 12:36 PM Gus Heck <gus.h...@gmail.com> wrote: > That's an interesting question. Some thoughts... > > If you are meaning to consider using jetty's interfaces so jetty can take a > more active role in the life cycle, one key thing to consider is that > CoreContainer (or a reference that will provide it) is needed by many > things. One thing I looked at while doing this was having this be started > in its own ServletContextListener, but modules are NOT on the classpath > when jetty starts up (they get added to a SolrResourceLoader later) so that > fell entirely flat. Further utilizing jetty would push us to formalize how > such application level modularity would work. (Modification of web.xml, or > use of web-fragment, placement/removal of modules jars where jetty can see > them at start, etc). Alternately, pushing CoreContainer up into a container > managed resource, and then all the standard context deployment stuff in > jetty becomes useful. Our module system is in some ways reinventing some > parts of that wheel. In another way, our entire core/SolrResourceLoader > thing that allows us to load and unload cores and their associated > classpath almost direclty apes the ServletContext web container > infrastructure that allows Jetty (or tomcat or glassfish) to deploy and > undeploy applications and their classpath safely. (and we wrote our own > authn/authz rather than use the stuff that comes with jetty). > > Although I can't imagine finding time to do such a thing, I can imagine a > way to re-architect Solr to actually utilize the capabilities that jetty > provides rather than running away from them and rebuilding them on our > own... Completely running away and dropping jetty entirely is also maybe > not bad, but probably even more work. Where we are now, with Jetty just > acting as a glorified http library and ignoring the rest of it is a bit > strange from a 10,000ft view. It's absolutely true that this experiment in > the linked PR perpetuates and enhances our re-invent a container inside a > container ethos, but It was only a plane ride (and a few moments after, so > I had to pick a small hill to climb). ;) > > If, on the other hand, you just mean that we just use the interfaces > because of their familiarity, and aren't contemplating jetty actually > consuming them, that's much easier to do, but also adds a thing that jetty > can break, making jetty upgrades harder. WRT HK2, if that's more stable and > less likely to change to suit the needs of a particular bit of software, > that's better, but googling it leaves me with a mess of old pre j4ee stuff, > and great difficulty finding whatever the current incarnation actually is. > (there's a red bar at the bottom of the old page that leads to a 404 on the > "status of this migration" > > So stability is a primary concern if we let someone else write the > interfaces. > > But breaking things into more small interfaces with fewer methods might be > a pattern to follow regardless. > > > > On Sun, Oct 13, 2024 at 2:41 PM David Smiley <dsmi...@apache.org> wrote: > > > Just a general question to us all -- do we want to create bespoke > > interfaces for lifecycle or maybe embrace something else? Like Jetty's > or > > maybe HK2 (used by Jersey)? Not sure if this quite makes sense; I > haven't > > thought through the practicalities. > > > > On Sat, Oct 12, 2024 at 11:07 PM Gus Heck <gus.h...@gmail.com> wrote: > > > > > I was traveling, and most of my ongoing work is back on my desktop, so > I > > > entertained myself on a flight by fiddling with an idea that's been > > > rattling around in the back of my head. It seems like it might be neat > to > > > have a websocket interface to solr, but we definitely don't need it to > > live > > > in the main code base since most folks will not use it, so a module > > seemed > > > appropriate. > > > > > > However, I had to do a bit of work to allow a module to start up a > > > socket, since the current infrastructure (as far as I could tell) only > > adds > > > to the classpath. (Possibly I missed something, feel free to point it > > out) > > > Although one *could* add an element to solr.xml to start it, it seems > > > pointless to force the user to declare the module AND edit a config > file > > to > > > do the thing they will always have to do (start a web server socket) if > > > they intend to use the module. So I added a module lifecycle, and > hacked > > in > > > the netty websocket example enough that it starts and stops gracefully > > and > > > answers every request with either "parse error" or "not yet > implemented" > > > etc... > > > > > > Not sure how much or how often I'll get to fiddle with this, but if it > > > sounds interesting to, you can read it and comment on it here: > > > > > > https://github.com/apache/solr/pull/2759 > > > > > > -- > > > http://www.needhamsoftware.com (work) > > > https://a.co/d/b2sZLD9 (my fantasy fiction book) > > > > > > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) >
