[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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.
Thanks,
Shawn
