RE: [EXT]Re: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure
Thank you so much Mark for working with me on this issue!
I am taking your recommendation to create a webapps-javaee directory and
place my Tomcat 9 running war file into
that dir so that Tomcat does the compile correctly.
Only problem is that now I cannot figure out what is the correct URL path to my
servlet!
When I place the .war, the old way with the .war being in
webapps/transaction,my tomcat cat log says...
Deploying web application directory [C:\apache-tomcat-9.0.73\webapps\transaction
And I see my application at
C:\apache-tomcat-9.0.73\webapps\transaction\ROOT##0001
And I can hit my servlet via...
http://localhost:8588/XmlRpc
BUT when I place my .war in webapps-javaee\transaction the tomcat cat log
says..
Deploying web application directory
[C:\apache-tomcat-10.1.18\webapps-javaee\transaction\transaction
And I cannot hit either..
http://localhost:8588/XmlRpc
or
http://localhost:8588/transaction/XmlRpc
The creation of the
C:\apache-tomcat-10.1.18\webapps-javaee\transaction\transaction directory is
baffling me
See attached file
I expect only to see the creation of a
C:\apache-tomcat-10.1.18\webapps-javaee\transaction\ROOT##0001 directory.
That is where I believe my application to be
Here is how I have my context defined in server.xml..
Is my server.xml wrong?
When I place my .war in webapps-javaee\transaction dir?
-Original Message-
From: Mark Thomas
Sent: Thursday, February 8, 2024 5:45 PM
To: users@tomcat.apache.org
Subject: Re: [EXT]Re: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure
[You don't often get email from ma...@apache.org. Learn why this is important
at https://aka.ms/LearnAboutSenderIdentification ]
Confirmed this is user error. There is no bug in the migration tool.
Steps to demonstrate this:
- Create new, blank Eclipse dynamic web project
- Add provided servlet code
- Add required libraries
- Remove referenced to internal logging code
- Add web.xml with basic mapping to "/test"
- Export WAR file
- Deploy to Tomcat
- Start Tomcat
- Request servlet
Servlet loads and then reports an exception during init. That is fine.
It proves that the servlet was loaded which is all we care about at this point.
- Use migration tool to migrate WAR
- Deploy migrated WAR to Tomcat 10.1.x
- Start Tomcat
- Request servlet
Servlet loads and then reports an exception during init. Again, this is fine as
it proves that the Servlet has been converted correctly and can be loaded by
Tomcat 10.1.x.
Best guess, the Eclipse project isn't configured correctly to compile the web
application for Tomcat 10.1.x.
At this point the simplest solution is likely to be:
- take the WAR file that works on Tomcat 9
- drop in webapps-javaee in Tomcat 10 and let Tomcat convert it
automatically
Mark
On 08/02/2024 20:28, Rick Noel wrote:
> No I cannot compile from command line.
>
> But I do not really care how eclipse compiles my class anyway.
> All I know is that eclipse compiles the class without errors. Using
> the jars I tell it to. (all the jars run through the migration tool) But
> Tomcat 10 can not compile the class using those same migrated jar files.
>
> And my class has no use of javax.server classes in it.
> All the javax.server classes are only in the third part jar files
> which are supposed to have been converted to use jakarta.server
> classes
>
> Is this not a bug with Tomcat migration tool?
>
> Again here is my class that does not compile on Tomcat 10...
> It has no reference to javax.server
>
>
> package com.radiovoodoo.xmlrpc;
>
> import java.io.IOException;
> import java.net.MalformedURLException; import java.net.URL;
>
> import org.apache.xmlrpc.XmlRpcException;
> import org.apache.xmlrpc.XmlRpcRequest; import
> org.apache.xmlrpc.server.AbstractReflectiveHandlerMapping.Authenticati
> onHandler; import org.apache.xmlrpc.server.XmlRpcHandlerMapping;
> import org.apache.xmlrpc.server.PropertyHandlerMapping;
> import org.apache.xmlrpc.webserver.XmlRpcServlet;
>
> import com.radiovoodoo.util.Log;
>
> /**
> * @(#)RVXmlRpcServlet.java
> *
> * new XmlRpcServlet, which extends the default Apache XmlRpcServlet
> *
> * @author Hank Zill
> * @version 1.0
> *
> * Copyright(c) 2005 RadioVoodoo, Inc. All Rights Reserved.
> */
>
> public class RVXmlRpcServlet
> extends XmlRpcServlet
> {
> /**
> * this init parameter defines the path to the property file from
> * which to load the XML RPC handler mappings.
> *
> * the path is relative to the CLASSPATH
> */
> public static final String RESOURCE_PATH = "property-file-path";
>
> protected XmlRpcHandlerMapping newXmlRpcHandlerMapping()
>throws XmlRpcException
> {
>PropertyHandlerMapping mapping = null;
>
>/* String resourcePath = getInitParameter( RESOURCE_PATH );
>
>if ( resourcePath == null )
>{
> throw new XmlRpcException( "No property file defined. This
Long lasting websocket sessions
I've been experimenting with tomcat 9.x in seeing how long i can get a web socket session to last. I'm currently struggling to get past 30 minutes or so. Looking for guidance on how to best increase this or if this is a bad idea. Here's the current configuration and what i've tried thus far: The server continuously streams messages the client, about 1 per second The client periodically (every 30 seconds) sends a keep alive text message back to the server The server side endpoint sets the Session.setTimeout(0); according to the docs, this should prevent timeouts The server side WAR file/WEB-INF/web.xml had a session timeout defined at 15 minutes but i then removed it in order to increase the websocket duration. Despite all this, both the client and server log a session disconnect, but i'm still not sure what the reasoning is. I'm still assuming it's some kind of timeout mechanism.
R: Tomcat Instance unable to connect to DB with TCPS
Hello, it seems you have changed the default Java trust store, so you also need to provide its password. You should provide more info about your requirements: - server authentication only or client authentication too (mTLS in Oracle documentation)? - which version of ucp/ojdbc are you using (Oracle adds features over time)? In my experience if you only need server authentication and you are using driver version 11.2 or later, the only configuration required is: - change protocol and port in the URL or tnsnames.ora file - add the certificate of root (issuer) CA to Java trust store If you are using a Java version provided by RedHat then adding the certificate is simply as copying the certificate file to /usr/share/pki/ca-trust-source/anchors/ and run update-ca-trust [1]. If client authentication (mTLS) is required then you must prepare a wallet and add extra jars to your deployment [2]. Roberto [1] https://access.redhat.com/documentation/it-it/red_hat_enterprise_linux/7/html/security_guide/sec-shared-system-certificates [2] https://docs.oracle.com/en/database/oracle/oracle-database/19/jjdbc/client-side-security.html#GUID-2BD2F189-A58C-4A85-8524-CFD9BB9AC575 -Messaggio originale- Da: Mark Thomas Inviato: venerdì 9 febbraio 2024 10:09 A: users@tomcat.apache.org Oggetto: Re: Tomcat Instance unable to connect to DB with TCPS CAUTION - This e-mail originates outside of Dedalus. Be vigilant with content, links and attachments! On 09/02/2024 02:54, Kebret, Michael wrote: > Tomcat version 9.0.83 running on Linux redhat 7 java 11.0.20. > > When changing the protocol from TCP to TCPS in Catalina.properties and in > server.xml we have attribute truststorePassword= (tested with both cleartext > and encrypted) password connection is refused to the DB and get the below > exceptions. It isn't clear what configuration you are using. Please provide both the non-TLS and TLS configurations. > However, when we add -Djavax.net.ssl.trustStorePassword=cleartext to > setenv.sh the connection is made successfully. Wanted to see if anyone > has faced something similar or have any suggestions on how I can get > TCPS working without having to use -D option in setenv.sh My reading of [1] is that the property name is "javax.net.ssl.trustStorePassword" whether it is set as a connection property or as a system property. You seem to be using a connection property of "truststorePassword" which is a Tomcat property for HTTPS connections. Mark [1] https://www.oracle.com/docs/tech/wp-oracle-jdbc-thin-ssl.pdf - 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: Tomcat not syncing existing sessions on restart
On 09/02/2024 07:51, Manak Bisht wrote: On Fri, Feb 9, 2024 at 3:25 AM Mark Thomas wrote: Same JRE? Yes, 8.0.402 Generally, I wouldn't use 0.0.0.0, I'd use a specific IP address. I'm not sure how the clustering would behave with 0.0.0.0 Using 0.0.0.0 as the address for the receiver is going to cause problems. I see similar issues with 11.0.x as 8.5.x. I haven't dug too deeply into things as a) I am short of time and b) I'm not convinced this should/could work anyway. What seems to happen is that the use of 0.0.0.0 confuses the cluster as to which node is which - I think because multiple nodes are using 0.0.0.0. That causes the failure of the initial state synchronisation. That's the problem really. Using the DNS name or IP address causes the following error - I am as sure as I can be that the issue you are seeing is environmental. I have configured my test cluster with: - your cluster configuration with changes to host names and IP addresses - Java 8.0.402 - Tomcat 8.5.x With the Receiver using address="0.0.0.0" I see the same issues you do. I'm not yet convinced that is a bug. With the Receiver using address="hostname" the cluster starts but doesn't work. Examining the logs shows that is because the host name resolves to a loopback address. I'd class that as behaving as expected. I coudl always change the host's config if I wanted the name to resolve to the public IP. With the Receiver using address="ip-address" the cluster start and log messages show that cluster state is exchanged within a few milliseconds. That leads me to conclude that the BindException you see is a configuration and/or envornmental issue although I don't see why your simple test works but clustering doesn't. Perhaps a conflict with something else in your Tomcat configuration? Somethign to try is starting Tomcat with the Receiver using 0.0.0.0 and then using nestat to see which address/port combinations are being used. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Instance unable to connect to DB with TCPS
On 09/02/2024 02:54, Kebret, Michael wrote: Tomcat version 9.0.83 running on Linux redhat 7 java 11.0.20. When changing the protocol from TCP to TCPS in Catalina.properties and in server.xml we have attribute truststorePassword= (tested with both cleartext and encrypted) password connection is refused to the DB and get the below exceptions. It isn't clear what configuration you are using. Please provide both the non-TLS and TLS configurations. However, when we add -Djavax.net.ssl.trustStorePassword=cleartext to setenv.sh the connection is made successfully. Wanted to see if anyone has faced something similar or have any suggestions on how I can get TCPS working without having to use -D option in setenv.sh My reading of [1] is that the property name is "javax.net.ssl.trustStorePassword" whether it is set as a connection property or as a system property. You seem to be using a connection property of "truststorePassword" which is a Tomcat property for HTTPS connections. Mark [1] https://www.oracle.com/docs/tech/wp-oracle-jdbc-thin-ssl.pdf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
