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

[Mark Thomas]

On 09/02/2024 16:26, Rick Noel wrote:

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


That is all very non-standard.

What I would expect to see is:

foo.war deployed to $CATALINA_BASE/webapps/foo.war and then accessed at 
http://localhost:port/foo


In server.xml what do you have configured for the Host's appBase ? Is it 
"webapps/transaction" ?


Mark




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()

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

[Rick Noel]

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

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

[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. L

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

[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 

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

[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

[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;
>   }
>});
>
>  

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

[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 [XmlRpcSer

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

[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)
> 

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

[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

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

[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

[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

[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

Re: Jakarta migration issue in Tomcat 10.1.12 with Java 11

[Mark Thomas]

28 Sept 2023 03:22:26 Muralisankar Srinivasan :


Dear Users,
I am facing the following Exceptions from the Java Maven application 
which
is migrated from Javax to Jakarta, using "jakartaee-migration-1.0.7". 
The

application was successful in "Apache Tomcat Version 9.0.64".

Please suggest the dependencies to be added in pom.xml for resolving 
these

issues. The current environment is " Apache Tomcat Version 10.1.12" and
"jdk-11.0.2".


Editing the pom isn't going to fix this.

What command did you use to convert your Java EE 8 war file that works 
with Tomcat 9 before you tried deploying it on Tomcat 10?


I suspect you need to use the EE profile rather than the Tomcat profile.

Mark




*XMLNS:*
*sub-jaxws.xml:* http://java.sun.com/xml/ns/jax-ws/ri/runtime;>

*web.xml:* http://xmlns.jcp.org/xml/ns/javaee; 
xmlns:xsi="

http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="

http://xmlns.jcp.org/xml/ns/javaee;http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd;
version="3.1">

*web.xml: *

com.sun.xml.ws.transport.http.servlet.WSServletContextListener

*web.xml:*
  
com.sun.xml.ws.transport.http.servlet.WSServlet



*Exceptions:*
1. jakarta.servlet.ServletException:
com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11:
failed to parse runtime descriptor: A WebService annotation is not 
present

on class:

2. jakarta.servlet.ServletException:
com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11:
failed to parse runtime descriptor: java.lang.NoSuchMethodError:

com.sun.xml.ws.api.WSBinding.getFeature(Ljava/lang/Class;)Ljavax/xml/ws/WebServiceFeature;

3. jakarta.servlet.ServletException:
com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11:
failed to parse runtime descriptor: java.lang.NoSuchMethodError:

com.sun.xml.ws.security.impl.policy.EncryptedParts.hasNestedAssertions()Z

4. jakarta.servlet.ServletException:
com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11:
failed to parse runtime descriptor: java.lang.NoSuchMethodError:

com.sun.xml.ws.security.impl.policy.ValidatorConfiguration.getNestedAssertionsIterator()Ljava/util/Iterator;

--
Regards,
Muralisankar Srinivasan


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

Jakarta migration issue in Tomcat 10.1.12 with Java 11

[Muralisankar Srinivasan]

Dear Users,
I am facing the following Exceptions from the Java Maven application which
is migrated from Javax to Jakarta, using "jakartaee-migration-1.0.7". The
application was successful in "Apache Tomcat Version 9.0.64".

Please suggest the dependencies to be added in pom.xml for resolving these
issues. The current environment is " Apache Tomcat Version 10.1.12" and
"jdk-11.0.2".

*XMLNS:*
*sub-jaxws.xml:* http://java.sun.com/xml/ns/jax-ws/ri/runtime;>

*web.xml:* http://xmlns.jcp.org/xml/ns/javaee; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
http://xmlns.jcp.org/xml/ns/javaee;http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd;
version="3.1">

*web.xml: *
com.sun.xml.ws.transport.http.servlet.WSServletContextListener

*web.xml:*
  com.sun.xml.ws.transport.http.servlet.WSServlet


*Exceptions:*
1. jakarta.servlet.ServletException:
com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11:
failed to parse runtime descriptor: A WebService annotation is not present
on class:

2. jakarta.servlet.ServletException:
com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11:
failed to parse runtime descriptor: java.lang.NoSuchMethodError:
com.sun.xml.ws.api.WSBinding.getFeature(Ljava/lang/Class;)Ljavax/xml/ws/WebServiceFeature;

3. jakarta.servlet.ServletException:
com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11:
failed to parse runtime descriptor: java.lang.NoSuchMethodError:
com.sun.xml.ws.security.impl.policy.EncryptedParts.hasNestedAssertions()Z

4. jakarta.servlet.ServletException:
com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11:
failed to parse runtime descriptor: java.lang.NoSuchMethodError:
com.sun.xml.ws.security.impl.policy.ValidatorConfiguration.getNestedAssertionsIterator()Ljava/util/Iterator;

-- 
Regards,
Muralisankar Srinivasan

[ANN] Apache Tomcat Migration tool for Jakarta EE 1.0.6

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Migration Tool for Jakarta EE 1.0.6

Apache Tomcat Migration Tool for Jakarta EE is an open source software
tool for migrating binary web applications (WAR files) and other binary
artifacts from Java EE 8 to Jakarta EE 9.

The notable changes since 1.0.5 include:

- Correct regression in handling of javax.annotation package introduced
  in 1.0.5. PR provided by Danny Thomas.

- Allow parallel use of ClassConverter. PR provided by Danny Thomas.


Please refer to the change log for the complete list of changes:
https://github.com/apache/tomcat-jakartaee-migration/blob/master/CHANGES.md

Downloads:
http://tomcat.apache.org/download-migration.cgi

Enjoy!

- The Apache Tomcat team


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

[ANN] Apache Tomcat Migration tool for Jakarta EE 1.0.5

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Migration Tool for Jakarta EE 1.0.5

Apache Tomcat Migration Tool for Jakarta EE is an open source software
tool for migrating binary web applications (WAR files) and other binary
artefacts from Java EE 8 to Jakarta EE 9.

The notable changes since 1.0.4 include:

- Narrow scope of javax.annotation conversion to Java EE. Pull request
  by Danny Thomas
- Improve manifest handling and conversion performance. Pull request by
  Danny Thomas.


Please refer to the change log for the complete list of changes:
https://github.com/apache/tomcat-jakartaee-migration/blob/master/CHANGES.md

Downloads:
http://tomcat.apache.org/download-migration.cgi

Enjoy!

- The Apache Tomcat team


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

[ANN] Apache Tomcat Migration tool for Jakarta EE 1.0.4

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Migration Tool for Jakarta EE 1.0.4

Apache Tomcat Migration Tool for Jakarta EE is an open source software
tool for migrating binary web applications (WAR files) and other binary
artefacts from Java EE 8 to Jakarta EE 9.

The notable changes since 1.0.3 include:

- Improve the fix converting web applications that include JARs that
  store one or more entries in uncompressed form

- Add a new conversion profile that converts from Jakarta EE 9 to Java
  EE 8

Please refer to the change log for the complete list of changes:
https://github.com/apache/tomcat-jakartaee-migration/blob/master/CHANGES.md

Downloads:
http://tomcat.apache.org/download-migration.cgi

Enjoy!

- The Apache Tomcat team


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

[ANN] Apache Tomcat Migration tool for Jakarta EE 1.0.3

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Migration Tool for Jakarta EE 1.0.3

Apache Tomcat Migration Tool for Jakarta EE is an open source software
tool for migrating binary web applications (WAR files) and other binary
artefacts from Java EE 8 to Jakarta EE 9.

The notable changes since 1.0.1 include:

- Update checksums for modified files to avoid issues when trying to use
  migrated JAR files
- Handle migration of manifest files when part of an exploded JAR


Please refer to the change log for the complete list of changes:
https://github.com/apache/tomcat-jakartaee-migration/blob/master/CHANGES.md

Downloads:
http://tomcat.apache.org/download-migration.cgi

Enjoy!

- The Apache Tomcat team


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

[ANN] Apache Tomcat Migration tool for Jakarta EE 1.0.1

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Migration Tool for Jakarta EE 1.0.1

Apache Tomcat Migration Tool for Jakarta EE is an open source software
tool for migrating binary web applications (WAR files) and other binary
artefacts from Java EE 8 to Jakarta EE 9.

The notable changes since 1.0.0 include:

- Add support for .groovy files

- Better support for non-standard archives

- Numerous library updates

Please refer to the change log for the complete list of changes:
https://github.com/apache/tomcat-jakartaee-migration/blob/master/CHANGES.md

Downloads:
http://tomcat.apache.org/download-migration.cgi

Enjoy!

- The Apache Tomcat team


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

RE: Automated migration for Tomcat 9 to 10

[Chetna Agrawal]

Hi,

This is a follow-up mail. Please help with the below issue.

Regards,
Chetna Agrawal

-Original Message-
From: Chetna Agrawal 
Sent: 28 April 2022 17:35
To: users@tomcat.apache.org
Subject: Automated migration for Tomcat 9 to 10

Hi,

I want to migrate my webapp from Java EE8 to Jakarta EE 9 in order to run it on 
tomcat 10.0.18. I am trying to run jakartaee migration tool at runtime by 
adding - , in  my context defined in 
server.xml. The tomcat version that I am using is 10.0.18. I am providing the 
value of path as /chetna and docbase as absolute path to my webapp's folder. On 
starting Tomcat, it is running fine and is not giving any error in logs but 
seems like it is not able to access my webapp folder. When trying to hit url - 
https://localhost/chetna, it is giving error 404. While when I run migration 
tool on my webapp explicitly and then use that migrated webapp's path in 
docbase, my app is running fine.

In changelog of Tomcat 10.0.3, it is given that - Allow the loader to directly 
use the Tomcat Migration Tool for JakartaEE as a ClassFileTransformer using the 
jakartaConverter attribute. This only supports javax to jakarta conversion for 
classes, not for classloader resources or static files.

Is there a way I can migrate my webapp at runtime while running it on tomcat 
10. Please let me know if I am doing something wrong in this method.

Regards,
Chetna Agrawal
Disclaimer: The information in this email is strictly confidential and may be 
legally privileged. If you are not the intended recipient, any use of this 
email or the information contained therein or disclosure or any action taken or 
omissions made including but not limited to copying, distribution or placing 
reliance on it, is expressly prohibited and may be unlawful. This email is 
intended solely for the addressee, access to this email by anyone else is 
unauthorized, the recipient is requested to notify Seclore and delete this 
email from their system immediately.
Disclaimer: The information in this email is strictly confidential and may be 
legally privileged. If you are not the intended recipient, any use of this 
email or the information contained therein or disclosure or any action taken or 
omissions made including but not limited to copying, distribution or placing 
reliance on it, is expressly prohibited and may be unlawful. This email is 
intended solely for the addressee, access to this email by anyone else is 
unauthorized, the recipient is requested to notify Seclore and delete this 
email from their system immediately.

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

Automated migration for Tomcat 9 to 10

[Chetna Agrawal]

Hi,

I want to migrate my webapp from Java EE8 to Jakarta EE 9 in order to run it on 
tomcat 10.0.18. I am trying to run jakartaee migration tool at runtime by 
adding - , in  my context defined in 
server.xml. The tomcat version that I am using is 10.0.18. I am providing the 
value of path as /chetna and docbase as absolute path to my webapp's folder. On 
starting Tomcat, it is running fine and is not giving any error in logs but 
seems like it is not able to access my webapp folder. When trying to hit url - 
https://localhost/chetna, it is giving error 404. While when I run migration 
tool on my webapp explicitly and then use that migrated webapp's path in 
docbase, my app is running fine.

In changelog of Tomcat 10.0.3, it is given that -
Allow the loader to directly use the Tomcat Migration Tool for JakartaEE as a 
ClassFileTransformer using the jakartaConverter attribute. This only supports 
javax to jakarta conversion for classes, not for classloader resources or 
static files.

Is there a way I can migrate my webapp at runtime while running it on tomcat 
10. Please let me know if I am doing something wrong in this method.

Regards,
Chetna Agrawal
Disclaimer: The information in this email is strictly confidential and may be 
legally privileged. If you are not the intended recipient, any use of this 
email or the information contained therein or disclosure or any action taken or 
omissions made including but not limited to copying, distribution or placing 
reliance on it, is expressly prohibited and may be unlawful. This email is 
intended solely for the addressee, access to this email by anyone else is 
unauthorized, the recipient is requested to notify Seclore and delete this 
email from their system immediately.

Re: Migration JDK11 - Tomcat 9 - NoClassDefFoundError: java/sql/Statement

[Rob Sargent]

On 3/29/22 10:54, Senguttuvan, Gopalakrishnan (CWM-NR) wrote:

Hi Thomas,

Thanks for the response.
This issue occurred when I have start the Tomcat server in Linux-QA machine.


Regards,
Gopalakrishnan S


Double check your runtime environment - something there is out of whack 
I suspect.


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

RE: Migration JDK11 - Tomcat 9 - NoClassDefFoundError: java/sql/Statement

[Senguttuvan, Gopalakrishnan (CWM-NR)]

Hi Thomas,

Thanks for the response.
This issue occurred when I have start the Tomcat server in Linux-QA machine.


Regards,
Gopalakrishnan S

-Original Message-


From: Thomas Hoffmann (Speed4Trade GmbH) 
[mailto:thomas.hoffm...@speed4trade.com.INVALID] 
Sent: March 26, 22 1:39 AM
To: Tomcat Users List 
Subject: AW: Migration JDK11 - Tomcat 9 - NoClassDefFoundError: 
java/sql/Statement

[External]<https://connect.fg.rbc.com/community/techhub/external-email-indicator>

Hello,
does this error show up in IntelliJ ?
Seems like there is a bug in IntelliJ:
https://stackoverflow.com/questions/52981800/getting-noclassfoundexception-java-sql-sqlexception-in-intellij-idea-for-jdk-1

java.sql.statement is shipped with Java 11.

Greetings,
Thomsa

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

> -Ursprüngliche Nachricht-
> Von: Senguttuvan, Gopalakrishnan (CWM-NR) 
> 
> Gesendet: Freitag, 25. März 2022 17:13
> An: users@tomcat.apache.org
> Betreff: Migration JDK11 - Tomcat 9 - NoClassDefFoundError:
> java/sql/Statement
>
> Hi Team,
>
> We are migrating our application from JDK8 to JDK11 (RedHat OpenJDK11).
> Modified the JAVA_HOME to JDK11 path.
> Currently we are using Tomcat version 9. (It is working fine with JDK8).
> Since the JDK11 won't support the JAVA_ENDORSED_DIRS, so I have 
> removed the "-Djava.endorsed.dirs" in catalina.sh.
>
> Once removed endorsed entry, got the below exception while start the
> application:
> java.lang.NoClassDefFoundError: java/sql/Statement
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.close(U
> TF
> 8Reader.java)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLEntityManager.clos
> eR
> eaders(XMLEntityManager.java:1452)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration
> .cl
> eanup(XML11Configuration.java:803)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration
> .p
> arse(XML11Configuration.java:844)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XM
> L
> Parser.java:141)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.
> par
> se(AbstractSAXParser.java:1216)
> at
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAX
> P
> arser.parse(SAXParserImpl.java:635)
> at 
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1517)
> at
> org.apache.catalina.startup.Catalina.parseServerXml(Catalina.java:584)
> at 
> org.apache.catalina.startup.Catalina.load(Catalina.java:675)
> at 
> org.apache.catalina.startup.Catalina.load(Catalina.java:712)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeM
> et
> hodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Del
> ega
> tingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at 
> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:302)
> at
> org.apache.catalina.startup.Bootstrap.mainStatement(Bootstrap.java:472
> ) Exception in thread "Thread-0" java.lang.NoClassDefFoundError:
> java/sql/Statement
> at java.base/java.io.PrintWriter.close(PrintWriter.java)
> at 
> org.apache.juli.FileHandler.closeWriter(FileHandler.java:339)
> at org.apache.juli.FileHandler.close(FileHandler.java:327)
> at
> org.apache.juli.ClassLoaderLogManager.resetLoggers(ClassLoaderLogManag
> er.java:397)
> at
> org.apache.juli.ClassLoaderLogManager.shutdown(ClassLoaderLogManager.j
> ava:376)
> at
> org.apache.juli.ClassLoaderLogManager$Cleaner.run(ClassLoaderLogManage
> r.java:80)
>
>
> Kindly help us to resolve this issue and let me know if you need any 
> further details.
>
>
>
>
> Regards,
> Gopalakrishnan S
>

__ This 
email is intended only for the use of the individual(s) to whom it is addressed 
and may be privileged and confidential. Unauthorised use or disclosure is 
prohibited. If you receive this e-mail in error, please advise immediately and 
delete the original message. This message 

AW: Migration JDK11 - Tomcat 9 - NoClassDefFoundError: java/sql/Statement

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Senguttuvan, Gopalakrishnan (CWM-NR)
> 
> Gesendet: Freitag, 25. März 2022 17:13
> An: users@tomcat.apache.org
> Betreff: Migration JDK11 - Tomcat 9 - NoClassDefFoundError:
> java/sql/Statement
> 
> Hi Team,
> 
> We are migrating our application from JDK8 to JDK11 (RedHat OpenJDK11).
> Modified the JAVA_HOME to JDK11 path.
> Currently we are using Tomcat version 9. (It is working fine with JDK8).
> Since the JDK11 won't support the JAVA_ENDORSED_DIRS, so I have
> removed the "-Djava.endorsed.dirs" in catalina.sh.
> 
> Once removed endorsed entry, got the below exception while start the
> application:
> java.lang.NoClassDefFoundError: java/sql/Statement
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.close(UTF
> 8Reader.java)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLEntityManager.closeR
> eaders(XMLEntityManager.java:1452)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.cl
> eanup(XML11Configuration.java:803)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.p
> arse(XML11Configuration.java:844)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XML
> Parser.java:141)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.par
> se(AbstractSAXParser.java:1216)
> at
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXP
> arser.parse(SAXParserImpl.java:635)
> at 
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1517)
> at
> org.apache.catalina.startup.Catalina.parseServerXml(Catalina.java:584)
> at 
> org.apache.catalina.startup.Catalina.load(Catalina.java:675)
> at 
> org.apache.catalina.startup.Catalina.load(Catalina.java:712)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet
> hodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega
> tingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at 
> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:302)
> at
> org.apache.catalina.startup.Bootstrap.mainStatement(Bootstrap.java:472)
> Exception in thread "Thread-0" java.lang.NoClassDefFoundError:
> java/sql/Statement
> at java.base/java.io.PrintWriter.close(PrintWriter.java)
> at 
> org.apache.juli.FileHandler.closeWriter(FileHandler.java:339)
> at org.apache.juli.FileHandler.close(FileHandler.java:327)
> at
> org.apache.juli.ClassLoaderLogManager.resetLoggers(ClassLoaderLogManag
> er.java:397)
> at
> org.apache.juli.ClassLoaderLogManager.shutdown(ClassLoaderLogManager.j
> ava:376)
> at
> org.apache.juli.ClassLoaderLogManager$Cleaner.run(ClassLoaderLogManage
> r.java:80)
> 
> 
> Kindly help us to resolve this issue and let me know if you need any further
> details.
> 
> 
> 
> 
> Regards,
> Gopalakrishnan S
> 

Hello,
does this error show up in IntelliJ ?
Seems like there is a bug in IntelliJ:
https://stackoverflow.com/questions/52981800/getting-noclassfoundexception-java-sql-sqlexception-in-intellij-idea-for-jdk-1

java.sql.statement is shipped with Java 11.

Greetings,
Thomsa

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

Migration JDK11 - Tomcat 9 - NoClassDefFoundError: java/sql/Statement

[Senguttuvan, Gopalakrishnan (CWM-NR)]

Hi Team,

We are migrating our application from JDK8 to JDK11 (RedHat OpenJDK11).
Modified the JAVA_HOME to JDK11 path.
Currently we are using Tomcat version 9. (It is working fine with JDK8).
Since the JDK11 won't support the JAVA_ENDORSED_DIRS, so I have removed the 
"-Djava.endorsed.dirs" in catalina.sh.

Once removed endorsed entry, got the below exception while start the 
application:
java.lang.NoClassDefFoundError: java/sql/Statement
at 
java.xml/com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.close(UTF8Reader.java)
at 
java.xml/com.sun.org.apache.xerces.internal.impl.XMLEntityManager.closeReaders(XMLEntityManager.java:1452)
at 
java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.cleanup(XML11Configuration.java:803)
at 
java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:844)
at 
java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at 
java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
at 
java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
at 
org.apache.tomcat.util.digester.Digester.parse(Digester.java:1517)
at 
org.apache.catalina.startup.Catalina.parseServerXml(Catalina.java:584)
at org.apache.catalina.startup.Catalina.load(Catalina.java:675)
at org.apache.catalina.startup.Catalina.load(Catalina.java:712)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:302)
at 
org.apache.catalina.startup.Bootstrap.mainStatement(Bootstrap.java:472)
Exception in thread "Thread-0" java.lang.NoClassDefFoundError: 
java/sql/Statement
at java.base/java.io.PrintWriter.close(PrintWriter.java)
at org.apache.juli.FileHandler.closeWriter(FileHandler.java:339)
at org.apache.juli.FileHandler.close(FileHandler.java:327)
at 
org.apache.juli.ClassLoaderLogManager.resetLoggers(ClassLoaderLogManager.java:397)
at 
org.apache.juli.ClassLoaderLogManager.shutdown(ClassLoaderLogManager.java:376)
at 
org.apache.juli.ClassLoaderLogManager$Cleaner.run(ClassLoaderLogManager.java:80)


Kindly help us to resolve this issue and let me know if you need any further 
details.




Regards,
Gopalakrishnan S


__ This 
email is intended only for the use of the individual(s) to whom it is addressed 
and may be privileged and confidential. Unauthorised use or disclosure is 
prohibited. If you receive this e-mail in error, please advise immediately and 
delete the original message. This message may have been altered without your or 
our knowledge and the sender does not accept any liability for any errors or 
omissions in the message. Emails are monitored by supervisory personnel in 
jurisdictions where monitoring is permitted. Such communications are retained 
and may be produced to regulatory authorities or others with legal rights to 
the information. Please see link for RBCCM disclosures. 
https://www.rbccm.com/rbccm/policies-disclaimers.page

[ANN] Apache Tomcat Migration tool for Jakarta EE 1.0.0

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Migration Tool for Jakarta EE 1.0.0

Apache Tomcat Migration Tool for Jakarta EE is an open source software
tool for migrating binary web applications (WAR files) and other binary
artefacts from Java EE 8 to Jakarta EE 9.

The notable changes since 0.2.0 include:

- Further fixes to exclude javax.xml packages that are not part of
  Java EE from the migration

- The class transformer now validates that the target classes in the
  Jakarta namespace exist in the runtime environment

Please refer to the change log for the complete list of changes:
https://github.com/apache/tomcat-jakartaee-migration/blob/master/CHANGES.md

Downloads:
http://tomcat.apache.org/download-migration.cgi

Enjoy!

- The Apache Tomcat team


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

[ANN] Apache Tomcat Migration tool for Jakarta EE 0.2.0

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Migration Tool for Jakarta EE 0.2.0

Apache Tomcat Migration Tool for Jakarta EE is an open source software
tool for migrating binary web applications (WAR files) and other binary
artefacts from Java EE 8 to Jakarta EE 9.

The notable changes since 0.1.0 include:

- Various fixes to the packages that are and are not converted

- A new option to process zip archives in memory to support zip files
  that use options that are incompatible with a streaming approach

- A new option to exclude files from transformation

Please refer to the change log for the complete list of changes:
https://github.com/apache/tomcat-jakartaee-migration/blob/master/CHANGES.md

Downloads:
http://tomcat.apache.org/download-migration.cgi

Enjoy!

- The Apache Tomcat team


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

Re: 10. migration doc flaw

[Rob Sargent]

> On Feb 9, 2021, at 1:25 AM, Mark Thomas  wrote:
> 
> On 08/02/2021 23:40, Rob Sargent wrote:
>> Well, it the 9->10 page, but that form generator is all about
>> 10.x->10.y  (Not sure it's doing anything useful either?)
> 
> Copy/paste error. Fixed now. Thanks for reporting this.
> 
> The configuration difference generator is working but the files haven't
> changed much. Look at server.xml between 10.0.0-M1 and 10.0.2 for an
> example where you will see output.
> 
> Mark
> 
I think it throws an error on a zero diff compare?
Far from urgent. 
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: 10. migration doc flaw

[Mark Thomas]

On 08/02/2021 23:40, Rob Sargent wrote:
> Well, it the 9->10 page, but that form generator is all about
> 10.x->10.y  (Not sure it's doing anything useful either?)

Copy/paste error. Fixed now. Thanks for reporting this.

The configuration difference generator is working but the files haven't
changed much. Look at server.xml between 10.0.0-M1 and 10.0.2 for an
example where you will see output.

Mark

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

Re: 10. migration doc flaw

[Rob Sargent]

Well, it the 9->10 page, but that form generator is all about 
10.x->10.y  (Not sure it's doing anything useful either?)



On 2/8/21 4:35 PM, Rob Sargent wrote:

I think there's an error on this page:

   http://tomcat.apache.org/migration-10.html


First paragraph under "Upgrading 10.0.x"

   When upgrading instances of Apache Tomcat from one version of
   _Tomcat 9 _to another, particularly when using separate

Which confused me because I was looking for 9.0 to 10.0 instrux, but 
this isn't the page for that, I don't think.

10. migration doc flaw

[Rob Sargent]

I think there's an error on this page:

   http://tomcat.apache.org/migration-10.html


First paragraph under "Upgrading 10.0.x"

   When upgrading instances of Apache Tomcat from one version of
   _Tomcat 9 _to another, particularly when using separate

Which confused me because I was looking for 9.0 to 10.0 instrux, but 
this isn't the page for that, I don't think.

Re: Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lavitesh,

On 6/22/20 07:12, Lavitesh Verma wrote:
> We didn’t use woodstox previously in our application and after we
> updated tomcat to version 8.5.5 we are getting this issue.
>
> We were able to resolve the issue by adding “wstx-asl-2.9.1.jar” to
> the application, could you please confirm if this is the
> recommended fix for this issue.

Tomcat doesn't use any particular XML API. It just uses JAXP which
will use whatever XML parser your environment has configured. It's
possible that your application (or a library you are using) or
configuration is specifying the use of this particular XML parser
which has some kind of missing dependency.

But this really has nothing to do with Tomcat.

Your stack trace shows that Tomcat is calling your code which,
ultimately, is using the Woodstox XML parser. It's up to you to decide
how best to fix your application.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7w0KsACgkQHPApP6U8
pFiXyw/+IBqW3IFBee+JjHU4nSLJuBHZOdWMrJjpbRtJgieLYkkOWToWhqlQ++HT
C9Tq5duINP0aAVZlXnE+2rzFXJrC4pESQSZOgbx1fYQ+6J8G4BABANtYbCpKFIbn
RolwfhsETOTdI68ROr7PgUBerVhMjEF8Gfh+i0J1f4/3pLQ4+bFbu1DVCseViaSP
JmcEmdWp/ODVAHq5fCD5I//zYfVKxjjsLHJnusIqUtMR9wTLOMb1m7t5VOUR27iJ
RyLfeq0dhm+61n9Z2VE3hqP3rKKOqIUuOG7wbOmZrAhRqnbWncvCR0xE+xEr9olg
VyBnWHAOcPZwBi533D8JbbV+IF9gkcWGe0x4Fm0rB3hvX6OMJwykDmqhXP1k8yha
1nBe8uadfB5A1o4H/e8VVwsRJx/WYdgx27V3IIbaZSwzT9x0bY8XOMzeBcH1pVMY
+qL5TTFzbVLDAsZVO1ggH2O61ehjpzz+siwO3K57mmncFFmmentdWEmhHtJpuqo6
gOk5zw6TWz6HeO9xZLsoQ3JqBHmj+jUyJ89nbJJaM271Sp/t2JgiGt1OvUvob69t
8i54NxXf1lszfqmLRr1qSHY9YBABLzP0vEhvVjNM8Nf180Ng9OGkMyO+htScl9ni
9GJMSH82PFlIO73wSpKKkNcn4cfJ8J1NI0ELs3+re3nHPsSgHfM=
=mfTw
-END PGP SIGNATURE-

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

RE: Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[Lavitesh Verma]

Hi John,

We didn't use woodstox previously in our application and after we updated 
tomcat to version 8.5.5 we are getting this issue.

We were able to resolve the issue by adding "wstx-asl-2.9.1.jar" to the 
application, could you please confirm if this is the recommended fix for this 
issue.

Thanks & Regards
Lavitesh Verma
Software Engineering Associate
Amdocs Global SmartOps
[download12]+91.9810157771
[cid:image001.jpg@01D2912B.17505E90]

From: john.e.gr...@wellsfargo.com.INVALID 
Sent: Wednesday, June 17, 2020 12:48 AM
To: users@tomcat.apache.org
Subject: RE: Issue found during migration of Tomcat version 6.0.35 to 8.5.5

Sorry for the top post.  I'm having email formatting problems.

Lavitesh,

15-Jun-2020 07:34:45.122 SEVERE [http-nio-7080-exec-10] 
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for 
servlet [MainControllerServlet] in context with path [/porequest] threw 
exception [Servlet execution threw an exception] with root cause
javax.xml.stream.FactoryConfigurationError: Provider 
com.ctc.wstx.stax.WstxInputFactory not found
at javax.xml.stream.XMLInputFactory.newInstance(Unknown Source)

This is saying it can't find WstxInputFactory, which appears to be the Woodstox 
implementation of the XMLInputFactory abstract class.

If you want to continue using Woodstox, you need to add it to your classpath 
again.

If you don't want to use it, there are a few things to check to find out why 
it's being used.  Look for:

  *   System property 
javax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory
  *   $JAVA_HOME/lib/stax.properties
  *   $JAVA_HOME/lib/jaxp.properties
  *   META-INF/services/javax.xml.stream.XMLInputFactory

That last one is actually a file of the same name as the class.  There is no 
traditional file extension.  This file might also be in a 3rd-party lib, too.  
The file contains the name of the implementation to use.

One of those things is probably telling the finder to use that Woodstox class.

If you don't want to use Woodstox anymore, you have to remove or change one of 
those sources.  Removing it just means you'll get the default.


John



From: Lavitesh Verma 
mailto:lavitesh.ve...@amdocs.com>>
Sent: Monday, June 15, 2020 8:49 AM
To: Tomcat Users List mailto:users@tomcat.apache.org>>
Subject: RE: Issue found during migration of Tomcat version 6.0.35 to 8.5.5


Hi,



PFA the complete Stack Trace for the Issue.

Thanks & Regards
Lavitesh Verma
Software Engineering Associate
Amdocs Global SmartOps
[download12]+91.9810157771
OOO - 06/16 - 06/19
[cid:image001.jpg@01D2912B.17505E90]




-Original Message-

From: Jason Wee mailto:peich...@gmail.com>>

Sent: Monday, June 15, 2020 6:49 PM

To: Tomcat Users List mailto:users@tomcat.apache.org>>

Subject: Re: Issue found during migration of Tomcat version 6.0.35 to 8.5.5



guess looks like jar not found, full stacktrace would be helpful.



On Mon, Jun 15, 2020 at 8:17 PM Lavitesh Verma 
mailto:lavitesh.ve...@amdocs.com>>

wrote:



> Hi Team,

>

>

>

> Below are the details of the system and tomcat version

>

> Old tomcat version: *Apache Tomcat/6.0.35*

>

> New tomcat version: *Apache Tomcat/8.5.5*

>

> Operating System: *SunOS *

>

> OS Version: *5.10*

>

> Architecture: *sparcv9*

>

> JVM Version: *1.8.0_101-b13*

>

> Vendor: *Oracle Corporation*

>

>

>

> We are trying to migrate Apache Tomcat version 6.0.35 to 8.5.5.

>

>

>

> We found the issue javax.xml.stream.FactoryConfigurationError:

> Provider com.ctc.wstx.stax.WstxInputFactory not found in localhost logs.

>

>

>

>

>

> Could you please assist on how we could resolve the issue.

>

>

>

> Thanks & Regards

>

> *Lavitesh Verma*

>

> Software Engineering Associate

>

> Amdocs Global SmartOps

>

> [image: download12]+91.9810157771

>

> *OOO - 06/16 - 06/19*

>

> [image: cid:image001.jpg@01D2912B.17505E90]

>

>

>

> *This email and the information contained herein is proprietary and

> confidential and subject to the Amdocs Email Terms of Service, which

> you may review at*

> *https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww

> .amdocs.com%2Fabout%2Femail-terms-of-service*data=02%7C01%7CLavit

> esh.Verma%40amdocs.com%7Cf5593255a1244392bb8a08d8113145f6%7Cc8eca3ca12

> 7646d59d9da0f2a028920f%7C0%7C0%7C637278250614631760sdata=%2B6rV%2

> Bbnayil4ZJr7yAuCsl2YyE86CZV19JWANZPz%2BIo%3Dreserved=0

> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww

> .amdocs.com%2Fabout%2Femail-terms-of-servicedata=02%7C01%7CLavite

> sh.Verma%40amdocs.com%7Cf5593255a1244392bb8a08d8113145f6%7Cc8eca3ca127

> 646d59d9da0f2a028920f%7C0%7C0%7C637278250614631760sdata=Wtzp%2BGE

> %2BjEvBwZwExHs1jlNLsN5wx

Re: Version migration problems

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Niranjan,

On 6/19/20 13:17, Niranjan Rao wrote:
> Hi Mark/Chris,
>
> Thank you for the reply.
>
> It's a spring application, related controllers/methods basically
> return page name as return "pages/Login".
>
> The view resolver maps it WEB-INF/jsp/pages/Login.jsp.
>
> Login.jsp has entry that says
>
> 
>
> This entry gets resolved correctly in V7, but V9 I get error can
> not find pages/jsp/fragments/commonData.jsp.
>
> After playing with it couple of hours, I figured out full path
> works. So issue seems to be root context/directory of jsp engine
> that was WEB-INF seems to have changed to current directory where
> page is getting loaded. JSP generation still generates same line
> for both of them like following.
>
> org.apache.jasper.runtime.JspRuntimeLibrary.include(request,
> response, "jsp/fragments/commonData.jsp", out, false);
>
> But v9 interprets it relative to directory of current jsp that is
> in my case WEB-INF/jsp/pages and older engine interprets it
> relative to WEB-INF directory.
>
> JDK version 1.8.0_111, Operating system is 16.04.6. It's same WAR
> file getting deployed in both tomcat versions. Only difference is
> server.xml has different ports.

I've never done this kind of thing (I tend not to use very many JSPs),
but I think you probably want all your file paths to start with "/".
So that should be:



or maybe:



... unless the path is supposed to be relative to "Login.jsp".

Do you have these two files?

WEB-INF/pages/Login.jsp
WEB-INF/pages/jsp/fragments/commonData.jsp

?

If not, then your application isn't built properly. These rules have
always been the case, though, so I'm not sure why it would have worked
on Tomcat 7 but no longer works on Tomcat 9.

- -chris

> On 6/19/20 6:13 AM, Mark Thomas wrote:
>> On 19/06/2020 13:19, Christopher Schultz wrote:
>>> Niranjan,
>>>
>>> On 6/18/20 13:47, Niranjan Rao wrote:
 I am trying to migrate from 7.0.73 to 9.0.36 and facing
 challenges. Java version and operating system version remains
 same in both cases.
>>> ... and what are those versions?
>>>
 I have carefully reviewed the configurations and everything
 looks ok. Version 9 does not report any problems when
 starting the application either in catalina.out file or in
 the application log file.
>>> Good.
>>>
 Applications has bunch of JSP pages which sit under
 WEB-INF/jsp/pages directory and some of these pages include
 fragments from WEB-INF/jsp/fragments directory. In the older
 version V7 this works correctly, but in V9 I get error about
 include not not found. Page do get resolved correctly, but
 includes do not.
>>> Can you give some examples?
>> +1. The simplest test case that demonstrates the issue would be
>> good. That should be a JSP, a JSP fragment and the appropriate
>> directory structure.
>>
>> Mark
>>
 Given only change is tomcat version as it's same WAR file
 deployed on same operating system and same java version, I am
 thinking I am missing some basic change in tomcat JSP lookup
 for version 9.
>>>
 Can anyone please point me what I can be doing wrong or what
 I need to do so that same WAR file works in both versions
>>> -chris
>>>
>>>
>>> 
- -
>>>
>>>
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
>>
>
>
> -
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7tHcAACgkQHPApP6U8
pFjqnQ/+LOlgMJirTrnwX/2Bsev2Pxfr80JXx7g9JjAxGTT+ncmYDPnV/xPfNS1m
OuZtveZorks4Hvmb62qhSaQWv3GlRwUGn4gYuvSb/EIUX7HWaKJ+f4Zwqjzx0LG/
YAWyK0WeFB4tm9NGjneHGJ5GzfV96WETGNKou38THVAf2nIFBh29kaC9dAd/Pwac
zx5Pp2EUGUxwfBR1J3MFoi9XAZnCorpPCKilvtKjn3VMuCvvgQc2CPqarF3NI/S3
EXPRSj5fvQKoAaazEn1IbGbXw1YxkcR9NnV5HUb/+5yYLIbxkpGXcQagt+cbmkJb
SBEBsU4q8d7p/ZQYMt7M55P4+kcwpHtPTZwUiKl0u+dI6aw+F/DJONk4adzvvTHu
TkAj3DbEuRCegnbGZ8kcYwXRqP5d/CzJh/DCp34neMlGx6fDajuTkY2KfVwcFiZL
6kjPVmym1Gg2csUXjhu0z8T2AbeSFCwm3Fz/Utiqy5OLmhf8Q/mhYiDKdPoT+f9K
+9pbidEM0lCLshc0aDR3QOXRLn/jVf3IGc4OrhMniuVYT+kmNRCwtVBCWgc82Xar
X+4AwtyGTEgn22gJJ/t0wt+ke0YPrXYvsfR3pk+1XlUZxmRwue/kfduboNsz4FO3
LggXLocMDNPt0FYgUd8pcN4C1n/YxoUgUSxR//I384CdytmfZtU=
=OKkM
-END PGP SIGNATURE-

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

Re: Version migration problems

[Niranjan Rao]

Hi Mark/Chris,

Thank you for the reply.

It's a spring application, related controllers/methods basically return 
page name as return "pages/Login".


The view resolver maps it WEB-INF/jsp/pages/Login.jsp.

Login.jsp has entry that says



This entry gets resolved correctly in V7, but V9 I get error can not 
find pages/jsp/fragments/commonData.jsp.


After playing with it couple of hours, I figured out full path works. So 
issue seems to be root context/directory of jsp engine that was WEB-INF 
seems to have changed to current directory where page is getting loaded.

JSP generation still generates same line for both of them like following.

org.apache.jasper.runtime.JspRuntimeLibrary.include(request, response, 
"jsp/fragments/commonData.jsp", out, false);


But v9 interprets it relative to directory of current jsp that is in my 
case WEB-INF/jsp/pages and older engine interprets it relative to 
WEB-INF directory.


JDK version 1.8.0_111, Operating system is 16.04.6. It's same WAR file 
getting deployed in both tomcat versions. Only difference is server.xml 
has different ports.


Regards,

Niranjan
On 6/19/20 6:13 AM, Mark Thomas wrote:

On 19/06/2020 13:19, Christopher Schultz wrote:

Niranjan,

On 6/18/20 13:47, Niranjan Rao wrote:

I am trying to migrate from 7.0.73 to 9.0.36 and facing
challenges.
Java version and operating system version remains same in both
cases.

... and what are those versions?


I have carefully reviewed the configurations and everything looks
ok. Version 9 does not report any problems when starting the
application either in catalina.out file or in the application log
file.

Good.


Applications has bunch of JSP pages which sit under
WEB-INF/jsp/pages directory and some of these pages include
fragments from WEB-INF/jsp/fragments directory. In the older
version V7 this works correctly, but in V9 I get error about
include not not found. Page do get resolved correctly, but includes
do not.

Can you give some examples?

+1. The simplest test case that demonstrates the issue would be good.
That should be a JSP, a JSP fragment and the appropriate directory
structure.

Mark


Given only change is tomcat version as it's same WAR file deployed
on same operating system and same java version, I am thinking I am
missing some basic change in tomcat JSP lookup for version 9.



Can anyone please point me what I can be doing wrong or what I need
to do so that same WAR file works in both versions

-chris


-
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




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

Re: Version migration problems

[Mark Thomas]

On 19/06/2020 13:19, Christopher Schultz wrote:
> Niranjan,
> 
> On 6/18/20 13:47, Niranjan Rao wrote:
>> I am trying to migrate from 7.0.73 to 9.0.36 and facing
>> challenges.
> 
>> Java version and operating system version remains same in both
>> cases.
> 
> ... and what are those versions?
> 
>> I have carefully reviewed the configurations and everything looks
>> ok. Version 9 does not report any problems when starting the
>> application either in catalina.out file or in the application log
>> file.
> 
> Good.
> 
>> Applications has bunch of JSP pages which sit under
>> WEB-INF/jsp/pages directory and some of these pages include
>> fragments from WEB-INF/jsp/fragments directory. In the older
>> version V7 this works correctly, but in V9 I get error about
>> include not not found. Page do get resolved correctly, but includes
>> do not.
> 
> Can you give some examples?

+1. The simplest test case that demonstrates the issue would be good.
That should be a JSP, a JSP fragment and the appropriate directory
structure.

Mark

> 
>> Given only change is tomcat version as it's same WAR file deployed
>> on same operating system and same java version, I am thinking I am
>> missing some basic change in tomcat JSP lookup for version 9.
> 
> 
>> Can anyone please point me what I can be doing wrong or what I need
>> to do so that same WAR file works in both versions
> 
> -chris
> 
>
> -
> 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: Version migration problems

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Niranjan,

On 6/18/20 13:47, Niranjan Rao wrote:
> I am trying to migrate from 7.0.73 to 9.0.36 and facing
> challenges.
>
> Java version and operating system version remains same in both
> cases.

... and what are those versions?

> I have carefully reviewed the configurations and everything looks
> ok. Version 9 does not report any problems when starting the
> application either in catalina.out file or in the application log
> file.

Good.

> Applications has bunch of JSP pages which sit under
> WEB-INF/jsp/pages directory and some of these pages include
> fragments from WEB-INF/jsp/fragments directory. In the older
> version V7 this works correctly, but in V9 I get error about
> include not not found. Page do get resolved correctly, but includes
> do not.

Can you give some examples?

> Given only change is tomcat version as it's same WAR file deployed
> on same operating system and same java version, I am thinking I am
> missing some basic change in tomcat JSP lookup for version 9.
>
>
> Can anyone please point me what I can be doing wrong or what I need
> to do so that same WAR file works in both versions

- -chris

-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7srVoACgkQHPApP6U8
pFgboBAAsPPfvI5s5NXt7ldN+tub4IBdjYnAqTDtd2Y7Rh2bCZLSjhet6wXIRZcL
acRC4o+OE+1Y9RhgTTDKYos9IEIr35WlFLLIRQMhFUjdSBQPbFjlKVIK6YMXJTCp
Sbh1IHV/mI+GqsswNaKVDy4l3CueSaUJDB7sw+y/5dbGqWmny+FP4QiR+l8uFofB
Yvyu/CilM0SxWpTYUc4Wm6QxXtWbztucSdRRKwKJC6JNnfGhBgZo1q63hjg+NbjZ
S6zhz6jc4CSzainEZqiOpJmxryqxUL4LvDfAcST6dmnCxn6Y7LAQd2M78e2reNsX
hnR+uNaPr4gPSHibsX6T+oVaXRQdxd05Ws+Fdyu1USIH1K8+cTl7TgEo4Zu92uwx
Z2P0OGLq8iWCosvKIQzk2YRq3+Y22UNO8MNMdrl/0NTomDCybNAL/i1PEwH5vCii
ylqCMVfk+jzbf91PZWue2ONx10x90NQ70C/I2k5KqkNd2XfnBcNM/BNsFX7SIXpG
fkZQHY72YQXC+hkVg4yoyNW9dVOiEQRhH6RTV3Jkjzjmc5NME9dpFn4aYKVG8Zay
qAuzz55bVSXcUVVRTUTSefaAsZB7MeUykIe7rSF4Y6wbdidUkbZEVzXHlf8SYXdO
EdRjzIddlZJYolbOBGY3uVWOEk4F1ts7EMmUBHsuhekl3wI3Zcc=
=BwV+
-END PGP SIGNATURE-

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

Version migration problems

[Niranjan Rao]

Greetings,


I am trying to migrate from 7.0.73 to 9.0.36 and facing challenges.


Java version and operating system version remains same in both cases.


I have carefully reviewed the configurations and everything looks ok. 
Version 9 does not report any problems when starting the application 
either in catalina.out file or in the application log file.



Applications has bunch of JSP pages which sit under WEB-INF/jsp/pages 
directory and some of these pages include fragments from 
WEB-INF/jsp/fragments directory. In the older version V7 this works 
correctly, but in V9 I get error about include not not found. Page do 
get resolved correctly, but includes do not.



Given only change is tomcat version as it's same WAR file deployed on 
same operating system and same java version, I am thinking I am missing 
some basic change in tomcat JSP lookup for version 9.



Can anyone please point me what I can be doing wrong or what I need to 
do so that same WAR file works in both versions



Regards,

Niranjan


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

RE: Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[John.E.Gregg]

Sorry for the top post.  I'm having email formatting problems.

Lavitesh,

15-Jun-2020 07:34:45.122 SEVERE [http-nio-7080-exec-10] 
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for 
servlet [MainControllerServlet] in context with path [/porequest] threw 
exception [Servlet execution threw an exception] with root cause
javax.xml.stream.FactoryConfigurationError: Provider 
com.ctc.wstx.stax.WstxInputFactory not found
at javax.xml.stream.XMLInputFactory.newInstance(Unknown Source)

This is saying it can't find WstxInputFactory, which appears to be the Woodstox 
implementation of the XMLInputFactory abstract class.

If you want to continue using Woodstox, you need to add it to your classpath 
again.

If you don't want to use it, there are a few things to check to find out why 
it's being used.  Look for:

-  System property 
javax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory

-  $JAVA_HOME/lib/stax.properties

-  $JAVA_HOME/lib/jaxp.properties

-  META-INF/services/javax.xml.stream.XMLInputFactory

That last one is actually a file of the same name as the class.  There is no 
traditional file extension.  This file might also be in a 3rd-party lib, too.  
The file contains the name of the implementation to use.

One of those things is probably telling the finder to use that Woodstox class.

If you don't want to use Woodstox anymore, you have to remove or change one of 
those sources.  Removing it just means you'll get the default.

John



From: Lavitesh Verma 
Sent: Monday, June 15, 2020 8:49 AM
To: Tomcat Users List 
Subject: RE: Issue found during migration of Tomcat version 6.0.35 to 8.5.5


Hi,



PFA the complete Stack Trace for the Issue.

Thanks & Regards
Lavitesh Verma
Software Engineering Associate
Amdocs Global SmartOps
[download12]+91.9810157771
OOO - 06/16 - 06/19
[cid:image001.jpg@01D2912B.17505E90]




-Original Message-

From: Jason Wee mailto:peich...@gmail.com>>

Sent: Monday, June 15, 2020 6:49 PM

To: Tomcat Users List mailto:users@tomcat.apache.org>>

Subject: Re: Issue found during migration of Tomcat version 6.0.35 to 8.5.5



guess looks like jar not found, full stacktrace would be helpful.



On Mon, Jun 15, 2020 at 8:17 PM Lavitesh Verma 
mailto:lavitesh.ve...@amdocs.com>>

wrote:



> Hi Team,

>

>

>

> Below are the details of the system and tomcat version

>

> Old tomcat version: *Apache Tomcat/6.0.35*

>

> New tomcat version: *Apache Tomcat/8.5.5*

>

> Operating System: *SunOS *

>

> OS Version: *5.10*

>

> Architecture: *sparcv9*

>

> JVM Version: *1.8.0_101-b13*

>

> Vendor: *Oracle Corporation*

>

>

>

> We are trying to migrate Apache Tomcat version 6.0.35 to 8.5.5.

>

>

>

> We found the issue javax.xml.stream.FactoryConfigurationError:

> Provider com.ctc.wstx.stax.WstxInputFactory not found in localhost logs.

>

>

>

>

>

> Could you please assist on how we could resolve the issue.

>

>

>

> Thanks & Regards

>

> *Lavitesh Verma*

>

> Software Engineering Associate

>

> Amdocs Global SmartOps

>

> [image: download12]+91.9810157771

>

> *OOO - 06/16 - 06/19*

>

> [image: cid:image001.jpg@01D2912B.17505E90]

>

>

>

> *This email and the information contained herein is proprietary and

> confidential and subject to the Amdocs Email Terms of Service, which

> you may review at*

> *https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww

> .amdocs.com%2Fabout%2Femail-terms-of-service*data=02%7C01%7CLavit

> esh.Verma%40amdocs.com%7Cf5593255a1244392bb8a08d8113145f6%7Cc8eca3ca12

> 7646d59d9da0f2a028920f%7C0%7C0%7C637278250614631760sdata=%2B6rV%2

> Bbnayil4ZJr7yAuCsl2YyE86CZV19JWANZPz%2BIo%3Dreserved=0

> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww

> .amdocs.com%2Fabout%2Femail-terms-of-servicedata=02%7C01%7CLavite

> sh.Verma%40amdocs.com%7Cf5593255a1244392bb8a08d8113145f6%7Cc8eca3ca127

> 646d59d9da0f2a028920f%7C0%7C0%7C637278250614631760sdata=Wtzp%2BGE

> %2BjEvBwZwExHs1jlNLsN5wxGZvYhHK7SAwfxM%3Dreserved=0>

>
This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at 
https://www.amdocs.com/about/email-terms-of-service

Re: [OT] [tomcat-users] Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[Lavitesh Verma]

All,



From: Christopher Schultz 
Sent: Tuesday, June 16, 2020, 23:29
To: users@tomcat.apache.org
Subject: Re: [OT] [tomcat-users] Issue found during migration of Tomcat version 
6.0.35 to 8.5.5

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 6/15/20 10:02, Jason Pyeron wrote:
> A quick brief on etiquette.
>
> 1.   Please do not harvest emails and send linked in requests

OMG +1 many many times to this.

If I haven't met you in person, don't send me a LinkedIn request.

For that, I have already apologised to Jason (You can certainly connect on that 
with him) but for instance if it had been intentional, we are all technical 
people here and know the value of digital networking.  LinkedIn is such a 
platform for that. Even if i never intended it to be sent to Jason Pyeron but 
to Jason Pryce. It was a bit of a misunderstanding.
> 2.   Do not mark questions as urgent and do provide sufficient
> details to reproduce the problem

I didn't see anything "urgent" about the initial post.

As for the marking urgent post, i had some really pressing need to complete the 
work as i am on leave for the whole week and wanted it to be completed as soon 
as possible. I did not know that marking urgent here on tomcat mailing list 
will create such blunders. I sincerely apologize for this as it was my first 
time on tom cat mailing list and it wont be repeated again. It was just me 
being proactive and completing my work on time and as fast as possible without 
considering the consequences(which i now got and again apologize for)

- -chris

-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7pCFgACgkQHPApP6U8
pFhLGA/+OCBFDtwXqg25GkHzJIVCCDz0PUmo+WwshsHXmg+6njQ6oyk0xfbqUQNh
2x4IQEsqi0wvTHXRBhWtK1RQfu1emcPdLADb7Fx58AAGzyc1aNSn/LPT3+XkVRJ1
D82SQVMFeoOtOxLTSRfWlHEvjthuV7g5nobKW5yDOiv0TR+CBqarAzSewvRis5DZ
9HtAzS3jZnZVC6cCdyScRYjc4vMYWhfVHzCaAvsSoMwR/+644xeN/6rUpl6eY8L/
gxBW+w1Vn7X91gLyXML1sHQhwaupCvw3jnaV5B/CkPGTUKufKV6x3Xpycg/OmNeI
7w9m5ukzFDqtwIfbep7ngHZyiWXCngkCH50bFc7q/O/7nlbrKNx6cBS6ifh9b7dX
go1juA3dLqekY98eZxKh8nz4U7hI6Snw0KQJruLiVin3E8F8LqUegvq5QJelsQql
IoZZaj44BaPvCHIzdUxLhMKj0YJEOH5TxG7/NyyCI98RLrz0hk+JbF1+7YREIN0s
NQk2701kfmrPy2XeywvNS8psXQEsh0QtL7WpFBBnw2LZefKlqX4OcMC3hAl1o2dS
RkakYu0/J7UCvvUg0wTG3kK/NDseOBi6sMLSXatgSXIa8nfhjxygxH/fBrrAJt/D
CSlHgXDLfJIsfz8sd+/htW2ACCmd6VpdYfcFc5p0fHpkz+tIE6c=
=jJNV
-END PGP SIGNATURE-

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



Sent from Outlook Mobile<https://aka.ms/blhgte>
This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at 
https://www.amdocs.com/about/email-terms-of-service 
<https://www.amdocs.com/about/email-terms-of-service>

Re: [OT] [tomcat-users] Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 6/15/20 10:02, Jason Pyeron wrote:
> A quick brief on etiquette.
>
> 1.   Please do not harvest emails and send linked in requests

OMG +1 many many times to this.

If I haven't met you in person, don't send me a LinkedIn request.

> 2.   Do not mark questions as urgent and do provide sufficient
> details to reproduce the problem

I didn't see anything "urgent" about the initial post.

- -chris

-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7pCFgACgkQHPApP6U8
pFhLGA/+OCBFDtwXqg25GkHzJIVCCDz0PUmo+WwshsHXmg+6njQ6oyk0xfbqUQNh
2x4IQEsqi0wvTHXRBhWtK1RQfu1emcPdLADb7Fx58AAGzyc1aNSn/LPT3+XkVRJ1
D82SQVMFeoOtOxLTSRfWlHEvjthuV7g5nobKW5yDOiv0TR+CBqarAzSewvRis5DZ
9HtAzS3jZnZVC6cCdyScRYjc4vMYWhfVHzCaAvsSoMwR/+644xeN/6rUpl6eY8L/
gxBW+w1Vn7X91gLyXML1sHQhwaupCvw3jnaV5B/CkPGTUKufKV6x3Xpycg/OmNeI
7w9m5ukzFDqtwIfbep7ngHZyiWXCngkCH50bFc7q/O/7nlbrKNx6cBS6ifh9b7dX
go1juA3dLqekY98eZxKh8nz4U7hI6Snw0KQJruLiVin3E8F8LqUegvq5QJelsQql
IoZZaj44BaPvCHIzdUxLhMKj0YJEOH5TxG7/NyyCI98RLrz0hk+JbF1+7YREIN0s
NQk2701kfmrPy2XeywvNS8psXQEsh0QtL7WpFBBnw2LZefKlqX4OcMC3hAl1o2dS
RkakYu0/J7UCvvUg0wTG3kK/NDseOBi6sMLSXatgSXIa8nfhjxygxH/fBrrAJt/D
CSlHgXDLfJIsfz8sd+/htW2ACCmd6VpdYfcFc5p0fHpkz+tIE6c=
=jJNV
-END PGP SIGNATURE-

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

RE: [tomcat-users] Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[Jason Pyeron]

If you deploy your application against a fresh extract of 
https://archive.apache.org/dist/tomcat/tomcat-6/v6.0.35/bin/apache-tomcat-6.0.35.tar.gz,
 without ANY customizations you do not get the problem?

 

If you have to make customizations to get it to run, what are they? (e.g. 
context.xml changes, lib/ JARs, startup parameters, etc)

 

Based on the limited information you have provided (e.g. no test case I can 
run) I do not see any relevant issues in the following guides.

 

https://tomcat.apache.org/migration-7.html

http://tomcat.apache.org/migration-8.html

http://tomcat.apache.org/migration-85.html

 

Since the JVM (indicated) and WAR (implied) is the same version in your two 
installs, then it is a configuration issue.

 

CLASSPATH ?

System properties?

 

Please provide details to reproduce here.

 

-Jason 

 

 

From: Lavitesh Verma  
Sent: Monday, June 15, 2020 11:14 AM
To: Tomcat Users List 
Cc: 'RUBIN, JACOB' ; lsrv...@list.att.com; Vasudev Wadhawan 

Subject: RE: [tomcat-users] Issue found during migration of Tomcat version 
6.0.35 to 8.5.5

 

HI Jason,

 

Below are the details for the Tomcat 6 version, that we used before, 

Server version: Apache Tomcat/6.0.35

Server number:  6.0.35.0

OS Name:SunOS

OS Version: 5.10

Architecture:   sparcv9

JVM Version:1.8.0_101-b13

JVM Vendor: Oracle Corporation

 

We don’t face any issue on the other test environment that we are facing on 
updating to 8.5.5.

 

Thanks & Regards

Lavitesh Verma

Software Engineering Associate

Amdocs Global SmartOps

+91.9810157771 

OOO – 06/16 – 06/19



 

From: Jason Pyeron mailto:jpye...@pdinc.us> > 
Sent: Monday, June 15, 2020 7:33 PM
To: 'Tomcat Users List' mailto:users@tomcat.apache.org> >
Cc: 'RUBIN, JACOB' mailto:jr2...@att.com> >; 
lsrv...@list.att.com <mailto:lsrv...@list.att.com> ; Vasudev Wadhawan 
mailto:vasudev.wadha...@amdocs.com> >
Subject: RE: [tomcat-users] Issue found during migration of Tomcat version 
6.0.35 to 8.5.5

 

What I see here is that there is a bit of custom code that is “causing” the 
issue.

 

at 
com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)

at javax.xml.ws.Service.(Service.java:77)

Above here are JARs / runtime in the classpath

at com.att.lsrv.preorder.PreOrderService.(Unknown Source)

at porequest.control.LviCsClient.getLviCsClientProxy(Unknown Source)

at porequest.control.LviCsClient.getCSRResponse(Unknown Source)

at porequest.control.MainControllerServlet.CsrqResponse(Unknown Source)

at porequest.control.MainControllerServlet.doPost(Unknown Source)

Below here is tomcat..

at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)

 

You indicate that this was on Tomcat 6.0.35, but you did not confirm the JVM it 
was running on. I am skeptical since the Tomcat version you indicated was 
released before Java 8 (2012 vs 2014) – but I am more skeptical that 6.0.35 was 
not customized. Have you deployed the application to an “out of the box” 6.0.35 
on the same JVM as 8.5.5?

 

Have you reached out to your developer of the com.att.lsrv and 
porequest.control code? You should have a test case to prove the issue out.

 

-Jason

 

From: Lavitesh Verma  
Sent: Monday, June 15, 2020 9:29 AM
To: Jason Pyeron mailto:jpye...@pdinc.us> >; 'Tomcat Users 
List' mailto:users@tomcat.apache.org> >
Cc: 'RUBIN, JACOB' mailto:jr2...@att.com> >; 
lsrv...@list.att.com <mailto:lsrv...@list.att.com> ; Vasudev Wadhawan 
mailto:vasudev.wadha...@amdocs.com> >
Subject: RE: [tomcat-users] Issue found during migration of Tomcat version 
6.0.35 to 8.5.5

 

Hi Jason,

 

We have updated the xercesImpl from version 2.6.2 to 2.12.0 for the migration 
and no new jars were added for the new environment.

 

We didn’t use Woodstox StAX jar with tomcat 6.0.35 and did not face any such 
issue.

 

PFA the complete Stack Trace for the Issue.

 

Thanks & Regards

Lavitesh Verma

Software Engineering Associate

Amdocs Global SmartOps

+91.9810157771 

OOO – 06/16 – 06/19



 

From: Jason Pyeron mailto:jpye...@pdinc.us> > 
Sent: Monday, June 15, 2020 6:15 PM
To: 'Tomcat Users List' mailto:users@tomcat.apache.org> >
Cc: 'RUBIN, JACOB' mailto:jr2...@att.com> >; 
lsrv...@list.att.com <mailto:lsrv...@list.att.com> ; Vasudev Wadhawan 
mailto:vasudev.wadha...@amdocs.com> >
Subject: RE: [tomcat-users] Issue found during migration of Tomcat version 
6.0.35 to 8.5.5

 

Sounds like you have added Jars to the old environment that are not in the new 
environment.

 

What is the offending code that causes the error?

 

What were your customizations against the 6.0.35 environment?

 

Is the Woodstox StAX jar in the web application or Tomcat lib directory? Where 
was it previously?

 

Did you test this before you migrated causing this “urgent” issue? What is 
diffe

RE: [tomcat-users] Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[Lavitesh Verma]

HI Jason,

Below are the details for the Tomcat 6 version, that we used before,
Server version: Apache Tomcat/6.0.35
Server number:  6.0.35.0
OS Name:SunOS
OS Version: 5.10
Architecture:   sparcv9
JVM Version:1.8.0_101-b13
JVM Vendor: Oracle Corporation

We don't face any issue on the other test environment that we are facing on 
updating to 8.5.5.

Thanks & Regards
Lavitesh Verma
Software Engineering Associate
Amdocs Global SmartOps
[download12]+91.9810157771
OOO - 06/16 - 06/19
[cid:image001.jpg@01D2912B.17505E90]

From: Jason Pyeron 
Sent: Monday, June 15, 2020 7:33 PM
To: 'Tomcat Users List' 
Cc: 'RUBIN, JACOB' ; lsrv...@list.att.com; Vasudev Wadhawan 

Subject: RE: [tomcat-users] Issue found during migration of Tomcat version 
6.0.35 to 8.5.5

What I see here is that there is a bit of custom code that is "causing" the 
issue.

at 
com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)
at javax.xml.ws.Service.(Service.java:77)
Above here are JARs / runtime in the classpath
at com.att.lsrv.preorder.PreOrderService.(Unknown Source)
at porequest.control.LviCsClient.getLviCsClientProxy(Unknown Source)
at porequest.control.LviCsClient.getCSRResponse(Unknown Source)
at porequest.control.MainControllerServlet.CsrqResponse(Unknown Source)
at porequest.control.MainControllerServlet.doPost(Unknown Source)
Below here is tomcat..
at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)

You indicate that this was on Tomcat 6.0.35, but you did not confirm the JVM it 
was running on. I am skeptical since the Tomcat version you indicated was 
released before Java 8 (2012 vs 2014) - but I am more skeptical that 6.0.35 was 
not customized. Have you deployed the application to an "out of the box" 6.0.35 
on the same JVM as 8.5.5?

Have you reached out to your developer of the com.att.lsrv and 
porequest.control code? You should have a test case to prove the issue out.

-Jason

From: Lavitesh Verma 
mailto:lavitesh.ve...@amdocs.com>>
Sent: Monday, June 15, 2020 9:29 AM
To: Jason Pyeron mailto:jpye...@pdinc.us>>; 'Tomcat Users 
List' mailto:users@tomcat.apache.org>>
Cc: 'RUBIN, JACOB' mailto:jr2...@att.com>>; 
lsrv...@list.att.com<mailto:lsrv...@list.att.com>; Vasudev Wadhawan 
mailto:vasudev.wadha...@amdocs.com>>
Subject: RE: [tomcat-users] Issue found during migration of Tomcat version 
6.0.35 to 8.5.5

Hi Jason,

We have updated the xercesImpl from version 2.6.2 to 2.12.0 for the migration 
and no new jars were added for the new environment.

We didn't use Woodstox StAX jar with tomcat 6.0.35 and did not face any such 
issue.

PFA the complete Stack Trace for the Issue.

Thanks & Regards
Lavitesh Verma
Software Engineering Associate
Amdocs Global SmartOps
[download12]+91.9810157771
OOO - 06/16 - 06/19
[cid:image001.jpg@01D2912B.17505E90]

From: Jason Pyeron mailto:jpye...@pdinc.us>>
Sent: Monday, June 15, 2020 6:15 PM
To: 'Tomcat Users List' 
mailto:users@tomcat.apache.org>>
Cc: 'RUBIN, JACOB' mailto:jr2...@att.com>>; 
lsrv...@list.att.com<mailto:lsrv...@list.att.com>; Vasudev Wadhawan 
mailto:vasudev.wadha...@amdocs.com>>
Subject: RE: [tomcat-users] Issue found during migration of Tomcat version 
6.0.35 to 8.5.5

Sounds like you have added Jars to the old environment that are not in the new 
environment.

What is the offending code that causes the error?

What were your customizations against the 6.0.35 environment?

Is the Woodstox StAX jar in the web application or Tomcat lib directory? Where 
was it previously?

Did you test this before you migrated causing this "urgent" issue? What is 
different between your test and this urgent outage's configuration.

-Jason

From: Lavitesh Verma [mailto:lavitesh.ve...@amdocs.com]
Sent: Monday, June 15, 2020 8:16 AM
To: users@tomcat.apache.org<mailto:users@tomcat.apache.org>
Cc: RUBIN, JACOB mailto:jr2...@att.com>>; 
lsrv...@list.att.com<mailto:lsrv...@list.att.com>; Vasudev Wadhawan 
mailto:vasudev.wadha...@amdocs.com>>
Subject: [tomcat-users] Issue found during migration of Tomcat version 6.0.35 
to 8.5.5
Importance: High

Hi Team,

Below are the details of the system and tomcat version
Old tomcat version: Apache Tomcat/6.0.35
New tomcat version: Apache Tomcat/8.5.5
Operating System: SunOS
OS Version: 5.10
Architecture: sparcv9
JVM Version: 1.8.0_101-b13
Vendor: Oracle Corporation

We are trying to migrate Apache Tomcat version 6.0.35 to 8.5.5.

We found the issue javax.xml.stream.FactoryConfigurationError: Provider 
com.ctc.wstx.stax.WstxInputFactory not found in localhost logs.

[cid:image004.jpg@01D6433C.E23C4DF0]

Could you please assist on how we could resolve the issue.

Thanks & Regards
Lavitesh Verma
Software Engineering Associate
Amdocs Global SmartOps
[download12]+91.9810157771
OOO - 06/16 - 06/19
[cid:image001.jpg@

RE: [tomcat-users] Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[Jason Pyeron]

A quick brief on etiquette.

 

1.   Please do not harvest emails and send linked in requests

2.   Do not mark questions as urgent and do provide sufficient details to 
reproduce the problem

 

What I see here is that there is a bit of custom code that is “causing” the 
issue.

 

at 
com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)

at javax.xml.ws.Service.(Service.java:77)

Above here are JARs / runtime in the classpath

at com.att.lsrv.preorder.PreOrderService.(Unknown Source)

at porequest.control.LviCsClient.getLviCsClientProxy(Unknown Source)

at porequest.control.LviCsClient.getCSRResponse(Unknown Source)

at porequest.control.MainControllerServlet.CsrqResponse(Unknown Source)

at porequest.control.MainControllerServlet.doPost(Unknown Source)

Below here is tomcat..

at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)

 

You indicate that this was on Tomcat 6.0.35, but you did not confirm the JVM it 
was running on. I am skeptical since the Tomcat version you indicated was 
released before Java 8 (2012 vs 2014) – but I am more skeptical that 6.0.35 was 
not customized. Have you deployed the application to an “out of the box” 6.0.35 
on the same JVM as 8.5.5?

 

Have you reached out to your developer of the com.att.lsrv and 
porequest.control code? You should have a test case to prove the issue out.

 

-Jason

 

From: Lavitesh Verma  
Sent: Monday, June 15, 2020 9:29 AM
To: Jason Pyeron ; 'Tomcat Users List' 

Cc: 'RUBIN, JACOB' ; lsrv...@list.att.com; Vasudev Wadhawan 

Subject: RE: [tomcat-users] Issue found during migration of Tomcat version 
6.0.35 to 8.5.5

 

Hi Jason,

 

We have updated the xercesImpl from version 2.6.2 to 2.12.0 for the migration 
and no new jars were added for the new environment.

 

We didn’t use Woodstox StAX jar with tomcat 6.0.35 and did not face any such 
issue.

 

PFA the complete Stack Trace for the Issue.

 

Thanks & Regards

Lavitesh Verma

Software Engineering Associate

Amdocs Global SmartOps

+91.9810157771 

OOO – 06/16 – 06/19



 

From: Jason Pyeron mailto:jpye...@pdinc.us> > 
Sent: Monday, June 15, 2020 6:15 PM
To: 'Tomcat Users List' mailto:users@tomcat.apache.org> >
Cc: 'RUBIN, JACOB' mailto:jr2...@att.com> >; 
lsrv...@list.att.com <mailto:lsrv...@list.att.com> ; Vasudev Wadhawan 
mailto:vasudev.wadha...@amdocs.com> >
Subject: RE: [tomcat-users] Issue found during migration of Tomcat version 
6.0.35 to 8.5.5

 

Sounds like you have added Jars to the old environment that are not in the new 
environment.

 

What is the offending code that causes the error?

 

What were your customizations against the 6.0.35 environment?

 

Is the Woodstox StAX jar in the web application or Tomcat lib directory? Where 
was it previously?

 

Did you test this before you migrated causing this “urgent” issue? What is 
different between your test and this urgent outage’s configuration.

 

-Jason

 

From: Lavitesh Verma [mailto:lavitesh.ve...@amdocs.com] 
Sent: Monday, June 15, 2020 8:16 AM
To: users@tomcat.apache.org <mailto:users@tomcat.apache.org> 
Cc: RUBIN, JACOB mailto:jr2...@att.com> >; 
lsrv...@list.att.com <mailto:lsrv...@list.att.com> ; Vasudev Wadhawan 
mailto:vasudev.wadha...@amdocs.com> >
Subject: [tomcat-users] Issue found during migration of Tomcat version 6.0.35 
to 8.5.5
Importance: High

 

Hi Team,

 

Below are the details of the system and tomcat version 

Old tomcat version: Apache Tomcat/6.0.35

New tomcat version: Apache Tomcat/8.5.5

Operating System: SunOS 

OS Version: 5.10 

Architecture: sparcv9

JVM Version: 1.8.0_101-b13

Vendor: Oracle Corporation

 

We are trying to migrate Apache Tomcat version 6.0.35 to 8.5.5.

 

We found the issue javax.xml.stream.FactoryConfigurationError: Provider 
com.ctc.wstx.stax.WstxInputFactory not found in localhost logs.

 



 

Could you please assist on how we could resolve the issue.

 

Thanks & Regards

Lavitesh Verma

Software Engineering Associate

Amdocs Global SmartOps

+91.9810157771 

OOO – 06/16 – 06/19



 

This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at 
https://www.amdocs.com/about/email-terms-of-service

This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at  
<https://www.amdocs.com/about/email-terms-of-service> 
https://www.amdocs.com/about/email-terms-of-service

RE: Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[Lavitesh Verma]

Hi,



PFA the complete Stack Trace for the Issue.

Thanks & Regards
Lavitesh Verma
Software Engineering Associate
Amdocs Global SmartOps
[download12]+91.9810157771
OOO - 06/16 - 06/19
[cid:image001.jpg@01D2912B.17505E90]




-Original Message-

From: Jason Wee 

Sent: Monday, June 15, 2020 6:49 PM

To: Tomcat Users List 

Subject: Re: Issue found during migration of Tomcat version 6.0.35 to 8.5.5



guess looks like jar not found, full stacktrace would be helpful.



On Mon, Jun 15, 2020 at 8:17 PM Lavitesh Verma 

wrote:



> Hi Team,

>

>

>

> Below are the details of the system and tomcat version

>

> Old tomcat version: *Apache Tomcat/6.0.35*

>

> New tomcat version: *Apache Tomcat/8.5.5*

>

> Operating System: *SunOS *

>

> OS Version: *5.10*

>

> Architecture: *sparcv9*

>

> JVM Version: *1.8.0_101-b13*

>

> Vendor: *Oracle Corporation*

>

>

>

> We are trying to migrate Apache Tomcat version 6.0.35 to 8.5.5.

>

>

>

> We found the issue javax.xml.stream.FactoryConfigurationError:

> Provider com.ctc.wstx.stax.WstxInputFactory not found in localhost logs.

>

>

>

>

>

> Could you please assist on how we could resolve the issue.

>

>

>

> Thanks & Regards

>

> *Lavitesh Verma*

>

> Software Engineering Associate

>

> Amdocs Global SmartOps

>

> [image: download12]+91.9810157771

>

> *OOO - 06/16 - 06/19*

>

> [image: cid:image001.jpg@01D2912B.17505E90]

>

>

>

> *This email and the information contained herein is proprietary and

> confidential and subject to the Amdocs Email Terms of Service, which

> you may review at*

> *https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww

> .amdocs.com%2Fabout%2Femail-terms-of-service*data=02%7C01%7CLavit

> esh.Verma%40amdocs.com%7Cf5593255a1244392bb8a08d8113145f6%7Cc8eca3ca12

> 7646d59d9da0f2a028920f%7C0%7C0%7C637278250614631760sdata=%2B6rV%2

> Bbnayil4ZJr7yAuCsl2YyE86CZV19JWANZPz%2BIo%3Dreserved=0

> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww

> .amdocs.com%2Fabout%2Femail-terms-of-servicedata=02%7C01%7CLavite

> sh.Verma%40amdocs.com%7Cf5593255a1244392bb8a08d8113145f6%7Cc8eca3ca127

> 646d59d9da0f2a028920f%7C0%7C0%7C637278250614631760sdata=Wtzp%2BGE

> %2BjEvBwZwExHs1jlNLsN5wxGZvYhHK7SAwfxM%3Dreserved=0>

>
This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at 
https://www.amdocs.com/about/email-terms-of-service 
<https://www.amdocs.com/about/email-terms-of-service>
15-Jun-2020 07:34:45.122 SEVERE [http-nio-7080-exec-10] 
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for 
servlet [MainControllerServlet] in context with path [/porequest] threw 
exception [Servlet execution threw an exception] with root cause
 javax.xml.stream.FactoryConfigurationError: Provider 
com.ctc.wstx.stax.WstxInputFactory not found
at javax.xml.stream.XMLInputFactory.newInstance(Unknown Source)
at 
com.sun.xml.internal.ws.util.xml.XmlUtil.newXMLInputFactory(XmlUtil.java:423)
at 
com.sun.xml.internal.ws.api.streaming.XMLStreamReaderFactory.getXMLInputFactory(XMLStreamReaderFactory.java:116)
at 
com.sun.xml.internal.ws.api.streaming.XMLStreamReaderFactory.access$000(XMLStreamReaderFactory.java:62)
at 
com.sun.xml.internal.ws.api.streaming.XMLStreamReaderFactory$1.initialValue(XMLStreamReaderFactory.java:77)
at 
com.sun.xml.internal.ws.api.streaming.XMLStreamReaderFactory$1.initialValue(XMLStreamReaderFactory.java:72)
at 
com.sun.xml.internal.ws.api.streaming.ContextClassloaderLocal.createNewInstance(ContextClassloaderLocal.java:61)
at 
com.sun.xml.internal.ws.api.streaming.ContextClassloaderLocal.get(ContextClassloaderLocal.java:47)
at 
com.sun.xml.internal.ws.api.streaming.XMLStreamReaderFactory.get(XMLStreamReaderFactory.java:137)
at 
com.sun.xml.internal.ws.api.streaming.XMLStreamReaderFactory.create(XMLStreamReaderFactory.java:160)
at 
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.createReader(RuntimeWSDLParser.java:1023)
at 
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.resolveWSDL(RuntimeWSDLParser.java:385)
at 
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:216)
at 
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:194)
at 
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:163)
at 
com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:348)
at 
com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:306)
at 
com.sun.xml.internal.ws.client.WSSe

RE: [tomcat-users] Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[Lavitesh Verma]

Hi Jason,

We have updated the xercesImpl from version 2.6.2 to 2.12.0 for the migration 
and no new jars were added for the new environment.

We didn't use Woodstox StAX jar with tomcat 6.0.35 and did not face any such 
issue.

PFA the complete Stack Trace for the Issue.

Thanks & Regards
Lavitesh Verma
Software Engineering Associate
Amdocs Global SmartOps
[download12]+91.9810157771
OOO - 06/16 - 06/19
[cid:image001.jpg@01D2912B.17505E90]

From: Jason Pyeron 
Sent: Monday, June 15, 2020 6:15 PM
To: 'Tomcat Users List' 
Cc: 'RUBIN, JACOB' ; lsrv...@list.att.com; Vasudev Wadhawan 

Subject: RE: [tomcat-users] Issue found during migration of Tomcat version 
6.0.35 to 8.5.5

Sounds like you have added Jars to the old environment that are not in the new 
environment.

What is the offending code that causes the error?

What were your customizations against the 6.0.35 environment?

Is the Woodstox StAX jar in the web application or Tomcat lib directory? Where 
was it previously?

Did you test this before you migrated causing this "urgent" issue? What is 
different between your test and this urgent outage's configuration.

-Jason

From: Lavitesh Verma [mailto:lavitesh.ve...@amdocs.com]
Sent: Monday, June 15, 2020 8:16 AM
To: users@tomcat.apache.org<mailto:users@tomcat.apache.org>
Cc: RUBIN, JACOB mailto:jr2...@att.com>>; 
lsrv...@list.att.com<mailto:lsrv...@list.att.com>; Vasudev Wadhawan 
mailto:vasudev.wadha...@amdocs.com>>
Subject: [tomcat-users] Issue found during migration of Tomcat version 6.0.35 
to 8.5.5
Importance: High

Hi Team,

Below are the details of the system and tomcat version
Old tomcat version: Apache Tomcat/6.0.35
New tomcat version: Apache Tomcat/8.5.5
Operating System: SunOS
OS Version: 5.10
Architecture: sparcv9
JVM Version: 1.8.0_101-b13
Vendor: Oracle Corporation

We are trying to migrate Apache Tomcat version 6.0.35 to 8.5.5.

We found the issue javax.xml.stream.FactoryConfigurationError: Provider 
com.ctc.wstx.stax.WstxInputFactory not found in localhost logs.

[cid:image004.jpg@01D6433C.E23C4DF0]

Could you please assist on how we could resolve the issue.

Thanks & Regards
Lavitesh Verma
Software Engineering Associate
Amdocs Global SmartOps
[download12]+91.9810157771
OOO - 06/16 - 06/19
[cid:image001.jpg@01D2912B.17505E90]

This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at 
https://www.amdocs.com/about/email-terms-of-service<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.amdocs.com_about_email-2Dterms-2Dof-2Dservice%26d%3DDwMFaQ%26c%3DLFYZ-o9_HUMeMTSQicvjIg%26r%3Dq4z4Z_LzvA-puKNZt92-wVsDWO_kmKRO8UvFw6kIv8E%26m%3Dya8xEu8AbtIK6o7mc8CpVi11Dn71LH_Ui1J-uJxXzNg%26s%3DEjDUw37y3DHXzYwFqeqanPK4qeTYOyqb8sJ7gq8J174%26e%3D=02%7C01%7CLavitesh.Verma%40amdocs.com%7C0018b1a5efe1486313dd08d81129f16c%7Cc8eca3ca127646d59d9da0f2a028920f%7C0%7C0%7C637278219127900245=1gEPDIY%2BI%2BFfKW3gB8kiuNPkiMDG8mHSg45Cod4%2BLaI%3D=0>
This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at 
https://www.amdocs.com/about/email-terms-of-service 
<https://www.amdocs.com/about/email-terms-of-service>
15-Jun-2020 07:34:45.122 SEVERE [http-nio-7080-exec-10] 
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for 
servlet [MainControllerServlet] in context with path [/porequest] threw 
exception [Servlet execution threw an exception] with root cause
 javax.xml.stream.FactoryConfigurationError: Provider 
com.ctc.wstx.stax.WstxInputFactory not found
at javax.xml.stream.XMLInputFactory.newInstance(Unknown Source)
at 
com.sun.xml.internal.ws.util.xml.XmlUtil.newXMLInputFactory(XmlUtil.java:423)
at 
com.sun.xml.internal.ws.api.streaming.XMLStreamReaderFactory.getXMLInputFactory(XMLStreamReaderFactory.java:116)
at 
com.sun.xml.internal.ws.api.streaming.XMLStreamReaderFactory.access$000(XMLStreamReaderFactory.java:62)
at 
com.sun.xml.internal.ws.api.streaming.XMLStreamReaderFactory$1.initialValue(XMLStreamReaderFactory.java:77)
at 
com.sun.xml.internal.ws.api.streaming.XMLStreamReaderFactory$1.initialValue(XMLStreamReaderFactory.java:72)
at 
com.sun.xml.internal.ws.api.streaming.ContextClassloaderLocal.createNewInstance(ContextClassloaderLocal.java:61)
at 
com.sun.xml.internal.ws.api.streaming.ContextClassloaderLocal.get(ContextClassloaderLocal.java:47)
at 
com.sun.xml.internal.ws.api.streaming.XMLStreamReaderFactory.get(XMLStreamReaderFactory.java:137)
at 
com.sun.xml.internal.ws.api.streaming.XMLStreamReaderFactory.create(XMLStreamReaderFactory.java:160)
at 
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.createReader(RuntimeWSDLParser.java:1023)
at 
com.sun.xml.internal.ws.wsdl.parse

Re: Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[Jason Wee]

guess looks like jar not found, full stacktrace would be helpful.

On Mon, Jun 15, 2020 at 8:17 PM Lavitesh Verma 
wrote:

> Hi Team,
>
>
>
> Below are the details of the system and tomcat version
>
> Old tomcat version: *Apache Tomcat/6.0.35*
>
> New tomcat version: *Apache Tomcat/8.5.5*
>
> Operating System: *SunOS *
>
> OS Version: *5.10*
>
> Architecture: *sparcv9*
>
> JVM Version: *1.8.0_101-b13*
>
> Vendor: *Oracle Corporation*
>
>
>
> We are trying to migrate Apache Tomcat version 6.0.35 to 8.5.5.
>
>
>
> We found the issue javax.xml.stream.FactoryConfigurationError: Provider
> com.ctc.wstx.stax.WstxInputFactory not found in localhost logs.
>
>
>
>
>
> Could you please assist on how we could resolve the issue.
>
>
>
> Thanks & Regards
>
> *Lavitesh Verma*
>
> Software Engineering Associate
>
> Amdocs Global SmartOps
>
> [image: download12]+91.9810157771
>
> *OOO – 06/16 – 06/19*
>
> [image: cid:image001.jpg@01D2912B.17505E90]
>
>
>
> *This email and the information contained herein is proprietary and
> confidential and subject to the Amdocs Email Terms of Service, which you
> may review at* *https://www.amdocs.com/about/email-terms-of-service*
> 
>

RE: [tomcat-users] Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[Jason Pyeron]

Sounds like you have added Jars to the old environment that are not in the new 
environment.

 

What is the offending code that causes the error?

 

What were your customizations against the 6.0.35 environment?

 

Is the Woodstox StAX jar in the web application or Tomcat lib directory? Where 
was it previously?

 

Did you test this before you migrated causing this “urgent” issue? What is 
different between your test and this urgent outage’s configuration.

 

-Jason

 

From: Lavitesh Verma [mailto:lavitesh.ve...@amdocs.com] 
Sent: Monday, June 15, 2020 8:16 AM
To: users@tomcat.apache.org
Cc: RUBIN, JACOB ; lsrv...@list.att.com; Vasudev Wadhawan 

Subject: [tomcat-users] Issue found during migration of Tomcat version 6.0.35 
to 8.5.5
Importance: High

 

Hi Team,

 

Below are the details of the system and tomcat version 

Old tomcat version: Apache Tomcat/6.0.35

New tomcat version: Apache Tomcat/8.5.5

Operating System: SunOS 

OS Version: 5.10 

Architecture: sparcv9

JVM Version: 1.8.0_101-b13

Vendor: Oracle Corporation

 

We are trying to migrate Apache Tomcat version 6.0.35 to 8.5.5.

 

We found the issue javax.xml.stream.FactoryConfigurationError: Provider 
com.ctc.wstx.stax.WstxInputFactory not found in localhost logs.

 



 

Could you please assist on how we could resolve the issue.

 

Thanks & Regards

Lavitesh Verma

Software Engineering Associate

Amdocs Global SmartOps

+91.9810157771 

OOO – 06/16 – 06/19



 

This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at  
<https://www.amdocs.com/about/email-terms-of-service> 
https://www.amdocs.com/about/email-terms-of-service

Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[Lavitesh Verma]

Hi Team,

Below are the details of the system and tomcat version
Old tomcat version: Apache Tomcat/6.0.35
New tomcat version: Apache Tomcat/8.5.5
Operating System: SunOS
OS Version: 5.10
Architecture: sparcv9
JVM Version: 1.8.0_101-b13
Vendor: Oracle Corporation

We are trying to migrate Apache Tomcat version 6.0.35 to 8.5.5.

We found the issue javax.xml.stream.FactoryConfigurationError: Provider 
com.ctc.wstx.stax.WstxInputFactory not found in localhost logs.

[cid:image004.jpg@01D6433C.E23C4DF0]

Could you please assist on how we could resolve the issue.

Thanks & Regards
Lavitesh Verma
Software Engineering Associate
Amdocs Global SmartOps
[download12]+91.9810157771
OOO - 06/16 - 06/19
[cid:image001.jpg@01D2912B.17505E90]

This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at 
https://www.amdocs.com/about/email-terms-of-service 

Re: Slow startup of webapps (e.g., manager) after migration

[Osipov, Michael]

Am 2019-06-21 um 14:33 schrieb Mark Thomas:

On 21/06/2019 13:13, Osipov, Michael wrote:

Folks,

we're migrating off old hosts to new ones, but remain at 8.5.x (.34 to
.42 at the moment) and Java 8. Surprisingly, an empty Tomcat wih just
manager installed takes way too long too start. More precisely, the
Tomcat is fast, deploying manager app is horribly slow:


That sounds like insufficient entropy.


That was my first idea too...


2019-06-21T13:50:35.233 INFORMATION
[deblndw024v.ad001.siemens.net-startStop-3]
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
web application directory [/var/opt/tomcat-smartld/webapps/manager]
has finished in [47,818] ms
2019-06-21T13:07:40.484 INFORMATION
[deblndw024v.ad001.siemens.net-startStop-1]
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
web application directory [/var/opt/tomcat-smartld/webapps/manager]
has finished in [126,041] ms
2019-06-21T13:17:35.885 INFORMATION
[deblndw024v.ad001.siemens.net-startStop-1]
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
web application directory [/var/opt/tomcat-smartld/webapps/manager]
has finished in [80,368] ms


Which class do I need to set to FINEST to narrow down the cause?

org.apache.catalina.startup.HostConfig.level = FINEST

did not help. If nothing helps, I'd debug the Tomcat code.


If it is happening per webapp then I'd take a look at
SessionIdGeneratorBase but it should log a warning if it takes more than
100ms to start.

A series of 3 thread dumps ~5s apart while the app is starting may also
shed some light. I often find doing a diff between them very enlightening.


I have now done the undeploy/redeploy at least 50 times, the line from 
SessionIdGeneratorBase never appeared in the log file and the issue 
seems to be non-deterministic after a container (HP-UX) restart now. 
Restarting the JVM process doesn't make a difference. I have the feeling 
that this might be related to the HP-UX container which ran for weeks 
now and had to be restarted due to the OpenSSL update.


I will keep on eye on this and re-report when I am able to trace this 
properly. I do have the dumps, but they are pointless because the start 
takes mostly < 2000 ms now.


Thanks for the pointers,

Michael

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

Re: Slow startup of webapps (e.g., manager) after migration

[Mark Thomas]

On 21/06/2019 13:13, Osipov, Michael wrote:
> Folks,
> 
> we're migrating off old hosts to new ones, but remain at 8.5.x (.34 to
> .42 at the moment) and Java 8. Surprisingly, an empty Tomcat wih just
> manager installed takes way too long too start. More precisely, the
> Tomcat is fast, deploying manager app is horribly slow:

That sounds like insufficient entropy.

>> 2019-06-21T13:50:35.233 INFORMATION
>> [deblndw024v.ad001.siemens.net-startStop-3]
>> org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
>> web application directory [/var/opt/tomcat-smartld/webapps/manager]
>> has finished in [47,818] ms
>> 2019-06-21T13:07:40.484 INFORMATION
>> [deblndw024v.ad001.siemens.net-startStop-1]
>> org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
>> web application directory [/var/opt/tomcat-smartld/webapps/manager]
>> has finished in [126,041] ms
>> 2019-06-21T13:17:35.885 INFORMATION
>> [deblndw024v.ad001.siemens.net-startStop-1]
>> org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
>> web application directory [/var/opt/tomcat-smartld/webapps/manager]
>> has finished in [80,368] ms
> 
> Which class do I need to set to FINEST to narrow down the cause?
>> org.apache.catalina.startup.HostConfig.level = FINEST
> did not help. If nothing helps, I'd debug the Tomcat code.

If it is happening per webapp then I'd take a look at
SessionIdGeneratorBase but it should log a warning if it takes more than
100ms to start.

A series of 3 thread dumps ~5s apart while the app is starting may also
shed some light. I often find doing a diff between them very enlightening.

Mark


> Note: I haven't tried any of our own apps for now, but this slow
> deployment gives me creeps.
> 
> FWIW, I am running off:
>> 2019-06-21T13:16:14.371 INFORMATION [main]
>> org.apache.catalina.startup.VersionLoggerListener.log Server
>> version:    Apache Tomcat/8.5.42
>> 2019-06-21T13:16:14.376 INFORMATION [main]
>> org.apache.catalina.startup.VersionLoggerListener.log Server
>> built:  Jun 4 2019 20:29:04 UTC
>> 2019-06-21T13:16:14.377 INFORMATION [main]
>> org.apache.catalina.startup.VersionLoggerListener.log Server
>> number: 8.5.42.0
>> 2019-06-21T13:16:14.377 INFORMATION [main]
>> org.apache.catalina.startup.VersionLoggerListener.log OS
>> Name:   HP-UX
>> 2019-06-21T13:16:14.377 INFORMATION [main]
>> org.apache.catalina.startup.VersionLoggerListener.log OS
>> Version:    B.11.31
>> 2019-06-21T13:16:14.377 INFORMATION [main]
>> org.apache.catalina.startup.VersionLoggerListener.log
>> Architecture:  IA64N
>> 2019-06-21T13:16:14.378 INFORMATION [main]
>> org.apache.catalina.startup.VersionLoggerListener.log Java
>> Home: /opt/java8/jre
>> 2019-06-21T13:16:14.378 INFORMATION [main]
>> org.apache.catalina.startup.VersionLoggerListener.log JVM
>> Version:   1.8.0.17-hp-ux-b1
>> 2019-06-21T13:16:14.379 INFORMATION [main]
>> org.apache.catalina.startup.VersionLoggerListener.log JVM
>> Vendor:    Hewlett Packard Enterprise Company
>> 2019-06-21T13:16:14.386 INFORMATION [main]
>> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded
>> APR based Apache Tomcat Native library [1.2.21] using APR version
>> [1.6.6].
>> 2019-06-21T13:16:14.386 INFORMATION [main]
>> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
>> capabilities: IPv6 [true], sendfile [true], accept filters [false],
>> random [true].
>> 2019-06-21T13:16:14.386 INFORMATION [main]
>> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
>> APR/OpenSSL configuration: useAprConnector [true], useOpenSSL [true]
>> 2019-06-21T13:16:14.401 INFORMATION [main]
>> org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
>> successfully initialized [OpenSSL 1.0.2k  26 Jan 2017]
> 
> I have compiled all native components myself, except for Java and
> OpenSSL. They are provided by HPE in binary form.
> Note: OpenSSL update to 1.0.2r is pending, but this should not be cause
> here.>
> Michael
> 
> -
> 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

Slow startup of webapps (e.g., manager) after migration

[Osipov, Michael]

Folks,

we're migrating off old hosts to new ones, but remain at 8.5.x (.34 to 
.42 at the moment) and Java 8. Surprisingly, an empty Tomcat wih just 
manager installed takes way too long too start. More precisely, the 
Tomcat is fast, deploying manager app is horribly slow:



2019-06-21T13:50:35.233 INFORMATION [deblndw024v.ad001.siemens.net-startStop-3] 
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web 
application directory [/var/opt/tomcat-smartld/webapps/manager] has finished in 
[47,818] ms
2019-06-21T13:07:40.484 INFORMATION [deblndw024v.ad001.siemens.net-startStop-1] 
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web 
application directory [/var/opt/tomcat-smartld/webapps/manager] has finished in 
[126,041] ms
2019-06-21T13:17:35.885 INFORMATION [deblndw024v.ad001.siemens.net-startStop-1] 
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web 
application directory [/var/opt/tomcat-smartld/webapps/manager] has finished in 
[80,368] ms


Which class do I need to set to FINEST to narrow down the cause?
> org.apache.catalina.startup.HostConfig.level = FINEST
did not help. If nothing helps, I'd debug the Tomcat code.

Note: I haven't tried any of our own apps for now, but this slow 
deployment gives me creeps.


FWIW, I am running off:

2019-06-21T13:16:14.371 INFORMATION [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server version:
Apache Tomcat/8.5.42
2019-06-21T13:16:14.376 INFORMATION [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server built:  
Jun 4 2019 20:29:04 UTC
2019-06-21T13:16:14.377 INFORMATION [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server number: 
8.5.42.0
2019-06-21T13:16:14.377 INFORMATION [main] 
org.apache.catalina.startup.VersionLoggerListener.log OS Name:   
HP-UX
2019-06-21T13:16:14.377 INFORMATION [main] 
org.apache.catalina.startup.VersionLoggerListener.log OS Version:
B.11.31
2019-06-21T13:16:14.377 INFORMATION [main] 
org.apache.catalina.startup.VersionLoggerListener.log Architecture:  
IA64N
2019-06-21T13:16:14.378 INFORMATION [main] 
org.apache.catalina.startup.VersionLoggerListener.log Java Home: 
/opt/java8/jre
2019-06-21T13:16:14.378 INFORMATION [main] 
org.apache.catalina.startup.VersionLoggerListener.log JVM Version:   
1.8.0.17-hp-ux-b1
2019-06-21T13:16:14.379 INFORMATION [main] 
org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:
Hewlett Packard Enterprise Company
2019-06-21T13:16:14.386 INFORMATION [main] 
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR based 
Apache Tomcat Native library [1.2.21] using APR version [1.6.6].
2019-06-21T13:16:14.386 INFORMATION [main] 
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: 
IPv6 [true], sendfile [true], accept filters [false], random [true].
2019-06-21T13:16:14.386 INFORMATION [main] 
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL 
configuration: useAprConnector [true], useOpenSSL [true]
2019-06-21T13:16:14.401 INFORMATION [main] 
org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL 
successfully initialized [OpenSSL 1.0.2k  26 Jan 2017]


I have compiled all native components myself, except for Java and 
OpenSSL. They are provided by HPE in binary form.
Note: OpenSSL update to 1.0.2r is pending, but this should not be cause 
here.


Michael

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

Re: Migration from Tomcat 7 to 9 results in more open file descriptors

[Mark Thomas]

On 03/06/2019 22:46, Mark Thomas wrote:
>> Florian,
>>
>>> On 5/23/19 06:59, Florian Trimmel wrote: We were able to figure out
>>> what was causing the file descriptor leak.
>>
>>> The leak has occured in the JSF2 MyFaces Implementation we are
>>> using. It is described here:
>>> https://marc.info/?l=myfaces-dev=152536956716792=2 The problem
>>> was found using this tool: http://file-leak-detector.kohsuke.org/
>>
>> Yup, that'll do it.
>>
>> Thanks for coming back to report your results.
> 
> +1.
> 
> This got me thinking. We should add a debugging section to the Wiki and
> include this tool.

Done:
https://cwiki.apache.org/confluence/display/TOMCAT/Debugging

Additional content welcome.

Mark

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

Re: Migration from Tomcat 7 to 9 results in more open file descriptors

[Mark Thomas]

> Florian,
> 
>> On 5/23/19 06:59, Florian Trimmel wrote: We were able to figure out
>> what was causing the file descriptor leak.
> 
>> The leak has occured in the JSF2 MyFaces Implementation we are
>> using. It is described here:
>> https://marc.info/?l=myfaces-dev=152536956716792=2 The problem
>> was found using this tool: http://file-leak-detector.kohsuke.org/
> 
> Yup, that'll do it.
> 
> Thanks for coming back to report your results.

+1.

This got me thinking. We should add a debugging section to the Wiki and
include this tool.

Mark

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

Re: Migration from Tomcat 7 to 9 results in more open file descriptors

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Florian,

> On 5/23/19 06:59, Florian Trimmel wrote: We were able to figure out
> what was causing the file descriptor leak.
> 
> The leak has occured in the JSF2 MyFaces Implementation we are
> using. It is described here:
> https://marc.info/?l=myfaces-dev=152536956716792=2 The problem
> was found using this tool: http://file-leak-detector.kohsuke.org/

Yup, that'll do it.

Thanks for coming back to report your results.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlz1kpIACgkQHPApP6U8
pFifABAAj3rtiX284coPU1v6lxIA+Xyh7+YBdboS4bOjXBDL3zszIPO8Emwja5Q6
N5zdu1HL48uL/PaYbb4WdhErne7H9116wVM3VJRGEbYDN2QFXm/EawnBQqhET1A6
zk+IFUDpzQYoQUu9ZOjJZlCrlShxzn45YrD9W8AU1lhBCxxDJqKoNQ8hL0kXQNTX
xKZ4ex5xd+nawzap1In7KpsTewAC/X46N6Q4FPbb8N8tArLXdL9ZDg/sBPdQ/JnZ
cIt+L5lorw2OqmTmawXWOK+JN09vY6yaCbZrzt4+PlkVdgP179znkxBc0DLS5/+z
2W/SpGhnuB4LePiu7ISRajYchfwsk338jxXKuUqhFtD+r4BwODWWFdGsdo0GyVk2
dLx7VWIAieJzZng+CyTiayJKYmw6SxslKzEfNFFR5gfqwitKfFUUjtTbB4cLATWR
vrgCyQJGevNMnMYmHPpeiZKBsxfe4psJY5seZ2X9zjb0Y+jKSpGnbheBJ17sah0W
HJvXs8QdR4PEDn6pumpSyFr6k5j6uw6/W++rLRhZVCZcFBDdZFuvjb/qgKS4C8/n
7tqBn1E4iWiTqTaIIfd8H6s5dti8eDFMOqx1wxKREb8fFA1bGJsLEW4zBH25iBCK
g6jiywtDaDXkjLIUrvpiuxBmWEJ0pCGDcv8daHx5mZuWgiFe0JY=
=DN0D
-END PGP SIGNATURE-

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

Re: Migration from Tomcat 7 to 9 results in more open file descriptors

[Florian Trimmel]

Am Do., 23. Mai 2019 um 17:14 Uhr schrieb Christopher Schultz <
ch...@christopherschultz.net>:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Florian,
>
> On 5/23/19 06:59, Florian Trimmel wrote:
> > After migrating from Tomact 7 to Tomcat 9.0.20 (running with same
> > Java Version 1.8.0_25) we have a problem with our JSF2 web
> > application on Linux RHEL 7. After some time we get Exceptions like
> > this:
> >
> >
> >
> > java.io.FileNotFoundException:
> > /f4m/tomcat/tomcat_f4mbs/webapps/ACM/WEB-INF/acm-config.xml (Too
> > many open files)
> >
> > at java.io.FileInputStream.open0(Native Method)
> >
> > at java.io.FileInputStream.open(FileInputStream.java:195)
> >
> > at java.io.FileInputStream.(FileInputStream.java:138)
> >
> > at java.io.FileInputStream.(FileInputStream.java:93)
> >
> >
> >
> >
> >
> > After searching around a while, I have found out that there are
> > many open file descriptors to xhtml files
>
> Do you know if your application opens these files, or are they
> (likely) being opened by Tomcat in response to incoming client
> requests for those files?
>
> > [snip]
> >
> > This is not the complete list - there are many more.
> >
> > The number of listed files goes up and down. For me it seems that
> > xhtml (or one of its used components) has an open file descriptor
> > as long as a page is shown in Browser.
>
> ... and when you close the browser, the fd is closed too? Spooky.
>
> > I already know how to increase the maximum number of open file
> > descriptors, what bothers me is that if I deploy the same
> > application on Tomcat 7 again, I can only see open file descriptors
> > for JAR Files, Sockets, but NEVER for xhtml's.
> >
> > Can someone please explain why this happens?
>
> The obvious explanation would be a fd leak within Tomcat but I see no
> data to support that. The "resources" (aka file-reading)
> implementation changed between Tomcat 7 and 9 and if your application
> is being a little lazy about resource-management, this could cause fds
> to be left open now where they were being cleaned-up for you in the past
> .
>
> Improper caching configuration could also leave file descriptors open,
> but multiple fds open to the same file is the exact opposite of
> caching, so the configuration would have to indeed be particularly bad.
>
> Are you able to attach a profiler to the JVM process? If so, try
> launching Tomcat, attaching the profiler, and then making some
> requests. The profiler ought to be able to show you where certain
> objects were allocated and you can track-down where e.g.
> FileInputStream objects are created. If they are being created in
> Tomcat's code without being called from your application (e.g. from
> within DefaultServlet), then something is very wrong.
>
> But at this point, the new resources implementation is fairly mature
> and I wouldn't expect it to leak like this.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzmuOUACgkQHPApP6U8
> pFgqwg/9FUmsAS/mOin0NKIlU1LOPRyf72/gT+8n5vyquC+CBk8jWFBqxNFZEoGV
> Fc+5rfwF1pqK8aTgDM2dzEb4bJ9s3sVGY/SLvspGyeRU81/uqZW4CnSGIL7VzrJk
> xpTi4hk02rNFbq8yNjMDqCUx2t41Bi8NUVJh9TUtHRPZRQWhy3JsG32HQdPrPklj
> AipBl/NkpizGZQlAGqMz87rYvFIEz1e1hA47CPfUFg7x8WCib7X9JcHHZYF5gQjS
> y/h5IdRT9A6F1Lu2arW00cFPSfoYoZA+gHWzQMGHmTXSQplwzF8h9tafNLXf4u4u
> Knav+K3KTPeskzuKUqxLTa2GwX6MNLnEnw3uicvuHT13JYncLTz6LCgSE31/xgj9
> EcnME4zQca7X14DrHaldwwejuvqL/HYTVkYc6YOt24E3FCAbkcPg8MOYo1QjT408
> u1GXl+n4HBgNsHO//FsAVYDEm14YXmvWyB+33aVc9OKbCk1X+vRbkq8Fe//Bz05T
> 72Mb5potJWGFhHVseSuiYp1XyhlgSWDqzQkqoYV8ffm5ecfbYd96gRqFxveK0S2I
> 9/9X6k8a/6lqQMidfNoqKfoA1G+5soI436j6LYlna4vqIgB+ZjCoTmnzJh4+NMy7
> VcAZ+S2uRb3bnTccsttcNbCKOM9BD9C9rSosS3N48XDl3u5ooL4=
> =B0WJ
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Christopher,
Thank you for your quick reply
We were able to figure out what was causing the file descriptor leak.

The leak has occured in the JSF2 MyFaces Implementation we are using.
It is described here: https://marc.info/?l=myfaces-dev=152536956716792=2
The problem was found using this tool:
http://file-leak-detector.kohsuke.org/


Thanks,
Florian

Re: Migration from Tomcat 7 to 9 results in more open file descriptors

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Florian,

On 5/23/19 06:59, Florian Trimmel wrote:
> After migrating from Tomact 7 to Tomcat 9.0.20 (running with same
> Java Version 1.8.0_25) we have a problem with our JSF2 web
> application on Linux RHEL 7. After some time we get Exceptions like
> this:
> 
> 
> 
> java.io.FileNotFoundException: 
> /f4m/tomcat/tomcat_f4mbs/webapps/ACM/WEB-INF/acm-config.xml (Too
> many open files)
> 
> at java.io.FileInputStream.open0(Native Method)
> 
> at java.io.FileInputStream.open(FileInputStream.java:195)
> 
> at java.io.FileInputStream.(FileInputStream.java:138)
> 
> at java.io.FileInputStream.(FileInputStream.java:93)
> 
> 
> 
> 
> 
> After searching around a while, I have found out that there are
> many open file descriptors to xhtml files

Do you know if your application opens these files, or are they
(likely) being opened by Tomcat in response to incoming client
requests for those files?

> [snip]
> 
> This is not the complete list - there are many more.
> 
> The number of listed files goes up and down. For me it seems that
> xhtml (or one of its used components) has an open file descriptor
> as long as a page is shown in Browser.

... and when you close the browser, the fd is closed too? Spooky.

> I already know how to increase the maximum number of open file
> descriptors, what bothers me is that if I deploy the same
> application on Tomcat 7 again, I can only see open file descriptors
> for JAR Files, Sockets, but NEVER for xhtml's.
> 
> Can someone please explain why this happens?

The obvious explanation would be a fd leak within Tomcat but I see no
data to support that. The "resources" (aka file-reading)
implementation changed between Tomcat 7 and 9 and if your application
is being a little lazy about resource-management, this could cause fds
to be left open now where they were being cleaned-up for you in the past
.

Improper caching configuration could also leave file descriptors open,
but multiple fds open to the same file is the exact opposite of
caching, so the configuration would have to indeed be particularly bad.

Are you able to attach a profiler to the JVM process? If so, try
launching Tomcat, attaching the profiler, and then making some
requests. The profiler ought to be able to show you where certain
objects were allocated and you can track-down where e.g.
FileInputStream objects are created. If they are being created in
Tomcat's code without being called from your application (e.g. from
within DefaultServlet), then something is very wrong.

But at this point, the new resources implementation is fairly mature
and I wouldn't expect it to leak like this.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzmuOUACgkQHPApP6U8
pFgqwg/9FUmsAS/mOin0NKIlU1LOPRyf72/gT+8n5vyquC+CBk8jWFBqxNFZEoGV
Fc+5rfwF1pqK8aTgDM2dzEb4bJ9s3sVGY/SLvspGyeRU81/uqZW4CnSGIL7VzrJk
xpTi4hk02rNFbq8yNjMDqCUx2t41Bi8NUVJh9TUtHRPZRQWhy3JsG32HQdPrPklj
AipBl/NkpizGZQlAGqMz87rYvFIEz1e1hA47CPfUFg7x8WCib7X9JcHHZYF5gQjS
y/h5IdRT9A6F1Lu2arW00cFPSfoYoZA+gHWzQMGHmTXSQplwzF8h9tafNLXf4u4u
Knav+K3KTPeskzuKUqxLTa2GwX6MNLnEnw3uicvuHT13JYncLTz6LCgSE31/xgj9
EcnME4zQca7X14DrHaldwwejuvqL/HYTVkYc6YOt24E3FCAbkcPg8MOYo1QjT408
u1GXl+n4HBgNsHO//FsAVYDEm14YXmvWyB+33aVc9OKbCk1X+vRbkq8Fe//Bz05T
72Mb5potJWGFhHVseSuiYp1XyhlgSWDqzQkqoYV8ffm5ecfbYd96gRqFxveK0S2I
9/9X6k8a/6lqQMidfNoqKfoA1G+5soI436j6LYlna4vqIgB+ZjCoTmnzJh4+NMy7
VcAZ+S2uRb3bnTccsttcNbCKOM9BD9C9rSosS3N48XDl3u5ooL4=
=B0WJ
-END PGP SIGNATURE-

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

Migration from Tomcat 7 to 9 results in more open file descriptors

[Florian Trimmel]

Hi,



After migrating from Tomact 7 to Tomcat 9.0.20 (running with same Java
Version 1.8.0_25) we have a problem with our JSF2 web application on Linux
RHEL 7. After some time we get Exceptions like this:



java.io.FileNotFoundException:
/f4m/tomcat/tomcat_f4mbs/webapps/ACM/WEB-INF/acm-config.xml (Too many open
files)

at java.io.FileInputStream.open0(Native Method)

at java.io.FileInputStream.open(FileInputStream.java:195)

at java.io.FileInputStream.(FileInputStream.java:138)

at java.io.FileInputStream.(FileInputStream.java:93)





After searching around a while, I have found out that there are many open
file descriptors to xhtml files, by executing this command (where 4025 is
the Tomcat process ID):



ls -l /proc/4025/fd





lr-x--. 1 f4mHttp f4mHttp 64 May 16 08:58 238 ->
/usr/java/jdk1.8.0_25/jre/lib/resources.jar

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 239 -> pipe:[3661823]

lr-x--. 1 f4mHttp f4mHttp 64 May 16 08:58 24 ->
/f4m/tomcat/tomcat_f4mbscrm/lib/websocket-api.jar

l-wx--. 1 f4mHttp f4mHttp 64 May 16 09:01 240 -> pipe:[3661823]

lrwx--. 1 f4mHttp f4mHttp 64 May 16 09:01 241 -> anon_inode:[eventpoll]

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 243 -> pipe:[3661824]

l-wx--. 1 f4mHttp f4mHttp 64 May 16 09:01 244 -> pipe:[3661824]

lrwx--. 1 f4mHttp f4mHttp 64 May 16 09:01 245 -> anon_inode:[eventpoll]

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 246 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/msgBox.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 247 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/msgBox.xhtml

lrwx--. 1 f4mHttp f4mHttp 64 May 16 09:01 248 -> socket:[3667364]

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 249 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/searchpage.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 08:58 25 ->
/f4m/tomcat/tomcat_f4mbscrm/lib/jasper.jar

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 250 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/searchpage.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 251 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/portal/nav/portalheader.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 252 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/portal/customizing/nav/menu.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 253 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/calendar.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 254 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/nav/bottomPanel.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 255 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/nav/bottomPanel.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 256 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/msgBox.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 257 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/calendar.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 258 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/calendar.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 259 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/calendar.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 08:58 26 ->
/f4m/tomcat/tomcat_f4mbscrm/lib/ecj-4.9.jar

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 260 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/calendar.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 261 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/calendar.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 262 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/common/barcodefunction_incl.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 263 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/portal/nav/portalfooterAll.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 264 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/partner/crmpartner.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 266 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/partner/crmpartner.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 267 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/portal/nav/portalheader.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 268 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/portal/customizing/nav/menu.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 08:58 27 ->
/f4m/tomcat/tomcat_f4mbscrm/lib/catalina-ha.jar

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 274 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/partner/crmpartner_topnav.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 275 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/msgBox.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 276 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/msgBox.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 277 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/calendar.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 278 

Re: migration from tomcat 7.0 to 8.5

[Mark Thomas]

On 04/10/2017 15:53, Aquatic Safaris Diver wrote:
> 
> I've read the migration manuals and have tried to make the changes to
> my configuration to work correctly in tomcat v8.5, but it's not.  I'm
> not an experton XML files and JDK so please help me.   I'm sure this is crazy 
> simple
> for you experts.

Why make life difficult for yourself? Just package those libraries in
your web application's WEB-INF/lib directory.

Mark

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

migration from tomcat 7.0 to 8.5

[Aquatic Safaris Diver]

I've read the migration manuals and have tried to make the changes to
my configuration files to work correctly in tomcat v8.5, but it's not.  I'm
not an expert on XML files and JDK so please help me.   I'm sure this is
crazy simple
for you experts.

The server.xml conf file is OK between the two versions.   But my
application's deployment is having problems.

In my tomcat v7 conf/Catalina/localhost directory, I have ed.xml file
for my application containing:








So the question is what to do with Loader section.  
After spending about 6 hours and reading tons of other web posts from
others trying to do the same thing,
I finally have something working, kinda.  My web application at least
deploys when tomcat starts.
The Loader part in the .xml was replaced with:


    
    
    
    
    
    



I think I'm up to 12 hours messing with this and reading everything I
can get my hands on.
I still don't have a good understanding of what webAppMount is or what I
should set it to, and,
for that matter, internalPath.  I changed PostResources to JarResources
and nothing changed.  
The jar files are not getting found or the classes in the jar files are
not getting found.  
When I access the JSP page that need to resolve classes in these .jar's,
I get

org.apache.jasper.JasperException: Unable to compile class for JSP:

An error occurred at line: [20] in the generated java file: 
[/work/Catalina/localhost/ed/org/apache/jsp/charters_jsp.java]
Only a type can be imported. com.google.api.client.json.JsonFactory resolves to 
a package

Line 20 is:
import com.google.api.client.json.JsonFactory;


I'd really like to get off Tomcat 7 before it's EOL.

Please help with what I need to do to make my app work in Tomcat 8.5.X

Thanks,
Paul






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

RE: Migration tomcat 7 to 9 : export static files

[andre seame]

My  server.xml is the delivered server.xml file + my declaration of testresult
===




  
  
  
  
  
  
  
  
  

  
  


  

  
  





















  
  

  
  


  

  










  

  


===
thanks
PHL.


De : Christopher Schultz 
Envoyé : jeudi 3 janvier 2019 14:52
À : users@tomcat.apache.org
Objet : Re: Migration tomcat 7 to 9 : export static files

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 1/3/19 03:56, andre seame wrote:
> Hello,
>
> In tomcat 7, I have a server.xml config file. In the host section I
> have
>
> 
>
> So, I can access to static file :
> http://server:8080/testresults/myfile.png, where the file is stored
> in d:\TESTRESULTS\myfile.png
>
> When using the HTML gui management interface
> -http://server:8080/manager/html), I see the list of applications
> that are running on my tomcat server. There is my application and a
> "testresult" application.
>
> In tomcat 9, I try the same configuration, but I get an error 404
> when I try to access to http://server:8080/testresults/myfile.png
>
> The
> http://server-tomat-9:8080/manager/html<http://server:8080/manager/htm
l>
> gives only y application (no more /testresults).
>
> My bug ? Tomcat 9 bug ? Insuffisant configuration or new security
> mechanism for tomcat 9.

What does your Tomcat 9 conf/server.xml file look like?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwuIZwACgkQHPApP6U8
pFhlXg//boCo965yTmAs+HVb925dSHemgVaWqNHsO0P6sfX58F6oxoNwcs6ZI2h7
GAgXEeSXUVwSwisRGjcRuLcxRf/o2nm+oU6p2OlK7WE+t9xulYsN7YUhVq09Mba9
bUNpY7wK2gk853B3ih4GtmVLOq3qJu+w1aanasoSJUAEC9SY6xg18qZgFc64oAgr
Sz4ij0gfQv3uvb+3mbSTe0LSBA0yApHMTQ8ETo9fXf7Z352FwUAeWM2Lx6WVDlvG
vCXLCDFRmkRvWzE6K5dOlQMMdbuFIs92peoFr/MPztdVYiiZIvR5Zl0xLZEPP/va
of+Va/JKgkJy1JZ0dt0VaqTPP8LgoauprvnyyhhzQYUz/LLmDGq6PGGmoihddKQ0
3Kkv3c+ug0Et+28Ef+aRLk8AJH7Joy16xNOutZbZY2+Nskc67X9Lc3OmSy2R0CEs
tSjo+ZflCAfXBUF2N8LdmtqMdI2XCpOijlTqkl00f3z/5keW0nwLfo7QUVyagDM4
ONg2cj4RbQgLqIgLTEQnIdm6TzWDOad+yOXBPM/8WAS+Qvo4p3aIgOzHBOL/JX89
+3bqMzNWTHGQpEELFtAsaGKQoW/ne1zSiK+uT+S7NR33KJnEBihgQC6LChvqrt5X
uk6b9KGHbphGVVNhWOCfctmI5nSsENXqgrHphoYKjtiu1fCOxVw=
=TDXs
-END PGP SIGNATURE-

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

Re: Migration tomcat 7 to 9 : export static files

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 1/3/19 03:56, andre seame wrote:
> Hello,
> 
> In tomcat 7, I have a server.xml config file. In the host section I
> have
> 
> 
> 
> So, I can access to static file :
> http://server:8080/testresults/myfile.png, where the file is stored
> in d:\TESTRESULTS\myfile.png
> 
> When using the HTML gui management interface
> -http://server:8080/manager/html), I see the list of applications
> that are running on my tomcat server. There is my application and a
> "testresult" application.
> 
> In tomcat 9, I try the same configuration, but I get an error 404
> when I try to access to http://server:8080/testresults/myfile.png
> 
> The
> http://server-tomat-9:8080/manager/html
> gives only y application (no more /testresults).
> 
> My bug ? Tomcat 9 bug ? Insuffisant configuration or new security
> mechanism for tomcat 9.

What does your Tomcat 9 conf/server.xml file look like?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwuIZwACgkQHPApP6U8
pFhlXg//boCo965yTmAs+HVb925dSHemgVaWqNHsO0P6sfX58F6oxoNwcs6ZI2h7
GAgXEeSXUVwSwisRGjcRuLcxRf/o2nm+oU6p2OlK7WE+t9xulYsN7YUhVq09Mba9
bUNpY7wK2gk853B3ih4GtmVLOq3qJu+w1aanasoSJUAEC9SY6xg18qZgFc64oAgr
Sz4ij0gfQv3uvb+3mbSTe0LSBA0yApHMTQ8ETo9fXf7Z352FwUAeWM2Lx6WVDlvG
vCXLCDFRmkRvWzE6K5dOlQMMdbuFIs92peoFr/MPztdVYiiZIvR5Zl0xLZEPP/va
of+Va/JKgkJy1JZ0dt0VaqTPP8LgoauprvnyyhhzQYUz/LLmDGq6PGGmoihddKQ0
3Kkv3c+ug0Et+28Ef+aRLk8AJH7Joy16xNOutZbZY2+Nskc67X9Lc3OmSy2R0CEs
tSjo+ZflCAfXBUF2N8LdmtqMdI2XCpOijlTqkl00f3z/5keW0nwLfo7QUVyagDM4
ONg2cj4RbQgLqIgLTEQnIdm6TzWDOad+yOXBPM/8WAS+Qvo4p3aIgOzHBOL/JX89
+3bqMzNWTHGQpEELFtAsaGKQoW/ne1zSiK+uT+S7NR33KJnEBihgQC6LChvqrt5X
uk6b9KGHbphGVVNhWOCfctmI5nSsENXqgrHphoYKjtiu1fCOxVw=
=TDXs
-END PGP SIGNATURE-

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

Migration tomcat 7 to 9 : export static files

[andre seame]

Hello,

In tomcat 7, I have a server.xml config file. In the host section I have



So, I can access to static file : http://server:8080/testresults/myfile.png, 
where the file is stored in d:\TESTRESULTS\myfile.png

When using the HTML gui management interface -http://server:8080/manager/html), 
I see the list of applications that are running on my tomcat server. There is 
my application and a "testresult" application.

In tomcat 9, I try the same configuration, but I get an error 404 when I try to 
access to http://server:8080/testresults/myfile.png

The http://server-tomat-9:8080/manager/html 
gives only y application (no more /testresults).

My bug ? Tomcat 9 bug ? Insuffisant configuration or new security mechanism for 
tomcat 9.

Have you pointers ? or ideas ?
Thanks.

Re: Tomcat 5.5.17 migration to 6.0.53

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 7/24/18 1:22 PM, David Babooram wrote:
> -Original Message- From: Christopher Schultz
> [mailto:ch...@christopherschultz.net] Sent: Tuesday, 24 July 2018
> 12:41 PM To: users@tomcat.apache.org Subject: [EXTERNAL] Re: Tomcat
> 5.5.17 migration to 6.0.53
> 
> David,
> 
> On 7/24/18 10:54 AM, David Babooram wrote:
>> I will try to be as clear as possible.
> 
> :)
> 
>> The files that were originally in 
>> /usr/local/tomcat/jakarta-tomcat-5.5.17/webapps/MYAPP/WEB-INF/lib
>>
>> 
were copied by default when I migrated the app to
>> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/
> 
> Good, that's what you probably should have done.
> 
>> When I ran MYAPP I got the error from my previous email.
> 
>> I then mv all the files from 
>> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib 
>> into a temp directory , in attempt to make it use the global lib
>> , but still the same error.
> 
> Hmm. I'd expect lots of problems when removing all required
> libraries from your application.
> 
> Did you copy the "work" directory from the Tomcat 5.5
> installation? (I'm guessing not.)
> 
>> My next idea was to place the files from 
>> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib 
>> into  /usr/local/tomcat/apache-tomcat-6.0.53/lib , but with the
>> new structure I am unsure what belongs where.
> 
> Definitely undo that... it's likely to break your Tomcat
> installation. You should basically never add anything other than
> maybe a JDBC driver to your CATALINA_BASE/lib directory. Definitely
> nothing application-specific.
> 
> I'd recommend removing all the files from CATALINA_BASE/lib and
> re-extracting the distro package you downloaded just to reset
> things back to the way they were.
> 
> ->
> 
> ok I did not place it in CAT/lib yet so everything is in tact.
> However in the 5.5 there was a server/lib folder that has some jar
> files what do I do with these? I assume we need to put that in the
> /lib but not sure server/lib/ catalina-ant.jar  catalina.jar
> commons-modeler.jar   servlets-invoker.jar  tomcat-ajp.jar
> tomcat-http.jar catalina-ant-jmx.jar  catalina-optional.jar
> servlets-cgi.renametojar  servlets-ssi.renametojar  tomcat-apr.jar
> tomcat-jkstatus-ant.jar catalina-cluster.jar
> catalina-storeconfig.jar  servlets-default.jar
> servlets-webdav.jar   tomcat-coyote.jar  tomcat-util.jar


That is Tomcat itself, at version 5.5. Leave all that stuff there.
Nothing should be copied to the new installation.

>> FYI : in my original
>> /usr/local/tomcat/jakarta-tomcat-5.5.17/common I have the
>> following directories
> 
>> classes  endorsed  i18n  lib
> 
> 
> 
> 
>> activation.jar antlr-2.7.2.jar
> 
> I think something got lost in the copy/paste. If you had files in
> the "common" loader in Tomcat 5.5 then you might have a bit of work
> figuring out which files are required by the application and which
> are expected to be supplied by the container (Tomcat).
> 
> I'm going to attempt to group these files into 2 categories: things
> that ought to be in your web application's WEB-INF/lib directory
> and which files should be ignored (because Tomcat and/or the JVM
> should be supplying them). Here goes:
> 
> 1. Files supplied by the JVM and/or Tomcat (and should be ignored
> from your old installation):
> 
>> activation.jar (Modern JVMs supply this) 
>> el-api-2.2.1-b04.jar   (Tomcat is required to supply the EL
>> APIs)
> 
> -->
> 
> Both those files are not present in /lib directory, I recheck the
> extracted data, this is what is present in /lib
> 
> ls lib annotations-api.jar  catalina-ha.jar  catalina-tribes.jar
> el-api.jar jasper.jar   server   tomcat-coyote.jar
> tomcat-i18n-es.jar  tomcat-i18n-ja.jar catalina-ant.jar
> catalina.jar ecj-4.3.1.jarjasper-el.jar  jsp-api.jar
> servlet-api.jar  tomcat-dbcp.jartomcat-i18n-fr.jar
> 
> A bit strange that you mention it should be in the /lib and its not
> there by default.

activation.jar is now included with your JRE. Well, it should be. What
version of Java are you running? If the answer isn't at least Java 8,
then you need to upgrade.

el-api.jar is supplied with Tomcat. At least, it's supplied with
modern, supported Tomcats. Another reason to abandon Tomcat 6?

Tomcat 6 is documented to support EL version 2.1 and your application
seems to need EL version 2.2 (or higher). Another reason to abandon
Tomcat 6?

> So I just moved activations.jar and el-api-2 to /lib and then
> place back all the webap

Re: Tomcat 5.5.17 migration to 6.0.53

[Christopher Schultz]

you might want to look into.
> 
>> mailapi.jar
> 
> Is that javamail?
> 
>> smtp.jar
> 
> Is that *also* javamail?
> 
>> ojdbc14.jar
> 
> Is that the Oracle JDBC driver? If the container (Tomcat) is
> managing your connection-pool, then you'll want to put this file
> into CATALINA_BASE/lib and *nowhere else*.
> 
>> junit.jar
> 
> Are you sure you need the junit runtime in your running
> application? My guess is "no" and you might want to see if things
> still work is you remove this. But it can wait until later.
> 
> Finally (and I say this as a proud Apache Struts 1.x user) it's 
> important that you understand that (a) Apache Struts 1.x has
> reached EOL and (b) there are unpatched, publicly-reported
> security vulnerabilities in the version you are using (1.3.10). You
> should really research those vulnerabilities and make sure that you
> have mitigated them all, or you risk exposing your users and
> servers to exploitation.
> 
> Hope that helps, -chris
> 
>> -Original Message- From: Christopher Schultz 
>> [mailto:ch...@christopherschultz.net] Sent: Monday, 23 July 2018 
>> 2:29 PM To: users@tomcat.apache.org Subject: [EXTERNAL] Re:
>> Tomcat 5.5.17 migration to 6.0.53
> 
>> David,
> 
>> On 7/23/18 12:51 PM, David Babooram wrote:
>>> Hello
> 
>>> I have begun a migration from 5.5 to 6. Yes I know 6 is EOL
>>> but the migration from 5.5 to 6 has some more documentation
>>> compared to 5.5 to the latest version.
> 
>>> I followed the standard migration of libs and classes from 
>>> /common /shared etc to the new /lin directory for 6..
> 
>>> The server engine runs and I can see the examples web pages
>>> come up.
> 
>>> When I migrated my production webapps to the 6.0 instance
>>> however I get the following error.
> 
>>> HTTP Status 500 - java.lang.LinkageError: loader constraint 
>>> violation: when resolving interface method 
>>> "javax.servlet.jsp.JspApplicationContext.getExpressionFactory()Ljava
x
>
>>> 
/
> 
>>> 
> el/ExpressionFactory;"
> 
> 
>> the class loader (instance of 
>> org/apache/jasper/servlet/JasperLoader)
>>> of the current class, org/apache/jsp/index_jsp, and the class 
>>> loader (instance of 
>>> org/apache/catalina/loader/StandardClassLoader) for resolved 
>>> class, javax/servlet/jsp/JspApplicationContext, have different 
>>> Class objects for the type javax/el/ExpressionFactory used in
>>> the signature
> 
>>> Any insight on this is welcomed.
> 
>>> I notice in that my app has its own lib directory, does this 
>>> means that there is a conflict with the lib files from the
>>> base directory ?
> 
>> Possibly. What files do you have in your app's WEB-INF/lib 
>> directory?
> 
>> -chris
> 
>> -
>
>> 
> 
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
>> 
> 
>> Notice of Confidentiality:
> 
>> The information contained in this communication is intended
>> solely for the use of the individual or entity to whom it is
>> addressed and others authorized to receive it. It may contain
>> confidential or legally privileged information. If you are not
>> the intended recipient you are hereby notified that any
>> disclosure, copying, distribution or taking any action in
>> reliance on the contents of this information is strictly
>> prohibited and may be unlawful. If you have received this
>> communication in error, please notify us immediately by
>> responding to this email and then delete it from your system.
> 
>> -
>
>> 
> 
> 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
> 
> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltYeosACgkQHPApP6U8
pFi6Bw/9Eb48b9evt2ALtv/abY3+41mnfyLTjpjUlGCLAU/rRxYOJbX/CMC0TBRM
4VFohsTUlSj5DObWsN0MQJvJN1oBfUc8OJAaUrMJcfYpDsW48AAbuFevf3mjgLzC
yGuLR03PQ+EK1s/uv/jxGnbkkIpVdxzNafAdBdk7zByVzrca0+vKIP4IZswy4Vbr
HNBYGS4nZXhWV50NN8YsixXWvI79ONkyOl7ShO4YODppQRN+W3rHU0oYYFqpgfED
0juux5ehdIOz9HaW9n/k653zRQllZYhQFpgv67rXpNDYdYs25Diwiz2SRzKmLLln
qiUzB7ZkuYxj1ST15fBc6KAvQ1OH8FCIqndkgxMAe3uCWFW+OLCU4Di745qKzfPh
VA9ABpqeWFAGmAQWCmc6cPBvm0j9RB1kAOqAIJOyCHzvSqUcJ100tCcDaiSeKksV
ftwuZZz9EYAj2mOCmwOruDOlSUqQ/hxrkDkjT21npd79brDwbvSXtUTXfVAuEH/o
MGktMcNZXdz5oCjVmoGLsMc4ppynevB6ox54F4UqO/zw5esRteWN2q8r46PknfGV
HTFbTo+x+xf8acsaMoVQ06FvoxPXFxrUc9noa25G0EHJ6QPa8h3q88EVxZaOJi5y
fDaLceIKxYdtc3wxpm8hrQNhKsUmLFdRvcnHsmbmv4EW2UwLkzg=
=Z5zW
-END PGP SIGNATURE-

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

RE: Re: Tomcat 5.5.17 migration to 6.0.53

[David Babooram]

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Tuesday, 24 July 2018 12:41 PM
To: users@tomcat.apache.org
Subject: [EXTERNAL] Re: Tomcat 5.5.17 migration to 6.0.53

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 7/24/18 10:54 AM, David Babooram wrote:
> I will try to be as clear as possible.

:)

> The files that were originally in
> /usr/local/tomcat/jakarta-tomcat-5.5.17/webapps/MYAPP/WEB-INF/lib
> were copied by default when I migrated the app to 
> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/

Good, that's what you probably should have done.

> When I ran MYAPP I got the error from my previous email.
> 
> I then mv all the files from
> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib
> into a temp directory , in attempt to make it use the global lib , but 
> still the same error.

Hmm. I'd expect lots of problems when removing all required libraries from your 
application.

Did you copy the "work" directory from the Tomcat 5.5 installation?
(I'm guessing not.)

> My next idea was to place the files from 
> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib
> into  /usr/local/tomcat/apache-tomcat-6.0.53/lib , but with the new 
> structure I am unsure what belongs where.

Definitely undo that... it's likely to break your Tomcat installation.
You should basically never add anything other than maybe a JDBC driver to your 
CATALINA_BASE/lib directory. Definitely nothing application-specific.

I'd recommend removing all the files from CATALINA_BASE/lib and re-extracting 
the distro package you downloaded just to reset things back to the way they 
were.

-> 

ok I did not place it in CAT/lib yet so everything is in tact.  
However in the 5.5 there was a server/lib folder that has some jar files what 
do I do with these? I assume we need to put that in the /lib but not sure
server/lib/
catalina-ant.jar  catalina.jar  
commons-modeler.jar   servlets-invoker.jar  tomcat-ajp.jar 
tomcat-http.jar
catalina-ant-jmx.jar  catalina-optional.jar 
servlets-cgi.renametojar  servlets-ssi.renametojar  tomcat-apr.jar 
tomcat-jkstatus-ant.jar
catalina-cluster.jar  catalina-storeconfig.jar  
servlets-default.jar  servlets-webdav.jar   tomcat-coyote.jar  
tomcat-util.jar
>





> FYI : in my original /usr/local/tomcat/jakarta-tomcat-5.5.17/common
> I have the following directories
> 
> classes  endorsed  i18n  lib
> 
> 
> 
> 
> activation.jar antlr-2.7.2.jar

I think something got lost in the copy/paste. If you had files in the "common" 
loader in Tomcat 5.5 then you might have a bit of work figuring out which files 
are required by the application and which are expected to be supplied by the 
container (Tomcat).

I'm going to attempt to group these files into 2 categories: things that ought 
to be in your web application's WEB-INF/lib directory and which files should be 
ignored (because Tomcat and/or the JVM should be supplying them). Here goes:

1. Files supplied by the JVM and/or Tomcat (and should be ignored from your old 
installation):

> activation.jar (Modern JVMs supply this)   
> el-api-2.2.1-b04.jar   (Tomcat is required to supply the EL APIs)

-->   

Both those files are not present in /lib directory, I recheck the 
extracted data, this is what is present in /lib

ls lib
annotations-api.jar  catalina-ha.jar  catalina-tribes.jar  el-api.jar   
  jasper.jar   server   tomcat-coyote.jar  tomcat-i18n-es.jar  
tomcat-i18n-ja.jar
catalina-ant.jar catalina.jar ecj-4.3.1.jar
jasper-el.jar  jsp-api.jar  servlet-api.jar  tomcat-dbcp.jar
tomcat-i18n-fr.jar

A bit strange that you mention it should be in the /lib and its not 
there by default.  

So I just moved activations.jar and el-api-2 to /lib and then place 
back all the webapps libs into its container lib directory , and I THINK its 
working. At least I got the page to come up



>



2. Files that ought to be in WEB-INF/lib in your application:

> antlr-2.7.2.jar axis-ant.jar axis.jar bsf-2.3.0.jar 
> commons-beanutils-1.8.0.jar commons-chain-1.2.jar 
> commons-codec-1.3.jar commons-collections.jar commons-dbcp-1.2.1.jar 
> commons-digester-1.8.jar commons-discovery-0.2.jar 
> commons-fileupload-1.1.1.jar commons-io-1.1.jar commons-lang.jar 
> commons-logging-1.0.4.jar commons-pool-1.2.jar 
> commons-validator-1.3.1.jar edtftpj.jar ibatis-common-2.jar 
> ibatis-dao-2.jar ibatis-sqlmap-2.jar invoice-generator.jar 
> itext-1.3.jar iText-2.1.0.jar j2ssh-ant-0.2.9.jar 
> j2ssh-common-0.2.9.jar j2ssh-core-0.2.9.jar j2ssh-daemon-0.2.9.jar 
> jakarta-oro.jar jaxrpc.jar 

Re: Re: Tomcat 5.5.17 migration to 6.0.53

[David Babooram]

truts 1.x has reached
EOL and (b) there are unpatched, publicly-reported security
vulnerabilities in the version you are using (1.3.10). You should
really research those vulnerabilities and make sure that you have
mitigated them all, or you risk exposing your users and servers to
exploitation.

Hope that helps,
- -chris

> -Original Message- From: Christopher Schultz
> [mailto:ch...@christopherschultz.net] Sent: Monday, 23 July 2018
> 2:29 PM To: users@tomcat.apache.org Subject: [EXTERNAL] Re: Tomcat
> 5.5.17 migration to 6.0.53
>
> David,
>
> On 7/23/18 12:51 PM, David Babooram wrote:
>> Hello
>
>> I have begun a migration from 5.5 to 6. Yes I know 6 is EOL but
>> the migration from 5.5 to 6 has some more documentation compared
>> to 5.5 to the latest version.
>
>> I followed the standard migration of libs and classes from
>> /common /shared etc to the new /lin directory for 6..
>
>> The server engine runs and I can see the examples web pages come
>> up.
>
>> When I migrated my production webapps to the 6.0 instance however
>> I get the following error.
>
>> HTTP Status 500 - java.lang.LinkageError: loader constraint
>> violation: when resolving interface method
>> "javax.servlet.jsp.JspApplicationContext.getExpressionFactory()Ljavax
/
>
>>
el/ExpressionFactory;"
>
>
> the class loader (instance of
> org/apache/jasper/servlet/JasperLoader)
>> of the current class, org/apache/jsp/index_jsp, and the class
>> loader (instance of
>> org/apache/catalina/loader/StandardClassLoader) for resolved
>> class, javax/servlet/jsp/JspApplicationContext, have different
>> Class objects for the type javax/el/ExpressionFactory used in the
>> signature
>
>> Any insight on this is welcomed.
>
>> I notice in that my app has its own lib directory, does this
>> means that there is a conflict with the lib files from the base
>> directory ?
>
> Possibly. What files do you have in your app's WEB-INF/lib
> directory?
>
> -chris
>
> -
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> 
>
> Notice of Confidentiality:
>
> The information contained in this communication is intended solely
> for the use of the individual or entity to whom it is addressed and
> others authorized to receive it. It may contain confidential or
> legally privileged information. If you are not the intended
> recipient you are hereby notified that any disclosure, copying,
> distribution or taking any action in reliance on the contents of
> this information is strictly prohibited and may be unlawful. If you
> have received this communication in error, please notify us
> immediately by responding to this email and then delete it from
> your system.
>
> -
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltXVrkACgkQHPApP6U8
pFjcsQ//WUXouVFgM8NPUITsDPr0IgH13queyAy9tE0QwzFgyGfaaMK9hqmeL9DM
86sWfWAuG1eNXZ3h1ttDMY9afjFHrIynJB8UHDRtDKQwU2d+MaoyuB+mRyOKaSY1
pKG4mAYnDNuZCnUxQaIt4R51tYVV2OJHhQEMZvPW2nrxTqgSHQjiaVG1Xk/XpsOl
6FA0BGfxWPD0Pxeu4FnYS/w1cwRoOWB1rWYkuW/HZkUtdgyVZKf7jp5PLBJ433FB
3q1ls5kFNOvWImkJ8eX0OsCpqjT0j11EvSjGMu5j9oTSpkWMQ096vtoSZIQFY5a0
Lq67Np+p3riaChaT2+vyRb7mlhpUPESmYUb6P3MiZe5nSe11stejezpW2EtUgbul
eHH9Jjgz05wTPo3u24rgo5Lx+scbklTATQSRj5QxI1slS1VCetkPODzFqcufQY7Z
/dv8gpnCiUBeZew/iLLwj7JlZjYvLpyizrxgtqhZJc5H5wC6xW+Wht80jEzgldGj
0oSeEHjJft2AFHch2iQGDtapRRWpXKU+eNYYXXfIIwH2tIdACRZq9H75bRBxJgFn
UBMl78am5Y4VjhCjfpxPFuGuZTfgxmL5xyPPNpXalA/WPWJRpc3ZQ1UNLtOsSTsK
l4fo0pkTGO/aWVkTFw385bJ0oxODK2PJwolid23oEJK7ywLN7Rk=
=b8Sz
-END PGP SIGNATURE-

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

Re: Tomcat 5.5.17 migration to 6.0.53

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 7/24/18 10:54 AM, David Babooram wrote:
> I will try to be as clear as possible.

:)

> The files that were originally in
> /usr/local/tomcat/jakarta-tomcat-5.5.17/webapps/MYAPP/WEB-INF/lib
> were copied by default when I migrated the app to
> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/

Good, that's what you probably should have done.

> When I ran MYAPP I got the error from my previous email.
> 
> I then mv all the files from
> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib
> into a temp directory , in attempt to make it use the global lib ,
> but still the same error.

Hmm. I'd expect lots of problems when removing all required libraries
from your application.

Did you copy the "work" directory from the Tomcat 5.5 installation?
(I'm guessing not.)

> My next idea was to place the files from
> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib
> into  /usr/local/tomcat/apache-tomcat-6.0.53/lib , but with the new
> structure I am unsure what belongs where.

Definitely undo that... it's likely to break your Tomcat installation.
You should basically never add anything other than maybe a JDBC driver
to your CATALINA_BASE/lib directory. Definitely nothing
application-specific.

I'd recommend removing all the files from CATALINA_BASE/lib and
re-extracting the distro package you downloaded just to reset things
back to the way they were.

> FYI : in my original /usr/local/tomcat/jakarta-tomcat-5.5.17/common
> I have the following directories
> 
> classes  endorsed  i18n  lib
> 
> 
> 
> 
> activation.jar antlr-2.7.2.jar

I think something got lost in the copy/paste. If you had files in the
"common" loader in Tomcat 5.5 then you might have a bit of work
figuring out which files are required by the application and which are
expected to be supplied by the container (Tomcat).

I'm going to attempt to group these files into 2 categories: things
that ought to be in your web application's WEB-INF/lib directory and
which files should be ignored (because Tomcat and/or the JVM should be
supplying them). Here goes:

1. Files supplied by the JVM and/or Tomcat (and should be ignored from
your old installation):

> activation.jar (Modern JVMs supply this) 
> el-api-2.2.1-b04.jar   (Tomcat is required to supply the EL APIs)

2. Files that ought to be in WEB-INF/lib in your application:

> antlr-2.7.2.jar axis-ant.jar axis.jar bsf-2.3.0.jar 
> commons-beanutils-1.8.0.jar commons-chain-1.2.jar 
> commons-codec-1.3.jar commons-collections.jar 
> commons-dbcp-1.2.1.jar commons-digester-1.8.jar 
> commons-discovery-0.2.jar commons-fileupload-1.1.1.jar 
> commons-io-1.1.jar commons-lang.jar commons-logging-1.0.4.jar 
> commons-pool-1.2.jar commons-validator-1.3.1.jar edtftpj.jar 
> ibatis-common-2.jar ibatis-dao-2.jar ibatis-sqlmap-2.jar 
> invoice-generator.jar itext-1.3.jar iText-2.1.0.jar 
> j2ssh-ant-0.2.9.jar j2ssh-common-0.2.9.jar j2ssh-core-0.2.9.jar 
> j2ssh-daemon-0.2.9.jar jakarta-oro.jar jaxrpc.jar jsch-0.1.20.jar 
> jstl-1.0.2.jar jstl-1.2.jar junit.jar log4j-1.2.11.jar mailapi.jar 
> ojdbc14.jar oro-2.0.8.jar poi-2.5.1-final-20040804.jar quartz.jar 
> saaj.jar smtp.jar standard-1.0.6.jar stringtemplate.jar 
> struts-core-1.3.10.jar struts-el-1.3.10.jar 
> struts-extras-1.3.10.jar struts-faces-1.3.10.jar 
> struts-mailreader-dao-1.3.10.jar struts-scripting-1.3.10.jar 
> struts-taglib-1.3.10.jar struts-tiles-1.3.10.jar wsdl4j-1.5.1.jar 
> xmlrpc-2.0.jar

3. Wait, there is another category. You appear to have some conflicts
in your existing libraries:

> jstl-1.0.2.jar jstl-1.2.jar

and
> jakarta-oro.jar oro-2.0.8.jar

If those files have the same classes in each of them, you might be
looking at some problems. Check the contents to see if they are
distinct or if you have duplicate libraries.

4. Things you might want to look into.

> mailapi.jar

Is that javamail?

> smtp.jar

Is that *also* javamail?

> ojdbc14.jar

Is that the Oracle JDBC driver? If the container (Tomcat) is managing
your connection-pool, then you'll want to put this file into
CATALINA_BASE/lib and *nowhere else*.

> junit.jar

Are you sure you need the junit runtime in your running application?
My guess is "no" and you might want to see if things still work is you
remove this. But it can wait until later.

Finally (and I say this as a proud Apache Struts 1.x user) it's
important that you understand that (a) Apache Struts 1.x has reached
EOL and (b) there are unpatched, publicly-reported security
vulnerabilities in the version you are using (1.3.10). You should
really research those vulnerabilities and make sure that you have
mitigated them all, or you risk exposing your users and servers to
exploitation.

Hope that helps,
- -chris

> -Original Message- From

RE: Re: Tomcat 5.5.17 migration to 6.0.53

[David Babooram]

Hi Christopher,


I will try to be as clear as possible.



The files that were originally in 
/usr/local/tomcat/jakarta-tomcat-5.5.17/webapps/MYAPP/WEB-INF/lib were copied 
by default when I migrated the app to  
/usr/local/tomcat/apache-tomcat-6.0.53/webapps/

When I ran MYAPP I got the error from my previous email.

I then mv all the files from 
/usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib into a temp 
directory , in attempt to make it use the global lib , but still the same error.

My next idea was to place the files from 
/usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib into  
/usr/local/tomcat/apache-tomcat-6.0.53/lib , but with the new structure I am 
unsure what belongs where.



FYI : in my original /usr/local/tomcat/jakarta-tomcat-5.5.17/common  I have the 
following directories

classes  endorsed  i18n  lib




activation.jar
antlr-2.7.2.jar
axis-ant.jar
axis.jar
bsf-2.3.0.jar
commons-beanutils-1.8.0.jar
commons-chain-1.2.jar
commons-codec-1.3.jar
commons-collections.jar
commons-dbcp-1.2.1.jar
commons-digester-1.8.jar
commons-discovery-0.2.jar
commons-fileupload-1.1.1.jar
commons-io-1.1.jar
commons-lang.jar
commons-logging-1.0.4.jar
commons-pool-1.2.jar
commons-validator-1.3.1.jar
edtftpj.jar
el-api-2.2.1-b04.jar
ibatis-common-2.jar
ibatis-dao-2.jar
ibatis-sqlmap-2.jar
invoice-generator.jar
itext-1.3.jar
iText-2.1.0.jar
j2ssh-ant-0.2.9.jar
j2ssh-common-0.2.9.jar
j2ssh-core-0.2.9.jar
j2ssh-daemon-0.2.9.jar
jakarta-oro.jar
jaxrpc.jar
jsch-0.1.20.jar
jstl-1.0.2.jar
jstl-1.2.jar
junit.jar
log4j-1.2.11.jar
mailapi.jar
ojdbc14.jar
oro-2.0.8.jar
poi-2.5.1-final-20040804.jar
quartz.jar
saaj.jar
smtp.jar
standard-1.0.6.jar
stringtemplate.jar
struts-core-1.3.10.jar
struts-el-1.3.10.jar
struts-extras-1.3.10.jar
struts-faces-1.3.10.jar
struts-mailreader-dao-1.3.10.jar
struts-scripting-1.3.10.jar
struts-taglib-1.3.10.jar
struts-tiles-1.3.10.jar
wsdl4j-1.5.1.jar
xmlrpc-2.0.jar


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Monday, 23 July 2018 2:29 PM
To: users@tomcat.apache.org
Subject: [EXTERNAL] Re: Tomcat 5.5.17 migration to 6.0.53

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 7/23/18 12:51 PM, David Babooram wrote:
> Hello
>
> I have begun a migration from 5.5 to 6. Yes I know 6 is EOL but the
> migration from 5.5 to 6 has some more documentation compared to
> 5.5 to the latest version.
>
> I followed the standard migration of libs and classes from /common
> /shared etc to the new /lin directory for 6..
>
> The server engine runs and I can see the examples web pages come up.
>
> When I migrated my production webapps to the 6.0 instance however I
> get the following error.
>
> HTTP Status 500 - java.lang.LinkageError: loader constraint
> violation: when resolving interface method
> "javax.servlet.jsp.JspApplicationContext.getExpressionFactory()Ljavax/
el/ExpressionFactory;"
>
>
the class loader (instance of org/apache/jasper/servlet/JasperLoader)
> of the current class, org/apache/jsp/index_jsp, and the class loader
> (instance of org/apache/catalina/loader/StandardClassLoader)
> for resolved class, javax/servlet/jsp/JspApplicationContext, have
> different Class objects for the type javax/el/ExpressionFactory used
> in the signature
>
> Any insight on this is welcomed.
>
> I notice in that my app has its own lib directory, does this means
> that there is a conflict with the lib files from the base directory ?

Possibly. What files do you have in your app's WEB-INF/lib directory?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltWHmYACgkQHPApP6U8
pFi4ow//e1d8mPY8X7K2X1h2X9Maim12GIbKAv0OrvthWMWYMIt6POTrxRepJLg6
BxgQ2Duabf2wCmZhGRRcBotc7++Niyyh3bHPwy11UfsHXkLPQlE1bnfprgYsUI+5
JRUf4ZHLQ+HCXTn3R54U5Z+a6U4ucSotPt2FwpslIGH2lZFrjSjM+lELagNIJvvU
gysavLRPZIQSCvDfPw1MeDbmtPalbVlq0XvS4d4szvWJy0oNzF1mRG4u6KWniisz
t0ULSmp/2virBNPmQ9SdeoG23avPtfxVOY2BbP1O5IAjKSfhPV+UNhvu48ufq5gj
gVYGVf5edxZy241ApGZHZoSSfl5LEiN1vJpIsF1a8HcqffhBTJTwtDzhscQDVxw9
89iiwTGEp5VtugI8vqMNI1hO9b0ESJhAfsCuMwvEvL2sivWWROXRzExsFiSFe0x2
K9tpqXBonXZ+4y+xwQdBoaDcRRjKhUW9rP5CbkNvDOfpttsnyD6c7ff1t/9K3vr/
FnBFCqo0qDRdSLckbtmU5C6/yHUjQiFtMXbMtnEVXwnk3zo0ICJnvxvTINp346nq
EiYAMcZF+RemlO3+0whK+B7BKgF9L4baqvQmglJaIEVY2D6w4SmW/xCO55a4V2c4
gRD9xNP6u7M/dlFGs+VaJvdwkh4wNxj319vxYsZ2O2KsdmDdvUw=
=YuGP
-END PGP SIGNATURE-

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




Notice of Confidentiality:

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others 

Re: Tomcat 5.5.17 migration to 6.0.53

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 7/23/18 12:51 PM, David Babooram wrote:
> Hello
> 
> I have begun a migration from 5.5 to 6. Yes I know 6 is EOL but
> the migration from 5.5 to 6 has some more documentation compared to
> 5.5 to the latest version.
> 
> I followed the standard migration of libs and classes from /common 
> /shared etc to the new /lin directory for 6..
> 
> The server engine runs and I can see the examples web pages come
> up.
> 
> When I migrated my production webapps to the 6.0 instance however
> I get the following error.
> 
> HTTP Status 500 - java.lang.LinkageError: loader constraint 
> violation: when resolving interface method 
> "javax.servlet.jsp.JspApplicationContext.getExpressionFactory()Ljavax/
el/ExpressionFactory;"
>
> 
the class loader (instance of org/apache/jasper/servlet/JasperLoader)
> of the current class, org/apache/jsp/index_jsp, and the class
> loader (instance of org/apache/catalina/loader/StandardClassLoader)
> for resolved class, javax/servlet/jsp/JspApplicationContext, have 
> different Class objects for the type javax/el/ExpressionFactory
> used in the signature
> 
> Any insight on this is welcomed.
> 
> I notice in that my app has its own lib directory, does this means 
> that there is a conflict with the lib files from the base
> directory ?

Possibly. What files do you have in your app's WEB-INF/lib directory?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltWHmYACgkQHPApP6U8
pFi4ow//e1d8mPY8X7K2X1h2X9Maim12GIbKAv0OrvthWMWYMIt6POTrxRepJLg6
BxgQ2Duabf2wCmZhGRRcBotc7++Niyyh3bHPwy11UfsHXkLPQlE1bnfprgYsUI+5
JRUf4ZHLQ+HCXTn3R54U5Z+a6U4ucSotPt2FwpslIGH2lZFrjSjM+lELagNIJvvU
gysavLRPZIQSCvDfPw1MeDbmtPalbVlq0XvS4d4szvWJy0oNzF1mRG4u6KWniisz
t0ULSmp/2virBNPmQ9SdeoG23avPtfxVOY2BbP1O5IAjKSfhPV+UNhvu48ufq5gj
gVYGVf5edxZy241ApGZHZoSSfl5LEiN1vJpIsF1a8HcqffhBTJTwtDzhscQDVxw9
89iiwTGEp5VtugI8vqMNI1hO9b0ESJhAfsCuMwvEvL2sivWWROXRzExsFiSFe0x2
K9tpqXBonXZ+4y+xwQdBoaDcRRjKhUW9rP5CbkNvDOfpttsnyD6c7ff1t/9K3vr/
FnBFCqo0qDRdSLckbtmU5C6/yHUjQiFtMXbMtnEVXwnk3zo0ICJnvxvTINp346nq
EiYAMcZF+RemlO3+0whK+B7BKgF9L4baqvQmglJaIEVY2D6w4SmW/xCO55a4V2c4
gRD9xNP6u7M/dlFGs+VaJvdwkh4wNxj319vxYsZ2O2KsdmDdvUw=
=YuGP
-END PGP SIGNATURE-

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

Tomcat 5.5.17 migration to 6.0.53

[David Babooram]

Hello

I have begun a migration from 5.5 to 6. Yes I know 6 is EOL but the migration 
from 5.5 to 6 has some more documentation compared to 5.5 to the latest version.

I followed the standard migration of libs and classes from /common /shared etc 
to the new /lin directory for 6..

The server engine runs and I can see the examples web pages come up.

When I migrated my production webapps to the 6.0 instance however I get the 
following error.

HTTP Status 500 - java.lang.LinkageError: loader constraint violation: when 
resolving interface method 
"javax.servlet.jsp.JspApplicationContext.getExpressionFactory()Ljavax/el/ExpressionFactory;"
 the class loader (instance of org/apache/jasper/servlet/JasperLoader) of the 
current class, org/apache/jsp/index_jsp, and the class loader (instance of 
org/apache/catalina/loader/StandardClassLoader) for resolved class, 
javax/servlet/jsp/JspApplicationContext, have different Class objects for the 
type javax/el/ExpressionFactory used in the signature

Any insight on this is welcomed..

I notice in that my app has its own lib directory, does this means that there 
is a conflict with the lib files from the base directory ?






Notice of Confidentiality:

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. If 
you are not the intended recipient you are hereby notified that any disclosure, 
copying, distribution or taking any action in reliance on the contents of this 
information is strictly prohibited and may be unlawful. If you have received 
this communication in error, please notify us immediately by responding to this 
email and then delete it from your system.

Re: Tomcat 5.5.17 migration to 6

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 7/14/18 4:53 PM, David Babooram wrote:
> Alright.
> 
> I guess the thought the process was to upgrade to 6, then 7, 8

Having gone through exactly this process a few years ago (from 4.1 to
5.0 and continuing on up the major-version ladder until I was
current), I can tell you that it was a collossal waste of our time to
do everything incrementally. We have a very conservative test-to-prod
pipeline at $work (where I'm personally responsible for that process)
and so that transition took a few years.

- From experience, I can tell you that going from 5.5 -> 6.0 is exactly
as difficult as it will be to go from 5.5 -> 8.5. I personally
recommend 8.5 over 9.0 due to some potential
backward-incompatibilities you may encounter with 9.0 that don't exist
in 8.5. An eventual migration from 8.5 -> 9.0 should be much less
"scary" and easy for you to do.

Here is exactly what you should do. There are 2 phases.

Phase I - Prep your environment

1. Read the RUNNING.txt file that comes with Tomcat, especially the
section titled "Advanced Configuration - Multiple Tomcat Instances".

2. Split your existing application configuration in Tomcat 5.5. such
that you have a stock, un-altered Tomcat 5.5.x installation as your
CATALINA_HOME and a CATALINA_BASE which contains your
instance-specific configuration to support your application.

3. Make sure you aren't using any deployments from conf/server.xml.
Specifically, there should be no  elements in that file. If
you have them there, there are better ways of doing deployments.[1]

4. Make sure everything still works.

Once you have done this, everything else will be a lot easier.

Phase II - Upgrade to your target version

0. Throw our all your existing Tomcat configuration. Well, almost.

1. Download a copy of 8.5.32 (current as of this writing) and unpack
it into wherever it will eventually go. This will be your new
CATALINA_HOME for your 8.5.x-based service. Don't change anything. Ever.

2. Create a new CATALINA_BASE structure for your 8.5.x-based service.

3. Compare your existing conf/server.xml file to the stock one from
Phase I step 2 above. There shouldn't be really that many changes...
usually just a few  definitions. Make appropriate similar
changes to a *copy of* the conf/server.xml file that comes with the
stock Tomcat 8.5.32 distribution and put that file into your new
CATALINA_BASE/conf directory.

4. Stop your old 5.5-based service. Start your 8.5-based service.

5. Test everything.

With any luck, you will just be good to go. If you find any problems,
feel free to ask for some help on this list.

For your next upgrade (e.g. 8.5.32 -> 8.5.33), simply do the following:

1. Unpack the new distribution into a NEW directory (e.g.
apache-tomcat-8.5.33/).

2. Stop your 8.5.32-based service.

3. Change CATALINA_HOME to point to the new directory from step 1.

4. Start Tomcat.

Patch-level upgrades should be just that simple every time. Moving
between versions usually requires starting with a fresh
conf/server.xml from the distribution and making modifications similar
to those described in Phase II step 3.

I hope that helps.

- -chris


[1]
https://tomcat.apache.org/tomcat-8.5-doc/config/context.html#Defining_a_
context
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltSAMwACgkQHPApP6U8
pFjsORAAg3OD5fRXxP9AsFd9TgjACHCd+yR20iG2Cd+ULBI7JNqleIL5aRXuE2GW
u6NpJd0sBpq73Z8jJZOPS5Q0OD5bO8Hc9ngV5pqkHaAMgrROvD/EpI+pw5Ky/HNQ
42wipu+AeKlTR4UWON4XccbaEUz2cPQl8MueuLiMRJ9tMpUSNEhXUm6GTf1q4f+c
WuEPSUsiHThi8tFCYp5EkkneZrfJO2t2fECsOJgflEKJyIds2X5JCL2NBQCfniqg
KkiX5evjnDwyfZJ2voGm30m+G/XroDViLWAZ1RunXpibwzKExJWQDqtEslVgX5Jz
xOPQL0xVgr0evtJ35sgOZGccQlaLy2us7t0/5zhvgXQeHmwguoIMZFAtrfNm5NOB
D0rpkEBzGQVzrsj/O8LmFNhv/UesM7gT8XpHHzQOTbXDy/cOqcwer5HzrWLt4pjc
dk+exvLQQBMMaStw6R6Jn7IJhOoCxot48L+kR41hzW+0gQo6nGDk9Siwvll4QmS2
tzJQrm74P2R55veju+W3xlUphUHPWTUk1btyr21xJ3H6CtnYDwXOYG7o+4s72Xcl
wr4xtikNIzd5Sr2rUU7N9N4piAzgZg6ZKMqs8FAC+5+SRgeCDQhAxGVivrHddlbd
yLotsopkPDYL6biL0UG0diBMwxBA/X9pttaJEZpGCkebF1unVRk=
=x04i
-END PGP SIGNATURE-

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

Re: Tomcat 5.5.17 migration to 6

[Igal Sapir]

On 7/14/2018 8:05 AM, calder wrote:

Why migrate to a version that is EOL (no doubt why you can't find docs) ?
https://tomcat.apache.org/tomcat-60-eol.html

If I were in the situation, I'd migrate to a more modern version, such as
8.5


Definitely! +1




On Saturday, July 14, 2018, David Babooram 
wrote:


Good morning

My intent is to migrate from 5.5.17 to 6 with the intent to upgrade to
6.0.48. , mainly due to a vulnerability notice.

I understand the changes listed from the Apache site wrt the migration.
but I have not gotten any steps on how to proceed.

Is there any proper documentation on how to proceed




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

Re: Tomcat 5.5.17 migration to 6

[Olaf Kock]

On 14.07.2018 22:53, David Babooram wrote:

Alright.

I guess the thought the process was to upgrade to 6, then 7, 8


If your application doesn't do anything too tomcat specific, but is 
rather a standard web application, you might be able to just deploy it 
on Tomcat 8.5 and check if it all works, fix problems when they appear.


Rather than migrating 3 times, check what you've configured on Tomcat 
5.5, validate how to do the same on tomcat 8.5 or 9.0, and just do it. I 
haven't ever worried about tomcat versions - because I've never dug 
deeply into Tomcat, and you might be lucky to be able to work the same way.


It might be harder to migrate to a current Java version than to use a 
current Tomcat version.


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

Re: RE: Re: Tomcat 5.5.17 migration to 6

[David Babooram]

Alright.

I guess the thought the process was to upgrade to 6, then 7, 8

Thanks,
David




On Sat, Jul 14, 2018 at 3:38 PM -0400, "Caldarale, Charles R" 
mailto:chuck.caldar...@unisys.com>> wrote:


> From: David Babooram [mailto:david.baboo...@digicelgroup.com]
> Subject: Re: Re: Tomcat 5.5.17 migration to 6

> But by decision was based on what was presented in the Apache site. In
that, upgrade from
> 5.5 was known to only go to 6.

Seriously, don't even think about "upgrading" to another very dead level.
There haven't been updates to Tomcat 6 for over a year; subsequent fixes for
known security holes and other issues have been applied to current levels,
but none of those will ever be retrofitted to Tomcat 6 (and 7, in the not
too distant future).  8.5 or 9.0 are the only sensible choices.

> Nevertheless.. is there some official documents on migrating to 8.5?

Due to the age of where you're starting from (over 12 years old), you're not
going to find anything specific for that level to a current one.  What you
can do is read all of the Migration Guides linked from here:
http://tomcat.apache.org/migration.html
and get a sense of the changes needed for your webapp configurations.

You may well need to update JVM versions as well; if the one you're using is
also 12 years old, it's scary dangerous.

  - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.





Notice of Confidentiality:

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. If 
you are not the intended recipient you are hereby notified that any disclosure, 
copying, distribution or taking any action in reliance on the contents of this 
information is strictly prohibited and may be unlawful. If you have received 
this communication in error, please notify us immediately by responding to this 
email and then delete it from your system.

RE: Re: Tomcat 5.5.17 migration to 6

[Caldarale, Charles R]

> From: David Babooram [mailto:david.baboo...@digicelgroup.com] 
> Subject: Re: Re: Tomcat 5.5.17 migration to 6

> But by decision was based on what was presented in the Apache site. In
that, upgrade from 
> 5.5 was known to only go to 6.

Seriously, don't even think about "upgrading" to another very dead level.
There haven't been updates to Tomcat 6 for over a year; subsequent fixes for
known security holes and other issues have been applied to current levels,
but none of those will ever be retrofitted to Tomcat 6 (and 7, in the not
too distant future).  8.5 or 9.0 are the only sensible choices.

> Nevertheless.. is there some official documents on migrating to 8.5?

Due to the age of where you're starting from (over 12 years old), you're not
going to find anything specific for that level to a current one.  What you
can do is read all of the Migration Guides linked from here:
http://tomcat.apache.org/migration.html
and get a sense of the changes needed for your webapp configurations.

You may well need to update JVM versions as well; if the one you're using is
also 12 years old, it's scary dangerous.

  - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.



smime.p7s
Description: S/MIME cryptographic signature

Re: Re: Tomcat 5.5.17 migration to 6

[David Babooram]

Hi

Good point.

But by decision was based on what was presented in the Apache site. In that, 
upgrade from 5.5 was known to only go to 6.


Nevertheless.. is there some official documents on migrating to 8.5?



Thanks,
David




On Sat, Jul 14, 2018 at 11:05 AM -0400, "calder" 
mailto:calder@gmail.com>> wrote:


Why migrate to a version that is EOL (no doubt why you can't find docs) ?
https://urldefense.proofpoint.com/v2/url?u=https-3A__tomcat.apache.org_tomcat-2D60-2Deol.html=DwIBaQ=rgYoxYEBLrFNu7L2jzNzTw=MW5XW3Oy92ra15dUPR3jKJRFG4SYwI8WcMv_vsnkhI8=BBOP12O2WPzudlhwCFnUC4e0DvDT_OfVbr1ORuU60EU=Ph5R4aW_MIkR03OtVE8KeF2sTCSJjI25o_HEqjp2r5k=

If I were in the situation, I'd migrate to a more modern version, such as
8.5


On Saturday, July 14, 2018, David Babooram
wrote:

> Good morning
>
> My intent is to migrate from 5.5.17 to 6 with the intent to upgrade to
> 6.0.48. , mainly due to a vulnerability notice.
>
> I understand the changes listed from the Apache site wrt the migration.
> but I have not gotten any steps on how to proceed.
>
> Is there any proper documentation on how to proceed
>




Notice of Confidentiality:

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. If 
you are not the intended recipient you are hereby notified that any disclosure, 
copying, distribution or taking any action in reliance on the contents of this 
information is strictly prohibited and may be unlawful. If you have received 
this communication in error, please notify us immediately by responding to this 
email and then delete it from your system.

Re: Tomcat 5.5.17 migration to 6

[calder]

Why migrate to a version that is EOL (no doubt why you can't find docs) ?
https://tomcat.apache.org/tomcat-60-eol.html

If I were in the situation, I'd migrate to a more modern version, such as
8.5


On Saturday, July 14, 2018, David Babooram 
wrote:

> Good morning
>
> My intent is to migrate from 5.5.17 to 6 with the intent to upgrade to
> 6.0.48. , mainly due to a vulnerability notice.
>
> I understand the changes listed from the Apache site wrt the migration.
> but I have not gotten any steps on how to proceed.
>
> Is there any proper documentation on how to proceed
>

Tomcat 5.5.17 migration to 6

[David Babooram]

Good morning


My intent is to migrate from 5.5.17 to 6 with the intent to upgrade to 6.0.48. 
, mainly due to a vulnerability notice.


I understand the changes listed from the Apache site wrt the migration. but I 
have not gotten any steps on how to proceed.


Is there any proper documentation on how to proceed with this migration?

Thanks,
David




Notice of Confidentiality:

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. If 
you are not the intended recipient you are hereby notified that any disclosure, 
copying, distribution or taking any action in reliance on the contents of this 
information is strictly prohibited and may be unlawful. If you have received 
this communication in error, please notify us immediately by responding to this 
email and then delete it from your system.

AW: [EXTERNAL] Re: Migration from Tomcat 8.0.37 to 8.5.24 , changes to protocol at Http11NioProtocol , from http-nio to https-jsse-nio

[Lauria Giuseppe]

Hi Marek, Hi Mark.
Thank you very much.

Best regards
G

-Ursprüngliche Nachricht-
Von: Mark Thomas [mailto:ma...@apache.org] 
Gesendet: Mittwoch, 7. Februar 2018 09:51
An: Tomcat Users List <users@tomcat.apache.org>
Betreff: [EXTERNAL] Re: Migration from Tomcat 8.0.37 to 8.5.24 , changes to 
protocol at Http11NioProtocol , from http-nio to https-jsse-nio

On 07/02/18 08:41, Lauria Giuseppe wrote:
> Hi tomcat users.
> 
> 
> We are in transition from Tomcat 8.0.37 to 8.5.24.



> What is the meaning of this ? Is this just naming change ?
> Or did functionality change ? If yes, what is different between http-nio and 
> https-jsse-nio ?

8.0.x only supports JSSE for TLS with NIO (and NIO2) HTTP connectors.

8.5.x supports JSSE or OpenSSL for TLS with NIO (and NIO2) HTTP connectors.

Therefore, the protocol name in 8.5.x was extended to indicate which TLS 
implementation is in use.

http-nio in 8.0.x is equivalent to http-jsse-nio in 8.5.x.

Mark

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

Re: Migration from Tomcat 8.0.37 to 8.5.24 , changes to protocol at Http11NioProtocol , from http-nio to https-jsse-nio

[Marek Czernek]

Hi Lauria,

This seems like everything is the same for you on both Tomcat 8 and 8.5; 
what changed is that the SSL implementation gets displayed in the console.


JSSE means you're using Java runtime JSSE implementation. There's the 
possibility to use OpenSSL implementation as well. See the docs [1 
] 
for further details on the SSL implementation with regards to your 
connector settings.


Someone please do correct me if I'm wrong, but the bottom line seems to 
be that nothing functional has changed in this case.


HTH!

[1] 
https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html#Edit_the_Tomcat_Configuration_File


On 02/07/2018 09:41 AM, Lauria Giuseppe wrote:

Hi tomcat users.


We are in transition from Tomcat 8.0.37 to 8.5.24.

We checked Tomcat docs and FAQ and searched in google for this topic but did 
not find an explanation.

Question:

Even we did not change server.xml for the connector , now the 'protocol' in the 
log changed to different value; from 'http-nio' to 'https-jsse-nio'.

Definition im server.xml :


--

Marek Czernek

Associate Quality Engineer

Re: Migration from Tomcat 8.0.37 to 8.5.24 , changes to protocol at Http11NioProtocol , from http-nio to https-jsse-nio

[Mark Thomas]

On 07/02/18 08:41, Lauria Giuseppe wrote:
> Hi tomcat users.
> 
> 
> We are in transition from Tomcat 8.0.37 to 8.5.24.



> What is the meaning of this ? Is this just naming change ?
> Or did functionality change ? If yes, what is different between http-nio and 
> https-jsse-nio ?

8.0.x only supports JSSE for TLS with NIO (and NIO2) HTTP connectors.

8.5.x supports JSSE or OpenSSL for TLS with NIO (and NIO2) HTTP connectors.

Therefore, the protocol name in 8.5.x was extended to indicate which TLS
implementation is in use.

http-nio in 8.0.x is equivalent to http-jsse-nio in 8.5.x.

Mark

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

Migration from Tomcat 8.0.37 to 8.5.24 , changes to protocol at Http11NioProtocol , from http-nio to https-jsse-nio

[Lauria Giuseppe]

Hi tomcat users.


We are in transition from Tomcat 8.0.37 to 8.5.24.

We checked Tomcat docs and FAQ and searched in google for this topic but did 
not find an explanation.

Question:

Even we did not change server.xml for the connector , now the 'protocol' in the 
log changed to different value; from 'http-nio' to 'https-jsse-nio'.

Definition im server.xml :

Looking for a migration assessment tool

[Mohamed Abdallah Omar]

Hello,

One of our clients(Fin Tech)  is moving an enterprise eco system to cloud (and 
micro services) from a monolithic architecture of enterprise apps(ear files)  
deployed  on Weblogic  .

Knowing the code is tighly coupled with Weblogic libs and configuration files. 
I was searching for a tool that analyse artifacts and  spot (some of the) 
potential areas that needs conversion. I previously used 
this tool to asses a 
conversion of some apps  from Weblogic to Jboss and it gave us an interesting 
report.

Thanks a lot and looking forward!





AVIS DE CONFIDENTIALITÉ
Ce courrier électronique et toutes les pièces jointes peuvent contenir des 
informations privilégiées et / ou confidentielles et ne sont destinées qu'aux 
destinataires visés. Si le lecteur de ce courriel n'est pas le destinataire 
prévu, vous êtes par la présente informé que toute diffusion, distribution ou 
reproduction non autorisée de ce courriel ou de ses pièces jointes est 
strictement interdite. Si vous avez reçu ce courriel par erreur, veuillez en 
informer immédiatement l'expéditeur et détruire le courriel et les pièces 
jointes.

NOTICE OF CONFIDENTIALITY:
This email and any attachments may contain information that is privileged, 
and/or confidential, and is meant only for the intended recipient(s). If the 
reader of this email is not the intended recipient, you are hereby notified 
that any unauthorized dissemination, distribution or reproduction of this 
email, or its attachments, is strictly prohibited. If you have received this 
email in error, please advise the sender immediately and destroy the email and 
any attachments.

Re: migration from tomcat 7.0 to 8.5

[Konstantin Kolinko]

2017-10-04 17:53 GMT+03:00 Aquatic Safaris Diver <di...@aquaticsafaris.com>:
>
> I've read the migration manuals and have tried to make the changes to
> my configuration to work correctly in tomcat v8.5, but it's not.  I'm
> not an experton XML files and JDK so please help me.   I'm sure this is crazy 
> simple
> for you experts.
>
> The server.xml conf file is OK between the two versions.   But my
> application's deployment is having problems.
>
> In my tomcat v7 conf/Catalina/localhost directory, I have ed.xml file
> for my application containing:
>
> 
> 

"path" cannot be used here, ignored

docBase is rare to be seen here, but OK (it is outside of webapps)

> 
> 
> 
> virtualClasspath="/usr/local/calendar/libs/google-api-client-1.22.0.jar;/usr/local/calendar/google-api-services-calendar-v3-rev230-1.22.0.jar;/usr/local/calendar/libs/google-http-client-1.22.0.jar;/usr/local/calendar/libs/google-http-client-jackson2-1.22.0.jar;/usr/local/calendar/libs/google-oauth-client-1.22.0.jar;/usr/local/calendar/libs/jackson-core-2.1.3.jar"/>
> 
>
> After spending about 6 hours and reading tons of other web posts from
> others trying to do the same thing, I finally have
> something working, kinda.  My web application at least deploys when
> tomcat starts.  The Loader part in the .xml was replaced with:
> 
>  className="org.apache.catalina.webresources.JarResourceSet"
>base="/usr/local/calendar/libs/google-api-client-1.22.0.jar" 
> webAppMount="/WEB-INF/lib" internalPath="/."/>
>  className="org.apache.catalina.webresources.JarResourceSet"
>
> base="/usr/local/calendar/google-api-services-calendar-v3-rev230-1.22.0.jar" 
> webAppMount="/WEB-INF/lib" internalPath="/."/>
>  className="org.apache.catalina.webresources.JarResourceSet"
>base="/usr/local/calendar/libs/google-http-client-1.22.0.jar" 
> webAppMount="/WEB-INF/lib" internalPath="/."/>
>  className="org.apache.catalina.webresources.JarResourceSet"
>
> base="/usr/local/calendar/libs/google-http-client-jackson2-1.22.0.jar" 
> webAppMount="/WEB-INF/lib" internalPath="/."/>
>  className="org.apache.catalina.webresources.JarResourceSet"
>base="/usr/local/calendar/libs/google-oauth-client-1.22.0.jar" 
> webAppMount="/WEB-INF/lib" internalPath="/."/>
>  className="org.apache.catalina.webresources.JarResourceSet"
>base="/usr/local/calendar/libs/jackson-core-2.1.3.jar" 
> webAppMount="/WEB-INF/lib" internalPath="/."/>
> 

I'd use org.apache.catalina.webresources.FileResourceSet.  There is an
example in "Ordering" section here:
http://tomcat.apache.org/tomcat-8.5-doc/config/resources.html#Nested_Components

The docs could be better.

> However, when I access the JSP page that need to resolve classes in these 
> .jar's, I get
> org.apache.jasper.JasperException: Unable to compile class for JSP:
>
> An error occurred at line: [20] in the generated java file: 
> [/work/Catalina/localhost/ed/org/apache/jsp/charters_jsp.java]
> Only a type can be imported. com.google.api.client.json.JsonFactory resolves 
> to a package
>
> Line 20 is:
> import com.google.api.client.json.JsonFactory;

It is odd.
Stacktrace?

In my experience I faced
https://bz.apache.org/bugzilla/show_bug.cgi?id=47323
but it is quite different from your case.

isPackage(className) check mentioned there tries to load (className +
".class") as a resource and reports "true, it is a package" if the
class resource is not found.

> I think I'm up to 12 hours messing with this and reading everything I can get 
> my hands on.
> Something that was so simple in tomcat 7 has turned out to be a nightmare in 
> tomcat 8.
> I still don't have a good understanding of what webAppMount is or what I 
> should set it to.
> I changed PostResources to JarResources and nothing changed.   The jar files 
> are not getting found
> or the classes in the jar files are not getting found.
>
> There is no way this can be this hard and complicated in tomcat 8.
>
> Please help.

Best regards,
Konstantin Kolinko

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

migration from tomcat 7.0 to 8.5

[Aquatic Safaris Diver]

I've read the migration manuals and have tried to make the changes to
my configuration to work correctly in tomcat v8.5, but it's not.  I'm
not an experton XML files and JDK so please help me.   I'm sure this is crazy 
simple
for you experts.

The server.xml conf file is OK between the two versions.   But my
application's deployment is having problems.

In my tomcat v7 conf/Catalina/localhost directory, I have ed.xml file
for my application containing:








After spending about 6 hours and reading tons of other web posts from
others trying to do the same thing, I finally have
something working, kinda.  My web application at least deploys when
tomcat starts.  The Loader part in the .xml was replaced with:

    
    
    
    
    
    


However, when I access the JSP page that need to resolve classes in these 
.jar's, I get
org.apache.jasper.JasperException: Unable to compile class for JSP:

An error occurred at line: [20] in the generated java file: 
[/work/Catalina/localhost/ed/org/apache/jsp/charters_jsp.java]
Only a type can be imported. com.google.api.client.json.JsonFactory resolves to 
a package

Line 20 is:
import com.google.api.client.json.JsonFactory;

I think I'm up to 12 hours messing with this and reading everything I can get 
my hands on.
Something that was so simple in tomcat 7 has turned out to be a nightmare in 
tomcat 8.
I still don't have a good understanding of what webAppMount is or what I should 
set it to.
I changed PostResources to JarResources and nothing changed.   The jar files 
are not getting found
or the classes in the jar files are not getting found. 

There is no way this can be this hard and complicated in tomcat 8.

Please help.




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

RE: Migration

[Berneburg, Cris J. - US]

Osama

> I have been asked by a company to update their existing working
> tomcat 5 application, which is working on an old Windows 2003
> platform and accessing SQL 2005. The new servers are Windows and
> SQL 2012. I downloaded  and installed Tomcat 8.5.12. So, what I
> need to do for migrating the existing application to work on the
> new environment?

If you do not have automated integrated testing to test your current SQL, 
stored procedures, etc., on the new SQL Server 2012 platform, one thing I would 
recommend is using the "SQL Server 2012 Upgrade Advisor".  It will help point 
out the areas in your current SQL server 2005 database that are not compatible 
with 2012.  There are some differences that could cause your stored procedures 
and other SQL to no longer run/compile.

--
Cris Berneburg
CACI Lead Software Engineer



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

Re: Migration

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Osama,

On 3/21/17 3:43 PM, M. Osama Alghwell wrote:
> On Mar 21, 2017 7:21 PM, "Christopher Schultz"
> <ch...@christopherschultz.net> wrote:
> 
> Osama,
> 
> On 3/21/17 1:10 PM, M. Osama Alghwell wrote:
>>>> I have been asked by a company to update their existing
>>>> working tomcat 5 application, which is working on an old
>>>> Windows 2003 platform and accessing SQL 2005. The new servers
>>>> are Windows and SQL 2012. I downloaded  and installed Tomcat
>>>> 8.5.12. So, what I need to do for migrating the existing
>>>> application to work on the new environment? Thank you in
>>>> advance for your reply.
> 
>> Read through the Migration Guide: 
>> http://tomcat.apache.org/migration.html

> The migration guide for migrating from Tomcat 7 to 8

Is it?

> I need from 5 to 8.

I understand. The Migration Guide covers all (reasonably-recent) version
s.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJY0qHgAAoJEBzwKT+lPKRYoY4P/iu3h8vTd9m19PaaN847SZVE
ir1003x1rLyFdodhaYLKW+atMLeaGl+Y4pzjL+f54wzYKFGl7O/kK7+w4ji1pHrt
VpL+oUXd379Z1BPrG8iZXKE/lqdqpWArVrsanPz3/5a+UKoiEkz0l7Bu7zULhKBj
dx7L9c9x2qiXgaICeIa/ZgP04Sz8CZry6koeFHaATCsWiyr/VBzDt4cpfmVOsRIx
IRnixreh9l30+PVbDIZR864+M5G88xjLs26Mkc4YNtXmwPAb8q5LtQGDhHrVAWes
aZMbhR2iPsv5LOCj5DLpI2+AXmFiGWhDzhcYc9emqLKhB+r1DQNR+CtMz5gd/Ocz
SxNXdD4y2qB/gy1Jpkwyb4ne0+DrU4Ff4uR4XcY6JtPewZZN+RxtQKhvROKBr3ZI
BwoT0mB8CEkQr+IFaDfBlLPLRf18y0zZFIHBwiGrECr0Mia8UOABu/eGG6xIIh0/
/DE23PUf2pq4Vgy4I2adj9NpngytkUpO/Mm+j1PBiMRW11bPwBNVsUNQF9SIHAFc
D6BGFXEBlLXeBzohhxYL0MkAfewc60FlNHJAAVTzppwZ/JQfDOciJIfBpTyMSah9
PhN7DUiLrom5UMj995QmhLOrf+JCsbxBTbeuMgVW6opJgllLQujcN8A1J7nGCPPf
R+kSlAzBtHivI3Vb3pBd
=uihm
-END PGP SIGNATURE-

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

Re: Migration

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Osama,

On 3/21/17 3:46 PM, M. Osama Alghwell wrote:
> On Mar 21, 2017 7:25 PM, "Caldarale, Charles R"
> <chuck.caldar...@unisys.com> wrote:
> 
>>> From: M. Osama Alghwell [mailto:malghw...@gmail.com] Subject:
>>> Migration
>> 
>>> I have been asked by a company to update their existing working
>>> tomcat 5 application, which is working on an old Windows 2003
>>> platform and
>> accessing
>>> SQL 2005. The new servers are Windows and SQL 2012. I
>>> downloaded  and installed Tomcat 8.5.12. So, what I need to do
>>> for migrating the existing application to work on the new
>>> environment?
>> 
>> The first step is to read the migration guides: 
>> http://tomcat.apache.org/migration.html
>> 
>> You'll need to look at all the ones that change levels, since the
>> steps are cumulative and there is no 5 -> 8.5 doc.
>> 
>> Once you've absorbed that, come back with specific questions.
> 
> I will follow the steps from 5 to 6, from 6 to 7, then from 7 to
> 8, is this what I should do?

You need to read and understand the migrations from 5.0 -> 8.5, but
there's no reason to actually install and test with each individual
major version in between.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJY0qGZAAoJEBzwKT+lPKRYfTAP/jnayHvU3lNAy8zB4S+ca3n4
V1ZU8rUjAIYkaWQwnVVIN76OkYhexNixKOjJ7BlvEZp5Gt4a+lA4/gbqsQwIZeWg
eIj0S4I0rW1HYzvGWxTau17hzSZi5XZKmeaYuffXz0labQJH7PldJcTamXMitCpK
rN2MtdWnzUS9l1Jj6p8wFf+oEWmCQJl3nwUut+oC8tgGPBf2ie+1Li4owXBTVvKZ
IOfRgASeOODzlf233pSLhgQWC8VQCtWkfofPwzgy+CS+Qtz2YVBKmhB5OwteY7J1
kkPxxSHRyUYE0FInb/btgU/Zj2nlYoJGTNxI8128bSvSwkVguyH6JVSqeePx+yNJ
vfE1UJ0ipgaF61jItj9dlAC1yP2UdBEwGyootHHVjZ+yUXIB/pknQfmsRRGHOEh4
im9gMqBOyORWc0WKGD7ia1Te08D/54D49tC+pFxjkYTJ5Nu31A4SecK6sso3ozZS
cGqUaqvBJTdlEGcEdBKrQM7/V16uRVIlScfAn9NsT9pL0kATdHbXm2Sc/QhIGajx
Fwn/QPdfTq6F6vUCDw2/4ydWIHedkgQQYZnJbXTME89FvuBx//tOupse9TiNURk0
88qQ8UzNG5YHKTflICR1nT9hw2WsRk5Xl9abSkZvrMYu6XKmK7+ZAuZsrw/2U/zA
ytKUfgtTlQoCJGEvNVNk
=NmkW
-END PGP SIGNATURE-

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

RE: Migration

[M. Osama Alghwell]

I will follow the steps from 5 to 6, from 6 to 7, then from 7 to 8, is this
what I should do?

On Mar 21, 2017 7:25 PM, "Caldarale, Charles R" <chuck.caldar...@unisys.com>
wrote:

> > From: M. Osama Alghwell [mailto:malghw...@gmail.com]
> > Subject: Migration
>
> > I have been asked by a company to update their existing working tomcat 5
> > application, which is working on an old Windows 2003 platform and
> accessing
> > SQL 2005. The new servers are Windows and SQL 2012. I downloaded  and
> > installed Tomcat 8.5.12. So, what I need to
> > do for migrating the existing application to work on the new environment?
>
> The first step is to read the migration guides:
> http://tomcat.apache.org/migration.html
>
> You'll need to look at all the ones that change levels, since the steps
> are cumulative and there is no 5 -> 8.5 doc.
>
> Once you've absorbed that, come back with specific questions.
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Migration

[M. Osama Alghwell]

The migration guide for migrating from Tomcat 7 to 8, I need from 5 to 8.
Thank you.

On Mar 21, 2017 7:21 PM, "Christopher Schultz" <ch...@christopherschultz.net>
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Osama,
>
> On 3/21/17 1:10 PM, M. Osama Alghwell wrote:
> > I have been asked by a company to update their existing working
> > tomcat 5 application, which is working on an old Windows 2003
> > platform and accessing SQL 2005. The new servers are Windows and
> > SQL 2012. I downloaded  and installed Tomcat 8.5.12. So, what I
> > need to do for migrating the existing application to work on the
> > new environment? Thank you in advance for your reply.
>
> Read through the Migration Guide:
> http://tomcat.apache.org/migration.html
>
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJY0WELAAoJEBzwKT+lPKRY5pQQAMVUxSFa+gNZLgCR1swbKWyV
> ksGQn6J18MUgX0opMd82NIyjyUjUt6a01E5O7FCr9zBECNRBZnEtGTmSGp8Yyh9i
> 6MmUGyjmmyI3UExhyRkprAfJ74QGGz5wKt5NDNX7igss3xRig9cx1LlfWmJSGHxa
> cZ5Xh2RDpqes4he09GKAdAjC7/dboRoAAZ4fNJABxNZxxHW2gGX/FZeEDuOMaD1O
> jLsuDyDpb4TdVLy/Yxn/mBc4scsXCx229pGHBV0PYD7SylvlJXa+/k6cJgj3f5iZ
> X+hxnFeTaR47M1Thqoa/WOxSkFKlvDbXi3DjEQx9nvnudm9TqZCYqXcrq7Pw9Qd6
> bpOP5cKXxrl1LCSDtxhc+6NUJKGu+piRuPibSRDcUNCcKNHmczf1zcMGwQ/GE3p/
> pYijz4v5FGfmIS/rt92igUJfAonGhAkiIKJdDUwSW+n7kUXVqj/TfCZlasQB+SsB
> sOAHruXr+9S0wa9wt3ekvVGkfkCQn1XXoTacV1sUe+N5x/zqpmA5Bv16hrMLr+xH
> kLk8dAm2SgC3WnOcEF1eUJ/KI1CP47eUqpziKyhlizuZhEi+QSWJz1w8HU3DtuHF
> uw1tPrDCEcyWdPJ2AzX2DnCCWYYO8Gp6GIHik3J/jry3k+bseeJBRbuYGqP5GfSI
> kNBDGVorkFNcx8hd1Yg8
> =CkDe
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: Migration

[Caldarale, Charles R]

> From: M. Osama Alghwell [mailto:malghw...@gmail.com] 
> Subject: Migration

> I have been asked by a company to update their existing working tomcat 5
> application, which is working on an old Windows 2003 platform and accessing
> SQL 2005. The new servers are Windows and SQL 2012. I downloaded  and
> installed Tomcat 8.5.12. So, what I need to
> do for migrating the existing application to work on the new environment?

The first step is to read the migration guides:
http://tomcat.apache.org/migration.html

You'll need to look at all the ones that change levels, since the steps are 
cumulative and there is no 5 -> 8.5 doc.

Once you've absorbed that, come back with specific questions.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: Migration

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Osama,

On 3/21/17 1:10 PM, M. Osama Alghwell wrote:
> I have been asked by a company to update their existing working
> tomcat 5 application, which is working on an old Windows 2003
> platform and accessing SQL 2005. The new servers are Windows and
> SQL 2012. I downloaded  and installed Tomcat 8.5.12. So, what I
> need to do for migrating the existing application to work on the
> new environment? Thank you in advance for your reply.

Read through the Migration Guide:
http://tomcat.apache.org/migration.html


- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJY0WELAAoJEBzwKT+lPKRY5pQQAMVUxSFa+gNZLgCR1swbKWyV
ksGQn6J18MUgX0opMd82NIyjyUjUt6a01E5O7FCr9zBECNRBZnEtGTmSGp8Yyh9i
6MmUGyjmmyI3UExhyRkprAfJ74QGGz5wKt5NDNX7igss3xRig9cx1LlfWmJSGHxa
cZ5Xh2RDpqes4he09GKAdAjC7/dboRoAAZ4fNJABxNZxxHW2gGX/FZeEDuOMaD1O
jLsuDyDpb4TdVLy/Yxn/mBc4scsXCx229pGHBV0PYD7SylvlJXa+/k6cJgj3f5iZ
X+hxnFeTaR47M1Thqoa/WOxSkFKlvDbXi3DjEQx9nvnudm9TqZCYqXcrq7Pw9Qd6
bpOP5cKXxrl1LCSDtxhc+6NUJKGu+piRuPibSRDcUNCcKNHmczf1zcMGwQ/GE3p/
pYijz4v5FGfmIS/rt92igUJfAonGhAkiIKJdDUwSW+n7kUXVqj/TfCZlasQB+SsB
sOAHruXr+9S0wa9wt3ekvVGkfkCQn1XXoTacV1sUe+N5x/zqpmA5Bv16hrMLr+xH
kLk8dAm2SgC3WnOcEF1eUJ/KI1CP47eUqpziKyhlizuZhEi+QSWJz1w8HU3DtuHF
uw1tPrDCEcyWdPJ2AzX2DnCCWYYO8Gp6GIHik3J/jry3k+bseeJBRbuYGqP5GfSI
kNBDGVorkFNcx8hd1Yg8
=CkDe
-END PGP SIGNATURE-

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

Migration

[M. Osama Alghwell]

I have been asked by a company to update their existing working tomcat 5
application, which is working on an old Windows 2003 platform and accessing
SQL 2005. The new servers are Windows and SQL 2012. I downloaded  and
installed Tomcat 8.5.12. So, what I need to
do for migrating the existing application to work on the new environment?
Thank you in advance for your reply.

Regards,

-- 
*M. Osama Alghwell*

Re: Migration to Tomcat 8.0 Post/PreResources vs VirtualWebappLoader with optional resources

[Mark Thomas]

On 07/12/2016 09:01, Berg, R. van den (Robin) wrote:
> Hello!
> I have an issue that seems not supported anymore with Tomcat 8.
> The same problem is also posted in the comments on: 
> https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html
> 
> PROBLEM:
> We used the virtualWebAppLoader to get some extra libraries and classes that 
> were on the machine on the classloader.
> The virtualClasspath-property of the virtualWebAppLoader was a ';'-seperated 
> list of directories. If one of them was empty, that was not a problem.
> We used the fact that non-existing/empty directories were not loaded, without 
> any exception. MQ were imported on
> Test-acceptance-production. However, in a local/dev-setup we do not provide 
> these libraries, since MQ-services are stubbed out.
> 
> We used the {Jar|File|Dir}ResourceSet in the context.xml as replacement for 
> the virtualWebAppLoader, as recommended by the migration guide.
> However, these fail when the base-property is non-existent. Therefore, it 
> breaks dev/local.
> 
> In the comments in 
> https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html a solution was 
> posted to extend the {Jar|File|Dir}ResourceSet.
> However, that solution won't work for us, since we can't provide the 
> tomcat-instances on test-acc-prd with an extra class/library with the 
> extended class. (access-rights/cloud-solution only allows default setup).

Can you not simply create an empty directory in the right place for
dev/local ?

Mark

> 
> PREFERRRED SOLUTION:
> Just like the tomcat 7  virtualWebAppLoader we would like the ResourceSet to 
> be optional/non-failing if the resource is not available. Is there any 
> configuration/property I can use to do that?
> 
> Thanks,
> Kind Regards,
> 
> 
> ATTENTION:
> The information in this e-mail is confidential and only meant for the 
> intended recipient. If you are not the intended recipient, don't use or 
> disclose it in any way. Please let the sender know and delete the message 
> immediately.
> --
> 
> -
> 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: Migration to Tomcat 8.0 Post/PreResources vs VirtualWebappLoader with optional resources

[Berg, R. van den (Robin)]

Hi,

No. For the record: I didn't posted the issue on  
https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html. I merely 
stumbled upon somebody having the same issue. I wanted to file an enhancement 
request. But, as also noted by the "what to do before posting a 
bug/enhancement"-page, I wanted to be 
sure there is no solution to this problem yet. 
I was interested whether this was already fixed perhaps, even though I couldn't 
find anything.
Also, maybe somebody knows a 'workaround', which would me because I don't have 
time to wait for the enhancement. Furthermore, I can't even use the 
newest version, unfortunately. That depends on the PAAS party.

Kind Regards,

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, December 07, 2016 10:58 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Migration to Tomcat 8.0 Post/PreResources vs VirtualWebappLoader 
with optional resources

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Robin,

On 12/7/16 4:01 AM, Berg, R. van den (Robin) wrote:
> Hello! I have an issue that seems not supported anymore with Tomcat 8. 
> The same problem is also posted in the comments on:
> https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html
> 
> PROBLEM: We used the virtualWebAppLoader to get some extra libraries 
> and classes that were on the machine on the classloader.
> The virtualClasspath-property of the virtualWebAppLoader was a 
> ';'-seperated list of directories. If one of them was empty, that was 
> not a problem. We used the fact that non-existing/empty directories 
> were not loaded, without any exception. MQ were imported on 
> Test-acceptance-production. However, in a local/dev-setup we do not 
> provide these libraries, since MQ-services are stubbed out.
> 
> We used the {Jar|File|Dir}ResourceSet in the context.xml as 
> replacement for the virtualWebAppLoader, as recommended by the 
> migration guide. However, these fail when the base-property is 
> non-existent. Therefore, it breaks dev/local.
> 
> In the comments in
> https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html a 
> solution was posted to extend the {Jar|File|Dir}ResourceSet.
> However, that solution won't work for us, since we can't provide the 
> tomcat-instances on test-acc-prd with an extra class/library with the 
> extended class. (access-rights/cloud-solution only allows default 
> setup).
> 
> PREFERRRED SOLUTION: Just like the tomcat 7  virtualWebAppLoader we 
> would like the ResourceSet to be optional/non-failing if the resource 
> is not available. Is there any configuration/property I can use to do 
> that?

Did you file an enhancement request as suggested by Konstantin all those months 
ago?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYSIXzAAoJEBzwKT+lPKRYRlcP/ip62nstdty643NjIdy8ImN4
/lhGdpw9qUfGTDiGF/wtqfOeAcTOIfoH1f0ZmnNaP9lZFMu917IT6Z0y3+fOwwnE
M3GPKBCZTQne3wY2oHqZujv4WVAiYzmcNlPDxeHljxP/aSiAf6DOyaWwGFLlUIml
7RiGBE+oJGQAMhohulPvSlh1ldSAsF637+xJA0O18DpRdSx9ikgDeeodRtA9Ei1d
R8sbZ9atYTqMH9ee4GBkc8yJDfZqf3Fo1FUjKghB3S4M9yxyjKqLqJORrFm4fOLH
PM4Oq7gkLEJNBWhkzABj6ruMw5/PHXrz4BV+K7rapdCSH7Bg5WXASiX0O0Z/rw1G
nVgd4kVwLRqDnRANjyU8+BnzyDq0sQ0Ndp6EZ/Sw4xBnaopQyYX9jsaqkQ8tqSg2
md4LdkX4axn/w0EhnE/XtVLBmmsjC4L7ALuGFleG+Etp2gh3vKE1rmhphwHUqvXX
GEKjR6HnXbCGKwJHkWt9lawpmK8N+VmI9FSbyx0vh4kheMjIUQmkH7uNnJhGOQc4
FO5GrS+zqEJwuDoBVZny2ZjSeOctu5bPJGfwd2nZa0uG8qra6Qhi8RCLSkG2ZPsq
EABJEpoLZMeiB6U6TFNQrxUFUTn1dtLQgQxKdbq8hUxX4n5KMl/12pZNhyapfor4
/PvNObLiXIy6930k/0Ag
=+++8
-END PGP SIGNATURE-

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



ATTENTION:
The information in this e-mail is confidential and only meant for the intended 
recipient. If you are not the intended recipient, don't use or disclose it in 
any way. Please let the sender know and delete the message immediately.
--

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

Re: Migration to Tomcat 8.0 Post/PreResources vs VirtualWebappLoader with optional resources

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Robin,

On 12/7/16 4:01 AM, Berg, R. van den (Robin) wrote:
> Hello! I have an issue that seems not supported anymore with Tomcat
> 8. The same problem is also posted in the comments on:
> https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html
> 
> PROBLEM: We used the virtualWebAppLoader to get some extra
> libraries and classes that were on the machine on the classloader. 
> The virtualClasspath-property of the virtualWebAppLoader was a
> ';'-seperated list of directories. If one of them was empty, that
> was not a problem. We used the fact that non-existing/empty
> directories were not loaded, without any exception. MQ were
> imported on Test-acceptance-production. However, in a
> local/dev-setup we do not provide these libraries, since
> MQ-services are stubbed out.
> 
> We used the {Jar|File|Dir}ResourceSet in the context.xml as
> replacement for the virtualWebAppLoader, as recommended by the
> migration guide. However, these fail when the base-property is
> non-existent. Therefore, it breaks dev/local.
> 
> In the comments in
> https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html a
> solution was posted to extend the {Jar|File|Dir}ResourceSet. 
> However, that solution won't work for us, since we can't provide
> the tomcat-instances on test-acc-prd with an extra class/library
> with the extended class. (access-rights/cloud-solution only allows
> default setup).
> 
> PREFERRRED SOLUTION: Just like the tomcat 7  virtualWebAppLoader we
> would like the ResourceSet to be optional/non-failing if the
> resource is not available. Is there any configuration/property I
> can use to do that?

Did you file an enhancement request as suggested by Konstantin all
those months ago?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYSIXzAAoJEBzwKT+lPKRYRlcP/ip62nstdty643NjIdy8ImN4
/lhGdpw9qUfGTDiGF/wtqfOeAcTOIfoH1f0ZmnNaP9lZFMu917IT6Z0y3+fOwwnE
M3GPKBCZTQne3wY2oHqZujv4WVAiYzmcNlPDxeHljxP/aSiAf6DOyaWwGFLlUIml
7RiGBE+oJGQAMhohulPvSlh1ldSAsF637+xJA0O18DpRdSx9ikgDeeodRtA9Ei1d
R8sbZ9atYTqMH9ee4GBkc8yJDfZqf3Fo1FUjKghB3S4M9yxyjKqLqJORrFm4fOLH
PM4Oq7gkLEJNBWhkzABj6ruMw5/PHXrz4BV+K7rapdCSH7Bg5WXASiX0O0Z/rw1G
nVgd4kVwLRqDnRANjyU8+BnzyDq0sQ0Ndp6EZ/Sw4xBnaopQyYX9jsaqkQ8tqSg2
md4LdkX4axn/w0EhnE/XtVLBmmsjC4L7ALuGFleG+Etp2gh3vKE1rmhphwHUqvXX
GEKjR6HnXbCGKwJHkWt9lawpmK8N+VmI9FSbyx0vh4kheMjIUQmkH7uNnJhGOQc4
FO5GrS+zqEJwuDoBVZny2ZjSeOctu5bPJGfwd2nZa0uG8qra6Qhi8RCLSkG2ZPsq
EABJEpoLZMeiB6U6TFNQrxUFUTn1dtLQgQxKdbq8hUxX4n5KMl/12pZNhyapfor4
/PvNObLiXIy6930k/0Ag
=+++8
-END PGP SIGNATURE-

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

Migration to Tomcat 8.0 Post/PreResources vs VirtualWebappLoader with optional resources

[Berg, R. van den (Robin)]

Hello!
I have an issue that seems not supported anymore with Tomcat 8.
The same problem is also posted in the comments on: 
https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html

PROBLEM:
We used the virtualWebAppLoader to get some extra libraries and classes that 
were on the machine on the classloader.
The virtualClasspath-property of the virtualWebAppLoader was a ';'-seperated 
list of directories. If one of them was empty, that was not a problem.
We used the fact that non-existing/empty directories were not loaded, without 
any exception. MQ were imported on
Test-acceptance-production. However, in a local/dev-setup we do not provide 
these libraries, since MQ-services are stubbed out.

We used the {Jar|File|Dir}ResourceSet in the context.xml as replacement for the 
virtualWebAppLoader, as recommended by the migration guide.
However, these fail when the base-property is non-existent. Therefore, it 
breaks dev/local.

In the comments in 
https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html a solution was 
posted to extend the {Jar|File|Dir}ResourceSet.
However, that solution won't work for us, since we can't provide the 
tomcat-instances on test-acc-prd with an extra class/library with the extended 
class. (access-rights/cloud-solution only allows default setup).

PREFERRRED SOLUTION:
Just like the tomcat 7  virtualWebAppLoader we would like the ResourceSet to be 
optional/non-failing if the resource is not available. Is there any 
configuration/property I can use to do that?

Thanks,
Kind Regards,


ATTENTION:
The information in this e-mail is confidential and only meant for the intended 
recipient. If you are not the intended recipient, don't use or disclose it in 
any way. Please let the sender know and delete the message immediately.
--

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

Re: 8.0->8.5 migration - digests

[Anthony Biacco]

On Mon, Aug 15, 2016 at 11:02 PM, Mark Thomas <ma...@apache.org> wrote:

> On 16/08/2016 04:08, Anthony Biacco wrote:
> > Just started testing a migration from 8.0 to 8.5.
> > I'm was using digested passwords with digest="sha-512" in my realm for
> > manager and i noticed in the migration doc that it said the digest
> property
> > was removed.
> > Took me a little while to figure out that this was replaced with the
> > CredentialHandler.
> > Might to nice to see a little blurb after the notice to say, this is
> > replaced by CredentialHandler. See
> > https://tomcat.apache.org/tomcat-8.5-doc/config/credentialhandler.html
>
> The digest attribute is deprecated in 8.0.x. The credential handler is
> referenced in the 8.0.x docs in the description for the digest attribute.
>
> That said, this isn't mentioned in the 7.0.x to 8.0.x migration guide.
> I've made some changes.
>
>
Yep, had no idea. That's probably exactly what happened. I followed the
migration guide going from 7 to 8.0 , then just followed the release notes
for all the 8.0 versions going forward. It's also possible I knew and then
forgot when i hit 40 :)

Much thanks

-Tony




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

Re: 8.0->8.5 migration - digests

[Mark Thomas]

On 16/08/2016 04:08, Anthony Biacco wrote:
> Just started testing a migration from 8.0 to 8.5.
> I'm was using digested passwords with digest="sha-512" in my realm for
> manager and i noticed in the migration doc that it said the digest property
> was removed.
> Took me a little while to figure out that this was replaced with the
> CredentialHandler.
> Might to nice to see a little blurb after the notice to say, this is
> replaced by CredentialHandler. See
> https://tomcat.apache.org/tomcat-8.5-doc/config/credentialhandler.html

The digest attribute is deprecated in 8.0.x. The credential handler is
referenced in the 8.0.x docs in the description for the digest attribute.

That said, this isn't mentioned in the 7.0.x to 8.0.x migration guide.
I've made some changes.

Mark


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