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)
