Re: Configure Tomcat development using NetBeans IDE
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 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 elements. I also added it to the 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 ) 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
Re: Configure Tomcat development using NetBeans IDE
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 elements. I also added it to the 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 ) 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
Re: Configure Tomcat development using NetBeans IDE
On 22/02/2022 17:59, John Barrow wrote:
John,
Thanks for separating this out into a new thread.
As a life-long supporter of Subversion, this was my first foray into
the world of git, but I believe, after a quick crash course, I have
managed to have forked and cloned Tomcat onto my laptop!
This is where using a clone would speed things up as you'd be able to fetch the
update from Git.
Therefore, you can now assume that I can speed things up :)
I have built Tomcat using Ant.
Great. If you can do this, you are at least 90% of the way there.
While I did get
warnings about deprecated features as expected, I also had quite a
number of other warnings that looked a bit concerning (which you asked
me to submit to you)
e.g. - WARN aQute.bnd.plugin.jpms.JPMSModuleInfoPlugin - Can't find a
module name for imported package: jakarta.websocket
Ah. Yes, those. You can ignore those too. Although thanks for checking
as looking at your logs I spotted a typo which I've now fixed.
Anyway, to cut a long investigation short, I found two environments
that were out of sync.
As far as I can tell, in nbproject\project.xml, the classpath just
underneath the element
output/classes:output/testclasses:${base.path}/junit-4.13.2/junit-4.13.2.jar:${base.path}/easymock-4.3/easymock-4.3.jar:${base.path}/objenesis-3.2/objenesis-3.2.jar:${base.path}/cglib-3.3.0/cglib-nodep-3.3.0.jar:${base.path}/hamcrest/hamcrest-2.2.jar
should look more like
output/classes:output/testclasses:${base.path}/junit-4.13.2/junit-4.13.2.jar:${base.path}/easymock-4.3/easymock-4.3.jar:${base.path}/objenesis-3.2/objenesis-3.2.jar:${base.path}/cglib-3.3.0/cglib-nodep-3.3.0.jar:${base.path}/hamcrest-2.2/hamcrest-2.2.jar:${base.path}/unboundid-ldapsdk-6.0.3/unboundid-ldapsdk-6.0.3.jar
Agreed.
There was a typo in the hamcrest folder name (missing version) and
some of the classes the test sources referred to were missing. I used
the Maven repository to identify the latest versions and downloaded
them.
The reason that the jUnit classes weren't found is that they weren't
being downloaded into the {base.path} folder as part of the 'ant'
script, used to build Tomcat, but looks like only the jars needed to
build the project were (but that's an assumption of mine). I do not
know enough about Ant to try and determine why this may be.
Ant only downloads those files if you try and run the tests via Ant. You
can trigger those downloads using:
ant download-test-compile
This might also be of interest
ant -projecthelp
Only documented targets are listed and I am fairly sure there are a few
targets that need to be documented so they appear in that list.
Also, while looking here, should the be at least
updated to '11' as '1.7' gives a bucketload of exceptions when loaded
into NetBeans?
Agreed.
So, my folder structure now looks like below, with jUnit, easyMock,
hamcrest, odjenesis, unboundid having being downloaded manually. I may
have missed one out of that list as I forgot to take a directory
listing prior to adding the additional folders to compare with.
C:\Community\DownloadedTomcatLibraries\bnd-6.1.0
C:\Community\DownloadedTomcatLibraries\cglib-3.3.0
C:\Community\DownloadedTomcatLibraries\commons-daemon-1.2.4
C:\Community\DownloadedTomcatLibraries\derby-10.15.2.0
C:\Community\DownloadedTomcatLibraries\easymock-4.3
C:\Community\DownloadedTomcatLibraries\ecj-4.22
C:\Community\DownloadedTomcatLibraries\hamcrest-2.2
C:\Community\DownloadedTomcatLibraries\jacoco-0.8.7
C:\Community\DownloadedTomcatLibraries\jaxrpc-1.1-rc4
C:\Community\DownloadedTomcatLibraries\junit-4.13.2
C:\Community\DownloadedTomcatLibraries\migration-1.0.0
C:\Community\DownloadedTomcatLibraries\objenesis-3.2
C:\Community\DownloadedTomcatLibraries\osgi-annotations-1.1.1
C:\Community\DownloadedTomcatLibraries\unboundid-6.0.3
C:\Community\DownloadedTomcatLibraries\unboundid-ldapsdk-6.0.3
C:\Community\DownloadedTomcatLibraries\wsdl4j-1.6.3
C:\Community\DownloadedTomcatLibraries\bnd-6.1.0\biz.aQute.bnd-6.1.0.jar
C:\Community\DownloadedTomcatLibraries\cglib-3.3.0\cglib-nodep-3.3.0.jar
I noticed Checkstyle is missing.
ant download-validate
If you submit a patch it is helpful if you configure and run Checkstyle
(see section 8 of BUILDING.txt for details)
If you do a release build you'll end up downloading at least one
additional library - the NSIS installer but unless you want to tweak the
Windows installer I doubt you'll need a release build.
I still have a handful of red ! against some of the test files.
org.apache.catalina.ant.TestDeployTask
- I have a red ! flag against this file, but the source file looks
to be fine (no markers against any of the lines to backup the red !
against the file). I will ask the Netbeans community if I can find out
what that means!
Odd. Eclipse does that sometimes. Sometimes opening and closing the file
fixes it. Sometimes I just delete the warning and it doesn't come back.
Don't know if
Re: Configure Tomcat development using NetBeans IDE
Hi Greg, > You should not need to reload tomcat for code unless NetBeans cannot handle > hot reload. I don't believe that there is a problem with NetBeans, it updates the active code files in the WEB_APP/classes perfectly, but then as previously discussed in the other thread, there is no file locking (not possible) and as soon as multiple files need recompiling (in my case a listener and a class) we risk having an unstable deployment, albeit for a fraction of a second. Tomcat detects the first file change and that triggers the reload of the webapp. However, the listener class (in my case) is still being created / updated and causes Tomcat to crash (understandably so). Weirdly enough, I never had an issue until I upgraded to Tomcat 10, but I suspect that was a fluke of the project I was working on rather than the upgrade. I mainly create Java Servlets (brilliant API by the way) and so am installing many small individual class files. > I would stop and restart tomcat for method signature changes, new classes > etc. It's quick and stops reload issues. You are right, Tomcat is ridiculously fast to Start / Stop (2 mouse clicks for me, 5 seconds). In fact when I first installed Tomcat that is how I operated until I discovered reloadable - and I fall into that historic stereotypical old-school developer type labelled 'lazy', true in my case. I could now halve the number of keystrokes (and shave 5 seconds off my deploy) so now it was F11 (recompile), F5 (browser refresh). Of course, once you have been tempted by the serpent, it is so hard to have your candy taken away from you hence me spending a week attempting to install Tomcat and implement some protection for this scenario :) John On Wed, 23 Feb 2022 at 08:10, Greg Huber wrote: > > There have been lots of emails on this, sorry if I have missed something.. > > Although I don't use net beans, I use Eclipse with the venerable Sysdeo > Tomcat Plugin (modified), and from my experience set reloadable = > "false". I would stop and restart tomcat for method signature changes, > new classes etc. It's quick and stops reload issues. > > You should not need to reload tomcat for code unless, net beans cannot > handle hot reload. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Configure Tomcat development using NetBeans IDE
There have been lots of emails on this, sorry if I have missed something..
Although I don't use net beans, I use Eclipse with the venerable Sysdeo
Tomcat Plugin (modified), and from my experience set reloadable =
"false". I would stop and restart tomcat for method signature changes,
new classes etc. It's quick and stops reload issues.
You should not need to reload tomcat for code unless, net beans cannot
handle hot reload.
On 22/02/2022 17:59, John Barrow wrote:
Hi,
Firstly, this is actually a continuation of a previous thread
(specifically the email from Make Thomas, dated 21/02/2022 08:10)
discussing the specification for enhancing the reloading of webapps
after changes to the deployed files. This thread is titled ‘ is too quick to respond’ and remains active with
outstanding discussion points. However, in order to try and implement
the suggested changes, I needed to create a development environment
and so the thread quickly shifted into a bunch of configuration issues
which took the thread off topic.
Secondly, this email is quite long as I wanted to describe the steps I
took to get to where I am now (briefly, nearly there, just can't fully
test, unless all of them!). I have also included some suggestions for
alterations to the NetBeans configuration files that I am happy to
commit back to git if my understanding is correct./ deductions are
correct although one of them appears to be an issue with the ant build
and I am not confident enough to research this.
There are a couple of attachments that, as before, I have placed in my
shared Dropbox folder, accessed from
https://www.dropbox.com/sh/2ewipogzr48qcxi/AAAf3Rqv6WoRO9hyMC0W7P2za?dl=0
Mark, your insightful email has proved invaluable and having spent a
couple of days working through this, it has provided the catalyst for
me to be able to start joining the dots to achieving a full
development environment.
So, responding to each of your suggestions has taken me on a massive
learning curve, but
Firstly, I started back with a blank piece of paper.
If your eventual aim is to provide a pull request to address this issue then
I'd recommend:
- Fork the Tomcat project in GitHub
- Checkout your clone
As a life-long supporter of Subversion, this was my first foray into
the world of git, but I believe, after a quick crash course, I have
managed to have forked and cloned Tomcat onto my laptop!
This is where using a clone would speed things up as you'd be able to fetch the
update from Git.
Therefore, you can now assume that I can speed things up :)
I have built Tomcat using Ant.
Ran the amended 'ant ide-netbeans' script (checked GitHub to see what
changes had been made - the details of this change log request turned
out to be very useful later!)
Hmm. You shouldn't see any warnings about modules. A handful of warnings about
deprecation are expected. If you still see these warnings then yes, please
provide a copy so we can take a look.
Launched NetBeans and did a clean > deploy. The results are in my
shared DropBox folder (along with everything else) called "Ant Clean
and Build from Netbeans.txt" and it did actually look to have done a
successful build if you believe the summary line! While I did get
warnings about deprecated features as expected, I also had quite a
number of other warnings that looked a bit concerning (which you asked
me to submit to you)
e.g. - WARN aQute.bnd.plugin.jpms.JPMSModuleInfoPlugin - Can't find a
module name for imported package: jakarta.websocket
At this point, I still had a lot of red [!] against the Tests folder,
just as before and so the version amendment for jUnit didn't appear to
work, although I verified that it is the latest jUnit v4 build from
Mavens repository. As an aside, as I am sure you are aware, NetBeans
didn't support any later versions of jUnit using the Ant framework as
they believe that no-one should be using Ant anymore and should
migrate to Maven / Gradle!
So, rather than push back immediately, I thought I would spend some
time yesterday trying to figure it out, given that you had (by your
change) hinted which of the files might be related to my issue. Also,
your reference to tomcat\res\ide-support\netbeans\README.txt was
enlightening!
Anyway, to cut a long investigation short, I found two environments
that were out of sync.
As far as I can tell, in nbproject\project.xml, the classpath just
underneath the element
output/classes:output/testclasses:${base.path}/junit-4.13.2/junit-4.13.2.jar:${base.path}/easymock-4.3/easymock-4.3.jar:${base.path}/objenesis-3.2/objenesis-3.2.jar:${base.path}/cglib-3.3.0/cglib-nodep-3.3.0.jar:${base.path}/hamcrest/hamcrest-2.2.jar
should look more like
