Help: Context.xml Resource difference between 5.0.x and 5.5.x ?
I'm having trouble moving my webapp from Tomcat 5.0 to 5.5. The dataSource in Context.xml seems to be the issue. According to the 'JNDI how-to' documentation for 5.0 and 5.5, it looks like the 'ResourceParams' tag has been removed from the Context.xml and instead you can now supply arbitrary attributes to the Resource tag itself. In 5.0, my Context.xml looked like this and it worked fine: ?xml version=1.0 encoding=UTF-8? Context antiResourceLocking=true docBase=myapp path=/myapp Resource name=jdbc/db1 auth=Container type=oracle.jdbc.pool.OracleDataSource / ResourceParams name=jdbc/db1 parameter namefactory/name valueoracle.jdbc.pool.OracleDataSourceFactory/value /parameter parameter namedriverClassName/name valueoracle.jdbc.driver.OracleDriver/value /parameter parameter nameurl/name valuejdbc:oracle:thin:@xx:xx:xx/value /parameter parameter nameuser/name valuexx/value /parameter parameter namepassword/name valuexx/value /parameter /ResourceParams /Context ...note that oracle's factory requires user, not username. Moving to 5.5, I changed it to: ?xml version=1.0 encoding=UTF-8? Context antiResourceLocking=true docBase=myapp path=/myapp Resource auth=Container driverClassName=oracle.jdbc.driver.OracleDriver factory=oracle.jdbc.pool.OracleDataSourceFactory name=jdbc/db1 password=xxx type=oracle.jdbc.pool.OracleDataSource url=jdbc:oracle:thin:@xx:xx:xx user=xx/ /Context ...this new Context.xml doesn't work. I get the following: javax.naming.NamingException: Cannot create resource instance at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:132) at javax.naming.spi.NamingManager.getObjectInstance(Unknown Source) at org.apache.naming.NamingContext.lookup(NamingContext.java:792) any ideas? Almost seems as if the factory attribute of Resource is not being used. thanks tk_
Solved: Context.xml Resource difference between 5.0.x and 5.5.x?
Solved.Crazy but true. When using the Oracle factory: In a Tomcat 5.0 context file, the url parameter (name, not the value) must be lower case. In a Tomcat 5.5 context file, the url parameter must be UPPER CASE. Works now. Thanks for the help. Sorry for so many mails... tk Parsons Technical Services [EMAIL PROTECTED] wrote: The docs say that the factory parameter is only needed for entries that Tomcat is not aware of. Since you had a special factory(in your old 5.0 context) and not the standard one used by Tomcat you will need to have the factory element in place. See: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/globalresources.html Under Resource Definitions it says: You MUST also define any other needed parameters using attributes on the Resource element, to configure the object factory to be used (if not known to Tomcat already), and the properties used to configure that object factory. And since Oracle does not use the standard factories that are built into Tomcat you will need the parameter for factory. And I could be full of manure and sprouting daisies. But every now and then I get one right. Doug - Original Message - From: Sean M. Duncan To: Sent: Monday, January 17, 2005 8:45 PM Subject: Re: Help: Context.xml Resource difference between 5.0.x and 5.5.x? On Mon, 2005-01-17 at 16:57 -0800, TomK wrote: I'm having trouble moving my webapp from Tomcat 5.0 to 5.5. The dataSource in Context.xml seems to be the issue. According to the 'JNDI how-to' documentation for 5.0 and 5.5, it looks like the '' tag has been removed from the Context.xml and instead you can now supply arbitrary attributes to the tag itself. In 5.0, my Context.xml looked like this and it worked fine: type=oracle.jdbc.pool.OracleDataSource / factory oracle.jdbc.pool.OracleDataSourceFactory driverClassName oracle.jdbc.driver.OracleDriver url jdbc:oracle:thin:@xx:xx:xx user xx password xx ...note that oracle's factory requires user, not username. Moving to 5.5, I changed it to: driverClassName=oracle.jdbc.driver.OracleDriver factory=oracle.jdbc.pool.OracleDataSourceFactory name=jdbc/db1 password=xxx type=oracle.jdbc.pool.OracleDataSource url=jdbc:oracle:thin:@xx:xx:xx user=xx/ ...this new Context.xml doesn't work. I get the following: javax.naming.NamingException: Cannot create resource instance at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:132) at javax.naming.spi.NamingManager.getObjectInstance(Unknown Source) at org.apache.naming.NamingContext.lookup(NamingContext.java:792) any ideas? Almost seems as if the factory attribute of is not being used. thanks tk_ - 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: JAR locking / Tomcat 5.5.4 / Windows
Thanks very much, I'll check the latest version out and post my results, in case anyone else has this issue. -tk didn't_get_my_coffee_this_morning_rant That I find myself saying In case anyone else has this issue is somewhat amazing to me. Either: 1) Hardly anyone is using Windows as their deployment environment for Tomcat. (I probably wouldn't be either, if I had a choice.) or 2) Those using Windows as the deploy environment aren't concerned about re-deploying applications, and are content to simply restart the server, so resource locking is not an issue. or 3) Everyone can properly edit the context.xml file, except me and 5 other people on this list. There have been quite a few posts to this list, as well as bugs opened in bugzilla reporting JAR locking (with versions 5.0.x, 5.5.x). I'm a bit disheartened by the earlier replies. Either the bug was closed as invalid, or the reply was Get yourself a better operating system, or You aren't doing it right. Given the unlikely nature of #3 above, it seems much more likely that this is indeed a bug.I hope it has been fixed. /didn't_get_my_coffee_this_morning_rant Dominik Drzewiecki [EMAIL PROTECTED] wrote: Siarhei Dudzin wrote: Did you find a solution? FYI it has been fixed on 17/12/2004 and the latest CVS version does not suffer from the nasty jar locking. The root of the problem was the JasperLoader locking (using cached getResourceAsStream()) the jars containing jsp tag libraries. It works for me. Please do give it a spin and test for yourselves. BTW, there seems to be 5.5.7 distro coming soon. cheers, /dd On Tue, 4 Jan 2005 15:27:56 -0800 (PST), TomK wrote: I've been following the recent threads regarding JAR locking with Tomcat 5.x on Windows platforms. A few people mentioned they had been able to get either the antiJARLocking or antiResourceLocking attributes to work, so I've spent quite a bit of time trying out different scenarios and configurations, under the impression that I must be missing something simple.however, I've not yet found a situation where either attribute has any effect on deploy/undeploy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAR locking / Tomcat 5.5.4 / Windows
Success! I was able to get the antiResourceLocking attribute to finally take effect with Tomcat 5.5.4. The problem is the default Windows install does not set the Working Path (viewable on the Startup/Shutdown tabs of the service manager that sits in the SysTray). Once I set the working path to the tomcat base directory, and restarted Tomcat, and deployed the WAR, the application files were copied to the temp directory and run from there, just as promised. Undeploy works fine. Interestingly, the directories created in the temp directory aren't deleted when Tomcat is shutdown, for the same reason: the jar's are locked. Dominik -- Regarding your statement that the latest CVS version does not suffer from the nasty jar locking. I'll try it out later, but are you suggesting 5.5.7 will not have JAR locking issues at all, and thus the antiResourceLocking and antiJARLocking attributes will be unnecessary?? thanks -tk TomK [EMAIL PROTECTED] wrote: Thanks very much, I'll check the latest version out and post my results, in case anyone else has this issue. -tk Dominik Drzewiecki wrote: Siarhei Dudzin wrote: Did you find a solution? FYI it has been fixed on 17/12/2004 and the latest CVS version does not suffer from the nasty jar locking. The root of the problem was the JasperLoader locking (using cached getResourceAsStream()) the jars containing jsp tag libraries. It works for me. Please do give it a spin and test for yourselves. BTW, there seems to be 5.5.7 distro coming soon. cheers, /dd On Tue, 4 Jan 2005 15:27:56 -0800 (PST), TomK wrote: I've been following the recent threads regarding JAR locking with Tomcat 5.x on Windows platforms. A few people mentioned they had been able to get either the antiJARLocking or antiResourceLocking attributes to work, so I've spent quite a bit of time trying out different scenarios and configurations, under the impression that I must be missing something simple.however, I've not yet found a situation where either attribute has any effect on deploy/undeploy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JAR locking / Tomcat 5.5.4 / Windows
I've been following the recent threads regarding JAR locking with Tomcat 5.x on Windows platforms. A few people mentioned they had been able to get either the antiJARLocking or antiResourceLocking attributes to work, so I've spent quite a bit of time trying out different scenarios and configurations, under the impression that I must be missing something simple.however, I've not yet found a situation where either attribute has any effect on deploy/undeploy. I've put together a simple app that illustrates the issue.Here's how to replicate: (I've actually started with a fresh, clean copy of Windows XP SP2) 1. Install JRE 5.0 (Update 1) 2. Install Tomcat 5.5.4, using windows installer. 3. Start Tomcat. 4. Using the manager webApp, deploy this WAR. 5. Point your browser to the webApp (named 'sample'), follow the link, enter data in sample form, click OK. 6. note the [TomcatHome]/'temp' directory is empty. 7. Using the manager webApp, undeploy the sample app. at this point, on my machine, struts.jar is left in the WEB-INF/lib directory. Note that at step 5, the application should be running from the 'temp' directory, which it is not.The context.xml for this webApp has the antiResourceLocking=true value set. Setting this attribute in the global context.xml also has no effect. Any ideas are appreciated. thanks tk
Re: JAR locking / Tomcat 5.5.4 / Windows
Re: the WAR link was stripped out in that last message. It is located here: http://www.tomk.nu/tc00/sample.war
