On Thu, Oct 10, 2013 at 8:52 AM, John English <[email protected]>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<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 <[email protected]> webtide.com <http://www.webtide.com/> - intalio.com/jetty Expert advice, services and support from from the Jetty & CometD experts eclipse.org/jetty - cometd.org
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
