Re: In what directory was tomcat installed

2022-02-23 Thread Suvendu Sekhar Mondal
Hello!

On Thu, Feb 24, 2022, 3:50 AM Amn Ojee Uw  wrote:

> I am trying to setup Tomecat in Netbeans, but after installing Tomcat in
> my Debian 11, and in Netbeans going to "Tools -> Servers->Add server
> ->Apache Tomcat or TomEE
> -> Server Location
> -> Browse"
>
> I cannot tell in which directory Tomcat 10.x was installed.
> I am not a qualified programmer, I am just someone who would like to
> program and to make things worst, I am  new to the Linux world. So... I
> am really lost here; any help will be much appreciated.
> Thanks in advance.
>

I have not used Netbeans for long times. Probably you can try to find where
CATALINA_HOME is pointing to. Normally that's the base of Tomcat in any
environment.

1. Start your Tomcat server from Netbeans
2. After that use ps and grep command to search for text "catalina". It'll
be something like:

ps aux | grep catalina

Thanks!
Suvendu

>


In what directory was tomcat installed

2022-02-23 Thread Amn Ojee Uw
I am trying to setup Tomecat in Netbeans, but after installing Tomcat in 
my Debian 11, and in Netbeans going to "Tools -> Servers->Add server

->Apache Tomcat or TomEE
-> Server Location
-> Browse"

I cannot tell in which directory Tomcat 10.x was installed.
I am not a qualified programmer, I am just someone who would like to 
program and to make things worst, I am new to the Linux world. So... I 
am really lost here; any help will be much appreciated.

Thanks in advance.


Configure mulitple installs tomcat 8.5 - catalina_base/catalina_home

2022-02-23 Thread Jason Countryman
Good afternoon,

On a Centos 7 machine, I have multiple full tomcat installs.

/var/tomcat_installs/initiatingPROD
/var/tomcat_installs/respondingPROD

My app uses a spring configuration for cxf, and uses catalina.base to identify 
the location for the keystore/truststore, and log4j2 for logging.  When I start 
each individual tomcat using startup.sh, they report setting CATALINA_HOME and 
CATALINA_BASE correctly for their respective locations.

 $ /var/tomcat_installs/initiatingPROD/apache-tomcat-8.5.73/bin/startup.sh
Using CATALINA_BASE:   /var/tomcat_installs/initiatingPROD/apache-tomcat-8.5.73
Using CATALINA_HOME:   /var/tomcat_installs/initiatingPROD/apache-tomcat-8.5.73
Using CATALINA_TMPDIR: 
/var/tomcat_installs/initiatingPROD/apache-tomcat-8.5.73/temp
Using JRE_HOME:/usr
Using CLASSPATH:   
/var/tomcat_installs/initiatingPROD/apache-tomcat-8.5.73/bin/bootstrap.jar:/var/tomcat_installs/initiatingPROD/apache-tomcat-8.5.73/bin/tomcat-juli.jar
Using CATALINA_OPTS:
Tomcat started.

$ /var/tomcat_installs/respondingPROD/apache-tomcat-8.5.73/bin/startup.sh
Using CATALINA_BASE:   /var/tomcat_installs/respondingPROD/apache-tomcat-8.5.73
Using CATALINA_HOME:   /var/tomcat_installs/respondingPROD/apache-tomcat-8.5.73
Using CATALINA_TMPDIR: 
/var/tomcat_installs/respondingPROD/apache-tomcat-8.5.73/temp
Using JRE_HOME:/usr
Using CLASSPATH:   
/var/tomcat_installs/respondingPROD/apache-tomcat-8.5.73/bin/bootstrap.jar:/var/tomcat_installs/respondingPROD/apache-tomcat-8.5.73/bin/tomcat-juli.jar
Using CATALINA_OPTS:
Tomcat started.

However, as I follow catalina.out, it appears the values for these are changed 
somehow, or I have a configuration error causing this (more likely).  There is 
all kinds of crosstalk in the respondingPROD catalina.out showing things from 
the initiatingPROD installation.  The initiatingPROD catalina.out, however, 
only has references to what it should.

I'm setting this up this way so to provide a testing/upgrade path for 
tomcat/log4j2 updates, and need each of these installations to be agnostic of 
the other, and really need a way to specify for spring where the keystores are 
located and they can not be in the classpath.

There has to be some configuration thing for multiple FULL tomcat installations 
that I'm missing here causing all this crosstalk for the respondingPROD 
installation, correct?

Thank you,

Jason T. Countryman


This message and any attachments may contain information that is protected by 
law as privileged and confidential, and is transmitted for the sole use of the 
intended recipient(s). If you are not the intended recipient, you are hereby 
notified that any use, dissemination, copying or retention of this e-mail or 
the information contained herein is strictly prohibited. If you received this 
e-mail in error, please immediately notify the sender by e-mail, and 
permanently delete this e-mail.


Re: Configure Tomcat development using NetBeans IDE

2022-02-23 Thread Mark Thomas

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: is too quick to respond

2022-02-23 Thread John Barrow
 Christopher,


> You will just change the implementation to answer the question "have any
resources been modified, but not-too-recently?"



OK


> The check must be fast, otherwise it will hang-up other processes on the
server. Don't introduce any new loops or stalls. Just return true or false
as quickly as possible. The process will be repeated during the "next"
check so you only have to decide not to reload "too early"?


Not sure that I understand this point (re 'check must be fast'). I wasn't
imagining affecting the initial trigger point at all (i.e. Tomcat has
detected a change in one of the active files) so shouldn't affect the
day-to-day performance. Once Tomcat has decided that a reload is required
*and* the user has requested for Tomcat to do the reload (i.e. Context flag
is defined to true), prior to actioning the reload, add the additional
check (simple user-specified timer delay to allow the external
application time to finish deployment, and then let Netbeans carry on.


Your additional suggestion that the time-stamps of the amended files should
remain consistent over that period also sounds sensible. Given that Tomcat
can't implement the event model for reasons you have already explained, I
am now thinking that the event that triggers the re-build won't contain
details of what files have been amended, simply that there has been a
change. Snapshotting all the files within the two folders, noting the
timestamps and then polling again after the delay seems to be repeating
what Tomcat is probably already doing to trigger the event in the first
place.


Now that I just about have a development environment I can explore and
debug, I think I should spend some time around this class and learn when /
why it's called and the calls it makes to do the reload. So far, I have had
to imagine how the code is structured and so consider a solution based on
that (possibly false hypothesis).


Just to be clear from other questions, I have no intention in going
anywhere near the 'rebuild' process - that is a black box as far as I am
concerned.


John


PS: Nice suggestion about contacting IT for more cores - unfortunately I am
now (recently) retired and so, I am the IT department and the Finance
director (wife) hasn't approved the budget :)


Re: Configure Tomcat development using NetBeans IDE

2022-02-23 Thread John Barrow
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: Native libraries not found?

2022-02-23 Thread Claude Brisson
There is no need to compile anything, the native libraries are supposed 
to be provided in the libtcnative-1 packet.


I found the problem, I guess it should be reported to the debian tomcat 
package maintainer. The path /usr/lib/x86_64-linux-gnu is missing from 
the default java.library.path.


To have it working, I did:

# systemctl edit tomcat9

    [Service]
Environment="CATALINA_OPTS=-Djava.library.path=/usr/java/packages/lib/amd64:/usr/lib/x86_64-linux-gnu:/usr/lib64:/lib64:/lib:/usr/lib"

# systemctl daemon-reload
# systemctl restart tomcat9


Claude Brisson

On 23/02/2022 09:28, i...@flyingfischer.ch wrote:

Am 23.02.22 um 09:12 schrieb Claude Brisson:

Hi.

After an upgrade from debian buster to debian bullseye, the APR 
native library stopped working:



Did you install libapr1 libapr1-dev libssl-dev before compiling?


Markus




# dpkg -l | ag tomcat
ii  libtcnative-1:amd64 1.2.26-1 amd64    Tomcat native library 
using the Apache Portable Runtime
ii  libtomcat9-java 9.0.43-2~deb11u3   all Apache Tomcat 
9 - Servlet and JSP engine -- core libraries
ii  tomcat9 9.0.43-2~deb11u3   all  Apache Tomcat 
9 - Servlet and JSP engine
ii  tomcat9-common 9.0.43-2~deb11u3   all Apache Tomcat 9 
- Servlet and JSP engine -- common files


And the log shows:

[2022-02-23 07:58:19] [info] Server version name:   Apache 
Tomcat/9.0.43 (Debian)
[2022-02-23 07:58:19] [info] Server built:  Jan 4 1970 
19:03:34 UTC

[2022-02-23 07:58:19] [info] Server version number: 9.0.43.0
[2022-02-23 07:58:19] [info] OS Name:   Linux
[2022-02-23 07:58:19] [info] OS Version: 4.19.0-8-amd64
[2022-02-23 07:58:19] [info] Architecture:  amd64
[2022-02-23 07:58:19] [info] Java Home: /usr/lib/jvm/java-8-oracle/jre
[2022-02-23 07:58:19] [info] JVM Version: 1.8.0_171-b11
[2022-02-23 07:58:19] [info] JVM Vendor:    Oracle Corporation
[2022-02-23 07:58:19] [info] CATALINA_BASE: /var/lib/tomcat9
[2022-02-23 07:58:19] [info] CATALINA_HOME: /usr/share/tomcat9
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.util.logging.config.file=/var/lib/tomcat9/conf/logging.properties
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.awt.headless=true
[2022-02-23 07:58:19] [info] Command line argument: 
-Djdk.tls.ephemeralDHKeySize=2048
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
[2022-02-23 07:58:19] [info] Command line argument: 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027
[2022-02-23 07:58:19] [info] Command line argument: 
-Dignore.endorsed.dirs=
[2022-02-23 07:58:19] [info] Command line argument: 
-Dcatalina.base=/var/lib/tomcat9
[2022-02-23 07:58:19] [info] Command line argument: 
-Dcatalina.home=/usr/share/tomcat9
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.io.tmpdir=/tmp
[2022-02-23 07:58:19] [info] The Apache Tomcat Native library which 
allows using OpenSSL was not found on the java.library.path: 
[/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib]
[2022-02-23 07:58:19] [crit] Failed to initialize component 
[Connector[org.apache.coyote.http11.Http11AprProtocol-443]]
[2022-02-23 07:58:19] [crit] org.apache.catalina.LifecycleException: 
The configured protocol [org.apache.coyote.http11.Http11AprProtocol] 
requires the APR/native library which is not available


Any idea why the native library, which was available before the 
upgrade, is not anymore available?


How can I diagnose the problem further?

Thanks,



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Native libraries not found?

2022-02-23 Thread i...@flyingfischer.ch

Am 23.02.22 um 09:12 schrieb Claude Brisson:

Hi.

After an upgrade from debian buster to debian bullseye, the APR native 
library stopped working:



Did you install libapr1 libapr1-dev libssl-dev before compiling?


Markus




# dpkg -l | ag tomcat
ii  libtcnative-1:amd64 1.2.26-1   amd64    
Tomcat native library using the Apache Portable Runtime
ii  libtomcat9-java 9.0.43-2~deb11u3   all  Apache 
Tomcat 9 - Servlet and JSP engine -- core libraries
ii  tomcat9 9.0.43-2~deb11u3   all  Apache Tomcat 
9 - Servlet and JSP engine
ii  tomcat9-common 9.0.43-2~deb11u3   all  Apache 
Tomcat 9 - Servlet and JSP engine -- common files


And the log shows:

[2022-02-23 07:58:19] [info] Server version name:   Apache 
Tomcat/9.0.43 (Debian)
[2022-02-23 07:58:19] [info] Server built:  Jan 4 1970 
19:03:34 UTC

[2022-02-23 07:58:19] [info] Server version number: 9.0.43.0
[2022-02-23 07:58:19] [info] OS Name:   Linux
[2022-02-23 07:58:19] [info] OS Version:    4.19.0-8-amd64
[2022-02-23 07:58:19] [info] Architecture:  amd64
[2022-02-23 07:58:19] [info] Java Home: /usr/lib/jvm/java-8-oracle/jre
[2022-02-23 07:58:19] [info] JVM Version:   1.8.0_171-b11
[2022-02-23 07:58:19] [info] JVM Vendor:    Oracle Corporation
[2022-02-23 07:58:19] [info] CATALINA_BASE: /var/lib/tomcat9
[2022-02-23 07:58:19] [info] CATALINA_HOME: /usr/share/tomcat9
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.util.logging.config.file=/var/lib/tomcat9/conf/logging.properties
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.awt.headless=true
[2022-02-23 07:58:19] [info] Command line argument: 
-Djdk.tls.ephemeralDHKeySize=2048
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
[2022-02-23 07:58:19] [info] Command line argument: 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027
[2022-02-23 07:58:19] [info] Command line argument: 
-Dignore.endorsed.dirs=
[2022-02-23 07:58:19] [info] Command line argument: 
-Dcatalina.base=/var/lib/tomcat9
[2022-02-23 07:58:19] [info] Command line argument: 
-Dcatalina.home=/usr/share/tomcat9

[2022-02-23 07:58:19] [info] Command line argument: -Djava.io.tmpdir=/tmp
[2022-02-23 07:58:19] [info] The Apache Tomcat Native library which 
allows using OpenSSL was not found on the java.library.path: 
[/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib]
[2022-02-23 07:58:19] [crit] Failed to initialize component 
[Connector[org.apache.coyote.http11.Http11AprProtocol-443]]
[2022-02-23 07:58:19] [crit] org.apache.catalina.LifecycleException: 
The configured protocol [org.apache.coyote.http11.Http11AprProtocol] 
requires the APR/native library which is not available


Any idea why the native library, which was available before the 
upgrade, is not anymore available?


How can I diagnose the problem further?

Thanks,



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Native libraries not found?

2022-02-23 Thread Claude Brisson

Hi.

After an upgrade from debian buster to debian bullseye, the APR native 
library stopped working:


# dpkg -l | ag tomcat
ii  libtcnative-1:amd64   1.2.26-1   amd64  
  Tomcat native library using the Apache Portable Runtime
ii  libtomcat9-java   9.0.43-2~deb11u3   all
  Apache Tomcat 9 - Servlet and JSP engine -- core libraries
ii  tomcat9   9.0.43-2~deb11u3   all
  Apache Tomcat 9 - Servlet and JSP engine
ii  tomcat9-common    9.0.43-2~deb11u3   all
  Apache Tomcat 9 - Servlet and JSP engine -- common files

And the log shows:

[2022-02-23 07:58:19] [info] Server version name:   Apache Tomcat/9.0.43 
(Debian)
[2022-02-23 07:58:19] [info] Server built:  Jan 4 1970 19:03:34 UTC
[2022-02-23 07:58:19] [info] Server version number: 9.0.43.0
[2022-02-23 07:58:19] [info] OS Name:   Linux
[2022-02-23 07:58:19] [info] OS Version:    4.19.0-8-amd64
[2022-02-23 07:58:19] [info] Architecture:  amd64
[2022-02-23 07:58:19] [info] Java Home: 
/usr/lib/jvm/java-8-oracle/jre
[2022-02-23 07:58:19] [info] JVM Version:   1.8.0_171-b11
[2022-02-23 07:58:19] [info] JVM Vendor:    Oracle Corporation
[2022-02-23 07:58:19] [info] CATALINA_BASE: /var/lib/tomcat9
[2022-02-23 07:58:19] [info] CATALINA_HOME: /usr/share/tomcat9
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.util.logging.config.file=/var/lib/tomcat9/conf/logging.properties
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
[2022-02-23 07:58:19] [info] Command line argument: -Djava.awt.headless=true
[2022-02-23 07:58:19] [info] Command line argument: 
-Djdk.tls.ephemeralDHKeySize=2048
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
[2022-02-23 07:58:19] [info] Command line argument: 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027
[2022-02-23 07:58:19] [info] Command line argument: -Dignore.endorsed.dirs=
[2022-02-23 07:58:19] [info] Command line argument: 
-Dcatalina.base=/var/lib/tomcat9
[2022-02-23 07:58:19] [info] Command line argument: 
-Dcatalina.home=/usr/share/tomcat9
[2022-02-23 07:58:19] [info] Command line argument: -Djava.io.tmpdir=/tmp
[2022-02-23 07:58:19] [info] The Apache Tomcat Native library which allows 
using OpenSSL was not found on the java.library.path: 
[/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib]
[2022-02-23 07:58:19] [crit] Failed to initialize component 
[Connector[org.apache.coyote.http11.Http11AprProtocol-443]]
[2022-02-23 07:58:19] [crit] org.apache.catalina.LifecycleException: The 
configured protocol [org.apache.coyote.http11.Http11AprProtocol] requires the 
APR/native library which is not available

Any idea why the native library, which was available before the upgrade, 
is not anymore available?


How can I diagnose the problem further?

Thanks,

--
Claude Brisson



Re: Configure Tomcat development using NetBeans IDE

2022-02-23 Thread Greg Huber

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