8

I have Jetty jetty-9.2.3.v20140905

My understanding was that jars in lib/jar or lib/ext were automatically on the classpath, but this may have been old behavior from jetty 8.

I'm trying to deploy a webapp with websockets. With my deployed WAR file in the webapps directory, jetty keeps complaining that it cannot find jars sitting right there in the jetty/lib directory (jetty-http, jetty-io, jetty-security, jetty-server, jetty-servlet, jetty-util are the ones my webapp needs that it cannot find)

jars placed in lib/ext are also not picked up when I do a --module-ext

How can I resolve this?

To address the answer below, (editing the original questioN) I have tried enabling the server module, whose server.mod file contains the following lines:

[lib]
lib/servlet-api-3.1.jar
lib/jetty-schemas-3.1.jar
lib/jetty-http-${jetty.version}.jar
lib/jetty-server-${jetty.version}.jar
lib/jetty-xml-${jetty.version}.jar
lib/jetty-util-${jetty.version}.jar
lib/jetty-io-${jetty.version}.jar

From the command line, I do

java -jar start.jar --module=server jetty.port=8182

and the result is:

2014-10-30 15:26:13.907:WARN:oejuc.AbstractLifeCycle:main: FAILED   
org.eclipse.jetty.annotations.ServletContainerInitializersStarter@2635068e: 
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/Handler
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/Handler

org.eclipse.jetty.server.Handler is right there in jetty-server jar sitting in my jetty/lib directory.

Perhaps the jetty.version or jetty.base variables are incorrect?

When I perform a

--list-classpath

I do see all the jars in the lib directory there.

user2197116
  • 667
  • 3
  • 8
  • 21

1 Answers1

9

What documentation are you reading? (link please)

The whole concept of a start.config only exists in Jetty 8 and earlier.

Current documentation is at http://www.eclipse.org/jetty/documentation/current/

That text is not valid for Jetty 9.2.3.v20140905

There is never a good reason to have ALL of the jars in lib/ in the server classpath at the same time. In fact it would result in an invalid environment, as there are different implementations of several core technologies that you can change (such as jsp, jstl, and javax.el). There are also libraries present in lib/ that require 3rd party optional libraries to function (like npn, alpn), which require you to acknowledge a license before they are downloaded.

What libraries are loaded, from either {jetty.home}/lib and/or {jetty.base}/lib are determined by what modules you have enabled in your jetty instance configuration.

To learn about startup, start.jar, command line, modules, libs, xml configuration, configuration properties, {jetty.base}, {jetty-dir}, and {jetty.home}, see the "Startup Documentation" at http://www.eclipse.org/jetty/documentation/current/startup.html

To address your specific question about starting jetty and webapps. (Again, this is all documented in the "Startup Documentation" URL above)

Here's a quick example using {jetty.home} itself (not recommended anymore, but works):

# Unpack the distribution
[~]$ unzip jetty-distribution-9.2.3.v20140905
[~]$ cd jetty-distribution-9.2.3.v20140905

# Copy your war into place
[jetty-distribution-9.2.3.v20140905]$ cp ~/Projects/mywebapp.war webapps/

# Run Jetty
[jetty-distribution-9.2.3.v20140905]$ java -jar start.jar

Now for the more appropriate way, using a {jetty.base}:

# Unpack the distribution
[~]$ unzip jetty-distribution-9.2.3.v20140905

# Make a {jetty.base} directory to house your configuration
[~]$ mkdir myappbase
[~]$ cd myappbase

# Since this is a new {jetty.base}, lets initialize it
[myappbase]$ java -jar ../jetty-distribution-9.2.3.v20140905/start.jar \
  --add-to-start=http,logging,deploy,jsp,ext,resources
INFO: http            initialised in ${jetty.base}/start.ini (appended)
INFO: server          initialised in ${jetty.base}/start.ini (appended)
INFO: logging         initialised in ${jetty.base}/start.ini (appended)
MKDIR: ${jetty.base}/logs
INFO: deploy          initialised in ${jetty.base}/start.ini (appended)
MKDIR: ${jetty.base}/webapps
...(snip)...
MKDIR: ${jetty.base}/lib
MKDIR: ${jetty.base}/lib/ext
INFO: resources       initialised in ${jetty.base}/start.ini (appended)
MKDIR: ${jetty.base}/resources

# Lets see what we have now
[myappbase]$ ls -F
lib/  logs/  resources/  start.ini  webapps/

# Copy your webapp into place
[myappbase]$ cp ~/Projects/mywebapp.war webapps/

# Run Jetty
[myappbase]$ java -jar ../jetty-distribution-9.2.3.v20140905/start.jar
Joakim Erdfelt
  • 46,896
  • 7
  • 86
  • 136
  • I guess that text was from Jetty 8. – user2197116 Oct 30 '14 at 19:21
  • I guess that text was from Jetty 8.Is it no longer the case that everything in jetty.home/lib is on the class path? What would I need to do to make every lib in the jetty.home/lib directory be on the class path? Reading the documentation, I copied everything from lib into ext, and did --module=ext from the command line when starting jetty, which didn't work. I also tried --module=http and --module=server, neither of which had any effect. If I attempt to use classes from those jars, jetty fails to load the war, saying it can't find the classes. – user2197116 Oct 30 '14 at 19:27
  • 1
    There is never a good reason for all of the jars in `{jetty.home}/lib/` to be in the server classpath. And forcing it will accomplish nothing too. Update your question to be more specific on what goal you are attempting to reach, such as "I want to deploy a webapp with jsps and websockets". – Joakim Erdfelt Oct 30 '14 at 19:48
  • Thank you for the detailed explanations. However, whether I modify the jetty.home start.ini to include --module=server, or do as you described above and create my own app specific jetty deployment and initialize server as a module there, or even just try to add the server module by the command line, it always fails, saying that java.lang.ClassNotFoundException: org.eclipse.jetty.server.Handler I can see org.eclipse.jetty.server.Handler.class right there in the jetty-server-9.2.3.v20140905.jar and right there in server.mod it lists lib/jetty-server-${jetty.version}.jar in the [lib] section. – user2197116 Oct 30 '14 at 21:06
  • 1
    The only reason for that message is if your own WebApp is using org.eclipse.jetty.server.Handler (which it cannot) – Joakim Erdfelt Oct 30 '14 at 23:49