You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by John Barrow <jb...@gmail.com> on 2022/02/22 17:59:42 UTC
Configure Tomcat development using NetBeans IDE
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 ‘<Context …
reloadable = "true"> 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 <unit-tests/> element
<classpath
mode="compile">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</classpath>
should look more like
<classpath
mode="compile">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</classpath>
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.
Also, while looking here, should the <source-level> be at least
updated to '11' as '1.7' gives a bucketload of exceptions when loaded
into NetBeans?
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 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!
org.apache.coyote.http2.TestStream
- package trailers does not exist - import trailers.ResponseTrailers;
util.TestCookieFilter
- cannot find symbol CookieFilter in (e.g., multiple instances)
Assert.assertEquals("a=b", CookieFilter.filter("a=b", null));
(e.g.) webapp/bug36923.jsp, but there are quite a few similar.
- This may be Netbeans validating against specific HTML versions. I
have taken 2 screenshots (prefixed JSP Exception) of the exception and
proposed fix but not done anything as not sure whether these are
historic or used as part of the test framework. It would be nice to
start with a clean sheet though, more in case others later come on
board and get distracted by exceptions that aren't important.
Apart from those remaining exceptions, the tests folder looks to be
acceptable to NetBeans.
I then ran 'ant test' and encouragingly, all the tests appeared to pass!!!!
> Following instructions in points 7 & 8 of the tomcat\res\ide-support\netbeans\README.txt (run and debug an individual test)
From NetBeans, I then went to see if I could run an individual test
and came unstuck. OK, I picked a test at random that looked
interesting so I tried
org.apache.catalina.servlets.ServletOptionsBaseTest. The log (Test
output for org.apache.catalina.servlets.ServletOptionsBaseTest.txt)
reported an Error and so FAILED the test. I have uploaded the log to
DropBox.
I also tried adding a breakpoint on the first line (as described in
point 8 of the document) and got the same response and the breakpoint
wasn't triggered.
Using details in the BUILDING.txt, I tried implementing the
instructions for a running a single test from the CMD using 'ant
test', but first, amending the build.properties file and adding the
line
test.entry=org.apache.catalina.util.TestServerInfo
which is the one documented in BUILDING.txt.
That failed as well, with the following (similar to NetBeans) error
Testsuite: org.apache.catalina.servlets.ServletOptionsBaseTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.128 sec
------------- Standard Error -----------------
java.util.logging.ErrorManager: 0: Unable to delete log files older
than [90] days
java.util.logging.ErrorManager: 0: Unable to delete log files older
than [90] days
java.util.logging.ErrorManager: 0: Unable to delete log files older
than [90] days
java.util.logging.ErrorManager: 0: Unable to delete log files older
than [90] days
------------- ---------------- ---------------
Testcase: testOptions took 0.002 sec
Caused an ERROR
null
java.lang.InstantiationException
at java.base/jdk.internal.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(InstantiationExceptionConstructorAccessorImpl.java:48)
at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
So it may be the specific test I picked (at random) that only makes
sense when run as part of a suite of tests so any help would be
appreciated.
I also tried the simple test case detailed in BUILDING.txt
(test.entry=org.apache.catalina.util.TestServerInfo) and this worked
both in NetBeans and Ant standalone, as well as adding a breakpoint
and so that adds weight to the thought that I picked a test that is
not meant to be run in isolation.
> The simplest way to test the build is to try the following:
> cd output\build\bin
> catalina.bat run
I then tried to launch Tomcat from a CMD line (again, thanks for the
'obvious' starting script but these hints really help so that I know
that taking the right path)
The first time I attempted it, it appeared to work beautifully, until
I realised that it had actually launched my production copy of Tomcat
as I could see the listeners that I have setup reporting that they had
been triggered successfully! So I amended the environment variable
CATALINA_HOME = C:\Community\tomcat (the location of the webapps
directory) and tried again and came to an abrupt halt.
The output was as follows
C:\Community\tomcat\output\build\bin>catalina.bat run
Using CATALINA_BASE: "C:\Community\tomcat"
Using CATALINA_HOME: "C:\Community\tomcat"
Using CATALINA_TMPDIR: "C:\Community\tomcat\temp"
Using JRE_HOME: "C:\Development\JDK\jdk-17"
Using CLASSPATH:
"C:\Community\tomcat\bin\bootstrap.jar;C:\Community\tomcat\bin\tomcat-juli.jar"
Using CATALINA_OPTS: ""
NOTE: Picked up JDK_JAVA_OPTIONS:
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED
--add-opens=java.base/java.util.concurrent=ALL-UNNAMED
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
Error: Could not find or load main class org.apache.catalina.startup.Bootstrap
Caused by: java.lang.ClassNotFoundException:
org.apache.catalina.startup.Bootstrap
This brings me to a point I noticed earlier - that there are two 'bin'
folders - C:\Community\tomcat\bin &
C:\Community\tomcat\output\build\bin and the first didn't have
bootstrap.jar within it, and from the date stamps are 21/02/2022 at
11:23 and no jars, and so this may be an outline folder, also, while
the dates are yesterday, that may be around the time that I cloned
Tomcat onto my laptop although I would have thought that the date/time
would represent when they were last amended rather than when they were
copied to me (as I would expect from Subversion).
So I amended the CATALINA_HOME = C:\Community\tomcat\output\build
C:\Community\tomcat\output\build\bin>catalina.bat run
Using CATALINA_BASE: "C:\Community\tomcat\output\build"
Using CATALINA_HOME: "C:\Community\tomcat\output\build"
Using CATALINA_TMPDIR: "C:\Community\tomcat\output\build\temp"
Using JRE_HOME: "C:\Development\JDK\jdk-17"
Using CLASSPATH:
"C:\Community\tomcat\output\build\bin\bootstrap.jar;C:\Community\tomcat\output\build\bin\tomcat-juli.jar"
Using CATALINA_OPTS: ""
and it launched!!!
I checked http://localhost:8080/examples and that all looks OK
So, out of interest, why are there two bin folders?
> I believe the way most Tomcat committers work is running Tomcat on the command line and remote debugging from their IDE of choice.
> Following instructions in points 9 of the tomcat\res\ide-support\netbeans\README.txt (run and debug an individual test)
In short, I was successful in this. Again, I had never done remote
debugging before! I needed to change the port to 8080 everywhere but
that was about it.
I fudged a few parameters in catalina.bat and tweaked the source of
org.apache.catalina.util.ServerInfo (added a console keyboard read to
pause the routine) in the first instance as I could test the remote
debugging on a simple example. Netbeans initially claimed that the
source with the breakpoint in wasn't from tomcat\java (it was) but
mysteriously, that message went away and got the "lineBreakpoint
ServerInfo:117 successfully submitted" in the status bar and all was
well.
Finally (you will be glad to know), I repeated the exercise, setting
the debugger to break at WebappLoaded.backgroundProcess(), as advised
and that worked a treat. This Java Remote Debugging is pretty
impressive!
> Tomcat 10.1.x (the current main branch) requires Java 11 as a minimum. You should be fine setting the source level to anything 11 or above. Personally, I'd set it to 11 as that way you avoid the (very low) risk of proposing a fix that doesn't work on Java 11.
If I set the build version to 11, do I need to install JDK 11 as well
and update my 'env' JAVA_HOME, or is the Java compiler clever enough
to limit the byte code generation to that which will run on Java 11
while still allowing me to have JDK 17 as my environment. I think the
answer is Yes, but would be nice to have confirmation.
> Tell NetBeans to ignore that folder. It should not be part of the source you are trying to compile. It is part of a (rather old) tutorial on building a web application.
To do this, I amended the project.xml in nbproject to remove the three
references to sample. I also removed the single reference to
'tomcat-lite'. The folder wasn't cloned from git and I could't find
any reference to a 'lite' version of Tomcat and so I was wondering if
this is an historic / abandoned project. Should the master
\tomcat\res\ide-support\netbeans\project.xml file be edited to remove
these permanently (again to provide a clean experience for others).
In summary, I am assuming from the lack of response from my request
about NetBeans, that this is not a favourite environment for Tomcat
development. It may just have been a long time since anyone deployed
the development framework into NetBeans and so my efforts might be
worthwhile as a refresher check on the current documentation. I am
keeping notes of the process I have been through so far as well as how
to resolve issues I have encountered and so will look to update the
README for NetBeans to help future developers.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Configure Tomcat development using NetBeans IDE
Posted by Christopher Schultz <ch...@christopherschultz.net>.
John,
On 2/23/22 05:08, John Barrow wrote:
> I fall into that historic stereotypical old-school developer type
> labelled 'lazy'
You're in good company.
Awww.. the threevirtues dot com website has been hijacked by some stupid
advertising company. This is why we can't have nice things.
Google for a better reference; I didn't want to post any of them in this
forum.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Configure Tomcat development using NetBeans IDE
Posted by John Barrow <jb...@gmail.com>.
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 <gr...@gmail.com> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Configure Tomcat development using NetBeans IDE
Posted by Greg Huber <gr...@gmail.com>.
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 ‘<Context …
> reloadable = "true"> 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 <unit-tests/> element
>
> <classpath
> mode="compile">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</classpath>
>
> should look more like
>
> <classpath
> mode="compile">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</classpath>
>
> 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.
>
> Also, while looking here, should the <source-level> be at least
> updated to '11' as '1.7' gives a bucketload of exceptions when loaded
> into NetBeans?
>
> 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 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!
>
> org.apache.coyote.http2.TestStream
> - package trailers does not exist - import trailers.ResponseTrailers;
>
> util.TestCookieFilter
> - cannot find symbol CookieFilter in (e.g., multiple instances)
> Assert.assertEquals("a=b", CookieFilter.filter("a=b", null));
>
> (e.g.) webapp/bug36923.jsp, but there are quite a few similar.
> - This may be Netbeans validating against specific HTML versions. I
> have taken 2 screenshots (prefixed JSP Exception) of the exception and
> proposed fix but not done anything as not sure whether these are
> historic or used as part of the test framework. It would be nice to
> start with a clean sheet though, more in case others later come on
> board and get distracted by exceptions that aren't important.
>
> Apart from those remaining exceptions, the tests folder looks to be
> acceptable to NetBeans.
>
> I then ran 'ant test' and encouragingly, all the tests appeared to pass!!!!
>
>> Following instructions in points 7 & 8 of the tomcat\res\ide-support\netbeans\README.txt (run and debug an individual test)
> From NetBeans, I then went to see if I could run an individual test
> and came unstuck. OK, I picked a test at random that looked
> interesting so I tried
> org.apache.catalina.servlets.ServletOptionsBaseTest. The log (Test
> output for org.apache.catalina.servlets.ServletOptionsBaseTest.txt)
> reported an Error and so FAILED the test. I have uploaded the log to
> DropBox.
>
> I also tried adding a breakpoint on the first line (as described in
> point 8 of the document) and got the same response and the breakpoint
> wasn't triggered.
>
> Using details in the BUILDING.txt, I tried implementing the
> instructions for a running a single test from the CMD using 'ant
> test', but first, amending the build.properties file and adding the
> line
> test.entry=org.apache.catalina.util.TestServerInfo
> which is the one documented in BUILDING.txt.
>
> That failed as well, with the following (similar to NetBeans) error
>
> Testsuite: org.apache.catalina.servlets.ServletOptionsBaseTest
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.128 sec
> ------------- Standard Error -----------------
> java.util.logging.ErrorManager: 0: Unable to delete log files older
> than [90] days
> java.util.logging.ErrorManager: 0: Unable to delete log files older
> than [90] days
> java.util.logging.ErrorManager: 0: Unable to delete log files older
> than [90] days
> java.util.logging.ErrorManager: 0: Unable to delete log files older
> than [90] days
> ------------- ---------------- ---------------
>
> Testcase: testOptions took 0.002 sec
> Caused an ERROR
> null
> java.lang.InstantiationException
> at java.base/jdk.internal.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(InstantiationExceptionConstructorAccessorImpl.java:48)
> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
>
> So it may be the specific test I picked (at random) that only makes
> sense when run as part of a suite of tests so any help would be
> appreciated.
>
> I also tried the simple test case detailed in BUILDING.txt
> (test.entry=org.apache.catalina.util.TestServerInfo) and this worked
> both in NetBeans and Ant standalone, as well as adding a breakpoint
> and so that adds weight to the thought that I picked a test that is
> not meant to be run in isolation.
>
>> The simplest way to test the build is to try the following:
>> cd output\build\bin
>> catalina.bat run
> I then tried to launch Tomcat from a CMD line (again, thanks for the
> 'obvious' starting script but these hints really help so that I know
> that taking the right path)
>
> The first time I attempted it, it appeared to work beautifully, until
> I realised that it had actually launched my production copy of Tomcat
> as I could see the listeners that I have setup reporting that they had
> been triggered successfully! So I amended the environment variable
> CATALINA_HOME = C:\Community\tomcat (the location of the webapps
> directory) and tried again and came to an abrupt halt.
>
> The output was as follows
>
> C:\Community\tomcat\output\build\bin>catalina.bat run
> Using CATALINA_BASE: "C:\Community\tomcat"
> Using CATALINA_HOME: "C:\Community\tomcat"
> Using CATALINA_TMPDIR: "C:\Community\tomcat\temp"
> Using JRE_HOME: "C:\Development\JDK\jdk-17"
> Using CLASSPATH:
> "C:\Community\tomcat\bin\bootstrap.jar;C:\Community\tomcat\bin\tomcat-juli.jar"
> Using CATALINA_OPTS: ""
> NOTE: Picked up JDK_JAVA_OPTIONS:
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.io=ALL-UNNAMED
> --add-opens=java.base/java.util=ALL-UNNAMED
> --add-opens=java.base/java.util.concurrent=ALL-UNNAMED
> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
> Error: Could not find or load main class org.apache.catalina.startup.Bootstrap
> Caused by: java.lang.ClassNotFoundException:
> org.apache.catalina.startup.Bootstrap
>
> This brings me to a point I noticed earlier - that there are two 'bin'
> folders - C:\Community\tomcat\bin &
> C:\Community\tomcat\output\build\bin and the first didn't have
> bootstrap.jar within it, and from the date stamps are 21/02/2022 at
> 11:23 and no jars, and so this may be an outline folder, also, while
> the dates are yesterday, that may be around the time that I cloned
> Tomcat onto my laptop although I would have thought that the date/time
> would represent when they were last amended rather than when they were
> copied to me (as I would expect from Subversion).
>
> So I amended the CATALINA_HOME = C:\Community\tomcat\output\build
>
> C:\Community\tomcat\output\build\bin>catalina.bat run
> Using CATALINA_BASE: "C:\Community\tomcat\output\build"
> Using CATALINA_HOME: "C:\Community\tomcat\output\build"
> Using CATALINA_TMPDIR: "C:\Community\tomcat\output\build\temp"
> Using JRE_HOME: "C:\Development\JDK\jdk-17"
> Using CLASSPATH:
> "C:\Community\tomcat\output\build\bin\bootstrap.jar;C:\Community\tomcat\output\build\bin\tomcat-juli.jar"
> Using CATALINA_OPTS: ""
>
> and it launched!!!
>
> I checked http://localhost:8080/examples and that all looks OK
>
> So, out of interest, why are there two bin folders?
>
>> I believe the way most Tomcat committers work is running Tomcat on the command line and remote debugging from their IDE of choice.
>> Following instructions in points 9 of the tomcat\res\ide-support\netbeans\README.txt (run and debug an individual test)
> In short, I was successful in this. Again, I had never done remote
> debugging before! I needed to change the port to 8080 everywhere but
> that was about it.
>
> I fudged a few parameters in catalina.bat and tweaked the source of
> org.apache.catalina.util.ServerInfo (added a console keyboard read to
> pause the routine) in the first instance as I could test the remote
> debugging on a simple example. Netbeans initially claimed that the
> source with the breakpoint in wasn't from tomcat\java (it was) but
> mysteriously, that message went away and got the "lineBreakpoint
> ServerInfo:117 successfully submitted" in the status bar and all was
> well.
>
> Finally (you will be glad to know), I repeated the exercise, setting
> the debugger to break at WebappLoaded.backgroundProcess(), as advised
> and that worked a treat. This Java Remote Debugging is pretty
> impressive!
>
>> Tomcat 10.1.x (the current main branch) requires Java 11 as a minimum. You should be fine setting the source level to anything 11 or above. Personally, I'd set it to 11 as that way you avoid the (very low) risk of proposing a fix that doesn't work on Java 11.
> If I set the build version to 11, do I need to install JDK 11 as well
> and update my 'env' JAVA_HOME, or is the Java compiler clever enough
> to limit the byte code generation to that which will run on Java 11
> while still allowing me to have JDK 17 as my environment. I think the
> answer is Yes, but would be nice to have confirmation.
>
>> Tell NetBeans to ignore that folder. It should not be part of the source you are trying to compile. It is part of a (rather old) tutorial on building a web application.
> To do this, I amended the project.xml in nbproject to remove the three
> references to sample. I also removed the single reference to
> 'tomcat-lite'. The folder wasn't cloned from git and I could't find
> any reference to a 'lite' version of Tomcat and so I was wondering if
> this is an historic / abandoned project. Should the master
> \tomcat\res\ide-support\netbeans\project.xml file be edited to remove
> these permanently (again to provide a clean experience for others).
>
> In summary, I am assuming from the lack of response from my request
> about NetBeans, that this is not a favourite environment for Tomcat
> development. It may just have been a long time since anyone deployed
> the development framework into NetBeans and so my efforts might be
> worthwhile as a refresher check on the current documentation. I am
> keeping notes of the process I have been through so far as well as how
> to resolve issues I have encountered and so will look to update the
> README for NetBeans to help future developers.
>
> John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Configure Tomcat development using NetBeans IDE
Posted by John Barrow <jb...@gmail.com>.
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 <jb...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Configure Tomcat development using NetBeans IDE
Posted by John Barrow <jb...@gmail.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Configure Tomcat development using NetBeans IDE
Posted by Mark Thomas <ma...@apache.org>.
On 22/02/2022 17:59, John Barrow wrote:
John,
<snip/>
Thanks for separating this out into a new thread.
<snip/>
> 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.
<snip/>
> 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 <unit-tests/> element
>
> <classpath
> mode="compile">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</classpath>
>
> should look more like
>
> <classpath
> mode="compile">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</classpath>
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 <source-level> 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 that is an option in NetBeans.
> org.apache.coyote.http2.TestStream
> - package trailers does not exist - import trailers.ResponseTrailers;
>
> util.TestCookieFilter
> - cannot find symbol CookieFilter in (e.g., multiple instances)
> Assert.assertEquals("a=b", CookieFilter.filter("a=b", null));
Ah. You need to add webapps/examples/WEB-INF/classes as a source folder.
That should fix the two issues above.
> (e.g.) webapp/bug36923.jsp, but there are quite a few similar.
> - This may be Netbeans validating against specific HTML versions. I
> have taken 2 screenshots (prefixed JSP Exception) of the exception and
> proposed fix but not done anything as not sure whether these are
> historic or used as part of the test framework.
That is a NetBeans bug. The JSP is valid but NetBeans is not taking into
account the isELIgnored="true" page directive.
To be fair to NetBeans, this is a can of worms. JSP Page directives can
be set in both the current page and any included page. To add to the
'fun' you can also specify includes in web.xml. Tomcat parses the page
(and all its includes) twice. Once to find all the directives and once
for everything else, once it knows what directives have been set.
> It would be nice to
> start with a clean sheet though, more in case others later come on
> board and get distracted by exceptions that aren't important.
I agree completely. IDE warnings have often provided me with a hint that
something isn't quite right with a change I have just made. That only
works because the project is warning free to start with.
I'd see if you can disable the JSP validation. If it makes you feel
better, Eclipse's JSP validation has similar issues.
> Apart from those remaining exceptions, the tests folder looks to be
> acceptable to NetBeans.
>
> I then ran 'ant test' and encouragingly, all the tests appeared to pass!!!!
Excellent.
>> Following instructions in points 7 & 8 of the tomcat\res\ide-support\netbeans\README.txt (run and debug an individual test)
>
> From NetBeans, I then went to see if I could run an individual test
> and came unstuck. OK, I picked a test at random that looked
> interesting so I tried
> org.apache.catalina.servlets.ServletOptionsBaseTest. The log (Test
> output for org.apache.catalina.servlets.ServletOptionsBaseTest.txt)
> reported an Error and so FAILED the test. I have uploaded the log to
> DropBox.
That is an abstract base class. You won't be able to run it. You should
be able to run one of the concrete sub-classes such as
org.apache.catalina.servlets.TestDefaultServletOptions
The naming convention is:
- Test* - tests you can run
- Tester* - support class - no tests to run
- Anything else - something you can't run as as test
<snip/>
> So I amended the CATALINA_HOME = C:\Community\tomcat\output\build
>
> C:\Community\tomcat\output\build\bin>catalina.bat run
> Using CATALINA_BASE: "C:\Community\tomcat\output\build"
> Using CATALINA_HOME: "C:\Community\tomcat\output\build"
> Using CATALINA_TMPDIR: "C:\Community\tomcat\output\build\temp"
> Using JRE_HOME: "C:\Development\JDK\jdk-17"
> Using CLASSPATH:
> "C:\Community\tomcat\output\build\bin\bootstrap.jar;C:\Community\tomcat\output\build\bin\tomcat-juli.jar"
> Using CATALINA_OPTS: ""
>
> and it launched!!!
>
> I checked http://localhost:8080/examples and that all looks OK
>
> So, out of interest, why are there two bin folders?
If we use GIT_CLONE to represent wherever you cloned the Tomcat source
%GIT_CLONE%\bin is the source folder.
When you run
ant
It creates a combined CATALINA_HOME/CATALINA_BASE in
%GIT_CLONE%\output\build
%GIT_CLONE% doesn't have a lib or logs directory either.
In Maven terms, output\build == target
>> I believe the way most Tomcat committers work is running Tomcat on the command line and remote debugging from their IDE of choice.
>> Following instructions in points 9 of the tomcat\res\ide-support\netbeans\README.txt (run and debug an individual test)
>
> In short, I was successful in this. Again, I had never done remote
> debugging before! I needed to change the port to 8080 everywhere but
> that was about it.
I think you mean 8000 for remote debugging but otherwise great. If you
can get this working, you are doing really well.
> I fudged a few parameters in catalina.bat and tweaked the source of
> org.apache.catalina.util.ServerInfo (added a console keyboard read to
> pause the routine) in the first instance as I could test the remote
> debugging on a simple example. Netbeans initially claimed that the
> source with the breakpoint in wasn't from tomcat\java (it was) but
> mysteriously, that message went away and got the "lineBreakpoint
> ServerInfo:117 successfully submitted" in the status bar and all was
> well.
>
> Finally (you will be glad to know), I repeated the exercise, setting
> the debugger to break at WebappLoaded.backgroundProcess(), as advised
> and that worked a treat. This Java Remote Debugging is pretty
> impressive!
It is incredibly useful. I use it all the time.
>> Tomcat 10.1.x (the current main branch) requires Java 11 as a minimum. You should be fine setting the source level to anything 11 or above. Personally, I'd set it to 11 as that way you avoid the (very low) risk of proposing a fix that doesn't work on Java 11.
>
> If I set the build version to 11, do I need to install JDK 11 as well
> and update my 'env' JAVA_HOME, or is the Java compiler clever enough
> to limit the byte code generation to that which will run on Java 11
> while still allowing me to have JDK 17 as my environment. I think the
> answer is Yes, but would be nice to have confirmation.
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.
>> Tell NetBeans to ignore that folder. It should not be part of the source you are trying to compile. It is part of a (rather old) tutorial on building a web application.
>
> To do this, I amended the project.xml in nbproject to remove the three
> references to sample. I also removed the single reference to
> 'tomcat-lite'. The folder wasn't cloned from git and I could't find
> any reference to a 'lite' version of Tomcat and so I was wondering if
> this is an historic / abandoned project. Should the master
> \tomcat\res\ide-support\netbeans\project.xml file be edited to remove
> these permanently (again to provide a clean experience for others).
Yes. tomcat-lite was an early experiment that evolved into the embedded
JARs. It was remove years ago.
> In summary, I am assuming from the lack of response from my request
> about NetBeans, that this is not a favourite environment for Tomcat
> development. It may just have been a long time since anyone deployed
> the development framework into NetBeans and so my efforts might be
> worthwhile as a refresher check on the current documentation. I am
> keeping notes of the process I have been through so far as well as how
> to resolve issues I have encountered and so will look to update the
> README for NetBeans to help future developers.
Thanks for persevering with this.
It is hard to know exactly why the issues with the NetBeans support
haven't been spotted sooner. It doesn't mean no-one is using NetBeans.
For example, I use Eclipse but never use the equivalent Eclipse scripts.
It looks like you have a bunch of changes that need to be made to the
NetBeans support files. Time to contribute those changes back :)
There are a couple of ways to contribute changes. The main ways are:
- Patch file in diff -u format attached to a BugZilla issue
- GitHub pull request
Happy to provide pointers for either approve if needed.
Looking forward to adding your name to the change log.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org