|Re: [jetty-users] Advice about embedding Jetty into a large existing app|
On 5/16/2018 11:53 PM, Greg Wilkins wrote:
It's difficult to give a definitive answer to your questions because there are so many possibilities. A couple of points:
First, thank you for your response. Anything I can get is probably going to help me.
I am aware of very vague nature of what I'm asking. I will be able to come up with more specific questions once I start getting into the work. After reading the "Embedding Jetty" documentation page, I am looking for something with a little more detail, maybe even a post where somebody has documented something similar, embedding Jetty into a large existing webapp project. Somewhere I can read about things that need attention and things to avoid.
* When a jetty distribution is configured in XML, it is essentially just writing java code in XML that creates some objects, calls some setters, then calls the start method. So anything that can be done in the distribution XML can be done in code. * LikeJettyXml is an embedded example that sets up pretty much the full server just as jetty.xml does.
I'm not too worried about replacing jetty.xml, and even web.xml, with code. The embedding documentation is short, but I think the examples it has are likely to cover that pretty well. A lot of what worries me is how to fix the build system. I think I can ask fellow project members for help with a lot of that.
* The start.jar is a different matter, as it's job is to build a classpath and a list of XMLs to execute. So you have to replace that by something that will build your classpath (or a fat jar) and call a main method. There are plugins for that kind of thing. Things like lib/ext are really classpath stuff rather than config stuff.
I think you've confirmed my suspicion. Sounds like most of the config infrastructure related to a full Jetty install is handled by Jetty's start code (with start.jar as the entry point), and I would have to take care of that myself.
* You also might want to consider java 9/10/11 executable jars for this kind of thing.
I'm torn on whether to require Java 9 with the next major version of Solr. It might be a good idea -- we could be close to (or maybe even past) Java 8's end of public support date by the time that version of Solr actually gets released. I will research the executable jar feature.
Back to the top