Re: Java 9, modularisation and build systems
On 06/10/17 13:01, Rémy Maucherat wrote: > On Fri, Oct 6, 2017 at 10:18 AM, Mark Thomas wrote: > >> The usual candidate for an alternative build system is Maven. The >> argument for Maven is that it is more widely known and hence easier to >> get started with. The argument against is broadly that Maven is very >> opinionated and they way Tomcat currently does things is not consistent >> with what Maven expects and some things (e.g. the Windows installer) are >> well outside the typical Maven build. Therefore switching to Maven would >> require a fair amount of effort. >> >> I'd like to suggest a third alternative: Gradle. The argument for Gradle >> is that it can boot-strap itself so, unlike Ant, a new user doesn't need >> to download the build tool. Gradle can also import Ant build files so we >> could start with a simple Gradle script that simply imported the current >> Ant script and then migrate slowly over time. The argument against is >> that it isn't as widely known as Maven. >> >> >> My own views are neutral at this point on modularisation. I don't have >> any immediate suggestions for changes but I'd like to hear what ideas >> others have. On build systems, I'm not convinced that the benefits of >> switching to Maven justify the costs. Gradle looks promising and I do >> like the boot-strapping feature. If there was consensus to move to >> Gradle, I'd be willing to help that process. >> > On Java 9 modularisation I'm super neutral too. Especially since it > wouldn't bring anything to Tomcat IMO. For Java 9 modules, I can see some benefits to defining Java 9 modules to be consistent with the names and dependencies we already have. Primarily, if a user adds a module (not using Maven) then they'll get notified about missing dependencies when they try and build it. That is about the only benefit I can see though and it is a fairly small one. > On the build and source structure, I'd say the first decision should be > another yes/no on Maven, since that's what everyone else has been asking > about. Then if it's still a no, we can make another decision on Gradle. I remain unconvinced that the benefits of switching to Maven would justify the costs. The previous experiments have shown that it is not practical to keep the current source code structure and use Maven. See: http://svn.apache.org/viewvc/tomcat/sandbox/trunk-mvn-build It is 6 years old (and for 7.0.24) but you get the idea. Note that: - I had to build and run with Java 7 to avoid various class version issues - It is incomplete (e.g. no Windows Installer build) Benefits: - More widely known, so easier/faster for newcomers to pick up - Standard project structure makes it easier/faster for newcomers to navigate - Producing OSGI bundles would be simpler - Bootstrap wrapper available Costs: - The code would need to be split into multi-modules - Back-ports would become more difficult unless all currently supported versions were also back-ported (which increases the costs of transition) - If we change the layout of the currently supported versions, that will create costs for downstream packagers - We'd need to write a code-signing plug-in for Maven - We'd need to write a plug-in to use NSIS or continue to use Ant for the Windows Installer Overall, I remain firmly unconvinced that a move to Maven is in the best interests of Apache Tomcat. The time that would be required to migrate to Maven would be significant and would disrupt the project for an extended period of time (my expectation is several months). It would also disrupt down-stream users. That is a significant cost. While I don't deny there are potential benefits, those benefits are - in my view - significantly smaller than the associated costs. Another concern is that switching to Maven would not be a small, reversible change. It would be reversible but the effort required, both to make the change and to reverse it, would not be small. I haven't seem any significant movement from the last time we discussed this so I don't think we need a vote or anything. That said, I've no objection to a vote being held if a committer wishes to call one. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Java 9, modularisation and build systems
Maven has another advantage that it provides a centralized repository for dependencies, which can be easily mirrored. The current build process for Tomcat requires different repositories such as: - apache.org(mirrors available) - archive.apache.org(mirrors unavailable, access unstable) - maven repo(mirrors available) - sourceforge.net (mirrors available, access unstable) which makes it incredibly slow for a clean build of tomcat in countries like China, making new comers difficult to start. -- Mark Thomas 2017 Oct 6 (Fri) 16:18 Tomcat Developers List Java 9, modularisation and build systems Hi all, As you have probably seen, I've been working on improving Java 9 support. The current TODO list is: - module path scanning - handling multi-release JARs in the JarScanner I've been looking at the module path scanning and while there are various approaches, they all make fairly heavy use of Java 9 APIs. Implementing them via the existing JreCompat approach is going to require a lot of reflection. That got me thinking about the obvious alternative: multi-release JARs. Handling multi-release JARs is going to require some changes / additions to the build process and source layout. That reminded me of a comment that Rémy made at TomcatCon in London regarding modularisation and build tools and whether we wanted to do things differently. If we want to make changes in that area it probably makes sense to make them now - hence this e-mail. Modularisation and build tools are inter-related so I think it makes sense to discuss them together. Hence this thread. I'm going to start with what I think is the easy one: Modularisation. Tomcat is already modular. You can remove some features (JSP, WebSocket, clustering?, store-config?) simply by removing the JARs. Do we want to take this further? Nothing immediately springs to mind hence the fairly open question: what changes could we implement to make Tomcat more modular and how would those changes benefit our users? The build tools aspect has, historically, been the area where fairly strong opinions have been expressed. The argument against Ant is that it isn't as well known amongst prospective new contributors as other tools and hence creates a barrier to contributing that harms the community. The argument for Ant is that it works, it isn't causing any pain points and it has the flexibility to handle all aspects of our build. The usual candidate for an alternative build system is Maven. The argument for Maven is that it is more widely known and hence easier to get started with. The argument against is broadly that Maven is very opinionated and they way Tomcat currently does things is not consistent with what Maven expects and some things (e.g. the Windows installer) are well outside the typical Maven build. Therefore switching to Maven would require a fair amount of effort. I'd like to suggest a third alternative: Gradle. The argument for Gradle is that it can boot-strap itself so, unlike Ant, a new user doesn't need to download the build tool. Gradle can also import Ant build files so we could start with a simple Gradle script that simply imported the current Ant script and then migrate slowly over time. The argument against is that it isn't as widely known as Maven. My own views are neutral at this point on modularisation. I don't have any immediate suggestions for changes but I'd like to hear what ideas others have. On build systems, I'm not convinced that the benefits of switching to Maven justify the costs. Gradle looks promising and I do like the boot-strapping feature. If there was consensus to move to Gradle, I'd be willing to help that process. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Java 9, modularisation and build systems
On 09/10/17 09:31, Huxing Zhang wrote: > Maven has another advantage that it provides a centralized repository for > dependencies, which can be easily mirrored. > The current build process for Tomcat requires different repositories such as: > - apache.org(mirrors available) > - archive.apache.org(mirrors unavailable, access unstable) > - maven repo(mirrors available) > - sourceforge.net (mirrors available, access unstable) The location of the dependencies and the choice of build system are independent. If any of the dependencies are causing problems we can look at potential alternative locations. We don't have to change the build system to do that. Mark > > which makes it incredibly slow for a clean build of tomcat in countries like > China, making new comers difficult to start. > -- > Mark Thomas > 2017 Oct 6 (Fri) 16:18 > Tomcat Developers List > Java 9, modularisation and build systems > > > Hi all, > > As you have probably seen, I've been working on improving Java 9 > support. The current TODO list is: > > - module path scanning > - handling multi-release JARs in the JarScanner > > I've been looking at the module path scanning and while there are > various approaches, they all make fairly heavy use of Java 9 APIs. > Implementing them via the existing JreCompat approach is going to > require a lot of reflection. That got me thinking about the obvious > alternative: multi-release JARs. > > Handling multi-release JARs is going to require some changes / additions > to the build process and source layout. That reminded me of a comment > that Rémy made at TomcatCon in London regarding modularisation and build > tools and whether we wanted to do things differently. If we want to make > changes in that area it probably makes sense to make them now - hence > this e-mail. > > Modularisation and build tools are inter-related so I think it makes > sense to discuss them together. Hence this thread. > > I'm going to start with what I think is the easy one: Modularisation. > > Tomcat is already modular. You can remove some features (JSP, WebSocket, > clustering?, store-config?) simply by removing the JARs. Do we want to > take this further? Nothing immediately springs to mind hence the fairly > open question: what changes could we implement to make Tomcat more > modular and how would those changes benefit our users? > > The build tools aspect has, historically, been the area where fairly > strong opinions have been expressed. > > The argument against Ant is that it isn't as well known amongst > prospective new contributors as other tools and hence creates a barrier > to contributing that harms the community. The argument for Ant is that > it works, it isn't causing any pain points and it has the flexibility to > handle all aspects of our build. > > The usual candidate for an alternative build system is Maven. The > argument for Maven is that it is more widely known and hence easier to > get started with. The argument against is broadly that Maven is very > opinionated and they way Tomcat currently does things is not consistent > with what Maven expects and some things (e.g. the Windows installer) are > well outside the typical Maven build. Therefore switching to Maven would > require a fair amount of effort. > > I'd like to suggest a third alternative: Gradle. The argument for Gradle > is that it can boot-strap itself so, unlike Ant, a new user doesn't need > to download the build tool. Gradle can also import Ant build files so we > could start with a simple Gradle script that simply imported the current > Ant script and then migrate slowly over time. The argument against is > that it isn't as widely known as Maven. > > > My own views are neutral at this point on modularisation. I don't have > any immediate suggestions for changes but I'd like to hear what ideas > others have. On build systems, I'm not convinced that the benefits of > switching to Maven justify the costs. Gradle looks promising and I do > like the boot-strapping feature. If there was consensus to move to > Gradle, I'd be willing to help that process. > > > Mark > > - > 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
Re: Java 9, modularisation and build systems
Le 9/10/2017 à 10:23, Mark Thomas a écrit : > - Back-ports would become more difficult unless all currently supported > versions were also back-ported (which increases the costs of > transition) This is an important point. Maybe the older versions of Tomcat could just adopt the new source layout (/src/main/java) but keep Ant as the build system. Thus, the patches could be backported without changing the paths. > - If we change the layout of the currently supported versions, that will > create costs for downstream packagers As far as Debian is concerned, switching to Maven shouldn't be that disruptive, the tool is well supported now. Ubuntu folks on the other hand may be less happy because they didn't include Maven in their main repository yet, unlike Tomcat and Ant. Changing the build system would force them to officially support Maven, which isn't a bad thing in 2017 anyway. > - We'd need to write a code-signing plug-in for Maven I did write a code-signing plug-in for Maven, maybe it could be extended to work with the Symantec service used by Tomcat? https://ebourg.github.io/jsign/ > - We'd need to write a plug-in to use NSIS or continue to use Ant for > the Windows Installer No need to write a plug-in for this I think, NSIS could be invoked with the maven-antrun-plugin. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1811560 - in /tomcat/trunk: bin/service.bat webapps/docs/changelog.xml
Author: markt Date: Mon Oct 9 12:27:29 2017 New Revision: 1811560 URL: http://svn.apache.org/viewvc?rev=1811560&view=rev Log: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=61590 Enable service.bat to recognise when JAVA_HOME is configured for a Java 9 JDK. Modified: tomcat/trunk/bin/service.bat tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/bin/service.bat URL: http://svn.apache.org/viewvc/tomcat/trunk/bin/service.bat?rev=1811560&r1=1811559&r2=1811560&view=diff == --- tomcat/trunk/bin/service.bat (original) +++ tomcat/trunk/bin/service.bat Mon Oct 9 12:27:29 2017 @@ -55,9 +55,16 @@ if not exist "%JRE_HOME%\bin\java.exe" g if not exist "%JRE_HOME%\bin\javaw.exe" goto noJavaHome goto okJavaHome :gotJdkHome -if not exist "%JAVA_HOME%\jre\bin\java.exe" goto noJavaHome -if not exist "%JAVA_HOME%\jre\bin\javaw.exe" goto noJavaHome if not exist "%JAVA_HOME%\bin\javac.exe" goto noJavaHome +rem Java 9 has a different directory structure +if exist "%JAVA_HOME%\jre\bin\java.exe" goto preJava9Layout +if not exist "%JAVA_HOME%\bin\java.exe" goto noJavaHome +if not exist "%JAVA_HOME%\bin\javaw.exe" goto noJavaHome +if not "%JRE_HOME%" == "" goto okJavaHome +set "JRE_HOME=%JAVA_HOME%" +goto okJavaHome +:preJava9Layout +if not exist "%JAVA_HOME%\jre\bin\javaw.exe" goto noJavaHome if not "%JRE_HOME%" == "" goto okJavaHome set "JRE_HOME=%JAVA_HOME%\jre" goto okJavaHome Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1811560&r1=1811559&r2=1811560&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Mon Oct 9 12:27:29 2017 @@ -91,6 +91,10 @@ such attempted use of the endorsed directory mechanism will trigger an error and Tomcat will fail to start. (rjung) + +61590: Enable service.bat to recognise when +JAVA_HOME is configured for a Java 9 JDK. (markt) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1811561 - in /tomcat/tc8.5.x/trunk: ./ bin/service.bat webapps/docs/changelog.xml
Author: markt Date: Mon Oct 9 12:28:57 2017 New Revision: 1811561 URL: http://svn.apache.org/viewvc?rev=1811561&view=rev Log: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=61590 Enable service.bat to recognise when JAVA_HOME is configured for a Java 9 JDK. Modified: tomcat/tc8.5.x/trunk/ (props changed) tomcat/tc8.5.x/trunk/bin/service.bat tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc8.5.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Mon Oct 9 12:28:57 2017 @@ -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,1762710,1762753,1762766,1762769,1762944,1762947,1762953,1763167,1763179,1763232,1763259,1763271-1763272,1763276-1763277,1763319-1763320,1763370,1763372,1763375,1763377,1763393,1763412,1763430
svn commit: r1811562 - in /tomcat/tc8.0.x/trunk: ./ bin/service.bat webapps/docs/changelog.xml
Author: markt Date: Mon Oct 9 12:30:37 2017 New Revision: 1811562 URL: http://svn.apache.org/viewvc?rev=1811562&view=rev Log: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=61590 Enable service.bat to recognise when JAVA_HOME is configured for a Java 9 JDK. Modified: tomcat/tc8.0.x/trunk/ (props changed) tomcat/tc8.0.x/trunk/bin/service.bat tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc8.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Mon Oct 9 12:30:37 2017 @@ -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 -/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,1679716,1680034,1680246,1681056,1681123,1681138,1681280,1681283,1681286,1681450,1681697,1681699,1681701,1681729,1681770,1681779,1681793,1681807,1681837-1681838,1681854,1681862,1681958,1682028,1682033,1682311,1682315,1682317,1682320,1682324,1682330,1682842,1684172,1684366,1684383,1684526-168452 7,1684549-168455
svn commit: r1811563 - in /tomcat/tc7.0.x/trunk: ./ bin/service.bat webapps/docs/changelog.xml
Author: markt Date: Mon Oct 9 12:32:20 2017 New Revision: 1811563 URL: http://svn.apache.org/viewvc?rev=1811563&view=rev Log: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=61590 Enable service.bat to recognise when JAVA_HOME is configured for a Java 9 JDK. Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/bin/service.bat tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc7.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Mon Oct 9 12:32:20 2017 @@ -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 -/tomcat/tc8.5.x/trunk:1735579,1736839,1737199,1737966,1738042,1738044,1738162,1738165,1738178,1739157,1739173,1739177,1739476,1740132,1740521,1740536,1740804,1740811,1740981,1741165,1741174,1741182,1741191,174120
[Bug 61590] service.bat fails to recognize JDK 9
https://bz.apache.org/bugzilla/show_bug.cgi?id=61590 Mark Thomas changed: What|Removed |Added OS||All Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Mark Thomas --- Fixed in: - trunk for 9.0.2 onwards - 8.5.x for 8.5.24 onwards - 8.0.x for 8.0.48 onwards - 7.0.x for 7.0.83 onwards -- 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 61597] New: StandardJarSacnner does not scan module path
https://bz.apache.org/bugzilla/show_bug.cgi?id=61597 Bug ID: 61597 Summary: StandardJarSacnner does not scan module path Product: Tomcat 9 Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: ma...@apache.org Target Milestone: - There is a TODO in the code for this. Scanning the module path requires a a handful of Java 9 specific calls. It may be cleaner to handle this with a multi-release JAR than by extending JreCompat. (Actually, all of the Jre9Compat code could move to multi-release JARs.) -- 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: Java 9, modularisation and build systems
On Mon, Oct 9, 2017 at 10:23 AM, Mark Thomas wrote: > On 06/10/17 13:01, Rémy Maucherat wrote: > > On Fri, Oct 6, 2017 at 10:18 AM, Mark Thomas wrote: > > > >> The usual candidate for an alternative build system is Maven. The > >> argument for Maven is that it is more widely known and hence easier to > >> get started with. The argument against is broadly that Maven is very > >> opinionated and they way Tomcat currently does things is not consistent > >> with what Maven expects and some things (e.g. the Windows installer) are > >> well outside the typical Maven build. Therefore switching to Maven would > >> require a fair amount of effort. > >> > >> I'd like to suggest a third alternative: Gradle. The argument for Gradle > >> is that it can boot-strap itself so, unlike Ant, a new user doesn't need > >> to download the build tool. Gradle can also import Ant build files so we > >> could start with a simple Gradle script that simply imported the current > >> Ant script and then migrate slowly over time. The argument against is > >> that it isn't as widely known as Maven. > >> > >> > >> My own views are neutral at this point on modularisation. I don't have > >> any immediate suggestions for changes but I'd like to hear what ideas > >> others have. On build systems, I'm not convinced that the benefits of > >> switching to Maven justify the costs. Gradle looks promising and I do > >> like the boot-strapping feature. If there was consensus to move to > >> Gradle, I'd be willing to help that process. > >> > > On Java 9 modularisation I'm super neutral too. Especially since it > > wouldn't bring anything to Tomcat IMO. > > For Java 9 modules, I can see some benefits to defining Java 9 modules > to be consistent with the names and dependencies we already have. > Primarily, if a user adds a module (not using Maven) then they'll get > notified about missing dependencies when they try and build it. That is > about the only benefit I can see though and it is a fairly small one. > > > On the build and source structure, I'd say the first decision should be > > another yes/no on Maven, since that's what everyone else has been asking > > about. Then if it's still a no, we can make another decision on Gradle. > > I remain unconvinced that the benefits of switching to Maven would > justify the costs. > > The previous experiments have shown that it is not practical to keep the > current source code structure and use Maven. > > See: > http://svn.apache.org/viewvc/tomcat/sandbox/trunk-mvn-build > > It is 6 years old (and for 7.0.24) but you get the idea. Note that: > - I had to build and run with Java 7 to avoid various class version > issues > - It is incomplete (e.g. no Windows Installer build) > > Benefits: > > - More widely known, so easier/faster for newcomers to pick up > > - Standard project structure makes it easier/faster for newcomers to > navigate > > - Producing OSGI bundles would be simpler > > - Bootstrap wrapper available > > Costs: > > - The code would need to be split into multi-modules > > - Back-ports would become more difficult unless all currently supported > versions were also back-ported (which increases the costs of > transition) > > - If we change the layout of the currently supported versions, that will > create costs for downstream packagers > > - We'd need to write a code-signing plug-in for Maven > > - We'd need to write a plug-in to use NSIS or continue to use Ant for > the Windows Installer > > > Overall, I remain firmly unconvinced that a move to Maven is in the best > interests of Apache Tomcat. The time that would be required to migrate > to Maven would be significant and would disrupt the project for an > extended period of time (my expectation is several months). It would > also disrupt down-stream users. That is a significant cost. While I > don't deny there are potential benefits, those benefits are - in my view > - significantly smaller than the associated costs. > > Another concern is that switching to Maven would not be a small, > reversible change. It would be reversible but the effort required, both > to make the change and to reverse it, would not be small. > > I haven't seem any significant movement from the last time we discussed > this so I don't think we need a vote or anything. That said, I've no > objection to a vote being held if a committer wishes to call one. > Yes, if there's a switch to maven, then Tomcat has to become something resembling a Maven project (IMO), with a non monolithic source tree. So it seems you don't like it any more than before, so then it looks like it's still a "no" for maven. Your arguments are reasonable especially for maintenance of previous branches. Poor Maven, he may start being depressed after being rejected so often ;) Rémy > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org >
[Bug 61598] New: Update Windows Installer to also search registry for JRE in Java 9 location
https://bz.apache.org/bugzilla/show_bug.cgi?id=61598 Bug ID: 61598 Summary: Update Windows Installer to also search registry for JRE in Java 9 location Product: Tomcat 9 Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Packaging Assignee: dev@tomcat.apache.org Reporter: ma...@apache.org Target Milestone: - Java 9: SOFTWARE\JavaSoft\JRE Java 8 and earlier: SOFTWARE\JavaSoft\Java Runtime Environment -- 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: Java 9, modularisation and build systems
OMG, Maven for Tomcat, after so many years :) May be time to resurrect Olivier Lamy works 2017-10-09 14:43 GMT+02:00 Rémy Maucherat : > On Mon, Oct 9, 2017 at 10:23 AM, Mark Thomas wrote: > > > On 06/10/17 13:01, Rémy Maucherat wrote: > > > On Fri, Oct 6, 2017 at 10:18 AM, Mark Thomas wrote: > > > > > >> The usual candidate for an alternative build system is Maven. The > > >> argument for Maven is that it is more widely known and hence easier to > > >> get started with. The argument against is broadly that Maven is very > > >> opinionated and they way Tomcat currently does things is not > consistent > > >> with what Maven expects and some things (e.g. the Windows installer) > are > > >> well outside the typical Maven build. Therefore switching to Maven > would > > >> require a fair amount of effort. > > >> > > >> I'd like to suggest a third alternative: Gradle. The argument for > Gradle > > >> is that it can boot-strap itself so, unlike Ant, a new user doesn't > need > > >> to download the build tool. Gradle can also import Ant build files so > we > > >> could start with a simple Gradle script that simply imported the > current > > >> Ant script and then migrate slowly over time. The argument against is > > >> that it isn't as widely known as Maven. > > >> > > >> > > >> My own views are neutral at this point on modularisation. I don't have > > >> any immediate suggestions for changes but I'd like to hear what ideas > > >> others have. On build systems, I'm not convinced that the benefits of > > >> switching to Maven justify the costs. Gradle looks promising and I do > > >> like the boot-strapping feature. If there was consensus to move to > > >> Gradle, I'd be willing to help that process. > > >> > > > On Java 9 modularisation I'm super neutral too. Especially since it > > > wouldn't bring anything to Tomcat IMO. > > > > For Java 9 modules, I can see some benefits to defining Java 9 modules > > to be consistent with the names and dependencies we already have. > > Primarily, if a user adds a module (not using Maven) then they'll get > > notified about missing dependencies when they try and build it. That is > > about the only benefit I can see though and it is a fairly small one. > > > > > On the build and source structure, I'd say the first decision should be > > > another yes/no on Maven, since that's what everyone else has been > asking > > > about. Then if it's still a no, we can make another decision on Gradle. > > > > I remain unconvinced that the benefits of switching to Maven would > > justify the costs. > > > > The previous experiments have shown that it is not practical to keep the > > current source code structure and use Maven. > > > > See: > > http://svn.apache.org/viewvc/tomcat/sandbox/trunk-mvn-build > > > > It is 6 years old (and for 7.0.24) but you get the idea. Note that: > > - I had to build and run with Java 7 to avoid various class version > > issues > > - It is incomplete (e.g. no Windows Installer build) > > > > Benefits: > > > > - More widely known, so easier/faster for newcomers to pick up > > > > - Standard project structure makes it easier/faster for newcomers to > > navigate > > > > - Producing OSGI bundles would be simpler > > > > - Bootstrap wrapper available > > > > Costs: > > > > - The code would need to be split into multi-modules > > > > - Back-ports would become more difficult unless all currently supported > > versions were also back-ported (which increases the costs of > > transition) > > > > - If we change the layout of the currently supported versions, that will > > create costs for downstream packagers > > > > - We'd need to write a code-signing plug-in for Maven > > > > - We'd need to write a plug-in to use NSIS or continue to use Ant for > > the Windows Installer > > > > > > Overall, I remain firmly unconvinced that a move to Maven is in the best > > interests of Apache Tomcat. The time that would be required to migrate > > to Maven would be significant and would disrupt the project for an > > extended period of time (my expectation is several months). It would > > also disrupt down-stream users. That is a significant cost. While I > > don't deny there are potential benefits, those benefits are - in my view > > - significantly smaller than the associated costs. > > > > Another concern is that switching to Maven would not be a small, > > reversible change. It would be reversible but the effort required, both > > to make the change and to reverse it, would not be small. > > > > I haven't seem any significant movement from the last time we discussed > > this so I don't think we need a vote or anything. That said, I've no > > objection to a vote being held if a committer wishes to call one. > > > > Yes, if there's a switch to maven, then Tomcat has to become something > resembling a Maven project (IMO), with a non monolithic source tree. So it > seems you don't like it any more than before, so then it looks like it's > still a "no" for maven. Your argum
buildbot failure in on tomcat-8-trunk
The Buildbot has detected a new failure on builder tomcat-8-trunk while building . Full details are available at: https://ci.apache.org/builders/tomcat-8-trunk/builds/1155 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: silvanus_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-8-commit' triggered this build Build Source Stamp: [branch tomcat/tc8.0.x/trunk] 1811562 Blamelist: markt BUILD FAILED: failed compile_1 Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61599] New: Update Commons Daemon for improved Java 9 support
https://bz.apache.org/bugzilla/show_bug.cgi?id=61599 Bug ID: 61599 Summary: Update Commons Daemon for improved Java 9 support Product: Tomcat 9 Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Packaging Assignee: dev@tomcat.apache.org Reporter: ma...@apache.org Target Milestone: - There are a number of Java 9 related bugs open against Commons Daemon. Noteably: Finding Java 9 JREs: https://issues.apache.org/jira/browse/DAEMON-376 https://issues.apache.org/jira/browse/DAEMON-373 Supporting Java 9 options: https://issues.apache.org/jira/browse/DAEMON-374 Fixing this depends on there being a new Commons Daemon release -- 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 61600] New: Windows service stop logs warnings on Java 9
https://bz.apache.org/bugzilla/show_bug.cgi?id=61600 Bug ID: 61600 Summary: Windows service stop logs warnings on Java 9 Product: Tomcat 9 Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Packaging Assignee: dev@tomcat.apache.org Reporter: ma...@apache.org Target Milestone: - On service stop with Java 9 warnings are logged due to the use of reflection in the WebappClassLoader. The approach of setting JDK_JAVA_OPTIONS works if the service uses the java start type, but not if jvm (the default) is used. We need a robust solution that works for all start types and supported Java versions (6 onwards since this will need to be back-ported to Tomcat 7). -- 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 61601] New: Make Tomcat multi-release JAR aware
https://bz.apache.org/bugzilla/show_bug.cgi?id=61601 Bug ID: 61601 Summary: Make Tomcat multi-release JAR aware Product: Tomcat 9 Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: ma...@apache.org Target Milestone: - Created attachment 35406 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35406&action=edit Java 8 / 9 JAR for testing The attached JAR file contains an annotated Servlet 4.0 ServletContextListener with both a Java 8 and Java 9 version. Each version simply outputs the Java version to stdout. When deployed on Tomcat 9, the Java 8 listener is reported whether running on Java 8 or Java 9. -- 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: r1811614 - in /tomcat/trunk: bin/ciphers.sh java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java
Author: schultz
Date: Mon Oct 9 21:55:29 2017
New Revision: 1811614
URL: http://svn.apache.org/viewvc?rev=1811614&view=rev
Log:
Add main method to OpenSSLCipherConfigurationParser and wrapper script to mimic
"openssl ciphers" command.
Added:
tomcat/trunk/bin/ciphers.sh (with props)
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java
Added: tomcat/trunk/bin/ciphers.sh
URL:
http://svn.apache.org/viewvc/tomcat/trunk/bin/ciphers.sh?rev=1811614&view=auto
==
--- tomcat/trunk/bin/ciphers.sh (added)
+++ tomcat/trunk/bin/ciphers.sh Mon Oct 9 21:55:29 2017
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements. See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the "License"); you may not use this file except in compliance with
+# the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+# -
+# Script to digest password using the algorithm specified
+# -
+
+# Better OS/400 detection: see Bugzilla 31132
+os400=false
+case "`uname`" in
+OS400*) os400=true;;
+esac
+
+# resolve links - $0 may be a softlink
+PRG="$0"
+
+while [ -h "$PRG" ] ; do
+ ls=`ls -ld "$PRG"`
+ link=`expr "$ls" : '.*-> \(.*\)$'`
+ if expr "$link" : '/.*' > /dev/null; then
+PRG="$link"
+ else
+PRG=`dirname "$PRG"`/"$link"
+ fi
+done
+
+PRGDIR=`dirname "$PRG"`
+EXECUTABLE=tool-wrapper.sh
+
+# Check that target executable exists
+if $os400; then
+ # -x will Only work on the os400 if the files are:
+ # 1. owned by the user
+ # 2. owned by the PRIMARY group of the user
+ # this will not work if the user belongs in secondary groups
+ eval
+else
+ if [ ! -x "$PRGDIR"/"$EXECUTABLE" ]; then
+echo "Cannot find $PRGDIR/$EXECUTABLE"
+echo "The file is absent or does not have execute permission"
+echo "This file is needed to run this program"
+exit 1
+ fi
+fi
+
+exec "$PRGDIR"/"$EXECUTABLE"
org.apache.tomcat.util.net.openssl.ciphers.OpenSSLCipherConfigurationParser "$@"
Propchange: tomcat/trunk/bin/ciphers.sh
--
svn:executable = *
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java?rev=1811614&r1=1811613&r2=1811614&view=diff
==
---
tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java
(original)
+++
tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java
Mon Oct 9 21:55:29 2017
@@ -824,4 +824,77 @@ public class OpenSSLCipherConfigurationP
}
return builder.toString().substring(0, builder.length() - 1);
}
+
+public static void usage() {
+System.out.println("Usage: java " +
OpenSSLCipherConfigurationParser.class.getName() + " [options] cipherspec");
+System.out.println();
+System.out.println("Displays the TLS cipher suites matching the
cipherspec.");
+System.out.println();
+System.out.println(" --help,");
+System.out.println(" -h Print this help message");
+System.out.println(" --openssl Show OpenSSL cipher suite names
instead of IANA cipher suite names.");
+System.out.println(" --verbose,");
+System.out.println(" -v Provide detailed cipher listing");
+}
+
+public static void main(String[] args) throws Exception
+{
+boolean verbose = false;
+boolean useOpenSSLNames = false;
+int argindex;
+for(argindex = 0; argindex < args.length; ++argindex)
+{
+String arg = args[argindex];
+if("--verbose".equals(arg) || "-v".equals(arg))
+verbose = true;
+else if("--openssl".equals(arg))
+useOpenSSLNames = true;
+else if("--help".equals(arg) || "-h".equals(arg)) {
+usage();
+System.exit(0);
+}
+else if("--".equals(arg)) {
+
svn commit: r1811615 - /tomcat/trunk/bin/ciphers.bat
Author: schultz Date: Mon Oct 9 21:56:50 2017 New Revision: 1811615 URL: http://svn.apache.org/viewvc?rev=1811615&view=rev Log: Add DOS batch file for ciphers command wrapepr. Added: tomcat/trunk/bin/ciphers.bat (with props) Added: tomcat/trunk/bin/ciphers.bat URL: http://svn.apache.org/viewvc/tomcat/trunk/bin/ciphers.bat?rev=1811615&view=auto == --- tomcat/trunk/bin/ciphers.bat (added) +++ tomcat/trunk/bin/ciphers.bat Mon Oct 9 21:56:50 2017 @@ -0,0 +1,58 @@ +@echo off +rem Licensed to the Apache Software Foundation (ASF) under one or more +rem contributor license agreements. See the NOTICE file distributed with +rem this work for additional information regarding copyright ownership. +rem The ASF licenses this file to You under the Apache License, Version 2.0 +rem (the "License"); you may not use this file except in compliance with +rem the License. You may obtain a copy of the License at +rem +rem http://www.apache.org/licenses/LICENSE-2.0 +rem +rem Unless required by applicable law or agreed to in writing, software +rem distributed under the License is distributed on an "AS IS" BASIS, +rem WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +rem See the License for the specific language governing permissions and +rem limitations under the License. + +rem --- +rem Script to digest password using the algorithm specified +rem --- + +setlocal + +rem Guess CATALINA_HOME if not defined +set "CURRENT_DIR=%cd%" +if not "%CATALINA_HOME%" == "" goto gotHome +set "CATALINA_HOME=%CURRENT_DIR%" +if exist "%CATALINA_HOME%\bin\tool-wrapper.bat" goto okHome +cd .. +set "CATALINA_HOME=%cd%" +cd "%CURRENT_DIR%" +:gotHome +if exist "%CATALINA_HOME%\bin\tool-wrapper.bat" goto okHome +echo The CATALINA_HOME environment variable is not defined correctly +echo This environment variable is needed to run this program +goto end +:okHome + +set "EXECUTABLE=%CATALINA_HOME%\bin\tool-wrapper.bat" + +rem Check that target executable exists +if exist "%EXECUTABLE%" goto okExec +echo Cannot find "%EXECUTABLE%" +echo This file is needed to run this program +goto end +:okExec + +rem Get remaining unshifted command line arguments and save them in the +set CMD_LINE_ARGS= +:setArgs +if ""%1""== goto doneSetArgs +set CMD_LINE_ARGS=%CMD_LINE_ARGS% %1 +shift +goto setArgs +:doneSetArgs + +call "%EXECUTABLE%" org.apache.tomcat.util.net.openssl.ciphers.OpenSSLCipherConfigurationParser %CMD_LINE_ARGS% + +:end Propchange: tomcat/trunk/bin/ciphers.bat -- svn:executable = * - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1811616 - /tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java
Author: schultz
Date: Mon Oct 9 22:01:27 2017
New Revision: 1811616
URL: http://svn.apache.org/viewvc?rev=1811616&view=rev
Log:
Always print a trailing newline.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java?rev=1811616&r1=1811615&r2=1811616&view=diff
==
---
tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java
(original)
+++
tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java
Mon Oct 9 22:01:27 2017
@@ -891,8 +891,7 @@ public class OpenSSLCipherConfigurationP
else
System.out.print(cipher.name());
}
-if(verbose)
-System.out.println();
+System.out.println();
} else {
System.out.println("No ciphers match '" + cipherSpec + "'");
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1811620 - /tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java
Author: schultz
Date: Mon Oct 9 22:26:47 2017
New Revision: 1811620
URL: http://svn.apache.org/viewvc?rev=1811620&view=rev
Log:
Fix mismatched ciphersuite metadata.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java?rev=1811620&r1=1811619&r2=1811620&view=diff
==
---
tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java
(original)
+++
tomcat/trunk/java/org/apache/tomcat/util/net/openssl/ciphers/OpenSSLCipherConfigurationParser.java
Mon Oct 9 22:26:47 2017
@@ -880,16 +880,16 @@ public class OpenSSLCipherConfigurationP
if(first) {
first = false;
} else {
-if(verbose) {
-System.out.println("\t" + cipher.getProtocol() +
"\tKx=" + cipher.getKx() + "\tAu=" + cipher.getAu() + "\tEnc=" +
cipher.getEnc() + "\tMac=" + cipher.getMac());
-}
-else
+if(!verbose)
System.out.print(',');
}
if(useOpenSSLNames)
System.out.print(cipher.getOpenSSLAlias());
else
System.out.print(cipher.name());
+if(verbose) {
+System.out.println("\t" + cipher.getProtocol() + "\tKx=" +
cipher.getKx() + "\tAu=" + cipher.getAu() + "\tEnc=" + cipher.getEnc() +
"\tMac=" + cipher.getMac());
+}
}
System.out.println();
} else {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61603] New: Not-well-formed XML returned from /manager/status?XML=true when running Java 9
https://bz.apache.org/bugzilla/show_bug.cgi?id=61603 Bug ID: 61603 Summary: Not-well-formed XML returned from /manager/status?XML=true when running Java 9 Product: Tomcat 8 Version: 8.5.23 Hardware: PC OS: Linux Status: NEW Severity: regression Priority: P2 Component: Manager Assignee: dev@tomcat.apache.org Reporter: shirag...@gmail.com Target Milestone: Hello! When running Tomcat 8.5.23 or Tomcat 9.0.1 for that matter with Java 9 the response from /manager/status?XML=true is returning not-well-formed XML data. Expected behaviour: Getting well-formed XML. Actual behaviour: Getting non-well-formed XML. Reproducible: Always when run on Java 9. Example snippet of offending output: Please note the apostrophes surrounding non-nmethods, which should be escaped. Possible solution: Ensure all String attribute values are XML-escaped. Thank you. -- 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
