Can is use as context root in Tomcat 7.0.59
Hi All, Is it possible to set am empty string () as the root context in Tomcat 7.0.59? I'm currently using / as the root context path. But since tomcat doesn't like that I want to change the path to something similar. Thanks /Thusitha --
Re: Can is use as context root in Tomcat 7.0.59
Am 20. Juli 2015 09:26:04 MESZ, schrieb Thusitha Thilina Dayaratne thusithathil...@gmail.com: Hi All, Is it possible to set am empty string () as the root context in Tomcat 7.0.59? I'm currently using / as the root context path. But since tomcat doesn't like that I want to change the path to something similar. The context name would be ROOT. See naming in https://tomcat.apache.org/tomcat-7.0-doc/config/context.html. Regards, Felix Thanks /Thusitha -- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Question concerning mod_jk Security Fix CVE-2014-8111
-Ursprüngliche Nachricht- Von: Mark Thomas [mailto:ma...@apache.org] Gesendet: Freitag, 17. Juli 2015 12:33 An: Tomcat Users List Betreff: Re: Question concerning mod_jk Security Fix CVE-2014-8111 On 16/07/2015 13:16, Kreuser, Peter wrote: Please let me repeat my question from June 6th: Why is this CVE still not addressed in Apache Tomcat JK Connectors vulnerabilities http://tomcat.apache.org/security-jk.html? http://www.cvedetails.com/cve/CVE-2014-8111/ I'm a project committer but this is my personal view. It is not an official project view. The information on that CVE was leaked by RedHat's security team when they broke embargoes associated with two Tomcat security vulnerabilities that they had been informed of in advance and in confidence. (There were also errors in the information they leaked about the other vulnerability that made it appear to be much worse than it actually is.) To be clear, the Tomcat committers who are employed by RedHat were in no way responsible for the leaking of this information. The leak was entirely the fault of the RedHat security team. The mod_jk releases involve producing a large number of Windows binaries and experience with tc-native suggests that figuring out the build process - even with the available documentation - will be non-trivial. To give you an idea of what is likely to be involved, compare the documented build instructions for tc-native on Windows [1] with what is actually required to produce a release [2]. Co-coincidently, the committers who typically handle the mod_jk releases are RedHat employees. Given all the above, I personally have little desire to dedicate a large chunk of my time figuring out the mod_jk build process so I can clear up the mess created by RedHat's security team. I'm not against spending the time to better document the mod_jk build process (like I did for tc-native) but that isn't a priority for me right now. I had hoped that, given that the mess is of RedHat's making, that RedHat would have directed one if its emmployees who is familiar with the mod_jk build process to spend the time necessary to produce a new mod_jk release. That hasn't happened. I hadn't realised - until I looked into it as a result of your e-mail - how long it has been since RedHat leaked this confidential information. It is looking increasingly like one of the Tomcat committers is going to have to clean up RedHat's mess for them. I'm not going to be in a position to do anything to fix this until week beginning 27th July but if nothing has been done by then I'll see what I can do. rant If I do end up having to clear up this mess I'll be even more annoyed with RedHat's security team than I am already. I don't actually mind that much that a mistake was made. We all make mistakes and I have made very similar mistakes in the past. What annoys me about this - and I get more annoyed the longer this goes on - is that after RedHat realised they had leaked vulnerability information and that some of the information they had leaked as incorrect RedHat have not (to my knowledge): - publicly stated some of the leaked information was incorrect; - publicly corrected the errors in the information they did leak; - publicly apologised for leaking the information (they have apologised in private so this is less of an issue); - done anything to help clear up the mess such as directing their employees who are Tomcat committers to help with the various releases that became more urgent as a result of these leaks. It is this last point that particularly annoys me. It bears repeating here that the RedHat employees who are committers are in no way responsible for this mess. It just so happens that they are best placed to clean it up. /rant I know this doesn't give you the release you need but hopefully you'll at least have a better understanding of how we ended up where we are and you do have my assurance that I'll look into this (with no guarantee I'll be able to produce the release) in just over a week if no-one beats me to it. Note you do have the option of building from trunk. I'm not aware of anything that needs fixing in mod_jk before the next release so the chances are that a build from the current trunk is going to be very close to a 1.2.41 release. Mark [1] http://tomcat.apache.org/native-doc/ [2] http://wiki.apache.org/tomcat/BuildTcNativeWin - Hi, could you please tell us, when the fixed mod_jk-Version 1.2.41 will be publicly available? The webpage does not mention any vulnerability at all, plus no newer release than the vulnerable 1.2.40. For now RedHat mentions only the fix to the source code from December 2014. http://svn.apache.org/viewvc?view=revisionrevision=1647017 Best regards. Peter Hi Mark, I appreciate your open comment and that clarifies the lengthy
Re: Can is use as context root in Tomcat 7.0.59
H Felix, The context name would be ROOT. See naming in https://tomcat.apache.org/tomcat-7.0-doc/config/context.html . Thanks for the quick response :) Regards 2015-07-20 14:42 GMT+05:30 Felix Schumacher felix.schumac...@internetallee.de: Am 20. Juli 2015 09:26:04 MESZ, schrieb Thusitha Thilina Dayaratne thusithathil...@gmail.com: Hi All, Is it possible to set am empty string () as the root context in Tomcat 7.0.59? I'm currently using / as the root context path. But since tomcat doesn't like that I want to change the path to something similar. The context name would be ROOT. See naming in https://tomcat.apache.org/tomcat-7.0-doc/config/context.html . Regards, Felix Thanks /Thusitha -- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --
Re: Can is use as context root in Tomcat 7.0.59
2015-07-20 12:12 GMT+03:00 Felix Schumacher felix.schumac...@internetallee.de: Am 20. Juli 2015 09:26:04 MESZ, schrieb Thusitha Thilina Dayaratne thusithathil...@gmail.com: Hi All, Is it possible to set am empty string () as the root context in Tomcat 7.0.59? I'm currently using / as the root context path. But since tomcat doesn't like that I want to change the path to something similar. The context name would be ROOT. The above is wrong. See naming in https://tomcat.apache.org/tomcat-7.0-doc/config/context.html. The link is good, more specifically: https://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naming ROOT is base name or Base File Name as listed in the table there. You use it when naming a file: ROOT.war, ROOT directory or ROOT.xml for a context file. The context path when used as explicit value in configuration attribute or in various APIs is an empty string. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Parse and SSL issue
2015-07-20 0:52 GMT+03:00 uzair rashid uzairrashi...@gmail.com: Konstantin: Thank you for your information. Could you please comment on the parse error are well? You helped a lot in understanding all other errors. I really appreciate. To remind of the error: at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455) Jul 16, 2015 3:54:02 PM org.apache.catalina.core.StandardService startInternal INFO: Starting service Catalina Jul 16, 2015 3:54:02 PM org.apache.catalina.core.StandardEngine startInternal INFO: Starting Servlet Engine: Apache Tomcat/7.0.57 Jul 16, 2015 3:54:02 PM org.apache.tomcat.util.digester.Digester fatalError SEVERE: Parse Fatal Error at line 36 column 4: XML document structures must start and end within the same entity. org.xml.sax.SAXParseException: XML document structures must start and end within the same entity. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) https://en.wikipedia.org/wiki/XML#Well-formedness_and_error-handling - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Keeping http-8443 threads in check (Apache Tomcat/6.0.29)
Konstantin Kolinko, Thank You Very Much for pointing me in the right direction. Brad On Sat, Jul 18, 2015 at 4:23 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2015-07-17 23:53 GMT+03:00 Brad Spry dbs...@uncc.edu: After ingesting copious amounts of objects into Fedora Commons, the system returns to an idle state. However, even with the system idle, http-8443 residue remains behind, chewing up RAM and CPU for no good reason: Your chewing up is an exaggeration. If you really want to have a thread pool that stops idle threads, you need to explicitly configure an Executor for you connector. http://tomcat.apache.org/tomcat-6.0-doc/config/executor.html Notes: 1) Online documentation is for the current releases of Tomcat. For Tomcat 6 that is 6.0.44 2) Tomcat 6 forthcoming EOL date has been announced, http://tomcat.apache.org/tomcat-60-eol.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Check if a URL exists programatically
On 07/17/2015 10:48 AM, Mitch Claborn wrote: On 07/16/2015 02:19 PM, chris derham wrote: I already have a custom error page. When I detect that a URL returned by google would return a 404, I exclude it from the search results so that the user never sees it. Mitch Mitch, Ok I see now what you mean. Sorry your original email was quite clear. Hmm interesting challenge. Big picture terms, I guess the two obvious choices seem to be to not use google for searching, or parse the google results, and determine the url validity as you are doing. Depending on the urls you use, that could be horrible. Guess that's where you are. Is not using google an option? Please let us know how you resolve it. Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Doing without google is not an option. We are quite happy with them except for this one, admittedly minor, glitch. I spent some time yesterday digging through code without much luck. Today I'm going to experiment with this: getting a Request Dispatcher for the URL from the ServletContext, creating a dummy ServerRequest and ServerResponse object and invoking include(request, response) or forward() on that dispatcher. With luck, I'll be able to get what would be the response from a HEAD or a GET request in some sort of output stream in the response object, then examine that output stream for the result. I guess I'm giving up on this. I tried the approach described above, but can't seem to make it work. Trying the case of a known-good URL as a baseline. When I invoke displatcher,forward(request,response) my dummy response objects gets called with a sendError(404, /url.html), but I can also see evidence that the code that should run for that URL (a struts action) is running and is returning a good Struts response. When I enable low level logging, it appears to me that the JSP that renders the output is being called, but the output is not making it back to my dummy response object. That sendError() is coming from the DefaultServlet, which is odd because I would think that should not be called as Struts is (should be) intercepting all of the requests. I must be setting something up wrong somewhere. The only next step I can think of is to compile Tomcat for myself so I can debug the execution path from the forward() to figure out what's going on. I can't justify that much time and effort on this. I'm guessing the RequestDispatcher only works down below the filters, which is where Struts is invoked. I welcome any further ideas. -- Mitch - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: programatically manipulating a JSP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sandro, On 7/19/15 7:32 AM, Sandro Boehme wrote: I have a use case where I have to programatically add HTML and/or Scriptlet code to a JSP. It has to be placed beside an HTML tag with a known id or at the end or the beginning within an HTML tag with a known id. Can you do this at the .jsp level, or do you need to modify an existing compiled JSP file? I guess what I'm asking is whether or not you have to post-process the tree, or if you can change the way the output is generated in a more standards-compliant way. For example, you can use jsp:include anywhere in a .jsp and you don't have to go digging-around in the AST for the JSP compiler, which is going to be a tough job. Can you tell us a little more about your use case? We might be able to give you better ideas. I would like to use Jasper 6.0.14 (or a newer version if that helps) but I haven't found tests in http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/test that come close to what I want (didn't check version 6.0.14 though) and I also haven't found documentation that I can use to get into the details. Does it makes sense to use https://theholyjava.wordpress.com/2011/06/10/hacking-jasper-to-get-obj ect-model-of-a-jsp-page/ as a starting point to get it done or is there a better way to approach it in the mean time? I thought about regExp but it seemed to be too unreliably to me. If the output is XHTML (or at least perfectly well-formed x-HTML), then you may be able to use XSLT to post-process the document, but you'd have to do that for every request since you wouldn't be modifying the source in any way. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVrTn4AAoJEBzwKT+lPKRY7l4P/j//PvbXilKatDZJRUsrkDo1 e1i7VwL3+uxYY9NSUP/wF095XsaaFqF5oY+SzAtrcZlDpgRKOo/OW1PNmEaoDMbA NMtND1MzGFnAA2/WRdIR2XRH6eeWPYp2hVYHUCWpLiPZFwoGsc4rT6SaMOEb/vI+ Cy9z+e+wval6V5ZicViFFWtAbxaBG0iRCVftxRw+fnXPI7ik5TVDW4bQAvct/tRK l5z9ExU/t6LDqOte5WElFe8g7oeitScsTu8+1canw0/7o8TjMIBiJi2MN1gEN7Nr lGh9XMwvsnNxQ+iNWYP0l1DB0uJyfkzjEWGJWQa7wCd3QKXy/MdcMrvy3A2AGSBo r4PhA5a/7/iSaDJrxlolEBoJdBIDZoXljOE1i2IsYoIIeyltjRUxOxTbFew9qj8g LEYyQUEU4HkWOEF6oJvMpSAr9NpzU+8lfCPkOikKySqUvfEu2EI467Suc6gmFJsV ShQF0O1ubqzRrav+Uhqj4KRt5FbKn+RE8skQTgEphNs8oE2CAQaRbR+JB4rd94tq GS+U4U+l7xgHgYJF5VyF9Po8f0ickyT7La4AjIWVfFuZstCokf8OSEmB3zypO+xG rphfc5UR90vy5eSwMrlYDmTMA0bCoIhq+93X/nggGSLMK2w/cxmwq77FuDnCxkNm xEZo29Y8yL5HRjCysX8/ =r4Lq -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Parse and SSL issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Uzair, On 7/19/15 4:52 PM, uzair rashid wrote: Konstantin: Thank you for your information. Could you please comment on the parse error are well? You helped a lot in understanding all other errors. I really appreciate. To remind of the error: at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455) Jul 16, 2015 3:54:02 PM org.apache.catalina.core.StandardService startInternal INFO: Starting service Catalina Jul 16, 2015 3:54:02 PM org.apache.catalina.core.StandardEngine startInternal INFO: Starting Servlet Engine: Apache Tomcat/7.0.57 Jul 16, 2015 3:54:02 PM org.apache.tomcat.util.digester.Digester fatalError SEVERE: Parse Fatal Error at line 36 column 4: XML document structures must start and end within the same entity. org.xml.sax.SAXParseException: XML document structures must start and end within the same entity. The error is clear (your XML is broken), but it's not entirely clear which XML document is broken unless you are experienced at reading the stack traces from Tomcat: at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXP arseException(ErrorHandlerWrapper.java:195) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError (ErrorHandlerWrapper.java:174) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(X MLErrorReporter.java:388) at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XM LScanner.java:1427) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl .endEntity(XMLDocumentFragmentScannerImpl.java:905) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.endEnti ty(XMLDocumentScannerImpl.java:604) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.endEntity(XML EntityManager.java:1420) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntit yScanner.java:1769) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.peekChar(XMLE ntityScanner.java:493) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl $FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2688) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XM LDocumentScannerImpl.java:647) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl .scanDocument(XMLDocumentFragmentScannerImpl.java:511) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XM L11Configuration.java:817) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XM L11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.j ava:119) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Abs tractSAXParser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.pa rse(SAXParserImpl.java:522) at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1580) at org.apache.catalina.users.MemoryUserDatabase.open(MemoryUserDatabase.j ava:432) This is coming from the MemoryUserDatabase component, which is likely reading a file called conf/tomcat-users.xml. Check that file to see if it's not valid XML. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVrRwHAAoJEBzwKT+lPKRYUSgP/j5OaqrF7XkxEGJtkdoOFh1H rXap+7vDMngaHR6ZtuQSCKl0gWy4/7fpWhbq6JPfTG+fhC7owPbSO4Lzr9d35mrq 1LS4RIDTc3Grlr9nv0PJbS9CKulSov89X/Xdiv43ixxj1Oqf7/32cDzY9t4i0fiY O7ATLt2L9x0P9HS67oGBb+6uOLnfywfO8q8oNvOUn5hSnxeWbr/RxvZuNztVsiPi e7BUuVSnmPEzkdByfKf4wAllAGSPSpPJN5Sa/ZM8WxmUEGgekEhm1tHxnTsHzfdN qHWlms7TYphTKYAOKUE+oESxf4rMNhn6VMzjH1QzFJeJFL/LZcpGQ2+v2sq6a3d9 ggHjyx1CAp8ZVximF9SfIQ7o9DTF/Hi69G9s5SXirMaYrTqs1wubE/4e95sB9xR7 fKJk/Pqss4q7QZWdA2jVJ0YJQHghMYhR8QIjBZ9VdnioA4CceZU8EJE6KcLt6wdY XCvef3RIgczfoQRymHys7KQtWo9OdQAcTbzaMVOj0cFqC6Q3R0NK/LxCn7HKZN5E U12T0tm87aqxcEZLlok94b4yOXcz0bT2fXaOlKRjlLPCNl32IwzpnP5DbqXyGpHk uO3CXfEl3RUQ9XZizjR8YAEySzXfNXjM5W6Tgs4MWDVkYulFeV1+fE0eI5W5uw/D KoA1F0GLRsnEFHLVWTB1 =mXGv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Check if a URL exists programatically
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mitch, On 7/20/15 2:09 PM, Mitch Claborn wrote: On 07/17/2015 10:48 AM, Mitch Claborn wrote: On 07/16/2015 02:19 PM, chris derham wrote: I already have a custom error page. When I detect that a URL returned by google would return a 404, I exclude it from the search results so that the user never sees it. Mitch Mitch, Ok I see now what you mean. Sorry your original email was quite clear. Hmm interesting challenge. Big picture terms, I guess the two obvious choices seem to be to not use google for searching, or parse the google results, and determine the url validity as you are doing. Depending on the urls you use, that could be horrible. Guess that's where you are. Is not using google an option? Please let us know how you resolve it. Chris - - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Doing without google is not an option. We are quite happy with them except for this one, admittedly minor, glitch. I spent some time yesterday digging through code without much luck. Today I'm going to experiment with this: getting a Request Dispatcher for the URL from the ServletContext, creating a dummy ServerRequest and ServerResponse object and invoking include(request, response) or forward() on that dispatcher. With luck, I'll be able to get what would be the response from a HEAD or a GET request in some sort of output stream in the response object, then examine that output stream for the result. I guess I'm giving up on this. I tried the approach described above, but can't seem to make it work. Trying the case of a known-good URL as a baseline. When I invoke displatcher,forward(request,response) my dummy response objects gets called with a sendError(404, /url.html), but I can also see evidence that the code that should run for that URL (a struts action) is running and is returning a good Struts response. When I enable low level logging, it appears to me that the JSP that renders the output is being called, but the output is not making it back to my dummy response object. That sendError() is coming from the DefaultServlet, which is odd because I would think that should not be called as Struts is (should be) intercepting all of the requests. S2 is implemented as a Filter. If nothing matches in the S2 setup, it will probably just call-down the Filter chain, eventually ending up at the DefaultServlet. So, a 404 is pretty much always handled by the DefaultServlet. I must be setting something up wrong somewhere. The only next step I can think of is to compile Tomcat for myself so I can debug the execution path from the forward() to figure out what's going on. I can't justify that much time and effort on this. I'm guessing the RequestDispatcher only works down below the filters, which is where Struts is invoked. RequestDispatcher will act pretty much just like an incoming request. At this point, you may just want to make the loopback request. You mentioned wasting resources using this approach. Which resources? If you're willing to call the RequestDispatcher, you're pretty much using those resources already. About the only difference is the use of another Thread. You can limit the number of threads used for these loopback requests by creating a second Connector that is only used for loopback requests, and use an Executor that has a small number of threads. Of course, if any incoming request can result in a loopback request, then it's possible to DOS your server just by making lots of requests that will trigger these kinds of lookback requests. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVrXoAAAoJEBzwKT+lPKRYzxwQAK9y9WOmqbDh8pCik1paKHsU aldPFJVwxdgxNxKPnhNHvtBVHBn+aueOv9ywK1MKun2UqYxznZmTon3Fy4IehVcV Y16+45MXXA/dpIDEwVgj8ByNB/7NRPscxkg9IIKV+eliGhhjpb33owCoT8qd5p7/ yDwvVM5bMZ9h4+faHinu/FY56Qx7tjBpXER/uLOK8aDgxgak1TdyhBzQHXktD1zB UPmydwDxlzGv0dODY/cEzWAh8FBDiyZtRakAKSs0rCD3t7Zs3q4JecEFq/vQDP71 xZoGwBtge3+Im2gEav5GYYF2EsDKrEUD1dbqCUyBI3uOnHQvNptngeKXfoq4Vkv6 6HY3VEMS0wsYPAG2JhAc/TVGH0Cm8Eq9FFvlRUeCIjOwVUK0OXACXTP1Wn9VDyUH vo+VfIUHgqzkdoGzKyoU6gvZgA7cwQAAp9iQlrVhbAxtvKkgor607a3g0LZ+A5hI Zw04wNy4ANsYi8ad989Ycg/Xmr9tZId6F1y9+sSmeJ3imWnEOYH6uyToa/0p8cQd VC9SfuOATSrjOdnn7CPiGdnQCmW3JSB3mZBCp4er78rHf5oyDN5Ybgm5jXGfGKI+ 61WlePY/NA5UsIMR8DYWSPIXdJfyVfEQcoUVmWV2fIt2zq0sf0c4wpt69c12PR+z 7aTZc4+lCOLbN0KJ/3zv =8TfU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
problem with x:set variables
I have a large webapp that processes XML data into JSPs using XPath/JSTL
plus some of my own custom tags. The app is working fine on two
separate Tomcat systems (one is TC7 and one is TC8). I copied the app
to a third system (TC 7.0.57) and I'm having problems with all of the
x:set variables on all pages. In the JSP code I simply do:
x:set var=myVar select=$doc///@ /
I then use ${myVar} to insert the string into the HTML. In the first
two TC environments, it inserts the appropriate data from the XML
attribute into the HTML as expected. In the third environment, it does
not recognize the ${myVar} as a variable and simply puts ${myVar} in
the HTML instead of substituting the data value.
I'm including all of the XPath/JSTL taglib jars in the WAR file. And I
don't see any stray XPath/JSTL jars in the TC library or anything. So
theoretically it should work the same. I could have missed something.
But I don't see anything obvious. Obviously, though, something is
different.
Any ideas why it won't substitute in this one environment only? Any
idea where to start looking? What code is responsible for recognizing
the ${...} syntax?
Thanks for any help you can give me.
Jerry
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: problem with x:set variables
BTW Everything else in XPath is working fine on the 3rd
environment. I can do
x:out select=$doc///@ /
and it outputs the data correctly. It appears the only thing not
working is when I reference an x:set variable using the ${...} syntax.
Jerry
On 7/20/2015 7:13 PM, Jerry Malcolm wrote:
I have a large webapp that processes XML data into JSPs using
XPath/JSTL plus some of my own custom tags. The app is working fine
on two separate Tomcat systems (one is TC7 and one is TC8). I copied
the app to a third system (TC 7.0.57) and I'm having problems with all
of the x:set variables on all pages. In the JSP code I simply do:
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat initialize SelectorContext twice when lookup for JNDI defined in web application (META-INF/context.xml)
[sending to users list] On Thu, Jul 16, 2015 at 10:23 AM, Niranjan Karunanandham niranjan.k...@gmail.com wrote: Hi, On debugging Tomcat (7.0.59), I noticed that the SelectorContext is initialized twice when a lookup is performed for JNDI defined in web application (META-INF/context.xml). When the lookup is performed, the Servlet first calls the init method of InitailContext and this returns new SelectorContext(env, true). Then it calls the lookup method of InitialContext which again initializes the SelectorContext but now it returns new SelectorContext(env) [where the SelectorContextor.initialContext is set to *false*] and then the lookup is performed. Why is tomcat initializing the SelectorContext twice here? My Java Webapp Code which does the lookup: *initCtx = new InitialContext();* *Context envContext = (Context) initCtx.lookup(java:comp/env);* *DataSource dataSource = (DataSource) envContext.lookup(*jdbc/contextDB *);* Resource defined in META-INF/context.xml in webapp: Resource name=jdbc/contextDB auth=Container type =javax.sql.DataSource maxActive=100 maxIdle=30 maxWait=1 username=user password=user123 driverClassName=com.mysql.jdbc.Driver url=jdbc:mysql://localhost:3306/WebAppTestDB/ Regards, *Niranjan Karunanandham* -- *Niranjan Karunanandham*
