Just as a follow up to the two rogue test files


I copied the util and trailers folders into the java folder and that
didn't make any difference. Also I noticed that, for the 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

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.


On Thu, 24 Feb 2022 at 15:13, John Barrow <> 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:
For additional commands, e-mail:

Reply via email to