Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Upgrading from 8.1.8 to 9.1.0



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

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

No, I meant that I copied them from the *distro* to my test server (where my
webapp is, which worked beautifully in the good old days). It has a minimal set of jars & whatnot because I want a minimal footprint. I really don't want all the other very nice stuff like websockets & what-have-you which my old-fashioned webapp doesn't need.

Just because the jars exist on disk does not mean that they are used.
The configuration controls what is used.

Use the "--list-config" to see the configuration, you'll note that only a subset of the jars from the distribution are in use.
That subset is determined by what modules you have enabled.

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


 


This technique can still be done.

Hurrah!

Here's your example:
... snip ...
*# 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*

Aha! (Sound of lightbulb appearing above my head)

This phrase always amused me, as I never associate lightbulbs with making noises. :-)
 


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

OK. Thanks to all your help, my test rig is now on the air again.

Good. good. 
 

To add request logging support ...

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

Did that earlier...


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

OK. Thanks.

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*

Done that, for reasons explained above.


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.

Hmm, makes no difference. I still see GMT in the logfile:
127.0.0.1 -  -  [10/Oct/2013:15:25:31 +0000] "GET /home HTTP/1.1" 200 -

It would be nice to get local time, to make it easier to match up requests with system log entries in the webapp's database (which use local time). But this is something I lived with before, it's just something that I thought would be nice to do while I was fiddling...

Historically, all logging related utilities that can parse access or request logs settled on GMT as the log file is portable across machines and time.
Search "access log report" or "web log analysis" or "access log analyzer" on google to see a list of these tools.

 

And in jetty-logging.xml, I tried this:
  <Call class="java.util.TimeZone" name="getDefault"/>
instead of
  <Call class="java.util.TimeZone" name="getTimeZone"><Arg>GMT</Arg></Call>
which gives me local time, but without daylight saving (and I suppose I need to get this one figured out before winter starts!). Maybe this is a timezone bug/feature, of which Java seems to have many. Maybe I should just stick to GMT and be happy.

Couple of other minor queries:
1) any reason why the old jetty.log files are now called stderrout.log by default? Changing this back to how it was appears to involve another XML edit...
2) any reason why the server log uses a TimeZone but the request log uses a String for the TZ name? Consistency would suggest one or the other, and it should also be easy to select local time IMHO.

You have entered into a bigger world then you realize.

Try this ...

    public static void main(String[] args)
    {
        TimeZone mytz = TimeZone.getDefault();
        System.out.printf("The TimeZone for this machine: %s%n", mytz);
        System.out.printf("The TimeZone.id: %s%n", mytz.getID());
        for (String string : TimeZone.getAvailableIDs(mytz.getRawOffset())) {
            System.out.println(string);
        }   
    }


I live in Phoenix, AZ, and all of these are valid java.util.TimeZone entries for me.

America/Boise
America/Cambridge_Bay
America/Chihuahua
America/Creston
America/Dawson_Creek
America/Denver
America/Edmonton
America/Hermosillo
America/Inuvik
America/Mazatlan
America/Ojinaga
America/Phoenix
America/Shiprock
America/Yellowknife
Canada/Mountain
Etc/GMT+7
MST
MST7MDT
Mexico/BajaSur
Navajo
PNT
SystemV/MST7
SystemV/MST7MDT
US/Arizona
US/Mountain

Now, I'm special, in so far that Arizona does not honor or follow the Daylights Savings Programs

Be extra careful of the TimeZone you choose, if you care about Daylights Savings offsets.
For example, if you choose "CST", thinking its Central Standard Time, you would have chosen wrong, as that ID is on one side or the other for Daylights Savings.
Java figured this out back in Java 1.1 days, and has since discouraged short IDs and instead urges you to use longer IDs, such as "America/Chicago",  "America/Mexico_City", "Mexico/General", "Canada/Central", or "US/Central" as those IDs have no DST associated with them.


--
Joakim Erdfelt <joakim@xxxxxxxxxxx>
Expert advice, services and support from from the Jetty & CometD experts

Back to the top