Re: [Slightly OT] MVC approach when JSP are not allowed
On Fri, 2005-03-18 at 23:33 -0500, Elihu Smails wrote: > I am working on a project that uses servlets exclusively. I would > like to take advantage of a Model-View-Controller system in order to > develop my servlets. For the last servlet project I worked on, I was > in charge of the "back-end" data processing and did not have to mess > with HTML. This time I do have to roll up my sleeves and play with > HTML. > > So I ask the question. Since the requirement that I have is to use > servlets only, can I use something like Struts or Java Server Faces? > I am reading some information and it looks like they both rely on JSP > to ge the job done. What is the reason for the ban on using JSPs? A JSP page gets converted into a servlet; in a sense JSP is just a different syntax for writing servlets in. If the reason is simply that the architects don't want run-time compilation of files, or don't want a java compiler available on the machine then JSPs can simply be precompiled. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Delegate flag for classloading (ATTN: Remy Maucherat)
Hi, I see here that there is an option for the webapp-specific classloader to use parent-first classloading instead of the (default) child-first classloading. Can someone suggest why this might be useful? Clearly someone thought so, but I can't see any point in it. It is in catalina since version 1.1 (committer: Remy Maucherat). See "delegate" option in this page: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/loader.html Using this option makes life exceedingly complicated for some libs like commons-beanutils and commons-logging, so I would like to know under what conditions someone might enable this feature. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing memory on undeploy
On Fri, 2005-03-18 at 18:48 -0800, Chris Hyzer wrote: > > currently looking > > into memory-leak issues with j2ee/servlet-engine > > We have about a dozen apps on 2 tomcats that have > 800MB each in linux (5.0.25), and they are not huge > apps, but after a few manager reloads the tomcat is > out of memory. Is this related? You said undeploy, > but maybe reloading is also a problem. Also, if we > let the server run for a while, we cannot add new apps > either. I suspect we need to profile and look for > memory leaks, but I thought it would mention it. Chris It might be the same problem. By "undeploy" I mean "throw away the classloader associated with the deployed component", which reload will also do. The problem is that both commons-logging and commons-beanutils use the Singleton pattern. And the Singleton pattern is *extremely* hard (possibly impossible) to implement correctly in a j2ee-style environment when a class might be loaded via a "shared" classloader. Tomcat includes a workaround for commons-logging which appears *to me* to be a complete fix for commons-logging leaks (though maybe not a very elegant one): it calls org.apache.commons.logging.LogFactory.release(this) from class WebappClassLoader. However there have been reports of leaks when using commons-logging despite this; I need to try to set up some testcases to determine what's going on, but testcases involving garbage-collection and complex classloading setups will be tricky to create. If you do find anything from profiling your app, please post the info to this group (and/or me). Note that I'm going to be away for the next three weeks, but will try to pick this topic up when I return. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: deleteOnExit doesn't seem to be working for session temporary files..
On Fri, 2005-03-18 at 10:27 -0800, Joseph Silverman wrote: > In our setup, we have JSP's that create a "temporary" file with the > deleteOnExit flag set. > The session timeout (getMaxInactiveInterval) appears to be the > "default" of 1800 seconds (30 minutes). > > We are blasting our servlet container (tomcat and jetty) with JSP > fetches (that don't handle cookies - http_load if you are curious as to > what we are using) and noting that these files stick around till the > servlet container itself quits (the java process goes away). At that > point ALL the files are deleted, and it can take HOURS in some cases to > do so. > > Is this expected behavior? We think that these files should be deleted > when the session "expires". That seems like the right thing to do. What you are seeing is what I would expect. The javadoc for File.deleteOnExit very clearly states that the file is deleted *when the virtual machine terminates*. A session is *not* a virtual machine. I suggest you use a SessionListener object instead; this should be invoked when the session expires, and you can delete the files then. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Windows NT
On Fri, 2005-03-18 at 08:13 -0300, Inove Infoshop Ltda wrote: > Hi, > > Shouldn't TC install under (not manufacturer supported any more) Windows NT 4? > > > I´m using a product called DeskNow and it uses Tomcat 5.x. Unfortunately (or > not), ver 2.6 of the product started using ver 5.x of Tomcat. I use a retired > WinNT box as the DeskNow Server, but, when upgrading to version 2.6, > service registration failed with the following message on Dr. Watson: > > Title: desknow.exe > Exception: access violation (0x0005), Address 0x77f92a66 Well, tomcat itself is a pure-java application. As such, as long as you have a working java virtual machine you can run tomcat, regardless of what the operating system is. I'm 99.99% sure that it will still work on NT as a stand-alone program, so there's always that option as long as you don't absolutely *have* to run it as a windows service. [1] But java doesn't support the concept of a "windows service" natively. Tomcat does that via the commons-daemon library that provides some native code to do that on various platforms; see http://jakarta.apache.org/commons/daemon. I would suggest investigating what version of commons-daemon your Tomcat instance uses, then have a look at what platforms that version of commons-daemon supports. If the latest release has dropped support for NT then you might be able to install an old release of commons-daemon over what DeskNow bundles. There's also the possibility that the crash is not anything to do with Tomcat, but instead in some custom code provided by DeskNow. You said that "service registration failed" but I'm not sure exactly what that means. Are you sure the crash is occurring within some part of tomcat or commons-daemon? [1] Of course if DeskNow is just a java application, then you could also run it on Linux :-) Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Releasing memory on undeploy
Hi, I'm one of the committers on commons-logging and am currently looking into memory-leak issues with j2ee/servlet-engine stuff when undeploying apps that use commons-logging. I see the following page in the tomcat FAQ states that classloaders cannot be garbage-collected in tomcat: http://jakarta.apache.org/tomcat/faq/deployment.html Can someone confirm this is in fact true, and if so explain why? Thanks, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging in Tomcat 5.5
On Fri, 2005-03-18 at 11:25 +0530, Joy Kenneth Harry wrote: > Hi, > I have a webapp in tomcat. I am using a separate Log4j.xml for it, in > its WEB-INF classes folder. > > I've also put a Log4j.xml in TOMCAT_HOME/ common/classes and set it to > false so that I do not get the general Tomcat logs. > > But even then my project logs are getting mixed with the TOMCAT logs. > Is there any way to disable TOMCAT logs. By "project logs" do you mean messages deliberately logged by the code within *your webapp*, or do you mean messages from tomcat itself? If you are talking about messages logged by code within your webapp, is it using the log4j API or the commons-logging API? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Starting Tomcat results in multiple Java processes
On Wed, 2003-03-12 at 13:43, Chris Dodunski wrote: > Hi, > > Sorry, only just noticed that myself. Of the two that aren't, I reduced > minProcessors to 1, and maxProcessors to 2 (server.xml). But alas, upon > restarting Tomcat, I still have 26 Java processes running! Please, what > must I do to reduce these? I suggest you chill out, and don't worry about them. They are *threads* not processes, and a few *hundred* threads really won't bother any decent operating system. Yes, the "ps" list looks a bit messy [that will go away with linux kernel 2.6 :- I presume you are using Linux] but no harm is being done. One note: have you got "hot deploy" enabled? At a guess, there will be a thread monitoring the .war deploy directory (or one per webapp) which could be disabled if you can live without hot-deploy. I guess some-one more familiar with recent tomcat versions than I could confirm/deny this. However even if it is possible to disable this, you are really losing functionality for no real gain. And setting maxProcessors to 2 means that if *three* people hit a url at your website concurrently, one will have to wait until one of the earlier users has finished receiving their page [or pages for http/1.1 persistent connections]. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Process.waitFor bug which might affect CGIServlet
Hi All, I have encountered what I believe to be a bug in the Sun JVM (1.4.1 at least). This causes Process.waitFor() and Process.exitValue() to hang intermittently. As CGIServlet uses process.exitValue(), I would expect this bug to also cause this servlet to intermittently hang. Note that this is NOT due to filling STDOUT/STDERR pipes of the externally executed application (http://developer.java.sun.com/developer/bugParade/bugs/4109888.html and friends). Firstly, has anyone experienced hangs with CGIServlet? Secondly, would someone here be willing to help me out by trying the attached code to verify that the problem can be duplicated? I submitted a bug to Sun in November 2002, and in Feb 2003 received a "cannot reproduce" mail. However I can reproduce it at will. So can at least one of my clients :-( I can reliably duplicate the issue on the following systems: * Mandrake Linux 9.0 on x86: java version "1.4.1_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) * RedHat Linux 7.2 on x86: java version "1.4.1_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) * Mandrake Linux 9.0 with Blackdown linux 1.4.1: java version "1.4.1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.1-01) Java HotSpot(TM) Client VM (build Blackdown-1.4.1-01, mixed mode) Exactly the same .class file (compiled with the Sun JDK) works correctly when run on the following: * Mandrake Linux 9.0 with IBM JVM 1.4.0: java version "1.4.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0) Classic VM (build 1.4.0, J2RE 1.4.0 IBM build cxia32140-20020917a (JIT enabled: jitc)) * IBM AIX 5 with IBM JVM 1.4.0: java version "1.4.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0) Classic VM (build 1.4.0, J2RE 1.4.0 IBM AIX build ca1401-20021126 (JIT enabled: jitc)) --- How to run the test app: (a) save "runme" script, make executable (chmod +x) (b) compile HangMe.java (c) java -cp . HangMe runme The application will print "about to waitFor .. waitFor completed" about 18 times. Then the text "about to waitFor" will be displayed and the application will hang. Don't forget the "runme" parameter to tell the app which external process to invoke - command-line error handling is not implemented :-) I have a variant of this app which uses a combination of Process.exitValue(), catch-clause, and sleep() to try to detect external process termination, but this hangs too, presumably due to the same underlying issue. This is basically the approach taken by CGIServlet... Regards, Simon Kitching The Electronic Commerce Network Ltd. #!/bin/sh #echo "runme" >> runme.out exit 0 import java.io.File; import java.io.IOException; class HangMe { private static void log_debug(String s) { System.out.println("DEBUG:" + s); } private static void log_debug(String s, Throwable t) { System.out.println("DEBUG:" + s + ":" + t.toString()); t.printStackTrace(); } private static void log_warn(String s) { System.out.println("WARN:" + s); } private static void log_warn(String s, Throwable t) { System.out.println("WARN:" + s + ":" + t.toString()); t.printStackTrace(); } public static void runIt(String appname) throws Exception { String[] envarray = new String[0]; String[] cmdarray = new String[1]; cmdarray[0] = appname; File workingDir = new File("."); Process proc; try { proc = Runtime.getRuntime().exec(cmdarray, envarray, workingDir); } catch(SecurityException se) { log_warn("Permission refused to run command", se); throw new Exception( "Permission refused to run command", se); } catch(IOException ioe) { log_warn("Unable to run command", ioe); throw new Exception( "Unable to run command", ioe); } // check process exit status try { log_debug("about to waitFor.."); proc.waitFor(); log_debug("waitFor completed."); } catch(InterruptedException e4) { throw new Exception("interrupted while waiting for app to end"); } int exitStatus = proc.exitValue(); if (exitStatus == 0) { // success log_debug("application executed successfully"); } else { log_debug("application failed");