Tomcat 4.1.29 and WAR context settings
Greetings, I am using Tomcat 4.1.29 and trying to deploy a WAR named meridian.war with context configuration values. The WAR is not unpacking and I keep getting the following error... java.lang.NullPointerException at java.io.File.init(File.java:180) at org.apache.catalina.core.StandardContext.getBasePath(StandardContext.java:3902) at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:3344) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3474) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:754) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:363) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2190) at org.apache.catalina.startup.Catalina.start(Catalina.java:512) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) My server.xml configuration is as follows (minus passwords and sensitive stuff): Server port=18006 shutdown=SHUTDOWN debug=0 Service name=Tomcat-Standalone Connector className=org.apache.catalina.connector.http.HttpConnector port=18081 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=6/ Connector className=org.apache.ajp.tomcat4.Ajp13Connector port=8009 minProcessors=5 maxProcessors=75 acceptCount=10 debug=0/ Engine name=Standalone defaultHost=localhost debug=0 Logger className=org.apache.catalina.logger.FileLogger prefix=catalina_log. suffix=.txt timestamp=true/ Host name=localhost debug=0 appBase=D:\java\projects\meridian\dist\war autoDeploy=true Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=common/ Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=localhost_log. suffix=.txt timestamp=true/ Realm className=com.plumcreek.commons.security.ReverseProxyRealm / Context path=/meridian debug=0 reloadable=true crossContext=false Resource name=jdbc/as400 auth=Container type=javax.sql.DataSource/ ResourceParams name=jdbc/as400 parameter namefactory/name valueorg.apache.commons.dbcp.BasicDataSourceFactory/value /parameter parameter namedriverClassName/name valuecom.ibm.as400.access.AS400JDBCDriver/value /parameter parameter nameurl/name valuejdbc:as400://some.place.net;naming=system/value /parameter parameter nameusername/name valuesomeusername/value /parameter parameter namepassword/name valuesomepassword/value /parameter parameter namemaxActive/name value10/value /parameter parameter namemaxIdle/name value5/value /parameter parameter namemaxWait/name value-1/value /parameter /ResourceParams /Context /Host /Engine /Service /Server Any help would be appreciated. Thanks Brandon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Realms getting confused in context reload
I have some strange behavior showing up with Tomcat 5.0.30. I have a host configured with two contexts. The contexts are deployed as wars. But, they have configuration information in the server.xml. Each context has it's own realm defined within the context tag. The contexts are named /admin and /customer. The /customer context is configured to use a DatasourceRealm for authentication. The /admin is configured to use a custom realm called ReverseProxyRealm5. Both contexts share a jndi datasource resource defined in the DefaultContext tag. The odd behavior that i am experiencing happens during an auto reload of the context after both of the war files have been changed. Once the contexts have reloaded and the new war files have been autoDeployed I lose the use of my ReverseProxyRealm5 on the admin context. But, not only do i lose it, it also switches to using the DatasourceRealm as defined in the customer context. After i stop and start tomcat everything is fine again. I have tested this out running Tomcat from the command line and within eclipse with the same resulting behavior. I deleted the /conf/Catalina directory and the /work/Catalina directory for good measure. But, all the behavior continues. Attached is my server.xml host file without the sensitive info. Host name=oi debug=0 autoDeploy=true appBase=D:\myappbase\projects\oi\dist\war Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=orderinquiry_log. suffix=.txt timestamp=true / DefaultContext Resource name=jdbc/oi auth=Container type=javax.sql.DataSource / ResourceParams name=jdbc/oi parameter namefactory/name value org.apache.commons.dbcp.BasicDataSourceFactory /value /parameter parameter namedriverClassName/name valuecom.ibm.as400.access.AS400JDBCDriver/value /parameter parameter nameurl/name value jdbc:as400://some.url.here.org;naming=system;date format=iso /value /parameter parameter nameusername/name valuedudesusername/value /parameter parameter namepassword/name valuedudespassword/value /parameter parameter namemaxActive/name value20/value /parameter parameter namemaxIdle/name value10/value /parameter parameter namemaxWait/name value-1/value /parameter parameter namevalidationQuery/name valueSELECT 0 FROM qsqptabl/value /parameter /ResourceParams /DefaultContext Context path=/customer debug=0 reloadable=true crossContext=false Realm className=org.apache.catalina.realm.DataSourceRealm debug=0 dataSourceName=jdbc/orderinquiry localDataSource=true userTable=UTABLE userNameCol=UNAMECOL userCredCol=PAZZWORD userRoleTable=UTABLERL roleNameCol=UROLE / /Context Context path=/admin debug=0 reloadable=true crossContext=false Realm className=com.plumcreek.commons.security.ReverseProxyRealm5 / /Context /Host Thanks, Brandon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Realms getting confused in context reload
Here is what solved this. My web.xml in the admin and in the customer app were defined as follows: login-config auth-methodBASIC/auth-method realm-nameOrder Inquiry/realm-name /login-config Apparently in tomcat you cannot have two contexts with a web.xml that shares the the same login-config/realm-name. The behavior is VERY bizarre. It would seem that the right way to deal with this would be to identify the realms based on context. So, if i use the same realm name in my web.xml it is totally irrelevant, because the realm is scoped in the context. Is this a bug? Brandon On Wed, 26 Jan 2005 11:51:54 -0700, Brandon Goodin [EMAIL PROTECTED] wrote: I have some strange behavior showing up with Tomcat 5.0.30. I have a host configured with two contexts. The contexts are deployed as wars. But, they have configuration information in the server.xml. Each context has it's own realm defined within the context tag. The contexts are named /admin and /customer. The /customer context is configured to use a DatasourceRealm for authentication. The /admin is configured to use a custom realm called ReverseProxyRealm5. Both contexts share a jndi datasource resource defined in the DefaultContext tag. The odd behavior that i am experiencing happens during an auto reload of the context after both of the war files have been changed. Once the contexts have reloaded and the new war files have been autoDeployed I lose the use of my ReverseProxyRealm5 on the admin context. But, not only do i lose it, it also switches to using the DatasourceRealm as defined in the customer context. After i stop and start tomcat everything is fine again. I have tested this out running Tomcat from the command line and within eclipse with the same resulting behavior. I deleted the /conf/Catalina directory and the /work/Catalina directory for good measure. But, all the behavior continues. Attached is my server.xml host file without the sensitive info. Host name=oi debug=0 autoDeploy=true appBase=D:\myappbase\projects\oi\dist\war Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=orderinquiry_log. suffix=.txt timestamp=true / DefaultContext Resource name=jdbc/oi auth=Container type=javax.sql.DataSource / ResourceParams name=jdbc/oi parameter namefactory/name value org.apache.commons.dbcp.BasicDataSourceFactory /value /parameter parameter namedriverClassName/name valuecom.ibm.as400.access.AS400JDBCDriver/value /parameter parameter nameurl/name value jdbc:as400://some.url.here.org;naming=system;date format=iso /value /parameter parameter nameusername/name valuedudesusername/value /parameter parameter namepassword/name valuedudespassword/value /parameter parameter namemaxActive/name value20/value /parameter parameter namemaxIdle/name value10/value /parameter parameter namemaxWait/name value-1/value /parameter parameter namevalidationQuery/name valueSELECT 0 FROM qsqptabl/value /parameter /ResourceParams /DefaultContext Context path=/customer debug=0 reloadable=true crossContext=false Realm className=org.apache.catalina.realm.DataSourceRealm debug=0 dataSourceName=jdbc/orderinquiry localDataSource=true userTable=UTABLE userNameCol=UNAMECOL userCredCol=PAZZWORD userRoleTable=UTABLERL roleNameCol=UROLE / /Context Context path=/admin debug=0 reloadable=true crossContext=false Realm className=com.plumcreek.commons.security.ReverseProxyRealm5 / /Context /Host Thanks, Brandon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANN] Apache Tomcat 5.0.19 Stable and Tomcat 4.1.30 Stable released
Shouldn't this say Tomcat 5.0.19 in the body of the message? ;-) -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Monday, February 23, 2004 1:38 AM To: Tomcat Developers List; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [ANN] Apache Tomcat 5.0.19 Stable and Tomcat 4.1.30 Stable released The Tomcat Team announces the immediate availability of Apache Tomcat 5.0.18 Stable and Tomcat 4.1.30 Stable. Please refer to the changelog for the list of changes. Downloads: Binaries: http://jakarta.apache.org/site/binindex.cgi Sources: http://jakarta.apache.org/site/sourceindex.cgi The Apache Tomcat Team - 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]
What changed between 5.0.18 and 5.0.19?
I've looked through the release notes and various other files. But, I cannot find anything that actually shows a list of changes for the versions. Am I missing it? If not, then that seems pretty crucial to a release. Thanks, Brandon
security constraint bug?
I have the following security constraint specified in my web.xml: security-constraint web-resource-collection web-resource-nameCustomer Area/web-resource-name url-pattern/customer/*/url-pattern /web-resource-collection auth-constraint role-namecustomer/role-name /auth-constraint /security-constraint When I go to the following url it gets blocked. http://phase.zapto.org:8282/customer.do I'm assuming this is a bug. Is it not? I'm using Tomcat 5.0.18 Brandon Goodin
Tomcat 4.x to 5.x and configuration layouts
I am upgrading from Tomcat 4 to Tomcat 5 and I am having some troubles getting apps that run under 4.x to run under 5.x. Matter of fact it appears that Tomcat does not even see them. The strange thing is that I am seeing no error messages of any sort (all debug levels are 99). When I access the localhost I see the example apps etc... When I add a new host and name (i.e. my.testsite.com) along with the folder for context under %TOMCAT_BASE%/Catalina/[host-name]/. Tomcat is not loading the new host and not providing any info as to why. I did get it to work by placing all of the context configurations in the host tag in the server.xml file It appears that you are supposed to be able to configure each one within the %TOMCAT_BASE%/Catalina/[host-name]/ROOT.xml(and other context). When i place my configuration in the afformentioned directory it fails silently. So, how do i get my own apps to use the new config layout? Thanks in advance, Brandon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DefaultContext Management from Tomcat Administration
I have just installed Tomcat 5 and am very impressed with the usability changes from 4.x and am thrilled about the new spec. But, i use the DefaultContext configuration component quite often in my Host. After having used the Tomcat Administration Tool I found no way to establish a DefaultContext within a host using the Tomcat Admonistration Tool. Am I missing something or is this a terrible oversite? Brandon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_jk problem
That is the most informative link i know of. http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/index.html -Original Message- From: Lukas Larsson [mailto:[EMAIL PROTECTED] Sent: Sunday, January 25, 2004 12:33 PM To: 'Tomcat Users List' Subject: mod_jk problem Hello Does anyone know of a good tutorial for setting up mo_jk or mod_jk2 in apache2? I've been trying now for 4 days to set it up but I've failed. I've been trying to set it up on SuSU linux 9.0 with apache2.0.48 (http://apache.archive.sunet.se/dist/httpd/httpd-2.0.48.tar.gz) and tomcat 5.0.18 (http://apache.archive.sunet.se/dist/jakarta/tomcat-5/v5.0.18/bin/jakarta-to mcat-5.0.18.tar.gz) and the lastest version of JK 1.2 (or JK2). After complíling apache2 and JK, and creating a workers.properties file and editing httpd.conf, no *.jsp pages are sent to tomcat to be interpreted but instead the unformated file is shown (in apache2) or only the html code is formated but not the jsp (in apache 1.3). Has anyone ever had the same problem or is there something that I'm missing? Thx before hand Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
getResourceAsStream cached by Tomcat's Classloader?
I saw a question similar to this asked in the Archives early in 2002. I didn't see a response to it. So, I hope there is an answer. I have a generic config file that is an xml file. We'll call it my-config.xml. When I load my-config.xml using Classloader.getResourceAsStream(my-config.xml) everything works great. However, when I make a change to that file and again call Classloader.getResourceAsStream(my-config.xml) the changes are not picked up and the same initial resource is returned. How do I get the Classloader to reconginze the resource changes? I'm using Tomcat 4.1.18. Brandon Goodin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: getResourceAsStream cached by Tomcat's Classloader?
Yes, it is closed. Brandon Goodin -Original Message- From: Dominic Parry [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 7:44 AM To: Tomcat Users List Subject: Re: getResourceAsStream cached by Tomcat's Classloader? did you close the original stream before making changes and reloading? - Original Message - From: Brandon Goodin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 05, 2003 3:45 PM Subject: getResourceAsStream cached by Tomcat's Classloader? I saw a question similar to this asked in the Archives early in 2002. I didn't see a response to it. So, I hope there is an answer. I have a generic config file that is an xml file. We'll call it my-config.xml. When I load my-config.xml using Classloader.getResourceAsStream(my-config.xml) everything works great. However, when I make a change to that file and again call Classloader.getResourceAsStream(my-config.xml) the changes are not picked up and the same initial resource is returned. How do I get the Classloader to reconginze the resource changes? I'm using Tomcat 4.1.18. Brandon Goodin - 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: getResourceAsStream cached by Tomcat's Classloader?
Thanks Dominic. Unfortuately, this is not being called from within a servlet. Brandon Goodin -Original Message- From: Dominic Parry [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 8:05 AM To: Tomcat Users List Subject: Re: getResourceAsStream cached by Tomcat's Classloader? I had similar issues with getResourceAsStream which caused me to go another route. I now use: new File(getServletContext().getRealPath(modules.xml)) to read files in. I'm not sure what your needs are, but mine were satisfied by using my method. Hope this helps Dom - Original Message - From: Brandon Goodin [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, June 05, 2003 4:04 PM Subject: RE: getResourceAsStream cached by Tomcat's Classloader? Yes, it is closed. Brandon Goodin -Original Message- From: Dominic Parry [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 7:44 AM To: Tomcat Users List Subject: Re: getResourceAsStream cached by Tomcat's Classloader? did you close the original stream before making changes and reloading? - Original Message - From: Brandon Goodin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 05, 2003 3:45 PM Subject: getResourceAsStream cached by Tomcat's Classloader? I saw a question similar to this asked in the Archives early in 2002. I didn't see a response to it. So, I hope there is an answer. I have a generic config file that is an xml file. We'll call it my-config.xml. When I load my-config.xml using Classloader.getResourceAsStream(my-config.xml) everything works great. However, when I make a change to that file and again call Classloader.getResourceAsStream(my-config.xml) the changes are not picked up and the same initial resource is returned. How do I get the Classloader to reconginze the resource changes? I'm using Tomcat 4.1.18. Brandon Goodin - 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] - 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: getResourceAsStream cached by Tomcat's Classloader?
I have tried it both ways. My notion is that it has to do with the fact that the getResourceAsStream is being called in a static method and the resulting InputStream, which is wrapped in an InputStreamReader, is passed into an object that is a static variable in my BaseDAO class. So, because the reference is at the Class level it might be holding onto it no matter what I do. If you want I can show you the code. I have some ideas. But, I'm not sure if they will work. Brandon Goodin -Original Message- From: Larry Meadors [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 8:58 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: getResourceAsStream cached by Tomcat's Classloader? Hey Brandon, Are you using this code to get a classloader? Thread.currentThread().getContextClassLoader(); If not, you are not getting tomcat's you are getting the system one. Larry [EMAIL PROTECTED] 06/05/03 8:04 AM Yes, it is closed. Brandon Goodin -Original Message- From: Dominic Parry [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 7:44 AM To: Tomcat Users List Subject: Re: getResourceAsStream cached by Tomcat's Classloader? did you close the original stream before making changes and reloading? - Original Message - From: Brandon Goodin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 05, 2003 3:45 PM Subject: getResourceAsStream cached by Tomcat's Classloader? I saw a question similar to this asked in the Archives early in 2002. I didn't see a response to it. So, I hope there is an answer. I have a generic config file that is an xml file. We'll call it my-config.xml. When I load my-config.xml using Classloader.getResourceAsStream(my-config.xml) everything works great. However, when I make a change to that file and again call Classloader.getResourceAsStream(my-config.xml) the changes are not picked up and the same initial resource is returned. How do I get the Classloader to reconginze the resource changes? I'm using Tomcat 4.1.18. Brandon Goodin - 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] - 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: getResourceAsStream cached by Tomcat's Classloader?
When I reload the webapp as a whole it is fine (via manager or a tomcat restart). But, when I want to reload the particular config while the app is running, it returns the original resource and not the updated one. Brandon Goodin -Original Message- From: Larry Meadors [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 9:45 AM To: [EMAIL PROTECTED] Subject: RE: getResourceAsStream cached by Tomcat's Classloader? Are the static variables transient? If not, the session manager may persist them on a reload. [EMAIL PROTECTED] 06/05/03 9:41 AM I have tried it both ways. My notion is that it has to do with the fact that the getResourceAsStream is being called in a static method and the resulting InputStream, which is wrapped in an InputStreamReader, is passed into an object that is a static variable in my BaseDAO class. So, because the reference is at the Class level it might be holding onto it no matter what I do. If you want I can show you the code. I have some ideas. But, I'm not sure if they will work. Brandon Goodin -Original Message- From: Larry Meadors [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 8:58 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: getResourceAsStream cached by Tomcat's Classloader? Hey Brandon, Are you using this code to get a classloader? Thread.currentThread().getContextClassLoader(); If not, you are not getting tomcat's you are getting the system one. Larry [EMAIL PROTECTED] 06/05/03 8:04 AM Yes, it is closed. Brandon Goodin -Original Message- From: Dominic Parry [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 7:44 AM To: Tomcat Users List Subject: Re: getResourceAsStream cached by Tomcat's Classloader? did you close the original stream before making changes and reloading? - Original Message - From: Brandon Goodin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 05, 2003 3:45 PM Subject: getResourceAsStream cached by Tomcat's Classloader? I saw a question similar to this asked in the Archives early in 2002. I didn't see a response to it. So, I hope there is an answer. I have a generic config file that is an xml file. We'll call it my-config.xml. When I load my-config.xml using Classloader.getResourceAsStream(my-config.xml) everything works great. However, when I make a change to that file and again call Classloader.getResourceAsStream(my-config.xml) the changes are not picked up and the same initial resource is returned. How do I get the Classloader to reconginze the resource changes? I'm using Tomcat 4.1.18. Brandon Goodin - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: getResourceAsStream cached by Tomcat's Classloader?
Are you using this code to get a classloader? Thread.currentThread().getContextClassLoader(); If not, you are not getting tomcat's you are getting the system one. Are you sure this is true? A ClassLoader can have a parent ClassLoader. But, a class does not maintain a single copy across all ClassLoader contexts. Therefore, the Class type can exist in multiple ClassLoaders. So a Class has a reference to it's ClassLoader context when it is created. When the this.getClass().getClassLoader() is called it calls the context that the class was loaded in. I think you would have to specifically call the getParent() of the Classloader in order to go up the Classloader chain. In this situation I think Thread.currentThread().getContextClassLoader() and this.getClass().getClassLoader() will accomplish the same thing. Brandon Goodin -Original Message- From: Larry Meadors [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 9:45 AM To: [EMAIL PROTECTED] Subject: RE: getResourceAsStream cached by Tomcat's Classloader? Are the static variables transient? If not, the session manager may persist them on a reload. [EMAIL PROTECTED] 06/05/03 9:41 AM I have tried it both ways. My notion is that it has to do with the fact that the getResourceAsStream is being called in a static method and the resulting InputStream, which is wrapped in an InputStreamReader, is passed into an object that is a static variable in my BaseDAO class. So, because the reference is at the Class level it might be holding onto it no matter what I do. If you want I can show you the code. I have some ideas. But, I'm not sure if they will work. Brandon Goodin -Original Message- From: Larry Meadors [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 8:58 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: getResourceAsStream cached by Tomcat's Classloader? Hey Brandon, Are you using this code to get a classloader? Thread.currentThread().getContextClassLoader(); If not, you are not getting tomcat's you are getting the system one. Larry [EMAIL PROTECTED] 06/05/03 8:04 AM Yes, it is closed. Brandon Goodin -Original Message- From: Dominic Parry [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 7:44 AM To: Tomcat Users List Subject: Re: getResourceAsStream cached by Tomcat's Classloader? did you close the original stream before making changes and reloading? - Original Message - From: Brandon Goodin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 05, 2003 3:45 PM Subject: getResourceAsStream cached by Tomcat's Classloader? I saw a question similar to this asked in the Archives early in 2002. I didn't see a response to it. So, I hope there is an answer. I have a generic config file that is an xml file. We'll call it my-config.xml. When I load my-config.xml using Classloader.getResourceAsStream(my-config.xml) everything works great. However, when I make a change to that file and again call Classloader.getResourceAsStream(my-config.xml) the changes are not picked up and the same initial resource is returned. How do I get the Classloader to reconginze the resource changes? I'm using Tomcat 4.1.18. Brandon Goodin - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: getResourceAsStream cached by Tomcat's Classloader?
Aaaah. A man after my own heart! Keep it simple. Brandon Goodin -Original Message- From: Larry Meadors [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 11:12 AM To: [EMAIL PROTECTED] Subject: RE: getResourceAsStream cached by Tomcat's Classloader? I think you are right, but I always use Thread method because it works even in a static method - you do not need 'this' for it to work. I prefer having one way to do this instead of two - that way I can think less about how to get the CL, and more about the problem it will help me solve (and I am lazy). ;-) Larry [EMAIL PROTECTED] 06/05/03 10:58 AM Are you using this code to get a classloader? Thread.currentThread().getContextClassLoader(); If not, you are not getting tomcat's you are getting the system one. Are you sure this is true? A ClassLoader can have a parent ClassLoader. But, a class does not maintain a single copy across all ClassLoader contexts. Therefore, the Class type can exist in multiple ClassLoaders. So a Class has a reference to it's ClassLoader context when it is created. When the this.getClass().getClassLoader() is called it calls the context that the class was loaded in. I think you would have to specifically call the getParent() of the Classloader in order to go up the Classloader chain. In this situation I think Thread.currentThread().getContextClassLoader() and this.getClass().getClassLoader() will accomplish the same thing. Brandon Goodin -Original Message- From: Larry Meadors [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 9:45 AM To: [EMAIL PROTECTED] Subject: RE: getResourceAsStream cached by Tomcat's Classloader? Are the static variables transient? If not, the session manager may persist them on a reload. [EMAIL PROTECTED] 06/05/03 9:41 AM I have tried it both ways. My notion is that it has to do with the fact that the getResourceAsStream is being called in a static method and the resulting InputStream, which is wrapped in an InputStreamReader, is passed into an object that is a static variable in my BaseDAO class. So, because the reference is at the Class level it might be holding onto it no matter what I do. If you want I can show you the code. I have some ideas. But, I'm not sure if they will work. Brandon Goodin -Original Message- From: Larry Meadors [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 8:58 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: getResourceAsStream cached by Tomcat's Classloader? Hey Brandon, Are you using this code to get a classloader? Thread.currentThread().getContextClassLoader(); If not, you are not getting tomcat's you are getting the system one. Larry [EMAIL PROTECTED] 06/05/03 8:04 AM Yes, it is closed. Brandon Goodin -Original Message- From: Dominic Parry [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 7:44 AM To: Tomcat Users List Subject: Re: getResourceAsStream cached by Tomcat's Classloader? did you close the original stream before making changes and reloading? - Original Message - From: Brandon Goodin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 05, 2003 3:45 PM Subject: getResourceAsStream cached by Tomcat's Classloader? I saw a question similar to this asked in the Archives early in 2002. I didn't see a response to it. So, I hope there is an answer. I have a generic config file that is an xml file. We'll call it my-config.xml. When I load my-config.xml using Classloader.getResourceAsStream(my-config.xml) everything works great. However, when I make a change to that file and again call Classloader.getResourceAsStream(my-config.xml) the changes are not picked up and the same initial resource is returned. How do I get the Classloader to reconginze the resource changes? I'm using Tomcat 4.1.18. Brandon Goodin - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
[SOLVED]RE: getResourceAsStream cached by Tomcat's Classloader?
Well, here is how I solved my problem: -- code start -- String resource = my-config.xml; ClassLoader loader = Thread.currentThread().getContextClassLoader(); URL url = loader.getResource(resource); Reader reader = new FileReader( new File( url.getFile())); -- code stop -- Directly calling the getResourceAsStream failed to produce a copy of the altered config. Is this a bug? Brandon Goodin -Original Message- From: Brandon Goodin [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 11:23 AM To: Tomcat Users List Subject: RE: getResourceAsStream cached by Tomcat's Classloader? Aaaah. A man after my own heart! Keep it simple. Brandon Goodin -Original Message- From: Larry Meadors [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 11:12 AM To: [EMAIL PROTECTED] Subject: RE: getResourceAsStream cached by Tomcat's Classloader? I think you are right, but I always use Thread method because it works even in a static method - you do not need 'this' for it to work. I prefer having one way to do this instead of two - that way I can think less about how to get the CL, and more about the problem it will help me solve (and I am lazy). ;-) Larry [EMAIL PROTECTED] 06/05/03 10:58 AM Are you using this code to get a classloader? Thread.currentThread().getContextClassLoader(); If not, you are not getting tomcat's you are getting the system one. Are you sure this is true? A ClassLoader can have a parent ClassLoader. But, a class does not maintain a single copy across all ClassLoader contexts. Therefore, the Class type can exist in multiple ClassLoaders. So a Class has a reference to it's ClassLoader context when it is created. When the this.getClass().getClassLoader() is called it calls the context that the class was loaded in. I think you would have to specifically call the getParent() of the Classloader in order to go up the Classloader chain. In this situation I think Thread.currentThread().getContextClassLoader() and this.getClass().getClassLoader() will accomplish the same thing. Brandon Goodin -Original Message- From: Larry Meadors [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 9:45 AM To: [EMAIL PROTECTED] Subject: RE: getResourceAsStream cached by Tomcat's Classloader? Are the static variables transient? If not, the session manager may persist them on a reload. [EMAIL PROTECTED] 06/05/03 9:41 AM I have tried it both ways. My notion is that it has to do with the fact that the getResourceAsStream is being called in a static method and the resulting InputStream, which is wrapped in an InputStreamReader, is passed into an object that is a static variable in my BaseDAO class. So, because the reference is at the Class level it might be holding onto it no matter what I do. If you want I can show you the code. I have some ideas. But, I'm not sure if they will work. Brandon Goodin -Original Message- From: Larry Meadors [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 8:58 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: getResourceAsStream cached by Tomcat's Classloader? Hey Brandon, Are you using this code to get a classloader? Thread.currentThread().getContextClassLoader(); If not, you are not getting tomcat's you are getting the system one. Larry [EMAIL PROTECTED] 06/05/03 8:04 AM Yes, it is closed. Brandon Goodin -Original Message- From: Dominic Parry [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 7:44 AM To: Tomcat Users List Subject: Re: getResourceAsStream cached by Tomcat's Classloader? did you close the original stream before making changes and reloading? - Original Message - From: Brandon Goodin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 05, 2003 3:45 PM Subject: getResourceAsStream cached by Tomcat's Classloader? I saw a question similar to this asked in the Archives early in 2002. I didn't see a response to it. So, I hope there is an answer. I have a generic config file that is an xml file. We'll call it my-config.xml. When I load my-config.xml using Classloader.getResourceAsStream(my-config.xml) everything works great. However, when I make a change to that file and again call Classloader.getResourceAsStream(my-config.xml) the changes are not picked up and the same initial resource is returned. How do I get the Classloader to reconginze the resource changes? I'm using Tomcat 4.1.18. Brandon Goodin - 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: [SOLVED]RE: getResourceAsStream cached by Tomcat's Classloader?
I checked out tomcat from the HEAD and found the following information in
the WebAppClassloader:
I see now that the WebAppClassLoader does intend to have a cache for the
loaded Resources (some day).
code snip
WebappClassLoader - Line 1211
...
// (0) Check for a cached copy of this resource
stream = findLoadedResource(name);
...
code snip
It does this by examining the ResourcEntry(s) in the resourceEntries Hashmap
and checking binaryContent (null vs not null).
code snip
WebappClassLoader - Line 1898
...
/**
* Finds the resource with the given name if it has previously been
* loaded and cached by this class loader, and return an input stream
* to the resource data. If this resource has not been cached, return
* codenull/code.
*
* @param name Name of the resource to return
*/
protected InputStream findLoadedResource(String name) {
ResourceEntry entry = (ResourceEntry) resourceEntries.get(name);
if (entry != null) {
if (entry.binaryContent != null)
return new ByteArrayInputStream(entry.binaryContent);
}
return (null);
}
}
...
code snip
But, there is no caching going on when the resources are loaded. So, the
code is executing with no purpose? Matter of fact the code has //FIX ME
cache??? statements intermingled with the ClassLoader delegation.
code snip
WebappClassLoader - Line 1219
...
// (1) Delegate to parent if requested
if (delegate) {
if (debug = 3)
log( Delegating to parent classloader);
ClassLoader loader = parent;
if (loader == null)
loader = system;
stream = loader.getResourceAsStream(name);
if (stream != null) {
// FIXME - cache???
if (debug = 2)
log( -- Returning stream from parent);
return (stream);
}
}
// (2) Search local repositories
if (debug = 3)
log( Searching local repositories);
URL url = findResource(name);
if (url != null) {
// FIXME - cache???
if (debug = 2)
log( -- Returning stream from local);
stream = findLoadedResource(name);
try {
if (hasExternalRepositories (stream == null))
stream = url.openStream();
} catch (IOException e) {
; // Ignore
}
if (stream != null)
return (stream);
}
// (3) Delegate to parent unconditionally
if (!delegate) {
if (debug = 3)
log( Delegating to parent classloader);
ClassLoader loader = parent;
if (loader == null)
loader = system;
stream = loader.getResourceAsStream(name);
if (stream != null) {
// FIXME - cache???
if (debug = 2)
log( -- Returning stream from parent);
return (stream);
}
}
// (4) Resource was not found
if (debug = 2)
log( -- Resource not found, returning null);
return (null);
...
code snip ---
So there are three things that I can conclude as a result of seeing this
code.
1) My getResourceAsStream loading problems are NOT caused by Tomcat because
Tomcat is grabbing the resource fresh each time.
2) Resource caching still needs to be implemented in Tomcat
3) The caching check in Tomcat does not check resource Timestamps. So, even
if the cache was working it would not reload resources upon file changes.
(only binaryContent is being checked. eg null or not null).
Are my observations correct?
Brandon Goodin
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 05, 2003 12:49 PM
To: Tomcat Users List
Subject: RE: [SOLVED]RE: getResourceAsStream cached by Tomcat's
Classloader?
Howdy,
Dang it! I knew it was too good to be true. Well, it works just fine
for
me.
I do not deal with WARs. Anywyas, why would anyone want to run from a
packed WAR anyways (instead of unpacked)? I'm not being sarcastic. I
am
just trying to think of an instance where it makes sense.
Two cases come to mind:
- Running from a non filesystem-based server that can't unpack wars.
Oracle's servlet container was like this (at least used to be), as it
used the DB instead of the filesystem to serve resources.
- When you want to just have one file (the .war) for your app, and you
want to prohibit (for intellectual property legal protection etc.) users
from examining its contents.
Note that the servlet specification does not mandate filesystem support
for web applications.
That said, it's always a debate on whether WAR should be seen as a
packaging format only, to be unpacked on the server, or an equivalent to
an executable file on windows, which is one unit.
Yoav Shapira
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
