Re: Tomcat not syncing existing sessions on restart

2024-02-08 Thread Manak Bisht
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
>
That's the problem really. Using the DNS name or IP address causes the
following error -

09-Feb-2024 13:08:32.440 SEVERE [main]
org.apache.catalina.startup.Catalina.start The required Server component
failed to start so Tomcat is unable to start.
 org.apache.catalina.LifecycleException: Failed to start component
[StandardServer[8006]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at org.apache.catalina.startup.Catalina.start(Catalina.java:625)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:351)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:485)
Caused by: org.apache.catalina.LifecycleException: Failed to start
component [StandardService[Catalina]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:760)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 7 more
Caused by: org.apache.catalina.LifecycleException: Failed to start
component [StandardEngine[Catalina]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:439)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 9 more
Caused by: org.apache.catalina.LifecycleException: Failed to start
component [org.apache.catalina.ha.tcp.SimpleTcpCluster[Catalina]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:902)
at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 11 more
Caused by: org.apache.catalina.LifecycleException:
org.apache.catalina.tribes.ChannelException: java.net.BindException: Cannot
assign requested address; No faulty members identified.
at
org.apache.catalina.ha.tcp.SimpleTcpCluster.startInternal(SimpleTcpCluster.java:549)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 14 more
Caused by: org.apache.catalina.tribes.ChannelException:
java.net.BindException: Cannot assign requested address; No faulty members
identified.
at
org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(ChannelCoordinator.java:184)
at
org.apache.catalina.tribes.group.ChannelCoordinator.start(ChannelCoordinator.java:102)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:155)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:155)
at
org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor.start(StaticMembershipInterceptor.java:108)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:155)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:155)
at
org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.start(TcpPingInterceptor.java:65)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:155)
at
org.apache.catalina.tribes.group.GroupChannel.start(GroupChannel.java:421)
at
org.apache.catalina.ha.tcp.SimpleTcpCluster.startInternal(SimpleTcpCluster.java:544)
... 15 more
Caused by: java.net.BindException: Cannot assign requested address
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
at
org.apache.catalina.tribes.transport.ReceiverBase.bind(ReceiverBase.java:184)
at
org.apache.catalina.tribes.transport.nio.NioReceiver.bind(NioReceiver.java:125)
at
org.apache.catalina.tribes.transport.nio.NioReceiver.start(NioReceiver.java:89)
at
org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(ChannelCoordinator.java:150)
... 25 more

The *host *attribute of the *member* element does not exhibit the same
problem.
The DNS/IP is also reachable via ping and telnet.
I even wrote a simple test to check this, and it works successfully -
java.net.InetAddress bind = java.net.InetAddress.getByName("tomcat");
System.out.println(bind); // Output: tomcat/ip

Sincerely,
Manak Bisht


Tomcat Instance unable to connect to DB with TCPS

2024-02-08 Thread Kebret, Michael
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. 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

java.sql.SQLException: Unable to start the Universal Connection Pool: 
oracle.ucp.UniversalConnectionPoolException: Cannot get Connection from 
Datasource: java.sql.SQLRecoverableException: IO Error: The Network Adapter 
could not establish
 the connection
at 
oracle.ucp.util.UCPErrorHandler.newSQLException(UCPErrorHandler.java:456)
at 
oracle.ucp.util.UCPErrorHandler.throwSQLException(UCPErrorHandler.java:133)
at 
oracle.ucp.jdbc.PoolDataSourceImpl.startPool(PoolDataSourceImpl.java:928)
at 
oracle.ucp.jdbc.PoolDataSourceImpl.getConnection(PoolDataSourceImpl.java:1961)
at 
oracle.ucp.jdbc.PoolDataSourceImpl.access$400(PoolDataSourceImpl.java:201)
at 
oracle.ucp.jdbc.PoolDataSourceImpl$31.build(PoolDataSourceImpl.java:4279)
at 
oracle.ucp.jdbc.PoolDataSourceImpl.getConnection(PoolDataSourceImpl.java:1917)
at 
oracle.ucp.jdbc.PoolDataSourceImpl.getConnection(PoolDataSourceImpl.java:1880)
at 
oracle.ucp.jdbc.PoolDataSourceImpl.getConnection(PoolDataSourceImpl.java:1865)
at 
com.wellsfargo.trust.SampleTrust.SampleTrust.doGet(SampleTrust.java:49)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:529)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:623)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:209)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153)
at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:178)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153)
at 
org.apache.catalina.filters.HttpHeaderSecurityFilter.doFilter(HttpHeaderSecurityFilter.java:129)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:178)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:168)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:90)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:481)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:130)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:93)
at 
org.apache.catalina.valves.StuckThreadDetectionValve.invoke(StuckThreadDetectionValve.java:185)
at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:670)
at 
org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:765)
at 
org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:355)
at 
org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java:54)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:390)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:928)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1794)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: oracle.ucp.UniversalConnectionPoolException: Cannot get Connection 
from Datasource: java.sql.SQLRecoverableException: IO Error: The Network 
Adapter could not establish the connection
at 
oracle.ucp.util.UCPErrorHandler.newUniversalConnectionPoolException(UCPErrorHandler.java:336)
at 

Re: Getting provider/properties from jaspic-providers.xml to my ServerAuthModule

2024-02-08 Thread Mark Thomas

On 08/02/2024 14:37, Ryan Esch wrote:

I'm using Tomcat 9. I have a provider in jaspic-providers.xml:





I am not sure how to get these properties to my
ServerAuthModule. I have a ServletContextListener and can see that the
jaspic-providers.xml file is being processed if I call:
AuthConfigFactory factory = AuthConfigFactory.getFactory()

It looks like
  I need to get the properties from the factory before calling:
factory.registerConfigProvider(
        new SimpleAuthConfigProvider(props, factory),
        "HttpServlet", null,
      "test");

I can't figure out how to get the properties from the
provider in the xml. If I hardcode the properties before passing them
into registerConfigProvider, the ServerAuthModule functions correctly.
Thanks!


You shouldn't need to call factory.registerConfigProvider() at all. That 
should happen automatically.


Are you sure the appContext is correct. The context path for the ROOT 
web application is "" (the empty string), not "/".


That would make the appContext "Catalina/localhost ".

Note that means it will only be applied to the ROOT web application.

Mark

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



Re: Persistent Manager Implementation Question

2024-02-08 Thread Mark Thomas

Try turning on ALL logging for the org.apache.catalina.session package.

Mark


On 08/02/2024 20:49, Miguel Vidal wrote:

  demo4.zip

Hello,

Specifications
Windows 10
Tomcat 8.5
this is a configuration question .
the tomcat specification that works :
https://tomcat.apache.org/tomcat-8.0-doc/config/manager.html

Im trying to configure correctly in 2 different applications : Persistent
Manager Implementation using a mysqldb as a datasource.

In one of them that is a legacy project i have some dependencies as


 org.springframework
 spring-core
 ${spring.framework.version}



 org.springframework
 spring-context
 ${spring.framework.version}


and it is already doing the registry of the sessions in my bd.
but in the other app im using a spring boot with the same configuration.
I'm not able to see any registration of the sessions in my db. After the
deploy of my app in a tomcat server and hit any resource example
/test/resource im able to see the response correctly but i just want to
know if this  Persistent Manager Implementation is only for legacy apps? or
why is running in one and in the other is not.

this is my xml for both




 
 
 

 
 jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.ConnectionState;
 org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer;
 org.apache.tomcat.jdbc.pool.interceptor.ResetAbandonedTimer"

these 2  are the guides where i learn the mayority how to do it
https://svn.apache.org/repos/asf/tomcat/archive/tc4.1.x/trunk/container/catalina/docs/JDBCStore-howto.html
https://gerrytan.wordpress.com/2013/08/21/tomcat-7-jdbc-session-persistence/

im going to attach the code that im trying to know why is not working.



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



Re: [EXT]Re: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

2024-02-08 Thread Mark Thomas

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.AuthenticationHandler;
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 servlet must have the 
init-param " + RESOURCE_PATH + " set." );
   } */
   String resourcePath = "somefile.properties";

   URL url = null;
  try {
url = getServletContext().getResource( resourcePath );
  } catch (MalformedURLException e1) {
throw new XmlRpcException( resourcePath + " " + e1 );
  }

   if (url == null)
   {
  throw new XmlRpcException("Failed to locate resource " + resourcePath 
);
   }
   try
   {
  mapping = newPropertyHandlerMapping(url);
   }
   catch (IOException e)
   {
  throw new XmlRpcException("Failed to load resource " + url + ": " + 
e.getMessage(), e);
   }

   if ( mapping == null )
  Log.debug( "HandlerMapping is null" );
   else
   {
  String[] methods = mapping.getListMethods();

  for ( int x = 0; x < methods.length; x++ )
  {
 Log.debug( "method: " + methods[x] );
  }
   }
   
   mapping.setAuthenticationHandler(new AuthenticationHandler() {

 //rick removed override annotaion so this class will compile on java 
1.5
//@Override
public boolean isAuthorized(XmlRpcRequest arg0) throws 
XmlRpcException {
return true;
}
   });

   return mapping;
}
}





Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Rob Sargent 
Sent: Thursday, February 8, 2024 1:54 PM
To: Tomcat Users List 
Subject: [EXT]Re: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

[You don't often get email from rsarg...@xmission.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]


On Feb 8, 2024, at 9:04 AM, Rick 

Re: Tomcat not syncing existing sessions on restart

2024-02-08 Thread Mark Thomas

On 07/02/2024 11:43, Manak Bisht wrote:

I think I have narrowed down the problem. For Tomcat 9 (v9.0.85), using
0.0.0.0 for the local member and receiver works fine. However, the same
does not work in Tomcat 8.5 (v8.5.98).


Same JRE?

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


Mark




Sincerely,
Manak Bisht


On Fri, Feb 2, 2024 at 9:41 PM Mark Thomas  wrote:


On 31/01/2024 13:33, Manak Bisht wrote:

I tried tweaking all the settings that I could think of but I am unable

to

sync sessions on restart even on a stock Tomcat 8.5.98 installation using
your provided war. I am unable to identify whether this is actually a bug
or something wrong with my configuration (this is far more likely). Could
you please share your server.xml? Did you make any other changes?

Sincerely,
Manak Bisht


Here is the cluster configuration from the first node my test environment:







  




  

  

  



  

  
  












-
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



Persistent Manager Implementation Question

2024-02-08 Thread Miguel Vidal
 demo4.zip

Hello,

Specifications
Windows 10
Tomcat 8.5
this is a configuration question .
the tomcat specification that works :
https://tomcat.apache.org/tomcat-8.0-doc/config/manager.html

Im trying to configure correctly in 2 different applications : Persistent
Manager Implementation using a mysqldb as a datasource.

In one of them that is a legacy project i have some dependencies as


org.springframework
spring-core
${spring.framework.version}



org.springframework
spring-context
${spring.framework.version}


and it is already doing the registry of the sessions in my bd.
but in the other app im using a spring boot with the same configuration.
I'm not able to see any registration of the sessions in my db. After the
deploy of my app in a tomcat server and hit any resource example
/test/resource im able to see the response correctly but i just want to
know if this  Persistent Manager Implementation is only for legacy apps? or
why is running in one and in the other is not.

this is my xml for both









jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.ConnectionState;
org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer;
org.apache.tomcat.jdbc.pool.interceptor.ResetAbandonedTimer"

these 2  are the guides where i learn the mayority how to do it
https://svn.apache.org/repos/asf/tomcat/archive/tc4.1.x/trunk/container/catalina/docs/JDBCStore-howto.html
https://gerrytan.wordpress.com/2013/08/21/tomcat-7-jdbc-session-persistence/

im going to attach the code that im trying to know why is not working.


RE: [EXT]Re: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

2024-02-08 Thread Rick Noel
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.AuthenticationHandler;
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 servlet 
must have the init-param " + RESOURCE_PATH + " set." );
  } */
  String resourcePath = "somefile.properties";

  URL url = null;
  try {
url = getServletContext().getResource( resourcePath );
  } catch (MalformedURLException e1) {
throw new XmlRpcException( resourcePath + " " + e1 );
  }

  if (url == null) 
  {
 throw new XmlRpcException("Failed to locate resource " + resourcePath 
);
  }
  try 
  {
 mapping = newPropertyHandlerMapping(url);
  } 
  catch (IOException e) 
  {
 throw new XmlRpcException("Failed to load resource " + url + ": " + 
e.getMessage(), e);
  }

  if ( mapping == null )
 Log.debug( "HandlerMapping is null" );
  else
  {
 String[] methods = mapping.getListMethods();

 for ( int x = 0; x < methods.length; x++ )
 {
Log.debug( "method: " + methods[x] );
 }
  }
  
  mapping.setAuthenticationHandler(new AuthenticationHandler() {
//rick removed override annotaion so this class will compile on java 1.5
//@Override
public boolean isAuthorized(XmlRpcRequest arg0) throws 
XmlRpcException {
return true;
}
  });

  return mapping;
   }
}





Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Rob Sargent  
Sent: Thursday, February 8, 2024 1:54 PM
To: Tomcat Users List 
Subject: [EXT]Re: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

[You don't often get email from rsarg...@xmission.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

> On Feb 8, 2024, at 9:04 AM, Rick Noel  wrote:
>
> I built  my app in Eclipse  and the build path is set to use the migrated 
> jar.
> It compiles without error on Eclipse and using the migrated jar.  I 
> have that same migrated jar in the Tomcat lib But when tomcat 10 
> compiles it does not compile
>
> I have also used the migration tool on my .war that runs in Tomcat 9 and that 
> war still fails with same compile error.
>
> So to summarize. the migration tool fails to convert third 
> party jar xmlrpc-server3.1.3.jar And it also fails when I use it on my .war 
> ran through the migration tool.
>
>
> Rick Noel
> Systems Programmer | Westwood One
> rn...@westwoodone.com
>

Can you build from the command  line?  Who knows what eclipse does under the 
covers
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you know the sender and you are sure the 
content is safe. Please report the message using the Report Message feature in 
your email client 

Re: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

2024-02-08 Thread Rob Sargent



> On Feb 8, 2024, at 9:04 AM, Rick Noel  wrote:
> 
> I built  my app in Eclipse  and the build path is set to use the migrated 
> jar.
> It compiles without error on Eclipse and using the migrated jar.  I have that 
> same migrated jar in the Tomcat lib
> But when tomcat 10 compiles it does not compile
> 
> I have also used the migration tool on my .war that runs in Tomcat 9 and that 
> war still fails with same compile error.
> 
> So to summarize. the migration tool fails to convert third party jar 
> xmlrpc-server3.1.3.jar
> And it also fails when I use it on my .war ran through the migration tool.
> 
> 
> Rick Noel
> Systems Programmer | Westwood One
> rn...@westwoodone.com
> 

Can you build from the command  line?  Who knows what eclipse does under the 
covers 
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

2024-02-08 Thread Rick Noel
I built  my app in Eclipse  and the build path is set to use the migrated jar.
It compiles without error on Eclipse and using the migrated jar.  I have that 
same migrated jar in the Tomcat lib
But when tomcat 10 compiles it does not compile

I have also used the migration tool on my .war that runs in Tomcat 9 and that 
war still fails with same compile error.

So to summarize. the migration tool fails to convert third party jar 
xmlrpc-server3.1.3.jar
And it also fails when I use it on my .war ran through the migration tool.


Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Mark Thomas  
Sent: Thursday, February 8, 2024 9:48 AM
To: users@tomcat.apache.org
Subject: 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 ]

On 08/02/2024 14:38, Rick Noel wrote:
> My code uses no javax.server  code other that what is in the third party jar.

Then you need to fix your build system that is compiling your code against the 
original xmlrpc-server3.1.3.jar rather than the migrated version.

> Is it not the third part jar that needs to stop using javax.server ?

No. It is the compiled form of your code that has the issue.

When you compile your class it retains a reference to the version of 
org.apache.xmlrpc.webserver.XmlRpcServlet that it was compiled against.
You can't just swap the xmlrpc-server3.1.3.jar at runtime. You have to use the 
migrated JAR at compile time as well.

Mark


>
> Where in my code does it use javax.server, other than from classes in package 
> org.apache.xmlrpc?
>
> 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 servlet 
> must have the init-param " + RESOURCE_PATH + " set." );
>} */
>String resourcePath = "/WEB-INF/somefile";
>
>URL url = null;
> try {
>   url = getServletContext().getResource( resourcePath );
> } catch (MalformedURLException e1) {
>   throw new XmlRpcException( resourcePath + " " + e1 );
> }
>
>if (url == null)
>{
>   throw new XmlRpcException("Failed to locate resource " + 
> resourcePath );
>}
>try
>{
>   mapping = newPropertyHandlerMapping(url);
>}
>catch (IOException e)
>{
>   throw new XmlRpcException("Failed to load resource " + url + ": " + 
> e.getMessage(), e);
>}
>
>if ( mapping == null )
>   Log.debug( "HandlerMapping is null" );
>else
>{
>   String[] methods = mapping.getListMethods();
>
>   for ( int x = 0; x < methods.length; x++ )
>   {
>  Log.debug( "method: " + methods[x] );
>   }
>}
>
>mapping.setAuthenticationHandler(new AuthenticationHandler() {
>  //rick removed override annotaion so this class will compile on java 
> 1.5
>   //@Override
>   public boolean isAuthorized(XmlRpcRequest arg0) throws 
> XmlRpcException {
>   return true;
>   }
>});
>
>return mapping;
> }
> }
> Rick Noel
> Systems Programmer | Westwood One
> rn...@westwoodone.com
>
> -Original Message-
> From: Mark Thomas 
> Sent: Thursday, February 8, 2024 9:27 AM
> To: users@tomcat.apache.org
> Subject: 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 

Re: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

2024-02-08 Thread Mark Thomas

On 08/02/2024 14:38, Rick Noel wrote:

My code uses no javax.server  code other that what is in the third party jar.


Then you need to fix your build system that is compiling your code 
against the original xmlrpc-server3.1.3.jar rather than the migrated 
version.



Is it not the third part jar that needs to stop using javax.server ?


No. It is the compiled form of your code that has the issue.

When you compile your class it retains a reference to the version of 
org.apache.xmlrpc.webserver.XmlRpcServlet that it was compiled against. 
You can't just swap the xmlrpc-server3.1.3.jar at runtime. You have to 
use the migrated JAR at compile time as well.


Mark




Where in my code does it use javax.server, other than from classes in package 
org.apache.xmlrpc?

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.AuthenticationHandler;
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 servlet must have the 
init-param " + RESOURCE_PATH + " set." );
   } */
   String resourcePath = "/WEB-INF/somefile";

   URL url = null;
  try {
url = getServletContext().getResource( resourcePath );
  } catch (MalformedURLException e1) {
throw new XmlRpcException( resourcePath + " " + e1 );
  }

   if (url == null)
   {
  throw new XmlRpcException("Failed to locate resource " + resourcePath 
);
   }
   try
   {
  mapping = newPropertyHandlerMapping(url);
   }
   catch (IOException e)
   {
  throw new XmlRpcException("Failed to load resource " + url + ": " + 
e.getMessage(), e);
   }

   if ( mapping == null )
  Log.debug( "HandlerMapping is null" );
   else
   {
  String[] methods = mapping.getListMethods();

  for ( int x = 0; x < methods.length; x++ )
  {
 Log.debug( "method: " + methods[x] );
  }
   }
   
   mapping.setAuthenticationHandler(new AuthenticationHandler() {

 //rick removed override annotaion so this class will compile on java 
1.5
//@Override
public boolean isAuthorized(XmlRpcRequest arg0) throws 
XmlRpcException {
return true;
}
   });

   return mapping;
}
}
Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Mark Thomas 
Sent: Thursday, February 8, 2024 9:27 AM
To: users@tomcat.apache.org
Subject: 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 ]

On 08/02/2024 14:17, Rick Noel wrote:

My class is RVXmlRpcServlet and below is the compile error that
happens when I use the xmlrpc-server3.1.3.jar after that jar has been
run through  the migration tool jakartaee-migration-1.0.7

That same class throws NO compile error on Tomcat 9 using
xmlrpc-server3.1.3.jar

Here is the compile error


The bug is your code. You need up update RVXmlRpcServlet to use 
jakarta.servlet.Servlet rather than javax.servlet.Servlet

Ditto for any other Java EE classes you have referenced in your code.

If you want your application to work with Tomcat 9 and Tomcat 10 I suggest you:

- write it for Tomcat 9
- package it as a WAR file
- process the entire WAR file with the migration tool
- use original WAR file with Tomcat 9 and the migrated WAR file with
Tomcat 10+

Mark



06-Feb-2024 15:48:53.044 SEVERE [http-nio-8588-exec-1] 
org.apache.catalina.core.StandardWrapperValve.invoke Allocate exception for 
servlet [XmlRpcServlet]
   java.lang.ClassCastException: class 
com.radiovoodoo.xmlrpc.RVXmlRpcServlet cannot be cast to 

RE: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

2024-02-08 Thread Rick Noel
My code uses no javax.server  code other that what is in the third party jar.
Is it not the third part jar that needs to stop using javax.server ? 

Where in my code does it use javax.server, other than from classes in package 
org.apache.xmlrpc?

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.AuthenticationHandler;
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 servlet 
must have the init-param " + RESOURCE_PATH + " set." );
  } */
  String resourcePath = "/WEB-INF/somefile";

  URL url = null;
  try {
url = getServletContext().getResource( resourcePath );
  } catch (MalformedURLException e1) {
throw new XmlRpcException( resourcePath + " " + e1 );
  }

  if (url == null) 
  {
 throw new XmlRpcException("Failed to locate resource " + resourcePath 
);
  }
  try 
  {
 mapping = newPropertyHandlerMapping(url);
  } 
  catch (IOException e) 
  {
 throw new XmlRpcException("Failed to load resource " + url + ": " + 
e.getMessage(), e);
  }

  if ( mapping == null )
 Log.debug( "HandlerMapping is null" );
  else
  {
 String[] methods = mapping.getListMethods();

 for ( int x = 0; x < methods.length; x++ )
 {
Log.debug( "method: " + methods[x] );
 }
  }
  
  mapping.setAuthenticationHandler(new AuthenticationHandler() {
//rick removed override annotaion so this class will compile on java 1.5
//@Override
public boolean isAuthorized(XmlRpcRequest arg0) throws 
XmlRpcException {
return true;
}
  });

  return mapping;
   }
}
Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Mark Thomas  
Sent: Thursday, February 8, 2024 9:27 AM
To: users@tomcat.apache.org
Subject: 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 ]

On 08/02/2024 14:17, Rick Noel wrote:
> My class is RVXmlRpcServlet and below is the compile error that 
> happens when I use the xmlrpc-server3.1.3.jar after that jar has been 
> run through  the migration tool jakartaee-migration-1.0.7
>
> That same class throws NO compile error on Tomcat 9 using 
> xmlrpc-server3.1.3.jar
>
> Here is the compile error

The bug is your code. You need up update RVXmlRpcServlet to use 
jakarta.servlet.Servlet rather than javax.servlet.Servlet

Ditto for any other Java EE classes you have referenced in your code.

If you want your application to work with Tomcat 9 and Tomcat 10 I suggest you:

- write it for Tomcat 9
- package it as a WAR file
- process the entire WAR file with the migration tool
- use original WAR file with Tomcat 9 and the migrated WAR file with
   Tomcat 10+

Mark

>
> 06-Feb-2024 15:48:53.044 SEVERE [http-nio-8588-exec-1] 
> org.apache.catalina.core.StandardWrapperValve.invoke Allocate exception for 
> servlet [XmlRpcServlet]
>   java.lang.ClassCastException: class 
> com.radiovoodoo.xmlrpc.RVXmlRpcServlet cannot be cast to class 
> jakarta.servlet.Servlet (com.radiovoodoo.xmlrpc.RVXmlRpcServlet is in unnamed 
> module of loader org.apache.catalina.loader.ParallelWebappClassLoader 
> @568750b7; jakarta.servlet.Servlet is in unnamed module of loader 
> java.net.URLClassLoader @18769467)
>   at 
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:865)
>   at 
> org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:649)
>   at 
> 

Getting provider/properties from jaspic-providers.xml to my ServerAuthModule

2024-02-08 Thread Ryan Esch
I'm using Tomcat 9. I have a provider in jaspic-providers.xml:
                I am not sure how to get these properties to my 
ServerAuthModule. I have a ServletContextListener and can see that the 
jaspic-providers.xml file is being processed if I call:
AuthConfigFactory factory = AuthConfigFactory.getFactory();It looks like I need 
to get the properties from the factory before calling:
factory.registerConfigProvider(        new SimpleAuthConfigProvider(props, 
factory),        "HttpServlet", null,        "test");I can't figure out how to 
get the properties from the provider in the xml. If I hardcode the properties 
before passing them into registerConfigProvider, the ServerAuthModule functions 
correctly.
Thanks!


Re: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

2024-02-08 Thread Mark Thomas

On 08/02/2024 14:17, Rick Noel wrote:

My class is RVXmlRpcServlet and below is the compile error that happens when I 
use the xmlrpc-server3.1.3.jar after that jar has been run through  the 
migration tool jakartaee-migration-1.0.7

That same class throws NO compile error on Tomcat 9 using xmlrpc-server3.1.3.jar

Here is the compile error


The bug is your code. You need up update RVXmlRpcServlet to use 
jakarta.servlet.Servlet rather than javax.servlet.Servlet


Ditto for any other Java EE classes you have referenced in your code.

If you want your application to work with Tomcat 9 and Tomcat 10 I 
suggest you:


- write it for Tomcat 9
- package it as a WAR file
- process the entire WAR file with the migration tool
- use original WAR file with Tomcat 9 and the migrated WAR file with
  Tomcat 10+

Mark



06-Feb-2024 15:48:53.044 SEVERE [http-nio-8588-exec-1] 
org.apache.catalina.core.StandardWrapperValve.invoke Allocate exception for 
servlet [XmlRpcServlet]
java.lang.ClassCastException: class 
com.radiovoodoo.xmlrpc.RVXmlRpcServlet cannot be cast to class 
jakarta.servlet.Servlet (com.radiovoodoo.xmlrpc.RVXmlRpcServlet is in unnamed 
module of loader org.apache.catalina.loader.ParallelWebappClassLoader 
@568750b7; jakarta.servlet.Servlet is in unnamed module of loader 
java.net.URLClassLoader @18769467)
at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:865)
at 
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:649)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:115)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:90)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:115)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:93)
at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:673)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:340)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:391)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:896)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1744)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:833)


Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Mark Thomas 
Sent: Thursday, February 8, 2024 8:54 AM
To: users@tomcat.apache.org
Subject: [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 ]

On 08/02/2024 13:45, Rick Noel wrote:

Our application uses classes in this jar xmlrpc-server3.1.3.jar .(it is the 
latest version)

We are trying to migrate to Tomcat 10 but that  jar uses the   javax.server. 
package classes instead of the needed  jakarta.server. pacakage.


I have tried running this jar trough the latest Tomcat 10 migration
tool (jakartaee-migration-1.0.7) which is suppose to alter the jar to
make all classes use  jakarta.server.  classes

but the tool is not fully converting all the classes,  since I still get 
compile errors at run time.


Please provide details of the compilation errors that you see.


I think in addition to not using  javax.server.  the jar should use
this class

java.net.URI  instead of   java.net.URL


That seems ... unlikely.


anyone have ideas on how to make xmlrpc-server3.1.3.jar  tomcat 10 compliant?


I'd be surprised if the migration tool didn't process a JAR that old correctly.

Mark



BTW the jar in question has classes in this package
org.apache.xmlrpc.

Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com




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

CAUTION: This email originated from outside of the 

RE: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

2024-02-08 Thread Rick Noel
My class is RVXmlRpcServlet and below is the compile error that happens when I 
use the xmlrpc-server3.1.3.jar after that jar has been run through  the 
migration tool jakartaee-migration-1.0.7

That same class throws NO compile error on Tomcat 9 using xmlrpc-server3.1.3.jar

Here is the compile error

06-Feb-2024 15:48:53.044 SEVERE [http-nio-8588-exec-1] 
org.apache.catalina.core.StandardWrapperValve.invoke Allocate exception for 
servlet [XmlRpcServlet]
java.lang.ClassCastException: class 
com.radiovoodoo.xmlrpc.RVXmlRpcServlet cannot be cast to class 
jakarta.servlet.Servlet (com.radiovoodoo.xmlrpc.RVXmlRpcServlet is in unnamed 
module of loader org.apache.catalina.loader.ParallelWebappClassLoader 
@568750b7; jakarta.servlet.Servlet is in unnamed module of loader 
java.net.URLClassLoader @18769467)
at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:865)
at 
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:649)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:115)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:90)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:115)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:93)
at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:673)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:340)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:391)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:896)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1744)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:833)


Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Mark Thomas  
Sent: Thursday, February 8, 2024 8:54 AM
To: users@tomcat.apache.org
Subject: [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 ]

On 08/02/2024 13:45, Rick Noel wrote:
> Our application uses classes in this jar xmlrpc-server3.1.3.jar .(it is 
> the latest version)
>
> We are trying to migrate to Tomcat 10 but that  jar uses the   javax.server. 
> package classes instead of the needed  jakarta.server. pacakage.
>
>
> I have tried running this jar trough the latest Tomcat 10 migration 
> tool (jakartaee-migration-1.0.7) which is suppose to alter the jar to 
> make all classes use  jakarta.server.  classes
>
> but the tool is not fully converting all the classes,  since I still get 
> compile errors at run time.

Please provide details of the compilation errors that you see.

> I think in addition to not using  javax.server.  the jar should use 
> this class
>
> java.net.URI  instead of   java.net.URL

That seems ... unlikely.

> anyone have ideas on how to make xmlrpc-server3.1.3.jar  tomcat 10 compliant?

I'd be surprised if the migration tool didn't process a JAR that old correctly.

Mark


> BTW the jar in question has classes in this package
> org.apache.xmlrpc.
>
> Rick Noel
> Systems Programmer | Westwood One
> rn...@westwoodone.com
>
>

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you know the sender and you are sure the 
content is safe. Please report the message using the Report Message feature in 
your email client if you believe the email is suspicious.


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



Re: jakartaee-migration-1.0.7 migration tool failure

2024-02-08 Thread Mark Thomas

On 08/02/2024 13:45, Rick Noel wrote:

Our application uses classes in this jar xmlrpc-server3.1.3.jar .(it is the 
latest version)

We are trying to migrate to Tomcat 10 but that  jar uses the   javax.server. 
package classes instead of the needed  jakarta.server. pacakage.


I have tried running this jar trough the latest Tomcat 10 migration tool 
(jakartaee-migration-1.0.7) which is suppose to alter the jar to make all 
classes use  jakarta.server.  classes

but the tool is not fully converting all the classes,  since I still get 
compile errors at run time.


Please provide details of the compilation errors that you see.


I think in addition to not using  javax.server.  the jar should use this class

java.net.URI  instead of   java.net.URL


That seems ... unlikely.


anyone have ideas on how to make xmlrpc-server3.1.3.jar  tomcat 10 compliant?


I'd be surprised if the migration tool didn't process a JAR that old 
correctly.


Mark



BTW the jar in question has classes in this package
org.apache.xmlrpc.

Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com




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



jakartaee-migration-1.0.7 migration tool failure

2024-02-08 Thread Rick Noel
Our application uses classes in this jar xmlrpc-server3.1.3.jar .(it is the 
latest version)

We are trying to migrate to Tomcat 10 but that  jar uses the   javax.server. 
package classes instead of the needed  jakarta.server. pacakage.


I have tried running this jar trough the latest Tomcat 10 migration tool 
(jakartaee-migration-1.0.7) which is suppose to alter the jar to make all 
classes use  jakarta.server.  classes

but the tool is not fully converting all the classes,  since I still get 
compile errors at run time.


I think in addition to not using  javax.server.  the jar should use this class

java.net.URI  instead of   java.net.URL


anyone have ideas on how to make xmlrpc-server3.1.3.jar  tomcat 10 compliant?

BTW the jar in question has classes in this package
org.apache.xmlrpc.

Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com