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

> 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

> - 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to