svn commit: r1827981 - in /tomcat/tc8.5.x/trunk: ./ build.xml java/org/apache/catalina/valves/LoadBalancerDrainingValve.java test/org/apache/catalina/valves/TestLoadBalancerDrainingValve.java webapps/
Author: schultz Date: Thu Mar 29 12:11:49 2018 New Revision: 1827981 URL: http://svn.apache.org/viewvc?rev=1827981&view=rev Log: Back-port r1799498, r1799514 (partial), r1799677, and r1800980 to add LoadBalancerDrainingFilter to Tomcat 8.5.x. Added: tomcat/tc8.5.x/trunk/java/org/apache/catalina/valves/LoadBalancerDrainingValve.java - copied, changed from r1799498, tomcat/trunk/java/org/apache/catalina/valves/LoadBalancerDrainingValve.java tomcat/tc8.5.x/trunk/test/org/apache/catalina/valves/TestLoadBalancerDrainingValve.java - copied, changed from r1799498, tomcat/trunk/test/org/apache/catalina/valves/TestLoadBalancerDrainingValve.java Modified: tomcat/tc8.5.x/trunk/ (props changed) tomcat/tc8.5.x/trunk/build.xml tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml tomcat/tc8.5.x/trunk/webapps/docs/config/valve.xml Propchange: tomcat/tc8.5.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Mar 29 12:11:49 2018 @@ -1,2 +1,2 @@ /tomcat/tc8.0.x/trunk:1809644 -/tomcat/trunk:1734785,1734799,1734845,1734928,1735041,1735044,1735480,1735577,1735597,1735599-1735600,1735615,1736145,1736162,1736209,1736280,1736297,1736299,1736489,1736646,1736703,1736836,1736849,1737104-1737105,1737112,1737117,1737119-1737120,1737155,1737157,1737192,1737280,1737339,1737632,1737664,1737715,1737748,1737785,1737834,1737860,1737903,1737959,1738005,1738007,1738014-1738015,1738018,1738022,1738039,1738043,1738059-1738060,1738147,1738149,1738174-1738175,1738261,1738589,1738623-1738625,1738643,1738816,1738850,1738855,1738946-1738948,1738953-1738954,1738979,1738982,1739079-1739081,1739087,1739113,1739153,1739172,1739176,1739191,1739474,1739492,1739726,1739762,1739775,1739814,1739817-1739818,1739975,1740131,1740324,1740465,1740495,1740508-1740509,1740520,1740535,1740707,1740803,1740810,1740969,1740980,1740991,1740997,1741015,1741033,1741036,1741058,1741060,1741080,1741147,1741159,1741164,1741173,1741181,1741190,1741197,1741202,1741208,1741213,1741221,1741225,1741232,1741409 ,1741501,1741677,1741892,1741896,1741984,1742023,1742042,1742071,1742090,1742093,1742101,1742105,1742111,1742139,1742146,1742148,1742166,1742181,1742184,1742187,1742246,1742248-1742251,1742263-1742264,1742268,1742276,1742369,1742387,1742448,1742509-1742512,1742917,1742919,1742933,1742975-1742976,1742984,1742986,1743019,1743115,1743117,1743124-1743125,1743134,1743425,1743554,1743679,1743696-1743698,1743700-1743701,1744058,1744064-1744065,1744125,1744149,1744194,1744229,1744270,1744323,1744432,1744684,1744697,1744705,1744713,1744760,1744786,1745083,1745142-1745143,1745145,1745177,1745179-1745180,1745227,1745248,1745254,1745337,1745467,1745473,1745535,1745576,1745735,1745744,1746304,1746306-1746307,1746319,1746327,1746338,1746340-1746341,1746344,1746427,1746441,1746473,1746490,1746492,1746495-1746496,1746499-1746501,1746503-1746507,1746509,1746549,1746551,1746554,1746556,1746558,1746584,1746620,1746649,1746724,1746939,1746989,1747014,1747028,1747035,1747210,1747225,1747234,1747253,1747 404,1747506,1747536,1747924,1747980,1747993,1748001,1748253,1748452,1748547,1748629,1748676,1748715,1749287,1749296,1749328,1749373,1749465,1749506,1749508,1749665-1749666,1749763,1749865-1749866,1749898,1749978,1749980,1750011,1750015,1750056,1750480,1750617,1750634,1750692,1750697,1750700,1750703,1750707,1750714,1750718,1750723,1750774,1750899,1750975,1750995,1751061,1751097,1751173,1751438,1751447,1751463,1751702,1752212,1752737,1752745,1753078,1753080,1753358,1753363,1754111,1754140-1754141,1754281,1754310,1754445,1754467,1754494,1754496,1754528,1754532-1754533,1754613,1754714,1754874,1754941,1754944,1754950-1754951,1755005,1755007,1755009,1755132,1755180-1755181,1755185,1755190,1755204-1755206,1755208,1755214,1755224,1755227,1755230,1755629,1755646-1755647,1755650,1755653,1755675,1755680,1755683,1755693,1755717,1755731-1755737,1755812,1755828,1755884,1755890,1755918-1755919,1755942,1755958,1755960,1755970,1755993,1756013,1756019,1756039,1756056,1756083-1756114,1756175,1756288-1 756289,1756408-1756410,1756778,1756798,1756878,1756898,1756939,1757123-1757124,1757126,1757128,1757132-1757133,1757136,1757145,1757167-1757168,1757175,1757180,1757182,1757195,1757271,1757278,1757347,1757353-1757354,1757363,1757374,1757399,1757406,1757408,1757485,1757495,1757499,1757527,1757578,1757684,1757722,1757727,1757790,1757799,1757813,1757853,1757883,1757903,1757976,1757997,1758000,1758058,1758072-1758075,1758078-1758079,1758223,1758257,1758261,1758276,1758292,1758369,1758378-1758383,1758421,1758423,1758425-1758427,1758430,1758443,1758448,1758459,1758483,1758486-1758487,1758499,1758525,1758556,1758580,1758582,1758584,1758588,1758842,1759019,1759212,1759224,1759227,1759252,1759274,1759513-1759516,1759611,1759757,1759785-1759790,1760005,1760022,1760109-1760110,1760135,1760200-1760201,1760227,1760300,1760397,1760446,1760454,1760640,1760648,1761057,1761422,1761491,1761498,1761500-176
svn commit: r1827982 - /tomcat/tc8.5.x/trunk/build.xml
Author: schultz
Date: Thu Mar 29 12:13:41 2018
New Revision: 1827982
URL: http://svn.apache.org/viewvc?rev=1827982&view=rev
Log:
Revert inadvertent changes to build.xml in r1827981.
Modified:
tomcat/tc8.5.x/trunk/build.xml
Modified: tomcat/tc8.5.x/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc8.5.x/trunk/build.xml?rev=1827982&r1=1827981&r2=1827982&view=diff
==
--- tomcat/tc8.5.x/trunk/build.xml (original)
+++ tomcat/tc8.5.x/trunk/build.xml Thu Mar 29 12:13:41 2018
@@ -1435,8 +1435,8 @@
-
+haltonfailure="${test.haltonfailure}"
+threads="${test.threads}" >
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DBCP2 in Tomcat
Rémy, On 3/28/18 2:25 PM, Rémy Maucherat wrote: > Hi, > > In Tomcat, DBCP2 is missing the XA portion (all contained in a single > "managed" package). So at work I now got some people asking about that > removal, and that's always a bit annoying as they have to go to a separate > vanilla DBCP2 to get the functionality. Annoying sometimes. > > So it would be possible to add the classes in Tomcat (including the > javax.transaction to build, as that's the Tomcat way to deal with that), > even though the user would need to add its own transaction manager to do > anything with it. > > Should I now add it (only in 9/trunk) or instead leave things the way they > are ? Both work to be honest, it's just that I've been bitten by the "we > only ship 3/4 of DBCP and I didn't know it" bug. I've always wondered why we bother to package-rename DBCP2 and check-in the source into our svn repo (soon to be Git). Why not pull DBCP2 from source during the build and re-name it on the fly? -chris signature.asc Description: OpenPGP digital signature
Re: DBCP2 in Tomcat
On Thu, Mar 29, 2018 at 2:33 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > Rémy, > > On 3/28/18 2:25 PM, Rémy Maucherat wrote: > > Hi, > > > > In Tomcat, DBCP2 is missing the XA portion (all contained in a single > > "managed" package). So at work I now got some people asking about that > > removal, and that's always a bit annoying as they have to go to a > separate > > vanilla DBCP2 to get the functionality. Annoying sometimes. > > > > So it would be possible to add the classes in Tomcat (including the > > javax.transaction to build, as that's the Tomcat way to deal with that), > > even though the user would need to add its own transaction manager to do > > anything with it. > > > > Should I now add it (only in 9/trunk) or instead leave things the way > they > > are ? Both work to be honest, it's just that I've been bitten by the "we > > only ship 3/4 of DBCP and I didn't know it" bug. > > I've always wondered why we bother to package-rename DBCP2 and check-in > the source into our svn repo (soon to be Git). Why not pull DBCP2 from > source during the build and re-name it on the fly? > > Because that's what was done before Tomcat 8.0 and it's not done like that now :) Mark wrote this: Switch to including Apache Commons DBCP via a package renamed svn copy rather than building from a source release for consistency with other Commons packages and to allow faster releases to fix DBCP related issues. (markt) And you didn't complain then it seems. Rémy
Re: DBCP2 in Tomcat
Rémy, On 3/29/18 8:42 AM, Rémy Maucherat wrote: > On Thu, Mar 29, 2018 at 2:33 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> Rémy, >> >> On 3/28/18 2:25 PM, Rémy Maucherat wrote: >>> Hi, >>> >>> In Tomcat, DBCP2 is missing the XA portion (all contained in a single >>> "managed" package). So at work I now got some people asking about that >>> removal, and that's always a bit annoying as they have to go to a >> separate >>> vanilla DBCP2 to get the functionality. Annoying sometimes. >>> >>> So it would be possible to add the classes in Tomcat (including the >>> javax.transaction to build, as that's the Tomcat way to deal with that), >>> even though the user would need to add its own transaction manager to do >>> anything with it. >>> >>> Should I now add it (only in 9/trunk) or instead leave things the way >> they >>> are ? Both work to be honest, it's just that I've been bitten by the "we >>> only ship 3/4 of DBCP and I didn't know it" bug. >> >> I've always wondered why we bother to package-rename DBCP2 and check-in >> the source into our svn repo (soon to be Git). Why not pull DBCP2 from >> source during the build and re-name it on the fly? >> >> Because that's what was done before Tomcat 8.0 and it's not done like that > now :) > Mark wrote this: > Switch to including Apache Commons DBCP via a package renamed svn > copy > rather than building from a source release for consistency with > other > Commons packages and to allow faster releases to fix DBCP related > issues. (markt) > > And you didn't complain then it seems. So we do it this way because I failed to speak-up? Unlikely. Anyhow, this seems like a "DBCP related issue" so we ought to be able to do a "faster release" by duplicating more code, then, eh? I'm +0 on this, FTR. -chris signature.asc Description: OpenPGP digital signature
[Bug 62231] New: java.lang.IllegalStateException: Component ID main:j_idt56 has already been found in the view
https://bz.apache.org/bugzilla/show_bug.cgi?id=62231 Bug ID: 62231 Summary: java.lang.IllegalStateException: Component ID main:j_idt56 has already been found in the view Product: Tomcat 7 Version: 7.0.82 Hardware: PC Status: NEW Severity: critical Priority: P2 Component: Servlet & JSP API Assignee: dev@tomcat.apache.org Reporter: rambabu.papp...@accenture.com Target Milestone: --- Hi, We are migrating the application from IBM WAS8.5.2 to Tomcat 7. We have used javax.faces-2.1.7 to compile and run the JSF pages in the current project. The issue related to the state saving in session scope. The dynamic ID which generating and append to the form id is not refreshing by which causing the below error. Could you please help us to resolve this issue and it is urgent because of this Application paused to move for Go Live. HTTP Status 500 - Component ID main:j_idt56 has already been found in the view. type Exception report message Component ID main:j_idt56 has already been found in the view. description The server encountered an internal error that prevented it from fulfilling this request. exception javax.servlet.ServletException: Component ID main:j_idt56 has already been found in the view. javax.faces.webapp.FacesServlet.service(FacesServlet.java:606) org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:349) org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) com.aig.pad.servlet.PADFilterServlet.doFilter(PADFilterServlet.java:51) root cause java.lang.IllegalStateException: Component ID main:j_idt56 has already been found in the view. com.sun.faces.util.Util.checkIdUniqueness(Util.java:836) com.sun.faces.util.Util.checkIdUniqueness(Util.java:820) com.sun.faces.util.Util.checkIdUniqueness(Util.java:820) com.sun.faces.application.view.FaceletPartialStateManagementStrategy.saveView(FaceletPartialStateManagementStrategy.java:461) com.sun.faces.application.StateManagerImpl.saveView(StateManagerImpl.java:89) com.sun.faces.application.view.WriteBehindStateWriter.flushToWriter(WriteBehindStateWriter.java:225) com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:456) com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:124) javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) org.apache.myfaces.tomahawk.application.ResourceViewHandlerWrapper.renderView(ResourceViewHandlerWrapper.java:93) com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:349) org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) com.aig.pad.servlet.PADFilterServlet.doFilter(PADFilterServlet.java:51) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750 --- Comment #1 from Christopher Schultz --- What about a listener for authentication events? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DBCP2 in Tomcat
On Thu, Mar 29, 2018 at 3:15 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > Rémy, > > On 3/29/18 8:42 AM, Rémy Maucherat wrote: > > On Thu, Mar 29, 2018 at 2:33 PM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > >> Rémy, > >> > >> On 3/28/18 2:25 PM, Rémy Maucherat wrote: > >>> Hi, > >>> > >>> In Tomcat, DBCP2 is missing the XA portion (all contained in a single > >>> "managed" package). So at work I now got some people asking about that > >>> removal, and that's always a bit annoying as they have to go to a > >> separate > >>> vanilla DBCP2 to get the functionality. Annoying sometimes. > >>> > >>> So it would be possible to add the classes in Tomcat (including the > >>> javax.transaction to build, as that's the Tomcat way to deal with > that), > >>> even though the user would need to add its own transaction manager to > do > >>> anything with it. > >>> > >>> Should I now add it (only in 9/trunk) or instead leave things the way > >> they > >>> are ? Both work to be honest, it's just that I've been bitten by the > "we > >>> only ship 3/4 of DBCP and I didn't know it" bug. > >> > >> I've always wondered why we bother to package-rename DBCP2 and check-in > >> the source into our svn repo (soon to be Git). Why not pull DBCP2 from > >> source during the build and re-name it on the fly? > >> > >> Because that's what was done before Tomcat 8.0 and it's not done like > that > > now :) > > Mark wrote this: > > Switch to including Apache Commons DBCP via a package renamed svn > > copy > > rather than building from a source release for consistency with > > other > > Commons packages and to allow faster releases to fix DBCP related > > issues. (markt) > > > > And you didn't complain then it seems. > > So we do it this way because I failed to speak-up? Unlikely. > It was done in 8.0.6 with the justification I quoted above and I have to assume that nobody complained. I was busy doing NIO2 stuff at that time personally. That's all I can remember. > > Anyhow, this seems like a "DBCP related issue" so we ought to be able to > do a "faster release" by duplicating more code, then, eh? > The rationale was probably: you can fix bugs without having to wait for a DBCP release. I'm not certain this actually happened though. I actually have a question. There's also that *second* connection pool, Tomcat JDBC, although it is more "external" as it is located inside the modules. So reading the list of "pros" from its docs, it seems DBCP addressed most (all ?) of them, except that it's still significantly bigger. So what's the current benefits of Tomcat JDBC over Tomcat DBCP2 ? Did anyone do benchmarks or anything ? Rémy > > I'm +0 on this, FTR. > > -chris > >
[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750 --- Comment #2 from Christopher Schultz --- Created attachment 35824 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35824&action=edit Draft patch to give an idea of the proposal See this draft patch for something that might work. At least, it will meet *my* needs. There is no provision for registering these listeners. It's just an example of how this kind of thing could work with FormAuthenticator as the guinea pig class. Comments welcome. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DBCP2 in Tomcat
Rémy, On 3/29/18 9:30 AM, Rémy Maucherat wrote: > On Thu, Mar 29, 2018 at 3:15 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> Rémy, >> >> On 3/29/18 8:42 AM, Rémy Maucherat wrote: >>> On Thu, Mar 29, 2018 at 2:33 PM, Christopher Schultz < >>> ch...@christopherschultz.net> wrote: >>> Rémy, On 3/28/18 2:25 PM, Rémy Maucherat wrote: > Hi, > > In Tomcat, DBCP2 is missing the XA portion (all contained in a single > "managed" package). So at work I now got some people asking about that > removal, and that's always a bit annoying as they have to go to a separate > vanilla DBCP2 to get the functionality. Annoying sometimes. > > So it would be possible to add the classes in Tomcat (including the > javax.transaction to build, as that's the Tomcat way to deal with >> that), > even though the user would need to add its own transaction manager to >> do > anything with it. > > Should I now add it (only in 9/trunk) or instead leave things the way they > are ? Both work to be honest, it's just that I've been bitten by the >> "we > only ship 3/4 of DBCP and I didn't know it" bug. I've always wondered why we bother to package-rename DBCP2 and check-in the source into our svn repo (soon to be Git). Why not pull DBCP2 from source during the build and re-name it on the fly? Because that's what was done before Tomcat 8.0 and it's not done like >> that >>> now :) >>> Mark wrote this: >>> Switch to including Apache Commons DBCP via a package renamed svn >>> copy >>> rather than building from a source release for consistency with >>> other >>> Commons packages and to allow faster releases to fix DBCP related >>> issues. (markt) >>> >>> And you didn't complain then it seems. >> >> So we do it this way because I failed to speak-up? Unlikely. >> > > It was done in 8.0.6 with the justification I quoted above and I have to > assume that nobody complained. I was busy doing NIO2 stuff at that time > personally. That's all I can remember. > >> >> Anyhow, this seems like a "DBCP related issue" so we ought to be able to >> do a "faster release" by duplicating more code, then, eh? >> > > The rationale was probably: you can fix bugs without having to wait for a > DBCP release. I'm not certain this actually happened though. > > I actually have a question. There's also that *second* connection pool, > Tomcat JDBC, although it is more "external" as it is located inside the > modules. So reading the list of "pros" from its docs, it seems DBCP > addressed most (all ?) of them, except that it's still significantly > bigger. So what's the current benefits of Tomcat JDBC over Tomcat DBCP2 ? > Did anyone do benchmarks or anything ? I believe Filip built that in response to the issues with DBCP at the time. I assume that benchmarks were done at the time proving the usefulness of the tomcat-pool over DBCP 1.x. I know of no new benchmarks. Sounds like fodder for an ApacheCon presentation. :) Tomcat-pool does have some features that DBCP2 still lacks (such as interceptors), which probably means that it serves a niche. I'm not sure how large that niche is. At some point, it probably makes sense to extract tomcat-pool from the Tomcat project and make it a separate entity. Probably not a TLP, but at least something that can be grabbed from source separately from Tomcat and used independently. Of course, you can already just grab tomcat-jdbc.jar and use it separately (right?) but we don't make it obvious how to do that (The build-tomcat-jdbc doesn't have a "description" attribute and so doesn't show up in ant -projecthelp). Perhaps the git-migration would be an opportunity to do that. -chris signature.asc Description: OpenPGP digital signature
Request for comment on BZ 59750 (authentication listener)
All, For reference: https://bz.apache.org/bugzilla/show_bug.cgi?id=59750 I've got a proposal (in patch form) attached to that BZ issue. Ralf's enhancement request is fairly terse, but this is something I'd like to have as well. The requirement is to be able to log failed authentication attempts. As it stands, using container-managed authentication does not allow this (as far as I can tell). My proposal is essentially a new listener interface that authenticator classes will invoke (if registered) when an authentication event occurs (success or failure). The Request object and username are currently arguments to the two methods on the interface. You can read the entire current path without even scrolling your screen. Before attempting to publish a more complete patch, I wanted to know if there was any appetite for this kind of thing, or any objections. Thanks, -chris signature.asc Description: OpenPGP digital signature
[Bug 62231] java.lang.IllegalStateException: Component ID main:j_idt56 has already been found in the view
https://bz.apache.org/bugzilla/show_bug.cgi?id=62231 Christopher Schultz changed: What|Removed |Added OS||All --- Comment #1 from Christopher Schultz --- This seems like a problem with JSF, not with Tomcat. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62231] java.lang.IllegalStateException: Component ID main:j_idt56 has already been found in the view
https://bz.apache.org/bugzilla/show_bug.cgi?id=62231 --- Comment #2 from Rambabu Pappala --- (In reply to Christopher Schultz from comment #1) > This seems like a problem with JSF, not with Tomcat. Thanks for getting back. Can you please elaborate, which can be possible issue with JSF. Is this related to JSF jar used for compile and run? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Request for comment on BZ 59750 (authentication listener)
On Thu, Mar 29, 2018 at 3:48 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > All, > > For reference: https://bz.apache.org/bugzilla/show_bug.cgi?id=59750 > > I've got a proposal (in patch form) attached to that BZ issue. > > Ralf's enhancement request is fairly terse, but this is something I'd > like to have as well. > > The requirement is to be able to log failed authentication attempts. As > it stands, using container-managed authentication does not allow this > (as far as I can tell). > > My proposal is essentially a new listener interface that authenticator > classes will invoke (if registered) when an authentication event occurs > (success or failure). The Request object and username are currently > arguments to the two methods on the interface. > > You can read the entire current path without even scrolling your screen. > > Before attempting to publish a more complete patch, I wanted to know if > there was any appetite for this kind of thing, or any objections. > Ok with the idea, but the patch is indeed very incomplete. Rémy > > Thanks, > -chris > >
Re: Request for comment on BZ 59750 (authentication listener)
On Thu, Mar 29, 2018 at 11:41 AM, Rémy Maucherat wrote: > On Thu, Mar 29, 2018 at 3:48 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> All, >> >> For reference: https://bz.apache.org/bugzilla/show_bug.cgi?id=59750 >> >> I've got a proposal (in patch form) attached to that BZ issue. >> >> Ralf's enhancement request is fairly terse, but this is something I'd >> like to have as well. >> >> The requirement is to be able to log failed authentication attempts. As >> it stands, using container-managed authentication does not allow this >> (as far as I can tell). >> >> My proposal is essentially a new listener interface that authenticator >> classes will invoke (if registered) when an authentication event occurs >> (success or failure). The Request object and username are currently >> arguments to the two methods on the interface. >> >> You can read the entire current path without even scrolling your screen. >> >> Before attempting to publish a more complete patch, I wanted to know if >> there was any appetite for this kind of thing, or any objections. >> > > Ok with the idea, but the patch is indeed very incomplete. +1, I like the idea too. > > Rémy > >> >> Thanks, >> -chris >> >> - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Request for comment on BZ 59750 (authentication listener)
Rémy, On 3/29/18 11:41 AM, Rémy Maucherat wrote: > On Thu, Mar 29, 2018 at 3:48 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> All, >> >> For reference: https://bz.apache.org/bugzilla/show_bug.cgi?id=59750 >> >> I've got a proposal (in patch form) attached to that BZ issue. >> >> Ralf's enhancement request is fairly terse, but this is something I'd >> like to have as well. >> >> The requirement is to be able to log failed authentication attempts. As >> it stands, using container-managed authentication does not allow this >> (as far as I can tell). >> >> My proposal is essentially a new listener interface that authenticator >> classes will invoke (if registered) when an authentication event occurs >> (success or failure). The Request object and username are currently >> arguments to the two methods on the interface. >> >> You can read the entire current path without even scrolling your screen. >> >> Before attempting to publish a more complete patch, I wanted to know if >> there was any appetite for this kind of thing, or any objections. >> > > Ok with the idea, but the patch is indeed very incomplete. Absolutely. I wanted to make sure there were no -1s before I spent much time on it. That represents maybe 5 minutes of work :) Some specific questions: For FormAuthenticator: there are several calls to authenticate() in doAuthenticate. I chose to ignore the call at the top of the method because I didn't understand the purpose. Something about re-authentication of a previous-authentication? Would it be appropriate to also fire an authentication event at that time? For Basic/DigestAuthenticator: since technically the user is being authenticated at *every* request, should we bother trying to avoid spamming the Listener, or should we let the Listener decide how to handle the huge number of events it will likely get? Does Tomcat know whether the authentication is a re-authentication or not? If so, should it let the Listener know this is a re-authentication? Implementing a listener in a webapp: can a listener be registered from within the web application without any ClassLoader weirdness? What options exist for writing a listener that doesn't require a compile-time dependency on Tomcat? (I suspect this is unavoidable, because even if reflection is used to invoke the listener's method by *name* and not via an interface-call, the Tomcat-specific Request class is a parameter to the interface methods. Changing that to "Object" kind of defeats the purpose of the interface.) Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: GSoC2018 - COMDEV-217 (AJP client library and command line tools)
On 27/03/18 09:54, Milan Karunarathne wrote: > Thanks for your reply! > > As the beginning, Do we need implement UI for the JMeter? Don't know. Probably better to ask the JMeter folks. Mark > > Regards, Thanks > > On Tue, Mar 27, 2018 at 2:18 PM, Mark Thomas wrote: > >> On 27 March 2018 08:25:27 BST, Milan Karunarathne < >> mhkarunarat...@gmail.com> wrote: >>> Hi, >>> >>> For the Implementation of AJP client, can I use *mod_jk* protocol? >> >> mod_jk is the name of an httpd module. AJP is the protocol used by mod_jk. >> Specifically AJP 1.3. I would expect this AJP client to implement the AJP >> 1.3 protocol. >> >> Mark >> >> >>> >>> On Sat, Mar 17, 2018 at 3:01 AM, Mark Thomas wrote: >>> On 16/03/18 21:18, Milan Karunarathne wrote: > Hi All, > > I am a 3rd year undergraduate of University of Moratuwa, Sri Lanka. >>> I > have been a proud contributor to open source products. I have >>> achieved GSoC > 2015 for OpenMRS organization (Support Laboratory Data Exchange >>> with > FHIR)[1]. I have completed my internship at *WSO2 Lanka (Pvt) >>> Ltd*(Open > source middleware company). I am passionate about Computer Science >>> and I > have a solid interest in open > source developments. > > I am interested in the $subject. I went through the issue on Jira >>> and > Bugzilla and got a brief understanding of the implementation. > > Can anyone kindly give me further guidance on procedures for the >>> project? > Your admirable information is highly appreciated. GSoC applications are due by 27 March. As part of your application you will need to included a detailed plan >>> of work. The expectation is that you write that plan with feedback from >>> the Tomcat and JMeter communities. We won't write it for you but we will review your drafts and provide feedback. We can also answer any technical questions you have that you think >>> you might need an answer to in order to develop your plan. Good luck with your application. Mark > > Thanks > Regards, > > *Milan Karunarathne* > Undergraduate > BSc. Information Technology > University of Moratuwa, Sri Lanka > > https://www.linkedin.com/in/milankarunarathne/ > https://github.com/milankarunarathne > https://twitter.com/hasithamilan > [1] > >>> https://www.google-melange.com/archive/gsoc/2015/orgs/openmrs/projects/ milankarunarathne.html > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224 --- Comment #4 from Mark Thomas --- The JNDI lookup must be happening on the ForkJoin Thread. The JNDI depends on the TCCL being set and it is no longer set on a ForkJoin thread (to avoid the memory leak). I'll confirm the Java 9 fix and then disable the protection for Java 9 onwards. Note that with the memory leak protection in place or when running on Java 9 onwards, the TCCL will have to be set on a ForkJoin thread. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1828016 - in /tomcat/trunk: java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java webapps/docs/changelog.xml webapps/docs/config/listeners.xml
Author: markt
Date: Thu Mar 29 19:28:30 2018
New Revision: 1828016
URL: http://svn.apache.org/viewvc?rev=1828016&view=rev
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62224
Disable the forkJoinCommonPoolProtection of the JreMemoryLeakPreventionListener
when running on Java 9 and above since the underlying JRE bug has been fixed.
Modified:
tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
tomcat/trunk/webapps/docs/changelog.xml
tomcat/trunk/webapps/docs/config/listeners.xml
Modified:
tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java?rev=1828016&r1=1828015&r2=1828016&view=diff
==
---
tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
(original)
+++
tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
Thu Mar 29 19:28:30 2018
@@ -349,9 +349,10 @@ public class JreMemoryLeakPreventionList
}
/*
- * Present in Java 8 onwards
+ * Present in Java 7 onwards
+ * Fixed in Java 9 (from early access build 156)
*/
-if (forkJoinCommonPoolProtection) {
+if (forkJoinCommonPoolProtection &&
!JreCompat.isJre9Available()) {
// Don't override any explicitly set property
if
(System.getProperty(FORK_JOIN_POOL_THREAD_FACTORY_PROPERTY) == null) {
System.setProperty(FORK_JOIN_POOL_THREAD_FACTORY_PROPERTY,
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1828016&r1=1828015&r2=1828016&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Thu Mar 29 19:28:30 2018
@@ -108,6 +108,11 @@
must be sent in order of increasing stream ID. These restriction were
not being enforced leading to protocol errors at the client. (markt)
+
+62224: Disable the forkJoinCommonPoolProtection
+of the JreMemoryLeakPreventionListener when running on
Java
+9 and above since the underlying JRE bug has been fixed. (markt)
+
Modified: tomcat/trunk/webapps/docs/config/listeners.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/listeners.xml?rev=1828016&r1=1828015&r2=1828016&view=diff
==
--- tomcat/trunk/webapps/docs/config/listeners.xml (original)
+++ tomcat/trunk/webapps/docs/config/listeners.xml Thu Mar 29 19:28:30 2018
@@ -212,7 +212,8 @@
java.util.concurrent.ForkJoinPool.common.threadFactory
system property. If this property is set when Tomcat starts, Tomcat
will
not over-ride it even if this protection is explicitly enabled. The
-default is true.
+default is true. This protection is disabled if running
on
+Java 9 onwards since the leak has been fixed for Java 9 onwards.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1828017 - in /tomcat/tc8.5.x/trunk: ./ java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java webapps/docs/changelog.xml webapps/docs/config/listeners.xml
Author: markt Date: Thu Mar 29 19:33:44 2018 New Revision: 1828017 URL: http://svn.apache.org/viewvc?rev=1828017&view=rev Log: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62224 Disable the forkJoinCommonPoolProtection of the JreMemoryLeakPreventionListener when running on Java 9 and above since the underlying JRE bug has been fixed. Modified: tomcat/tc8.5.x/trunk/ (props changed) tomcat/tc8.5.x/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml tomcat/tc8.5.x/trunk/webapps/docs/config/listeners.xml Propchange: tomcat/tc8.5.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Mar 29 19:33:44 2018 @@ -1,2 +1,2 @@ /tomcat/tc8.0.x/trunk:1809644 -/tomcat/trunk:1734785,1734799,1734845,1734928,1735041,1735044,1735480,1735577,1735597,1735599-1735600,1735615,1736145,1736162,1736209,1736280,1736297,1736299,1736489,1736646,1736703,1736836,1736849,1737104-1737105,1737112,1737117,1737119-1737120,1737155,1737157,1737192,1737280,1737339,1737632,1737664,1737715,1737748,1737785,1737834,1737860,1737903,1737959,1738005,1738007,1738014-1738015,1738018,1738022,1738039,1738043,1738059-1738060,1738147,1738149,1738174-1738175,1738261,1738589,1738623-1738625,1738643,1738816,1738850,1738855,1738946-1738948,1738953-1738954,1738979,1738982,1739079-1739081,1739087,1739113,1739153,1739172,1739176,1739191,1739474,1739492,1739726,1739762,1739775,1739814,1739817-1739818,1739975,1740131,1740324,1740465,1740495,1740508-1740509,1740520,1740535,1740707,1740803,1740810,1740969,1740980,1740991,1740997,1741015,1741033,1741036,1741058,1741060,1741080,1741147,1741159,1741164,1741173,1741181,1741190,1741197,1741202,1741208,1741213,1741221,1741225,1741232,1741409 ,1741501,1741677,1741892,1741896,1741984,1742023,1742042,1742071,1742090,1742093,1742101,1742105,1742111,1742139,1742146,1742148,1742166,1742181,1742184,1742187,1742246,1742248-1742251,1742263-1742264,1742268,1742276,1742369,1742387,1742448,1742509-1742512,1742917,1742919,1742933,1742975-1742976,1742984,1742986,1743019,1743115,1743117,1743124-1743125,1743134,1743425,1743554,1743679,1743696-1743698,1743700-1743701,1744058,1744064-1744065,1744125,1744149,1744194,1744229,1744270,1744323,1744432,1744684,1744697,1744705,1744713,1744760,1744786,1745083,1745142-1745143,1745145,1745177,1745179-1745180,1745227,1745248,1745254,1745337,1745467,1745473,1745535,1745576,1745735,1745744,1746304,1746306-1746307,1746319,1746327,1746338,1746340-1746341,1746344,1746427,1746441,1746473,1746490,1746492,1746495-1746496,1746499-1746501,1746503-1746507,1746509,1746549,1746551,1746554,1746556,1746558,1746584,1746620,1746649,1746724,1746939,1746989,1747014,1747028,1747035,1747210,1747225,1747234,1747253,1747 404,1747506,1747536,1747924,1747980,1747993,1748001,1748253,1748452,1748547,1748629,1748676,1748715,1749287,1749296,1749328,1749373,1749465,1749506,1749508,1749665-1749666,1749763,1749865-1749866,1749898,1749978,1749980,1750011,1750015,1750056,1750480,1750617,1750634,1750692,1750697,1750700,1750703,1750707,1750714,1750718,1750723,1750774,1750899,1750975,1750995,1751061,1751097,1751173,1751438,1751447,1751463,1751702,1752212,1752737,1752745,1753078,1753080,1753358,1753363,1754111,1754140-1754141,1754281,1754310,1754445,1754467,1754494,1754496,1754528,1754532-1754533,1754613,1754714,1754874,1754941,1754944,1754950-1754951,1755005,1755007,1755009,1755132,1755180-1755181,1755185,1755190,1755204-1755206,1755208,1755214,1755224,1755227,1755230,1755629,1755646-1755647,1755650,1755653,1755675,1755680,1755683,1755693,1755717,1755731-1755737,1755812,1755828,1755884,1755890,1755918-1755919,1755942,1755958,1755960,1755970,1755993,1756013,1756019,1756039,1756056,1756083-1756114,1756175,1756288-1 756289,1756408-1756410,1756778,1756798,1756878,1756898,1756939,1757123-1757124,1757126,1757128,1757132-1757133,1757136,1757145,1757167-1757168,1757175,1757180,1757182,1757195,1757271,1757278,1757347,1757353-1757354,1757363,1757374,1757399,1757406,1757408,1757485,1757495,1757499,1757527,1757578,1757684,1757722,1757727,1757790,1757799,1757813,1757853,1757883,1757903,1757976,1757997,1758000,1758058,1758072-1758075,1758078-1758079,1758223,1758257,1758261,1758276,1758292,1758369,1758378-1758383,1758421,1758423,1758425-1758427,1758430,1758443,1758448,1758459,1758483,1758486-1758487,1758499,1758525,1758556,1758580,1758582,1758584,1758588,1758842,1759019,1759212,1759224,1759227,1759252,1759274,1759513-1759516,1759611,1759757,1759785-1759790,1760005,1760022,1760109-1760110,1760135,1760200-1760201,1760227,1760300,1760397,1760446,1760454,1760640,1760648,1761057,1761422,1761491,1761498,1761500-1761501,1761550,1761553,1761572,1761574,1761625-1761626,1761628,1761682,1761740,1761752,1762051-176205 3,1762123,1762168,1762172,1762182,1762201-1762202,1762204,1762208,1762288,1762296,1762324,1762348,1762353,1762362,1762374,1762492,1762503,1762505,1762541,1762608,
svn commit: r1828018 - /tomcat/trunk/webapps/docs/changelog.xml
Author: markt Date: Thu Mar 29 19:37:07 2018 New Revision: 1828018 URL: http://svn.apache.org/viewvc?rev=1828018&view=rev Log: Correct section Sorry for the noise Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1828018&r1=1828017&r2=1828018&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Thu Mar 29 19:37:07 2018 @@ -80,6 +80,11 @@ notified once of property changes on the associated naming resources. (markt) + +62224: Disable the forkJoinCommonPoolProtection +of the JreMemoryLeakPreventionListener when running on Java +9 and above since the underlying JRE bug has been fixed. (markt) + @@ -108,11 +113,6 @@ must be sent in order of increasing stream ID. These restriction were not being enforced leading to protocol errors at the client. (markt) - -62224: Disable the forkJoinCommonPoolProtection -of the JreMemoryLeakPreventionListener when running on Java -9 and above since the underlying JRE bug has been fixed. (markt) - - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1828019 - /tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml
Author: markt Date: Thu Mar 29 19:37:43 2018 New Revision: 1828019 URL: http://svn.apache.org/viewvc?rev=1828019&view=rev Log: Correct section Sorry for the noise Modified: tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml Modified: tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml?rev=1828019&r1=1828018&r2=1828019&view=diff == --- tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml Thu Mar 29 19:37:43 2018 @@ -84,6 +84,11 @@ Add LoadBalancerDrainingValve, a Valve designed to reduce the amount of time required for a node to drain its authenticated users. (schultz) + +62224: Disable the forkJoinCommonPoolProtection +of the JreMemoryLeakPreventionListener when running on Java +9 and above since the underlying JRE bug has been fixed. (markt) + @@ -112,11 +117,6 @@ must be sent in order of increasing stream ID. These restriction were not being enforced leading to protocol errors at the client. (markt) - -62224: Disable the forkJoinCommonPoolProtection -of the JreMemoryLeakPreventionListener when running on Java -9 and above since the underlying JRE bug has been fixed. (markt) - - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1828020 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java webapps/docs/changelog.xml webapps/docs/config/listeners.xml
Author: markt Date: Thu Mar 29 19:39:21 2018 New Revision: 1828020 URL: http://svn.apache.org/viewvc?rev=1828020&view=rev Log: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62224 Disable the forkJoinCommonPoolProtection of the JreMemoryLeakPreventionListener when running on Java 9 and above since the underlying JRE bug has been fixed. Modified: tomcat/tc8.0.x/trunk/ (props changed) tomcat/tc8.0.x/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml tomcat/tc8.0.x/trunk/webapps/docs/config/listeners.xml Propchange: tomcat/tc8.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Mar 29 19:39:21 2018 @@ -1,2 +1,2 @@ /tomcat/tc8.5.x/trunk:1735042,1737966,1743139-1743140,1744151,1747537,1747925,1748002,1754614,1754643,1762124,1762183,1762203,1763792,1772948,1777014,1779719,1782037,1782240,1782386-1782387,1785669,1786845,1788249,1788324,1788905,1789216,1789335,1791528,1791558,1796697-1796698,1797521,1798543,1799162,1800143,1801693,1802805,1806799,1807079-1807080,1808880,1809831,1812093,1812143,1812145,1812319,1814975,1815945,1815956,1820207,1822186,1823164,1823497,1824960,1826872-1826873,1827862 -/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1637890,1637892,1638720-1638725,1639653,1640010,1640083-1640084,1640088,1640275,1640322,1640347,1640361,1640365,1640403,1640410,1640652,1640655-1640658,1640688,1640700-1640883,1640903,1640976,1640978,1641000,1641026,1641038-1641039,1641051-1641052,1641058,1641064,1641300,1641369,1641374,1641380,1641486,1641634,1641656-1641692,1641704,1641707-1641718,1641720-1641722,1641735,1641981,1642233,1642280,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1642766,1643002,1643045,1643054-1643055,1643066,1643121,1643128,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643536,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814,1643937,1643963,1644017,1644169,1644201-1644203,1644321,1644323,1644516,1644523,1644529,1644535,1644730,1644768,1644784-1644785,1644790,1644793,1644815,1644884,1644886 ,1644890,1644892,1644910,1644924,1644929-1644930,1644935,1644989,1645011,1645247,1645355,1645357-1645358,1645455,1645465,1645469,1645471,1645473,1645475,1645486-1645488,1645626,1645641,1645685,1645743,1645763,1645951-1645953,1645955,1645993,1646098-1646106,1646178,1646220,1646302,1646304,1646420,1646470-1646471,1646476,1646559,1646717-1646723,1646773,1647026,1647042,1647530,1647655,1648304,1648815,1648907,1649973,1650081,1650365,1651116,1651120,1651280,1651470,1652938,1652970,1653041,1653471,1653550,1653574,1653797,1653815-1653816,1653819,1653840,1653857,1653888,1653972,1654013,1654030,1654050,1654123,1654148,1654159,1654513,1654515,1654517,1654522,1654524,1654725,1654735,1654766,1654785,1654851-1654852,1654978,1655122-1655124,1655126-1655127,1655129-1655130,1655132-1655133,1655312,1655351,1655438,1655441,1655454,168,1656087,1656299,1656319,1656331,1656345,1656350,1656590,1656648-1656650,1656657,1657041,1657054,1657374,1657492,1657510,1657565,1657580,1657584,1657586,1657589,1657 592,1657607,1657609,1657682,1657907,1658207,1658734,1658781,1658790,1658799,1658802,1658804,1658833,1658840,1658966,1659043,1659053,1659059,1659174,1659184,1659188-1659189,1659216,1659263,1659293,1659304,1659306-1659307,1659382,1659384,1659428,1659471,1659486,1659505,1659516,1659521,1659524,1659559,1659562,1659803,1659806,1659814,1659833,1659862,1659905,1659919,1659948,1659967,1659983-1659984,1660060,1660074,1660077,1660133,1660168,1660331-1660332,1660353,1660358,1660924,1661386,1661770,1661867,1661972,1661990,1662200,1662308-1662309,1662548,1662614,1662696,1662736,1662985,1662988-1662989,1663264,1663277,1663298,1663534,1663562,1663676,1663715,1663754,1663768,1663772,1663781,1663893,1663995,1664143,1664163,1664174,1664301,1664317,1664347,1664657,1664659,1664710,1664863-1664864,1664866,1665085,1665292,1665559,1665653,1665661,1665672,1665694,1665697,1665736,1665779,1665976-1665977,1665980-1665981,1665985-1665986,1665989,1665998,1666004,1666008,1666013,1666017,1666024,1666116,1666386-1 666387,1666494,1666496,1666552,1666569,1666579,137,149,1666757,1666966,1666972,1666985,1666995,1666997,1667292,1667402,1667406,1667546,1667615,1667630,1667636,1667688,1667764,1667871,1668026,1668135,1668193,1668593,1668596,1668630,1668639,1668843,1669353,1669370,1669451,1669800,1669838,1669876,1669882,1670394,1670433,1670591,1670598-1670600,1670610,1670631,1670719,1670724,1670726,1670730,1670940,1671112,1672272,1672284,1673754,1674294,1675461,1675486,1675594,1675830,1676231,1676250-1676251,1676364,1676381,1676393,1676479,1676525,1676552,1676615,1676630,1676634,1676721,1676926,1676943,1677140,1677802,1678011,1678162,1678174,1678339,1678426-1678427,1678694,1678701,1679534,1679708,1679710,16
svn commit: r1828021 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java webapps/docs/changelog.xml webapps/docs/config/listeners.xml
Author: markt Date: Thu Mar 29 19:43:01 2018 New Revision: 1828021 URL: http://svn.apache.org/viewvc?rev=1828021&view=rev Log: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62224 Disable the forkJoinCommonPoolProtection of the JreMemoryLeakPreventionListener when running on Java 9 and above since the underlying JRE bug has been fixed. Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml tomcat/tc7.0.x/trunk/webapps/docs/config/listeners.xml Propchange: tomcat/tc7.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Mar 29 19:43:01 2018 @@ -1,3 +1,3 @@ -/tomcat/tc8.0.x/trunk:1636525,1637336,1637685,1637709,1638726,1640089,1640276,1640349,1640363,1640366,1640642,1640672,1640674,1640689,1640884,1641001,1641065,1641067,1641375,1641638,1641723,1641726,1641729-1641730,1641736,1641988,1642669-1642670,1642698,1642701,1643205,1643215,1643217,1643230,1643232,1643273,1643285,1643329-1643330,1643511,1643513,1643521,1643539,1643571,1643581-1643582,1643635,1643655,1643738,1643964,1644018,1644333,1644525,1644954,1644992,1645014,1645360,1645456,1645627,1645642,1645686,1645903-1645904,1645908-1645909,1645913,1645920,1646458,1646460-1646462,1646735,1646738-1646741,1646744,1646746,1646748-1646755,1646757,1646759-1646760,1647043,1648816,1651420-1651422,1651844,1652926,1652939-1652940,1652973,1653798,1653817,1653841,1654042,1654161,1654736,1654767,1654787,1656592,1659907,1662986,1663265,1663278,1663325,1663535,1663567,1663679,1663997,1664175,1664321,1664872,1665061,1665086,1666027,1666395,1666503,1666506,1666560,1666570,1666581,1666759,1666967,1666988 ,1667553-1667555,1667558,1667617,1667633,1667637,1667747,1667767,1667873,1668028,1668137,1668634,1669432,1669801,1669840,1669895-1669896,1670398,1670435,1670592,1670605-1670607,1670609,1670632,1670720,1670725,1670727,1670731,1671114,1672273,1672285,1673759,1674220,1674295,1675469,1675488,1675595,1675831,1676232,1676367-1676369,1676382,1676394,1676483,1676556,1676635,1678178,1679536,1679988,1680256,1681124,1681182,1681703,1681730,1681840,1681864,1681869,1682010,1682034,1682047,1682052-1682053,1682062,1682064,1682070,1682312,1682325,1682331,1682386,1684367,1684385,1685759,1685774,1685827,1685892,1687341,1688904,1689358,1689657,1689921,1692850,1693093,1693108,1693324,1694060,1694115,1694291,1694427,1694431,1694503,1694549,1694789,1694873,1694881,1695356,1695372,1695823-1695825,1696200,1696281,1696379,1696468,1700608,1700871,1700897,1700978,1701094,1701124,1701608,1701668,1701676,1701766,1701944,1702248,1702252,1702314,1702390,1702723,1702725,1702728,1702730,1702733,1702735,1702737,1702 739,1702742,1702744,1702748,1702751,1702754,1702758,1702760,1702763,1702766,1708779,1708782,1708806,1709314,1709670,1710347,1710442,1710448,1710490,1710574,1710578,1712226,1712229,1712235,1712255,1712618,1712649,1712655,1712860,1712899,1712903,1712906,1712913,1712926,1712975,1713185,1713262,1713287,1713613,1713621,1713872,1713976,1713994,1713998,1714004,1714013,1714059,1714538,1714580,1715189,1715207,1715544,1715549,1715637,1715639-1715645,1715667,1715683,1715866,1715978,1715981,1716216-1716217,1716355,1716414,1716421,1717208-1717209,1717257,1717283,1717288,1717291,1717421,1717517,1717529,1718797,1718840-1718843,1719348,1719357-1719358,1719400,1719491,1719737,1720235,1720396,1720442,1720446,1720450,1720463,1720658-1720660,1720756,1720816,1721813,1721818,1721831,1721861,1721867,1721882,1722523,1722527,1722800,1722926,1722941,1722997,1723130,1723440,1723488,1723890,1724434,1724674,1724792,1724803,1724902,1725128,1725131,1725154,1725167,1725911,1725921,1725929,1725963-1725965,1725970,1 725974,1726171-1726173,1726175,1726179-1726182,1726190-1726191,1726195-1726200,1726203,1726226,1726576,1726630,1726992,1727029,1727037,1727671,1727676,1727900,1728028,1728092,1728439,1728449,1729186,1729362,1731009,1731303,1731867,1731872,1731874,1731876,1731885,1731947,1731955,1731959,1731977,1731984,1732360,1732490,1732672,1732902,1733166,1733603,1733619,1733735,1733752,1733764,1733915,1733941,1733964,1734115,1734133,1734261,1734421,1734531,1736286,1737967,1738173,1738182,1738992,1739039,1739089-1739091,1739294,1739777,1739821,1739981,1740513,1740726,1741019,1741162,1741217,1743647,1743681,1744152,1744272,1746732,1746750,1752739,1754615,1755886,1756018,1758563,1759565,1761686,1762173,1762206,1766280,1767507-1767508,1767653,1767656,1769267,1772949,1773521,1773527,1774104,1777015,1777213,1779330,1783151,1784188,1784966,1785670,1786846,1788260,1788999,1789140,1789402,1791529,1791559,1795291,1796906,1797523,1799214,1800998-1800999,1801003,1801007-1801008,1801017,1801020,1802808,180281 4,1803618,1806107,1806733,1807082-1807083,1808707,1808884,1809267,1809644,1809832,1809904,1809915,1809924,1810283,1810328,1810574,1810576-1810577,1810584,1810588,1811141,1811842,1812090,1812096
[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Mark Thomas --- Protection disabled in Java 9 onwards in: - trunk for 9.0.7 onwards - 8.5.x for 8.5.30 onwards - 8.0.x for 8.0.51 onwards - 7.0.x for 7.0.86 onwards FYI: Useful test cases for exploring memory leaks: https://github.com/markt-asf/memory-leaks -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DBCP2 in Tomcat
On 29/03/18 14:39, Christopher Schultz wrote: > On 3/29/18 9:30 AM, Rémy Maucherat wrote: >> On Thu, Mar 29, 2018 at 3:15 PM, Christopher Schultz < >> ch...@christopherschultz.net> wrote: >>> On 3/29/18 8:42 AM, Rémy Maucherat wrote: On Thu, Mar 29, 2018 at 2:33 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > On 3/28/18 2:25 PM, Rémy Maucherat wrote: >> Hi, >> >> In Tomcat, DBCP2 is missing the XA portion (all contained in a single >> "managed" package). So at work I now got some people asking about that >> removal, and that's always a bit annoying as they have to go to a > separate >> vanilla DBCP2 to get the functionality. Annoying sometimes. >> >> So it would be possible to add the classes in Tomcat (including the >> javax.transaction to build, as that's the Tomcat way to deal with >>> that), >> even though the user would need to add its own transaction manager to >>> do >> anything with it. >> >> Should I now add it (only in 9/trunk) or instead leave things the way > they >> are ? Both work to be honest, it's just that I've been bitten by the >>> "we >> only ship 3/4 of DBCP and I didn't know it" bug. > I've always wondered why we bother to package-rename DBCP2 and check-in > the source into our svn repo (soon to be Git). Why not pull DBCP2 from > source during the build and re-name it on the fly? So we can release Tomcat with the latest DBCP2 and POOL2 sources without having to wait on Commons to produce a release. I find the Commons release process a pain to navigate. The svn copy (now a merge from git) is less hassle. Commons is open to all ASF committers so if anyone here wants more frequent DBCP2 and POOL2 releases I am sure the Commons community would welcome them with open arms. >> The rationale was probably: you can fix bugs without having to wait for a >> DBCP release. I'm not certain this actually happened though. It has. >> I actually have a question. There's also that *second* connection pool, >> Tomcat JDBC, although it is more "external" as it is located inside the >> modules. So reading the list of "pros" from its docs, it seems DBCP >> addressed most (all ?) of them, except that it's still significantly >> bigger. So what's the current benefits of Tomcat JDBC over Tomcat DBCP2 ? >> Did anyone do benchmarks or anything ? Performance wise DBCP1, DBCP2 and Tomcat-JDBC are all pretty much equal until you start to hammer the connection pool with concurrent borrows and returns. At that point DBCP1 performance falls off a cliff. DBCP2 and Tomcat-JDBC are so close you probably won't notice but Tomcat-JDBC does have a slight edge. Functionality wise, DBCP2 handles more edge cases by default than Tomcat-JDBC. Most (I'm not sure if all) can be handled by Tomcat-JDBC with additional configuration (usually extra interceptors). Tomcat-JDBC has better JMX support, particularly performance related metrics. > I believe Filip built that in response to the issues with DBCP at the > time. I assume that benchmarks were done at the time proving the > usefulness of the tomcat-pool over DBCP 1.x. I know of no new > benchmarks. Sounds like fodder for an ApacheCon presentation. :) > > Tomcat-pool does have some features that DBCP2 still lacks (such as > interceptors), which probably means that it serves a niche. I'm not sure > how large that niche is. I'm aware of a couple of clients at $work that had performance issues with DBCP1 that Tomcat-JDBC solved. I'm not aware of anyone switching from DBCP2 to Tomcat-JDBC for performance reasons. I do occasionally see folks switching in both directions to either avoid an edge case bug or to get a particular feature. > At some point, it probably makes sense to extract tomcat-pool from the > Tomcat project and make it a separate entity. Probably not a TLP, but at > least something that can be grabbed from source separately from Tomcat > and used independently. Of course, you can already just grab > tomcat-jdbc.jar and use it separately (right?) but we don't make it > obvious how to do that (The build-tomcat-jdbc doesn't have a > "description" attribute and so doesn't show up in ant -projecthelp). We tried that before. Getting the votes to do a release was hard work. A number of releases failed. That is why we moved to releasing it as part of Tomcat. > Perhaps the git-migration would be an opportunity to do that. Or folks can just grab it from Maven Central which is what most users would do. FTR it has a dependency on JULI. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62231] java.lang.IllegalStateException: Component ID main:j_idt56 has already been found in the view
https://bz.apache.org/bugzilla/show_bug.cgi?id=62231 Mark Thomas changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #3 from Mark Thomas --- Bugzilla is not a support forum. Especially when the issue does not appear to be Tomcat related. It looks like you need to ask your question on the MyFaces users mailing list. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Request for comment on BZ 59750 (authentication listener)
On 29/03/18 19:07, Christopher Schultz wrote: > Rémy, > > On 3/29/18 11:41 AM, Rémy Maucherat wrote: >> On Thu, Mar 29, 2018 at 3:48 PM, Christopher Schultz < >> ch...@christopherschultz.net> wrote: >> >>> All, >>> >>> For reference: https://bz.apache.org/bugzilla/show_bug.cgi?id=59750 >>> >>> I've got a proposal (in patch form) attached to that BZ issue. >>> >>> Ralf's enhancement request is fairly terse, but this is something I'd >>> like to have as well. >>> >>> The requirement is to be able to log failed authentication attempts. As >>> it stands, using container-managed authentication does not allow this >>> (as far as I can tell). >>> >>> My proposal is essentially a new listener interface that authenticator >>> classes will invoke (if registered) when an authentication event occurs >>> (success or failure). The Request object and username are currently >>> arguments to the two methods on the interface. >>> >>> You can read the entire current path without even scrolling your screen. >>> >>> Before attempting to publish a more complete patch, I wanted to know if >>> there was any appetite for this kind of thing, or any objections. I think this is better than changing the existing Realm.authenticate(*) methods to add Request. My biggest concern at this point is how does the listener get registered? Might this be better as ContainerListener and two new events? That reduces the plumbing required to make this work. >> Ok with the idea, but the patch is indeed very incomplete. > > Absolutely. I wanted to make sure there were no -1s before I spent much > time on it. That represents maybe 5 minutes of work :) > > Some specific questions: > > For FormAuthenticator: there are several calls to authenticate() in > doAuthenticate. I chose to ignore the call at the top of the method > because I didn't understand the purpose. Something about > re-authentication of a previous-authentication? Would it be appropriate > to also fire an authentication event at that time? I don't think so. > For Basic/DigestAuthenticator: since technically the user is being > authenticated at *every* request, should we bother trying to avoid > spamming the Listener, or should we let the Listener decide how to > handle the huge number of events it will likely get? Does Tomcat know > whether the authentication is a re-authentication or not? If so, should > it let the Listener know this is a re-authentication? Let the listener solve that problem. There may be different ways that are appropriate for different use cases (client IP, session ID, etc.) > Implementing a listener in a webapp: can a listener be registered from > within the web application without any ClassLoader weirdness? Yes. > What > options exist for writing a listener that doesn't require a compile-time > dependency on Tomcat? (I suspect this is unavoidable, because even if > reflection is used to invoke the listener's method by *name* and not via > an interface-call, the Tomcat-specific Request class is a parameter to > the interface methods. Use HttpServletRequest? Or do you need access to Tomcat specific internals? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DBCP2 in Tomcat
On 29/03/18 20:58, Mark Thomas wrote: > On 29/03/18 14:39, Christopher Schultz wrote: >> On 3/29/18 9:30 AM, Rémy Maucherat wrote: >>> On Thu, Mar 29, 2018 at 3:15 PM, Christopher Schultz < >>> ch...@christopherschultz.net> wrote: On 3/29/18 8:42 AM, Rémy Maucherat wrote: > On Thu, Mar 29, 2018 at 2:33 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: >> On 3/28/18 2:25 PM, Rémy Maucherat wrote: >>> Hi, >>> >>> In Tomcat, DBCP2 is missing the XA portion (all contained in a single >>> "managed" package). So at work I now got some people asking about that >>> removal, and that's always a bit annoying as they have to go to a >> separate >>> vanilla DBCP2 to get the functionality. Annoying sometimes. >>> >>> So it would be possible to add the classes in Tomcat (including the >>> javax.transaction to build, as that's the Tomcat way to deal with that), >>> even though the user would need to add its own transaction manager to do >>> anything with it. >>> >>> Should I now add it (only in 9/trunk) or instead leave things the way >> they >>> are ? Both work to be honest, it's just that I've been bitten by the "we >>> only ship 3/4 of DBCP and I didn't know it" bug. Sorry. I meant to reply to this bit as well but forgot. >From memory I left it out on the basis few people needed it and that we could always add it in later if there was demand. There appears to be demand so no objections here to adding that code. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Request for comment on BZ 59750 (authentication listener)
Mark, On 3/29/18 4:11 PM, Mark Thomas wrote: > On 29/03/18 19:07, Christopher Schultz wrote: >> Rémy, >> >> On 3/29/18 11:41 AM, Rémy Maucherat wrote: >>> On Thu, Mar 29, 2018 at 3:48 PM, Christopher Schultz < >>> ch...@christopherschultz.net> wrote: >>> All, For reference: https://bz.apache.org/bugzilla/show_bug.cgi?id=59750 I've got a proposal (in patch form) attached to that BZ issue. Ralf's enhancement request is fairly terse, but this is something I'd like to have as well. The requirement is to be able to log failed authentication attempts. As it stands, using container-managed authentication does not allow this (as far as I can tell). My proposal is essentially a new listener interface that authenticator classes will invoke (if registered) when an authentication event occurs (success or failure). The Request object and username are currently arguments to the two methods on the interface. You can read the entire current path without even scrolling your screen. Before attempting to publish a more complete patch, I wanted to know if there was any appetite for this kind of thing, or any objections. > > I think this is better than changing the existing Realm.authenticate(*) > methods to add Request. Yes, I like this better, too. The separation-of-concerns is architecturally appropriate. > My biggest concern at this point is how does the listener get > registered? Why not attach it to the Authenticator valve? Most people don't explicitly declare their authenticator valve and let Tomcat auto-select based upon the auth-method. But most people don't need this new listener (not many people have mentioned this before, which is surprising ... maybe everyone's been using Spring Security forever), but if they do, they'll have to manually-configure the Valve. > Might this be better as ContainerListener and two new > events? That reduces the plumbing required to make this work. That would definitely require a dependency upon Tomcat code. I think it's worth the trade-off of plumbing-code versus dependencies. >>> Ok with the idea, but the patch is indeed very incomplete. >> >> Absolutely. I wanted to make sure there were no -1s before I spent much >> time on it. That represents maybe 5 minutes of work :) >> >> Some specific questions: >> >> For FormAuthenticator: there are several calls to authenticate() in >> doAuthenticate. I chose to ignore the call at the top of the method >> because I didn't understand the purpose. Something about >> re-authentication of a previous-authentication? Would it be appropriate >> to also fire an authentication event at that time? > > I don't think so. Okay, thanks for the confirmation. >> For Basic/DigestAuthenticator: since technically the user is being >> authenticated at *every* request, should we bother trying to avoid >> spamming the Listener, or should we let the Listener decide how to >> handle the huge number of events it will likely get? Does Tomcat know >> whether the authentication is a re-authentication or not? If so, should >> it let the Listener know this is a re-authentication? > > Let the listener solve that problem. There may be different ways that > are appropriate for different use cases (client IP, session ID, etc.) +1 This was my nominal position as well... especially because it's less work in Tomcat. >> Implementing a listener in a webapp: can a listener be registered from >> within the web application without any ClassLoader weirdness? > > Yes. I was thinking about something that needed to depend upon the Tomcat API, but ... >> What options exist for writing a listener that doesn't require a >> compile-time dependency on Tomcat? (I suspect this is unavoidable, >> because even if reflection is used to invoke the listener's method >> by *name* and not via an interface-call, the Tomcat-specific >> Request class is a parameter to the interface methods. > > Use HttpServletRequest? Or do you need access to Tomcat specific internals? I don't see a particular need to access Tomcat-specific internals at this point. I was just being lazy with the initial patch I guess. Thanks, -chris signature.asc Description: OpenPGP digital signature
Permalinks to presentations
All, Occasionally, we all have the need to give a reference to a presentation to someone e.g. on the users mailing list. For example: https://lists.apache.org/thread.html/6b604dd26142038a4abb1c378af49beee12d4ae1d2d8dc65391fd701@%3Cusers.tomcat.apache.org%3E In that case, I gave a direct link to a specific presentation (my Monitoring w/JMX presentation from ApacheCon NA 2016). I think this isn't good for 2 reasons: 1. Links are fragile. I may remove my presentation from people.a.o/~username, that stuff may be relocated, etc. 2. It may not be the most up-to-date version of that presentation. I gave a similar talk at ApacheCon NA 2015 but the 2016 version is better. If I do another one in 2018, presumably it will be the best, most up-to-date one and yet I've emailed-out links directly to the 2017 (and presumably 2015) version. 3. It avoids the Tomcat "presentations" page. Presumably, someone interested in one presentation may be interested in the others. The alternative is to say "go to /presentations.html" and search for "topic X", but as that page fills-up, I suspect people will be unlikely to actually find and read the document. I think a direct-link is probably best, if possible. I'm wondering if there might be a way to fix these. My initial idea was something like an "always up-to-date link to presentation X" where X is whatever presentations we often refer to (e.g. Mark's "tracking-down memory leaks in web applications"). That doesn't fix issue #3 but maybe someone else has an idea. What are our options when it comes to something like a URL which is an alias to the "latest presentation X"? If I were in control of the web server(s), I'd use something like mod_alias to perform a temporary-redirect from tomcat.apache.org/presentations/current-X to people.a.o/~user/whatever. That just needs to be updated any time the presentation is updated. That's a little fragile, too, since anyone making a presentation would have to register the presentation under a well-known name and then submit requests to update it. That means work for someone here (likely Mark, part of Infra). Is there a way we could do this such that any committer could update such redirects? Any other thoughts or ideas? In order to satisfy #3 above, perhaps we could have a dynamic (or maybe auto-generated but not actually dynamic) page which lists all the presentation topics and floats the "requested" one up to the top. Something like: [Tomcat Presentations] You have requested the latest version of "Monitoring Tomcat w/JMX". You can find it here: [direct link to latest] You may be interested in these other presentations as well: * [Other topic A, link to latest] * [Other topic B, link to latest] * ... Or even more good stuff: [link to /presentations.html] WDYT? Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Permalinks to presentations
Am 30.03.2018 um 02:30 schrieb Christopher Schultz: All, Occasionally, we all have the need to give a reference to a presentation to someone e.g. on the users mailing list. For example: https://lists.apache.org/thread.html/6b604dd26142038a4abb1c378af49beee12d4ae1d2d8dc65391fd701@%3Cusers.tomcat.apache.org%3E In that case, I gave a direct link to a specific presentation (my Monitoring w/JMX presentation from ApacheCon NA 2016). I think this isn't good for 2 reasons: 1. Links are fragile. I may remove my presentation from people.a.o/~username, that stuff may be relocated, etc. 2. It may not be the most up-to-date version of that presentation. I gave a similar talk at ApacheCon NA 2015 but the 2016 version is better. If I do another one in 2018, presumably it will be the best, most up-to-date one and yet I've emailed-out links directly to the 2017 (and presumably 2015) version. 3. It avoids the Tomcat "presentations" page. Presumably, someone interested in one presentation may be interested in the others. The alternative is to say "go to /presentations.html" and search for "topic X", but as that page fills-up, I suspect people will be unlikely to actually find and read the document. I think a direct-link is probably best, if possible. I'm wondering if there might be a way to fix these. My initial idea was something like an "always up-to-date link to presentation X" where X is whatever presentations we often refer to (e.g. Mark's "tracking-down memory leaks in web applications"). That doesn't fix issue #3 but maybe someone else has an idea. What are our options when it comes to something like a URL which is an alias to the "latest presentation X"? If I were in control of the web server(s), I'd use something like mod_alias to perform a temporary-redirect from tomcat.apache.org/presentations/current-X to people.a.o/~user/whatever. That just needs to be updated any time the presentation is updated. That's a little fragile, too, since anyone making a presentation would have to register the presentation under a well-known name and then submit requests to update it. That means work for someone here (likely Mark, part of Infra). Is there a way we could do this such that any committer could update such redirects? Any other thoughts or ideas? In order to satisfy #3 above, perhaps we could have a dynamic (or maybe auto-generated but not actually dynamic) page which lists all the presentation topics and floats the "requested" one up to the top. Something like: [Tomcat Presentations] You have requested the latest version of "Monitoring Tomcat w/JMX". You can find it here: [direct link to latest] You may be interested in these other presentations as well: * [Other topic A, link to latest] * [Other topic B, link to latest] * ... Or even more good stuff: [link to /presentations.html] WDYT? Our ASF link shortener s.apache.org seems to allow to edit shortened URLs later. So this would give us: - short auto.generated permalink or alternatively a self-chosen URI - the ability to change the target of the permalink if necessary I don't know whether only the creator of the original short link can edit it, but I think so. Just try the freshly created: https://s.apache.org/tomcat-jmx-presentation.pdf and after you have seen the redirect, got the the mini-GUI at s.apache.org and see whether you can edit that link (ID) and let it point to another URL. When submitting the data it will ask you for your apache user id. The experiment will tell us, if any apache committer can edit any s.apache.org URL, or only the original creator of a URL. Regards, Rainer Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
