Mark, Just as a follow up to the two rogue test files
tomcat\test\org\apache\coyote\http2\TestStream.java tomcat\test\util\TestCookieFilter.java I copied the util and trailers folders into the java folder and that didn't make any difference. Also I noticed that, for the TestStream.java source it mentions import trailers.ResponseTrailers; and when I hover over the exception it says that 'package trailers' doesn't exist, whereas there is a POJC in the trailers folder (ResponseTrailers.java). Both these points may be irrelevant or, in the case of the second point - package = java class as far as import goes, but I mention them just in case. John On Thu, 24 Feb 2022 at 15:13, John Barrow <jbarrow...@gmail.com> wrote: > > Mark, > > I have now got grep working (following a post from another member > indicating that built into git bash!) > > > ant download-test-compile > > This is useful to know as I didn't run the tests script until later. > > > ant download-validate > > This didn't report Checkstyle missing - probably as not needed for > actual development. Running Checkstyle using > > ant -Dexecute.validate=true validate > > did then update the libraries folder > > > I doubt you'll need a release build > > So do I by the sound of it - I will probably come back to the forum > when looking to commit anything for the first time but I assume that I > will just upload any changes that, once approved, will form part of > the next release. Of course I will be able to benefit from the newly > developed time-delay in the meantime :) > > I have passed on your observation "but NetBeans is not taking into > account the isELIgnored="true" page directive" to the NetBeans > community > > > I'd see if you can disable the JSP validation. If it makes you feel better, > > Eclipse's JSP validation has similar issues. > > That has no effect! We can drop the issues over JSP as the NetBeans > community has taken up that baton. > > > That is an abstract base class. You won't be able to run it. > > Trust me to pick that one! I have only ever written simple unit tests > so not needed to create any abstract classes in my testing, but I > should have spent more time looking into your source and then would > have spotted the 'abstract' keyword!! In a very weak defence, I tend > to use interfaces rather than abstract classes. Anyway, thanks for the > naming conventions, that will prove time-saving. For good measure, I > ran TestDefaultServlet and that ran the tests successfully. > > Thanks for the explanation of the dual 'bin' folders. > > > Yes, the Java compiler is smart enough to generate the byte code as if it > > was generated with Java 11 so you are fine to stick with Java 17 as long as > > the build version is 11. > > I have amended my project options to reflect this and rebuilt the > project to check everything still works - it does! > > > Ah. You need to add webapps/examples/WEB-INF/classes as a source folder. > > That should fix the two issues above. > > I must still be missing a link here, I have added that folder to the > list of <folders> elements. I also added it to the <view> since, as > the project references files inside this folder, it seemed applicable > to include it. However, it didn't appear to make any difference - i.e. > NetBeans still couldn't tie the source back to those Java classes. > > I have checked that I have typed the paths correctly and I can see the > trailers.ResponseTrailers (& util.CookieFilter) file(s) in the > WEB-APP\classes and visible in the project folders (I assume as added > to <view>) to back-up paths are valid. NetBeans doesn't let me take > any action to try and find the file to resolve the [!], I assume > because it is a free form Ant project and so configuration is > 'read-only' once loaded (I would have options in Maven to locate the > missing resource). > > I have added my current project.xml and Trailers.ResponseTrailers.jpg > to the DropBox folder in case either of them helps. My only > observation is that, as I can't find a corresponding XSD file for > project.xml, there is another attribute I need to set to indicate that > these are class files in a different folder to the one the other > package files are in, but that seems unlikely. > > > I think you mean 8000 for remote debugging but otherwise great. If you can > > get this working, you are doing really well. > > I was using 8080 and appeared to be working although I have not used > it in anger yet. I had amended the catalina.bat line "set > JPDA_ADDRESS=localhost:8080, because I connect to Tomcat using > http://localhost:8080/examples. Your statement concerned me slightly > in that I now believe that I had made a wrong assumption. Anyway, I > amended the catalina.bat back and set NetBeans remote debugging to the > same and it worked as well so I will leave it at 8000. I couldn't find > anything on the web re Port 8000 vs 8080 (apart from "use which one > you want"), but I suspect that, ideally, the debugging communications > should be using a different port to the application otherwise there > may be conflicts but couldn't find anything to back up that > hypothesis. > > > - Patch file in diff -u format attached to a BugZilla issue > > - GitHub pull request > > Happy to provide pointers for either approval if needed. > > Unfortunately,II will now probably have to wait a bit for that. I will > soak the changes to the NetBeans configuration files while I explore > Tomcat, once the webapps/examples/WEB-INF/classes issue is sorted and > (hopefully) the NetBeans community has resolved the other exceptions. > That way, if I discover another missing link, I can incorporate it and > upload all the configuration changes at once to minimise confusion. > However, I am away in a weeks time - 5th March (Snowboarding at > last!), and have to catch up with some other chores / tasks before > getting back on the laptop. Hopefully, we can get these last minor > sticking points resolved prior to the 5th. > > Thanks again for your continued patience and valuable insights. > > John --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
