Re: [jetty-users] Upgrading from 8.1.8 to 9.1.0

[Joakim Erdfelt <joakim@xxxxxxxxxxx>]

Inline ...

On Thu, Oct 10, 2013 at 5:07 AM, John English <john.foreign@xxxxxxxxx> wrote:

On 09/10/2013 17:24, Joakim Erdfelt wrote:

/me takes a deep breath ... :)

Me too... :-)

/me takes calm zen-like breaths ...

OK, I've created a "modules" directory, copied a bunch of XML and mod files from the distro (https, jmx, logging, requestlog, server, servlet, ssl, and webapp) and yes, the module system is pretty cute...

Leave the modules and xml files alone in the ${jetty.home} directory, there is no need to be copying them around.

(Unless you want to make your own modules or override the behavior of an existing module)

However, a few points still elude me. The main problem I have is that my server only hosts a single webapp, which was formerly configured like this in jetty.xml:

  <Call name="setHandler">
    <Arg>
      <New class="org.eclipse.jetty.webapp.WebAppContext">
        <Set name="Descriptor">
          <Property name="jetty.home" default="." />/webapps/myapp/WEB-INF/web.xml
        </Set>
        <Set name="ResourceBase">
          <Property name="jetty.home" default="." />/webapps/myapp
        </Set>
        <Set name="ContextPath">/</Set>
      </New>
    </Arg>
  </Call>

This is valid behavior for Jetty.

What you are doing is manually inserting the WebAppContext and not using the deployers or deploy behaviors provided by the distribution.

This technique can still be done.

Here's your example:

# Create your own base directory (can be anywhere)

[/home/user]$ mkdir my-base

[/home/user]$ cd my-base

[my-base]$ ls -la

total 8

drwxrwxr-x   2 user group 4096 Oct 10 06:19 ./

drwxr-xr-x 103 user group 4096 Oct  9 13:27 ../

[my-base]$

# Lets start configuring the new shiny base directory

# We want this configuration to support webapp basics + http

[my-base]$ java -jar ~/jetty-distribution-9.1.0.RC0/start.jar --add-to-start=http,webapp

http            initialised in ${jetty.base}/start.ini (appended)

http            enabled in     ${jetty.base}/start.ini

server          initialised in ${jetty.base}/start.ini (appended)

server          enabled in     ${jetty.base}/start.ini

webapp          initialised in ${jetty.base}/start.ini (appended)

webapp          enabled in     ${jetty.base}/start.ini

server          enabled in     ${jetty.base}/start.ini

# now lets add our webapp

[my-base]$ cp ~/project/myproject/mywebapp.war ~/my-base/mywebapp.war

# we want to manually add this webapp, no deploy mechanism

[my-base]$ cp ~/project/myproject/mywebapp.xml ~/my-base/mywebapp.xml

# lets see what we have in our base directory so far

[my-base]$ ls -la 

total 2184

drwxrwxr-x   2 user group    4096 Oct 10 06:31 ./

drwxr-xr-x 103 user group    4096 Oct 10 06:24 ../

-rw-rw-r--   1 user group 2219292 Oct 10 06:31 mywebapp.war

-rw-rw-r--   1 user group    2695 Oct 10 06:31 mywebapp.xml

-rw-rw-r--   1 user group     298 Oct 10 06:24 start.ini

# what does the mywebapp.xml look like?

[my-base]$ cat mywebapp.xml

<?xml version="1.0"?>

<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_0.dtd">

<Configure id="Server" class="org.eclipse.jetty.server.Server">

  <Ref refid="Contexts">

    <Call name="addHandler">

      <Arg>

        <New class="org.eclipse.jetty.webapp.WebAppContext">

          <Set name="ResourceBase">

            <Property name="jetty.base" default="." />/mywebapp.war

          </Set>

          <Set name="ContextPath">/</Set>

        </New>

      </Arg>

    </Call>

  </Ref>

</Configure>

# This simply adds the one webapp, as a WebAppContext, to the existing "Contexts" 

# reference present already in the standard ${jetty.home}/etc/jetty.xml

# Lets make sure our configuration in our base uses this xml

# We'll just add a call to the mywebapp.xml at the end of the existing start.ini

[my-base]$ echo "mywebapp.xml" >> start.ini

# Feel free to start your jetty now

[my-base]$ java -jar ~/jetty-distribution-9.1.0.RC0/start.jar

 

I could presumably use the "deploy" module, renaming the webapp directory from "myapp" to "ROOT" and letting it discover it, but I don't want or need hot deployment. Putting the above in jetty.xml doesn't work; this is what I get:

  Caused by: java.lang.NoClassDefFoundError: org/eclipse/jetty/security/SecurityHandler
        at java.lang.Class.getDeclaredConstructors0(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors(Class.java:2404)
        at java.lang.Class.getConstructors(Class.java:1476)
        at org.eclipse.jetty.util.TypeUtil.construct(TypeUtil.java:542)
        at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:806)

        at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1125)
        at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1030)
        at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.call(XmlConfiguration.java:721)
        at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:417)
        at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:354)
        at org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:262)
        at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1238)

Ah, you are using some feature of the servlet spec that requires security to be enabled.

Add support for this feature via the security module, and start jetty again

[my-base]$ java -jar ~/jetty-distribution-9.1.0.RC0/start.jar --add-to-start=security

security        initialised in ${jetty.base}/start.ini (appended)

security        enabled in     ${jetty.base}/start.ini

server          enabled in     ${jetty.base}/start.ini

 

So I have a server that starts but has no webapp contexts...

I also ended up editing the XML files for the logging as I couldn't figure out how to specify additional logging parameters in start.ini and the documentation doesn't seem to cover this. I've been trying to use the local default timezone (using "getDefault" instead of "getTimeZone" in the XML) but since AsyncNCSARequestLog takes a String instead of a TimeZone, I commented out the LogTimeZone setting in the hope that it would give me local time to avoid hardwiring it into the configuration and having to edit it if the server is deployed in a different time zone. However, since I have got a webapp to  make any requests to, I have no idea whether this will work yet!

To add request logging support ...

[my-base] $ java -jar ~/jetty-distribution-9.1.0.RC0/start.jar --add-to-start=requestlog

As for not using GMT and using something else, that's an overlooked parameterization and configuration!

Feature / Bug filed  https://bugs.eclipse.org/bugs/show_bug.cgi?id=419146

For now, you can do this extra step (and once that bug is resolved/fixed this step becomes irrelevant)

# Copy the existing etc/jetty-requestlog.xml so you can modify it to suit your configuration base

[my-base]$ mkdir etc

[my-base]$ cp ~/jetty-distribution-9.1.0.RC0/etc/jetty-requestlog.xml etc/

Then edit the my-base/etc/jetty-requestlog.xml to have this change ...

Replace:

              <Set name="LogTimeZone">GMT</Set>

With:

              <Set name="LogTimeZone" type="String">

                <Get class="java.util.TimeZone" name="default">

                  <Get name="ID"/>

                </Get>

              </Set>

And you should be good to go.

 

Sorry to be a bear of very little brain here!

No worries, I'm here to spread the new about the new changes.

- Joakim