[ANN] Apache Tomcat 8.0.18 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.0.18. Apache Tomcat 8 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language and Java WebSocket technologies. Apache Tomcat 8.0.18 includes numerous fixes for issues identified in 8.0.17 as well as a number of other enhancements and changes. The notable changes since 8.0.17 include: - A regression that caused response truncation when using forwarding (bug 57475) has been fixed. - Various improvements to ReplicatedMap in Tribes. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-8.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 5.5.x, 6.0.x and 7.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Mod_jk Configuration
>I'm surprised that the Alfresco team is still giving-out advice that >was appropriate in the mid-2000s. >Some notes: >1. Don't put in server.xml. Just don't. >2. "debug" hasn't been used in ... forever. >3. path="" is bad, and isn't necessary if you follow #1 It did not work so i took it out >Normally, docBase="share" would be bad, because it's relative to the >host's appBase and would result in double-deployment. In your case, >you want (?) double-deployment so it's not a big deal. Note that you >are therefore running *two* copies of the Alfresco "share" application >in your server. That may impact your capacity planning. No, 1 running instance which is what we have working on the other server >Also, you (or they?) said that you can't re-base the application to >"/", so I'm not sure why they are recommending that you do that. They answered that question, not me >Is everything else currently working? Just the problem with "/share"? I haven't moved past the /share issue as this is the most important right now. I can't move any further in the server upgrade until this is taken care of, then i can move to other stuff - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Application getting stopped with error code 610 038
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rahul, On 1/27/15 1:56 AM, Shruti-Prithvi wrote: > My tomcat web application stopped working after getting following > error. > > janv. 09, 2015 9:57:16 AM > org.apache.tomcat.util.net.AprEndpoint$Poller run Grave: Poller > failed with error [610 038] : [APR does not understand this error > code] Tomcat version? tcnative version? APR version? OS vendor/version? With a relatively recent version of Tomcat, the startup logs will include the version numbers of tcnative and APR. What about the usage? Are you using Comet/Websocket, or is this just regular HTTP(s) requests? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUx72zAAoJEBzwKT+lPKRY71AQAJUpaYm+Ygf1YhmSbBasJ+sS /AduvAjW4fuIWg4N4JIq09Buu9VXfYt72FJWFZ4n8LudaBpb68myOQ2sMwgznh0O 9dzCAPaHCHp5++7wo0Bdip/vC3kwvm7QLxoZEBXJR/VzaGdCkz9hFn/HxHUePOs2 XV8Lm7RA1NFlDYSqMjN71OvEvYv9QBOhkSwrJJIun33CEWWBY97n9A2yDQ/awq56 FzaX411CSJygBPoWKieh9XEmZCF3XjNlh6Uwv6N4Bh4iadzXuDqpoThY7ih9KjKx M1hA7QnxA1Gt4AznABegD5IS0N+SH2NqazCJbUvQj4yzM9MvPlv5T+GUP9jWVhW7 4AnizeiXJm0DQqWEniwQtiYuGMMhr5WzIm0CuMyjRp+uaX4q4x1W5aACRifrQ827 hz2aGjnlT3JB8GWaMXp6qrpBnAJGPPtA2AWKnkspOMLCkMuEYdDZJ+OhVnIvc2HO tlIJ0H0Ta3SP8CAa3gLwbXOeHT8+i+BMCVL1MP2XK+w9+/6aNdarb9yLalaz8xlf 38u3kTSHhE4Zv3eIYHGFqIizjLfZh8fLLxhEG+7Zq4bmcQh7w/UpKA46fKXRQ+b/ 72UMe7HVuyh4dU4ViVz9qokm2vV1tU1bVd2P/IfzfQZbv4QJtG4QRt3FNi2SnXMg /olE/Fk5qq0XKGPO3rD7 =TtZp -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mod_jk Configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris, On 1/26/15 8:05 PM, Chris Arnold wrote: >>> Yeah, that document is evidently a pack of lies. Specifically, >>> the "path" and "docbase" attributes in are ignored >>> in META-INF/context.xml files, and you really shouldn't have >>> your anywhere else (except in >>> conf/[engine]/[host]/[appname].xml, which behaves almost the >>> same way). >>> >>> Best thing to do is to name the web application the same as >>> where you want it to be deployed and not try to re-write >>> anything. >>> >>> Is there a particular reason you want to map / to /share >>> instead of /share to /share? >> >> Ease of use and it worked in a previous installment. > > I think this goes against what you are saying in the above text > but, I just got a reply from the alfresco mailinglist. Here is what > was said: > > The way we got around this was to just tell tomcat to deploy Share > at / (ROOT) as well as at /share. To do that, we added the > following line to the very end of our tomcat server.xml file (5 > lines from the end, just before the line reading “”): > > > > I don’t know if that’s exactly the right way to go about it, but > it’s worked well for us for about 4.5 years now. I'm surprised that the Alfresco team is still giving-out advice that was appropriate in the mid-2000s. Some notes: 1. Don't put in server.xml. Just don't. 2. "debug" hasn't been used in ... forever. 3. path="" is bad, and isn't necessary if you follow #1 Normally, docBase="share" would be bad, because it's relative to the host's appBase and would result in double-deployment. In your case, you want (?) double-deployment so it's not a big deal. Note that you are therefore running *two* copies of the Alfresco "share" application in your server. That may impact your capacity planning. Also, you (or they?) said that you can't re-base the application to "/", so I'm not sure why they are recommending that you do that. Honestly, that application should be written to be re-baseable without a problem. I'm disappointed with Alfresco that it's not. > I still have a concern with this as we have other sites that we > need to access at the http://domain.tld level and it seems to me ( > I could e understanding his solution wrong) that above solution > will point all http(s)://domain.tld requests to /share. Am I > misunderstanding his solution? Remember that Tomcat controls virtually nothing: if you deploy something on "/" in Tomcat, but don't proxy it in httpd, then it effectively does not exist. So if you only proxy "/share", then "/" doesn't matter. Is everything else currently working? Just the problem with "/share"? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUx70/AAoJEBzwKT+lPKRYVQEP/2nSC7lyg8but7sw/n2zrh0o TqR+Z+MLQJb+pAY5x3ba4Gn+TQvve6XrLkdCBb+ebhOoAz36fIG+Nmb8QemmtXgs aVud0ogbqtvUOL2D67Hitw/yesIzCODzrjv0xX3QkM4As8doSF/ntRCDndlco8TI Jw2fDQMEtjwog8DnMo09H6kwCTOSamzAGG5TDSO3nAWdDErMWwaf9ytltZMo8Ran aG3ZTFpgMg3C6p/txGKxToNFWolP7PTve+jtzn774eGZTktyFWyhA9NKC4NCSwlb 4CGWG8x13BcdSBpqTDgw1UnwDHLNSO4mLkj01E2JAa8JoiGZ7MKgxfyA0e1Bon2p zkk/3XmJ992tSvzIWxwIj38dcdACjTT9sU2cHQO6DB8JxnFO/RM3JXjYCMuh6Up7 +VORu14gZJOPQSPQ8kr+Gctbdb60eAh2G9TLVFT+yxm1vpctzjMQJFmtgsGL8x9y OwaDn7oeVHy5zAz8B/faHJckLTEkgPibkKavEFjyGysABo27wvtA5FXIvHUyezO6 yo75Tu5cFsK5ei3n/QJ+jnxMKJZdXYC2e/FiAskwPIvoKBiPf2avewEjXhr33/Y6 fzWc63qGqe80oryJ4x078M2OhOiENvphpCbfb2CHEwRSzyRPjXUTNcLhCCcoReSm c8CyeBm5y5sPDUnve2/T =39Gx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Strict Transport Security (HSTS) in tomcat 7.0.57
How can i write it..in web.xml? > Date: Tue, 27 Jan 2015 10:48:15 + > From: ma...@apache.org > To: users@tomcat.apache.org > Subject: Re: Strict Transport Security (HSTS) in tomcat 7.0.57 > > On 27/01/2015 09:27, Muhammad Muddassir Farooq wrote: > > Hi,I want to enable Strict Transport Security (HSTS) in tomcat 7.0.57. > > please guide > > Write a filter to add the necessary header. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
Re: persisting sessions best practices
On Tue, Jan 27, 2015 at 3:03 AM, Aristedes Maniatis wrote: > Thank you to Dan and Chris for your valuable comments. > > On 1/19/15 9:21 AM, Daniel Mikusa wrote: > > Question 1: Is the documentation still correct after all these years of > BackupManager being used? Is it still considered of lower reliability? > > > > It's just saying that less people use it. Because DeltaManager is the > default and works fine in a lot of cases, the majority of users are just > going to stick with it. Naturally then less people use BackupManager. It's > not implying that BackupManager has problems. I've see BackupManager used a > bunch of times and it worked great every time. > > > Great. Then just as a summary, let me outline the options: > > Choice 1: to stick or not to stick > If you use sticky sessions, then any session persistence layer is just > there as a backup in case of failure of that node. So, for example, > memcache would be used almost entirely to write entries and is never read > from. You've got the gist of it. Sticky sessions get you 90% of the way there. If that's good enough for your usage, you can stop there. If you can't afford to lose a session then you've got to go the remaining 10% and setup clustering or shared storage for the session data. > If you don't use sticky sessions, then the session persistence layer > becomes a new point of failure and needs its own redundancy and load > balancing. > Correct. Tomcat's Clustering support works in a peer to peer fashion, so data is replicated between the Tomcat nodes. If you use a session store, session data is persisted to that store. The store itself could be a single node or multiple nodes in an HA configuration. That's up to you though. Dan > > Choices 2: which backend > > * JDBC > * memcache > * backup manager (can only be used in sticky mode) > * delta manager > > > For my needs I think the backupManager is the way to go. No extra moving > parts, very simple to implement and not too much extra network traffic. > > > On Mon, Jan 19, 2015 at 11:05 AM, Christopher Schultz wrote: > > My question would be whether you are engineering to solve a problem that > does not yet exist. We went through this conversation years ago at $work, > and decided that users having to re-authenticate in the event of a failure > was an okay compromise given all the work it would require to keep a > high-availability cluster up and running. Our user's needs simply aren't > that critical. > > > This is actually designed to make our life easier with sysadmin more than > anything. We can then take an instance offline to adjust memory usage, > attach a profiler or anything else, without worrying about doing it out of > hours or slowly waiting for all sessions to expire. > > If you have commit rights to the tomcat documentation, can I suggest that > you add your notes about HttpSession.setAttribute(). That hint is > absolutely invaluable! > > Thanks > Ari > > > > > -- > --> > Aristedes Maniatis > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 9550 4001 > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: How to use Jasper to Parse JSP
On 27/01/2015 11:36, t-zhang wrote: > Hi guys > > I am looking for a tool which can parse the JSP code(parse and generate > the AST) Why? What problem are you trying to solve? (There may be a better solution). Mark > If anyone use Jasper to parse the JSP, > Could you share your experience to me? > > I guess the class "org.apache.jasper.compiler.Parser" in Jasper is able > to generate the AST. > But I can't get the Return Value maybe because of I can't import > org.apache.jasper.compiler.Node to my project. > > Best Regards > > Tao Zhang > > > > - > 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
How to use Jasper to Parse JSP
Hi guys I am looking for a tool which can parse the JSP code(parse and generate the AST) If anyone use Jasper to parse the JSP, Could you share your experience to me? I guess the class "org.apache.jasper.compiler.Parser" in Jasper is able to generate the AST. But I can't get the Return Value maybe because of I can't import org.apache.jasper.compiler.Node to my project. Best Regards Tao Zhang - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strict Transport Security (HSTS) in tomcat 7.0.57
On 27/01/2015 09:27, Muhammad Muddassir Farooq wrote: > Hi,I want to enable Strict Transport Security (HSTS) in tomcat 7.0.57. please > guide Write a filter to add the necessary header. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple instances?
On 26/01/2015 16:13, Billy Bones wrote: > Hi Markt, my wiki alias username is ArKam and my Real username is > GaelTherond, thank you very much. You should have access now. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Strict Transport Security (HSTS) in tomcat 7.0.57
Hi,I want to enable Strict Transport Security (HSTS) in tomcat 7.0.57. please guide ThanksMuddassir
Re: persisting sessions best practices
Thank you to Dan and Chris for your valuable comments. On 1/19/15 9:21 AM, Daniel Mikusa wrote: > Question 1: Is the documentation still correct after all these years of > BackupManager being used? Is it still considered of lower reliability? > > It's just saying that less people use it. Because DeltaManager is the default > and works fine in a lot of cases, the majority of users are just going to > stick with it. Naturally then less people use BackupManager. It's not > implying that BackupManager has problems. I've see BackupManager used a bunch > of times and it worked great every time. Great. Then just as a summary, let me outline the options: Choice 1: to stick or not to stick If you use sticky sessions, then any session persistence layer is just there as a backup in case of failure of that node. So, for example, memcache would be used almost entirely to write entries and is never read from. If you don't use sticky sessions, then the session persistence layer becomes a new point of failure and needs its own redundancy and load balancing. Choices 2: which backend * JDBC * memcache * backup manager (can only be used in sticky mode) * delta manager For my needs I think the backupManager is the way to go. No extra moving parts, very simple to implement and not too much extra network traffic. On Mon, Jan 19, 2015 at 11:05 AM, Christopher Schultz wrote: > My question would be whether you are engineering to solve a problem that does > not yet exist. We went through this conversation years ago at $work, and > decided that users having to re-authenticate in the event of a failure was an > okay compromise given all the work it would require to keep a > high-availability cluster up and running. Our user's needs simply aren't that > critical. This is actually designed to make our life easier with sysadmin more than anything. We can then take an instance offline to adjust memory usage, attach a profiler or anything else, without worrying about doing it out of hours or slowly waiting for all sessions to expire. If you have commit rights to the tomcat documentation, can I suggest that you add your notes about HttpSession.setAttribute(). That hint is absolutely invaluable! Thanks Ari -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
