Thread return to pool
Hi I have a bit peculiar problem, that I hope someone can help me with. At the start of my servlet I bind some classes to the Thread, so it can be retrieved everywhere in that thread without passing it along into every method. At the end of my servlet I unbind all the info from the thread. So far so good. I use velocity to do the html output, and the templates do some java code calls aswell. These code calls needs to access the info in the Thread too, but since it is already removed it cant. Is there a way to run some code immidiately before the thread is returned to the pool? This to avoid memory leaks. There might be some I can do with velocity instead, but I will adress that to the velocity list. Magne Skjeret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Singleton behaviour
Hi I had a peculiar experience today, which really conflicts with my previous knowledge. I have 2 applications that use the same base classes (just UI differences). I have duplicated those jar files into each of the contexts WEB-INF/lib. I try to start a singleton in each of the contexts: e.g WebProperties.getInstance() But it only seem to do it once, so the singleton is shared cross context. I always thought that a static variable was only visible in its classloader and its children. Surely each context must have its own classloader?? Is this the expected behaviour? It is a tomcat that runs inside jboss. tomcat 4.1.29 Could it be a jboss issue? I think I saw something in a config file about using a jboss classloader. Thanks Magne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Singleton behaviour
Shapira, Yoav wrote: Hi, JBoss (some versions thereof, or some configurations, at least) use a Unified Class Loader where the classloader is shared among webapps. Your understanding that each webapp should have its own classloader (and does, in tomcat) is correct. Further, your understanding that the two singletons would be separate, once per context classloader, is also true. Is the base class shared (in common/lib or another shared location) or duplicated (one copy in each WEB-INF/lib)? Ah good to know. I was starting to doubt myself and saw myself doing university all over again. :-) The jar files are duplicated. One in each WEB-INF/lib. I found in the jboss-service.xml inside the tomcat sar that it does seem to use the unified classloader. attribute name=*UseJBossWebLoader*true/attribute A bit out of the scope of this list, but is there any know complications using tomcats classloader instead? Magne Yoav Shapira Millennium Research Informatics -Original Message- From: Magne Skjeret [mailto:[EMAIL PROTECTED] Sent: Friday, June 04, 2004 2:28 PM To: Tomcat Users List Subject: Singleton behaviour Hi I had a peculiar experience today, which really conflicts with my previous knowledge. I have 2 applications that use the same base classes (just UI differences). I have duplicated those jar files into each of the contexts WEB-INF/lib. I try to start a singleton in each of the contexts: e.g WebProperties.getInstance() But it only seem to do it once, so the singleton is shared cross context. I always thought that a static variable was only visible in its classloader and its children. Surely each context must have its own classloader?? Is this the expected behaviour? It is a tomcat that runs inside jboss. tomcat 4.1.29 Could it be a jboss issue? I think I saw something in a config file about using a jboss classloader. Thanks Magne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Peculiar problem
Hi Just wanted to report a peculiar sighting. I had to test my server from a external machine, and the sys admin set it up.. But the only port he opened for me was 443. So I set my http port to 443 (yes, I did not use ssl). Peculiar setup, I admit that, but when accessing the server with this url. http://serverurl:443/mycontext and did a request.getServerPort(), it reported 80, not 443 as expected. Has anyone else seen this? Is it a feauture or a bug? Magne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Peculiar problem
Magne Skjeret wrote: Forgot to say it was on tomcat 4.0.4 magne Hi Just wanted to report a peculiar sighting. I had to test my server from a external machine, and the sys admin set it up.. But the only port he opened for me was 443. So I set my http port to 443 (yes, I did not use ssl). Peculiar setup, I admit that, but when accessing the server with this url. http://serverurl:443/mycontext and did a request.getServerPort(), it reported 80, not 443 as expected. Has anyone else seen this? Is it a feauture or a bug? Magne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
static variables and context
Hi I just need someone to confirm my belives. I have a jar file added to my WEB-INF/lib I create a singleton of one of my classes. In another context I have the same jar file, so it is duplicated. And I create a singleton of the same class there. I thought that each context had its own classloader so that a singleton was private for each context. But now I have doubts. Can anyone shed some light on this. Magne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: static variables and context
Rodrigo Ruiz wrote: If your class is present only in the WEB-INF/lib directory of your webapps, there will be separated singletons for each one. If you put the jar in $CATALINA_HOME/common/lib or $CATALINA_HOME/shared/lib, the class loader will take the class from there, so there will be only one shared instance for all your webapps. Thanks. Just as I thought. Not worried anymore :-) Magne Magne Skjeret wrote: Hi I just need someone to confirm my belives. I have a jar file added to my WEB-INF/lib I create a singleton of one of my classes. In another context I have the same jar file, so it is duplicated. And I create a singleton of the same class there. I thought that each context had its own classloader so that a singleton was private for each context. But now I have doubts. Can anyone shed some light on this. Magne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing data files via APPLET tags in JSP pages
man, 09.06.2003 kl. 12.48 skrev Susan Hoddinott: Hello, I am restricted in that my web hoster does not have an installed graphics environment (therefore any attempts to draw graphics offscreen in a servlet results in a null pointer from getLocalGraphicsEnvironment). In order to bypass this problem I have attempted to replace my servlet with an applet and I call this via an APPLET HTML tag in a JSP. It works fine except for the fact that any attempt to read a data file on the server seems instead to be interpreted as an attempt to read the file in a directory of the same name on the client, despite passing in such parameters as request.getRealPath(/) and request.getServletPath(). It also seems to use the JVM in any plug-in on the client machine rather than my preferred JVM environment on the server. Has anyone encountered these problems and found a way around them? An applet is running on the client machine, not on the server. If the server is using java1.4 you can set the server to be headless, making it possible to create images and such on a server without a graphichs environment. -Djava.awt.headless=true on the startup script will make it run headless. I hope this can help. Magne Skjeret Regards, Susan Hoddinott http://www.hexworx.com __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
