RE: [FAQ] jGuru FAQ Update
Maby it is on http://www.adcritic.com. Or ask if they set it up.. (so I can see it too..) -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 21, 2001 2:40 AM To: [EMAIL PROTECTED] Subject: Re: [FAQ] jGuru FAQ Update [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: Sure, it could, but (a) I don't think one message a week will be enough traffic to bother anyone, and (b) sometimes developer-related FAQs show up on the Tomcat list. It's pretty cool, but check your scripts, as it's coming once a day, not once a week... Pier (again on the floor laughing for that MTV ad: gotta MPG it)
FW: [javax_compiler] Re: sun.tools.javac.Main will be removedfrom JDK1.4
FYI Pier -- Forwarded Message From: Neal M Gafter [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Fri, 20 Jul 2001 20:46:51 -0700 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [javax_compiler] Re: sun.tools.javac.Main will be removed from JDK1.4 Craig R. McClanahan wrote: An additional note of interest to Ant developers - there is evidence that running the compiler (either old or new) leaves a fair amount of cruft lying around in static variables, after the compile has completed. The recommended solution is to load the compiler itself in its own class loader, so that you can throw it all away afterwards. That's the approach we'll take when modifying Jasper. I was part of the source for this rumor, but I'd like to comment. There was a bug in the internal version of javac for the past month or two in which the compiler failed to clean up after itself. I fixed that today. The symbol tables, trees, etc are definitely cleaned up now. If you're a source licensee getting weekly releases of Merlin (1.4) your most recent versions will definitely have this bug. It may be a couple of weeks before this fix gets back to you. There are two categories of things that are NOT cleaned up between compiles: (1) Objects that are essentially constants, like symbol table entries for the root package, built-in types, etc. While its true that these stick around, its better that they do because javac runs faster the second time. These are fixed size. (2) Names in the name table. javac maintains its own version of an interned string table, and all the names that it sees are entered into it and remain in it forever. The representation was custom designed for the compiler and it's much more compact than strings. This table does appear to approach an asymptotic limit when you use the compiler repeatedly; when all of JDK (1.2) was compiled using javac this table reaches a maximum of about 500K. I have to admit a likely third category - bugs in the compiler. But if you find any, tell me and I'll fix it. In short, I don't think it's necessary to load the compiler into its own class loader in most circumstances, but you're welcome to try it either way you please. If you try it both ways and can share some data on the relative performance (space and time) I'd love to hear from you. I plan to try an experiment replacing the name table with actual interned String objects. That will probably slow things down a bit and use more space, but it has the advantage that otherwise unreachable interned strings are reclaimed, so this would remove a leak from the compiler. To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ -- End of Forwarded Message
Re: [DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es
On Fri, Jul 20, 2001 at 12:47:51PM -0500, David Haraburda wrote: I don't think unsetting your CLASSPATH is necessary, especially since other applications may rely on it. I would guess that most problems occur when: 1) You add things you have in your WEB-INF/classes to your CLASSPATH (thus causing them to be loaded by the system class loader, not the Tomcat web app class loader, which causes problems) or, as the case would appear to be with the POET sdk referred to before, 2) Your web application requires a certain JAR that you have placed in your WEB-INF/lib directory, but unbeknownst to you, there is actually another JAR (perhaps an older version of the software) sitting in your classpath, which gets loaded first. Remember, a classloader always asks it's parent classloader to load a resource first, and then only loads it itself if the parent cannot find it. Just make sure things your web application requires are in your WEB-INF/libs directory, and not in your classpath. Craig McClanahan has two good posts about this: http://mikal.org/interests/java/tomcat/archive/view?mesg=22444 http://mikal.org/interests/java/tomcat/archive/view?mesg=8512 Thanks for the tips, what you've described is the exact behavior I've experienced. I just haven't had the time to read up about classloaders and the order which classes are loaded. As far as logging goes, you may want to check out the Logger elements is your server.xml file. They provide a good way to keep your terminal un-cluttered. :-) Crap, I never really noticed this one before: Logger name=tc_log verbosityLevel = INFORMATION / Is there any other tricks I've been missing for a while with Tomcat? (I know, getting off-topic for tomcat-dev) Thanks, -Dave
[DOC] TC4 jakarta doc site...
Hi guys, I just upgraded to Mozilla 0.9 and tried having a look at the Server Configuration part of the tc4 doc site. (I hope to have my tc4 appendix shelled out by the end of the day.) I noticed that the background on the left is set to black...Problem is, the styles your using don't seem to be valid as the text comes out black too. (Spotted the problem yet!?! 8o) ) Also, a black background is a bit gash! (call me old fashioned) Mozilla works fine with my XHTML site which uses CSS 1 and 2 so I think it may be your site. I can get by without it, but as you can tell its not exactly ideal! Adam. -- Adam Fowler Help Desk Live Project Information Services University of Wales, Aberystwyth Tomcatbook Project Author and web maintainer http://tomcatbook.sourceforge.net web: http://users.aber.ac.uk/aff9 e-mail: [EMAIL PROTECTED] --
RE: [DOC] TC4 jakarta doc site...
I submitted a mockup site several weeks ago, and a modified home page using the same sort of scheme yesterday. I don't think people like to comment on aesthetics =) Problem is that everyone has a friend of a friend that will make us a sharp, light-weight site, but no one ever gets around to it =/ - r -Original Message- From: Adam Fowler [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 21, 2001 11:56 AM To: [EMAIL PROTECTED] Subject: [DOC] TC4 jakarta doc site... Hi guys, I just upgraded to Mozilla 0.9 and tried having a look at the Server Configuration part of the tc4 doc site. (I hope to have my tc4 appendix shelled out by the end of the day.) I noticed that the background on the left is set to black...Problem is, the styles your using don't seem to be valid as the text comes out black too. (Spotted the problem yet!?! 8o) ) Also, a black background is a bit gash! (call me old fashioned) Mozilla works fine with my XHTML site which uses CSS 1 and 2 so I think it may be your site. I can get by without it, but as you can tell its not exactly ideal! Adam. -- Adam Fowler Help Desk Live Project Information Services University of Wales, Aberystwyth Tomcatbook Project Author and web maintainer http://tomcatbook.sourceforge.net web: http://users.aber.ac.uk/aff9 e-mail: [EMAIL PROTECTED] --
Re: [DOC] TC4 jakarta doc site...
Rob, If I could get CVS access behind this damned secure network I'd volunteer!...Unless you'd let me FTP/SSH to it 8o) Tomcat can have my thoroughly tested layout if you'd like though. (With a few mods, of course!) Take a gander at http://tomcatbook.sourceforge.net Adam. Rob S. wrote: I submitted a mockup site several weeks ago, and a modified home page using the same sort of scheme yesterday. I don't think people like to comment on aesthetics =) Problem is that everyone has a friend of a friend that will make us a sharp, light-weight site, but no one ever gets around to it =/ - r -Original Message- From: Adam Fowler [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 21, 2001 11:56 AM To: [EMAIL PROTECTED] Subject: [DOC] TC4 jakarta doc site... Hi guys, I just upgraded to Mozilla 0.9 and tried having a look at the Server Configuration part of the tc4 doc site. (I hope to have my tc4 appendix shelled out by the end of the day.) I noticed that the background on the left is set to black...Problem is, the styles your using don't seem to be valid as the text comes out black too. (Spotted the problem yet!?! 8o) ) Also, a black background is a bit gash! (call me old fashioned) Mozilla works fine with my XHTML site which uses CSS 1 and 2 so I think it may be your site. I can get by without it, but as you can tell its not exactly ideal! Adam. -- Adam Fowler Help Desk Live Project Information Services University of Wales, Aberystwyth Tomcatbook Project Author and web maintainer http://tomcatbook.sourceforge.net web: http://users.aber.ac.uk/aff9 e-mail: [EMAIL PROTECTED] --
RE: [TC4.0] Disabling debug output...
There's work done to remove code from Java class files at load time to support the new assert feature in JDK1.4. IIRC the class loader is doing most if not all of the work. So it may be possible to make it work in earlier JDKs. Could something similiar be done for logging? Jin Yu -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 7:09 PM To: [EMAIL PROTECTED] Subject: Re: [TC4.0] Disabling debug output... On Thu, 19 Jul 2001, Jonathan Reichhold wrote: This hack definitely works. As long as you're willing to pay the overhead for the method call, it's essentially equivalent to asking Log4J whether or not debugging output is enabled, which does something similar (but asks the instantiated logger object, instead of being a static method). I'm not sure if Log4j has an accesible boolean like this (maybe it does, haven't used it yet), It's accessible, but via a method call. That's still a *lot* cheaper than doing useless string concatenations, but not quite as cheap as an integer comparison. I don't have the Log4J APIs available right at the moment, but there's a call on the logger object that can be used to check for enabled levels (or at least for debug). Craig McClanahan Enterprise Channel Management Software for Manufacturers Visit us at http://www.ultryx.com
Re: JDK 1.3.0...
On Tuesday 17 July 2001 22:46, you wrote: You do realize that re-distribution of the JDK is illegal, right? You can only redistribute the JRE. Oh F*?*!!! *phoning Paul* Thx Jon. Adam. -- - | Adam Fowler | | Help Desk Live Project| TomcatBook Project| | Information Services | Author and Web Maintainer | | University of Wales, Aberystwyth | http://tomcatbook.sourceforge.net | | Web: http://users.aber.ac.uk/aff9 | E-mail: [EMAIL PROTECTED] | -
Re: [DOC] TC4 jakarta doc site...
Adam Fowler at [EMAIL PROTECTED] wrote: I noticed that the background on the left is set to black...Problem is, the styles your using don't seem to be valid as the text comes out black too. (Spotted the problem yet!?! 8o) ) Also, a black background is a bit gash! (call me old fashioned) Downloaded it for OS/X (seems to work fairly well now, 0.9.2 as of today's nightly!) and I have the same problem... It's not THAT black (seen on a LCD of my Titanimu), but definitely too dark... Might want to change that sky blue background into something slightly less dark? Pier
Re: [DOC] TC4 jakarta doc site...
Hi, Change it to Air force blue 8o) wedgewood blue as its called over here. Not that I'm bias! *dreamin' of harrier pilotage* Adam. Pier P. Fumagalli wrote: Adam Fowler at [EMAIL PROTECTED] wrote: I noticed that the background on the left is set to black...Problem is, the styles your using don't seem to be valid as the text comes out black too. (Spotted the problem yet!?! 8o) ) Also, a black background is a bit gash! (call me old fashioned) Downloaded it for OS/X (seems to work fairly well now, 0.9.2 as of today's nightly!) and I have the same problem... It's not THAT black (seen on a LCD of my Titanimu), but definitely too dark... Might want to change that sky blue background into something slightly less dark? Pier
ROOT/index.html
Here's my take on a new default index.html along with the jakarta banner since I've incorporated that in as well. I'd like it if all of the sample apps retained a somewhat similar look and feel (volunteering if people agree that it should be done). I tried this page under Opera and IE and it works fine. I'm scared to try NS! =) I'd really like the default apps to showcase Tomcat, and they've always been kind of clunky. IIRC, some of the JSP/Servlet example links don't work correctly. I'd also like the default homepage to brag about the features of Tomcat to some degree, e.g. session persistence and whatnot, but I don't know enough about these things yet... - r jakarta-banner.gif
