Re: page extends not working???

2023-09-12 Thread Aryeh Friedman
On Tue, Sep 12, 2023 at 1:51 PM Christopher Schultz
 wrote:
>
> Aryeh,
>
> On 9/12/23 12:42, Aryeh Friedman wrote:
> > On Tue, Sep 12, 2023 at 11:42 AM Christopher Schultz
> >  wrote:
> >>
> >> Aryeh,
> >>
> >> On 9/11/23 10:05, Aryeh Friedman wrote:
> >>> On Mon, Sep 11, 2023 at 9:47 AM Christopher Schultz
> >>>  wrote:
> 
>  Aryeh,
> 
>  On 9/9/23 19:36, Aryeh Friedman wrote:
> > On Sat, Sep 9, 2023 at 1:23 PM Mark Thomas  wrote:
> >>
> >> On 09/09/2023 11:52, Aryeh Friedman wrote:
> >>> Every other jsp in my webapp (and other webapps on the same tomcat
> >>> instance [9.0.75]) works and I am using a the default container but as
> >>> curl/catalina.out show BasePage is *NEVER* being called (either the
> >>> _jspService() or the getX()):
> >>
> >> How have you configured your JSP(s) to use this alternative base class?
> >
> > sudo cat 
> > /usr/local/apache-tomcat-9.0/webapps/tlaitc-dashboard-1a1/index.jsp
> > 
> > <%@page extends="dashboard.web.pages.BasePage"%>
> > hi x is ${x}
> >
> > Output shown in log (sorry for not including the JSP the first time)
> > but to make it easier to find the output is "hi x is " when it should
> > be "hi x is 123234"... as you notice there are zero errors/warning in
> > catalina but there is none of the println's also... so the only thing
> > I can surmise is BasePage is never being called <%@page
> > extends="dashboard.web.pages.BasePage"%> somehow failed but I have
> > verified that correct spelling several times and also verified any
> > syntextual errors [including the contents of the string literal] will
> > show up in catalina.out (i.e. wrong class name is logged as an error)
> 
>  Your _jspService method in your base class will never be called, because
>  it is overridden by the auto-generated class for your JSP, which does
>  not call super._jspService.
> 
>  I do not believe that this:
> 
>  Hi X is ${x}
> 
>  ...will result in this.getX() being called from the JSP. References in
>  EL ${...} expressions will be resolved against the PageContext (and
>  other wider contexts), not against the JSP class currently executing.
> 
>  If you want to call this.getX() then you will need to do this:
> 
>  Hi X is <% getX() %>
> 
>  I wouldn't bother messing-around with class hierarchies in JSP. It
>  usually doesn't get you much but almost always requires you to bind
>  yourself very closely with the specific implementation of the JSP engine.
> 
>  It would be far better to use typical MVC-style development where a
>  servlet (or similar) handles the real work of the request, possibly
>  including writing a value of "x" to the request attributes. Then forward
>  your request to your JSP to produce the response content. This will be
>  much more straightforward and you will have fewer problems like this,
>  where expected behavior is confused by all the magic that JSP provides.
> >>>
> >>> Thanks but I have a very specific use case which the following working
> >>> example below should make more clear:
> >>>
> >>> 
> >>> <%@page import="dashboard.web.page.Page"%>
> >>> <%
> >>>   // THIS WOULD NOT BE NEEDED if <%@page extends="..."%> worked
> >>>   //
> >>>   // for now we don't need to keep the page object just
> >>>   // the setAttributes in our ctx
> >>>   new Page(pageContext);
> >>> %>
> >>>
> >>> 
> >>> 
> >>>   <%@include file="/widgets/scripts/scripts.jsp"%>
> >>> 
> >>> 
> >>>
> >>> 
> >>> 
> >>>
> >>> and the Page class:
> >>>
> >>> package dashboard.web.page;
> >>>
> >>> import javax.servlet.http.HttpServletRequest;
> >>> import javax.servlet.jsp.PageContext;
> >>>
> >>> import org.petitecloud.util.PetiteCloudNullException;
> >>>
> >>> // making this extend the right subclass plus working page
> >>> extends="" would mean zero in-line Java
> >>> // Copyright (C) 2023 TLAITC and contributors
> >>> public class Page
> >>> {
> >>>   public Page(PageContext ctx)
> >>>   {
> >>>   _dbc_construction(ctx);
> >>>
> >>>   this.ctx=ctx;
> >>>
> >>>   HttpServletRequest req=(HttpServletRequest) ctx.getRequest();
> >>>   String[] parts=req.getRequestURI().split("/");
> >>>   int split=2;
> >>>
> >>>   if(parts[0].equals("http:"))
> >>>   split+=2;
> >>>
> >>>   name="";
> >>>   for(int i=split;i >>>   name+="/"+parts[i];
> >>>
> >>>   if(name.length()==0)
> >>>   name="/index.jsp";
> >>>
> >>>   // we can safely asssume all valid requests will end with
> >>>   // .jsp at this point
> >>>   name=name.substring(1,name.length()-".jsp".length());
> >>>   path="/content/"+name+"/main.jsp";
> >>>
> >>>   ctx.setAttribute("pagePath",path);
> >>>  

[ANN] Apache Tomcat Connectors 1.2.49 released

2023-09-12 Thread Mark Thomas

The Apache Tomcat Connectors project is part of the Tomcat project and
provides web server plugins for httpd (mod_jk) and IIS (ISAPI) to 
connect those web servers with Tomcat and other backends.


The Apache Tomcat Project is proud to announce the release of version
1.2.49 of the Apache Tomcat Connectors.
This version fixes a number of bugs found in previous releases.

Full details of these changes and new features,
are available in the Apache Tomcat Connectors changelog:
https://tomcat.apache.org/connectors-doc/miscellaneous/changelog.html

In addition to the usual source release, this release includes Windows
binaries for the JK ISAPI connector for IIS.

Downloads:
https://tomcat.apache.org/download-connectors.cgi

Thank you,
--
The Apache Tomcat Team

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



Where do find debug logging

2023-09-12 Thread Alan F
We have some applications which are pushing out to their own applogs clearly 
showing 'Debug' on most lines with a large amount of data and CI.

I would like to find out where the app team are setting this level, I have 
check in the obvious in the war files as it's a Spring Boot app in 
application.properties and logback.xml but mention error only there. Any advice 
appreciated thanks




Re: page extends not working???

2023-09-12 Thread Christopher Schultz

Aryeh,

On 9/12/23 12:42, Aryeh Friedman wrote:

On Tue, Sep 12, 2023 at 11:42 AM Christopher Schultz
 wrote:


Aryeh,

On 9/11/23 10:05, Aryeh Friedman wrote:

On Mon, Sep 11, 2023 at 9:47 AM Christopher Schultz
 wrote:


Aryeh,

On 9/9/23 19:36, Aryeh Friedman wrote:

On Sat, Sep 9, 2023 at 1:23 PM Mark Thomas  wrote:


On 09/09/2023 11:52, Aryeh Friedman wrote:

Every other jsp in my webapp (and other webapps on the same tomcat
instance [9.0.75]) works and I am using a the default container but as
curl/catalina.out show BasePage is *NEVER* being called (either the
_jspService() or the getX()):


How have you configured your JSP(s) to use this alternative base class?


sudo cat /usr/local/apache-tomcat-9.0/webapps/tlaitc-dashboard-1a1/index.jsp

<%@page extends="dashboard.web.pages.BasePage"%>
hi x is ${x}

Output shown in log (sorry for not including the JSP the first time)
but to make it easier to find the output is "hi x is " when it should
be "hi x is 123234"... as you notice there are zero errors/warning in
catalina but there is none of the println's also... so the only thing
I can surmise is BasePage is never being called <%@page
extends="dashboard.web.pages.BasePage"%> somehow failed but I have
verified that correct spelling several times and also verified any
syntextual errors [including the contents of the string literal] will
show up in catalina.out (i.e. wrong class name is logged as an error)


Your _jspService method in your base class will never be called, because
it is overridden by the auto-generated class for your JSP, which does
not call super._jspService.

I do not believe that this:

Hi X is ${x}

...will result in this.getX() being called from the JSP. References in
EL ${...} expressions will be resolved against the PageContext (and
other wider contexts), not against the JSP class currently executing.

If you want to call this.getX() then you will need to do this:

Hi X is <% getX() %>

I wouldn't bother messing-around with class hierarchies in JSP. It
usually doesn't get you much but almost always requires you to bind
yourself very closely with the specific implementation of the JSP engine.

It would be far better to use typical MVC-style development where a
servlet (or similar) handles the real work of the request, possibly
including writing a value of "x" to the request attributes. Then forward
your request to your JSP to produce the response content. This will be
much more straightforward and you will have fewer problems like this,
where expected behavior is confused by all the magic that JSP provides.


Thanks but I have a very specific use case which the following working
example below should make more clear:


<%@page import="dashboard.web.page.Page"%>
<%
  // THIS WOULD NOT BE NEEDED if <%@page extends="..."%> worked
  //
  // for now we don't need to keep the page object just
  // the setAttributes in our ctx
  new Page(pageContext);
%>



  <%@include file="/widgets/scripts/scripts.jsp"%>


   



and the Page class:

package dashboard.web.page;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.jsp.PageContext;

import org.petitecloud.util.PetiteCloudNullException;

// making this extend the right subclass plus working page
extends="" would mean zero in-line Java
// Copyright (C) 2023 TLAITC and contributors
public class Page
{
  public Page(PageContext ctx)
  {
  _dbc_construction(ctx);

  this.ctx=ctx;

  HttpServletRequest req=(HttpServletRequest) ctx.getRequest();
  String[] parts=req.getRequestURI().split("/");
  int split=2;

  if(parts[0].equals("http:"))
  split+=2;

  name="";
  for(int i=split;i
<%@page extends="dashboard.web.page.Page"%>



  <%@include file="/widgets/scripts/scripts.jsp"%>


   



Side note I am currently adding user detection to the above page class
to that it can auto-enforce ACL's


I'm not sure I understand the point of the whole exercise. Nothing you
have in the PageContext class constructor cannot be done from within the
JSP itself, or -- better yet -- in an <%include> used by as many pages
as you want. *OR* ... you could do it in a Filter and apply it to all
requests, storing the information in the request attributes, which is
much more standard than directly modifying the page context.


The idea is to avoid any custom entries in web.xml (which filters
require)


This is not entirely true, and seems to be an arbitrary requirement. The 
application is configured via web.xml. Why disallow any configuration in 
web.xml?



and the entire point is this is a top level template and
future versions will provide a number of standard setAttriburtes that
expose different things like the logged in user.


Yeah, you are welcome to your own opinion, but everything you describe 
sounds like "we want to use JSPs for everything and not write Java code" 
and honestly what you n

Re: page extends not working???

2023-09-12 Thread Aryeh Friedman
On Tue, Sep 12, 2023 at 11:42 AM Christopher Schultz
 wrote:
>
> Aryeh,
>
> On 9/11/23 10:05, Aryeh Friedman wrote:
> > On Mon, Sep 11, 2023 at 9:47 AM Christopher Schultz
> >  wrote:
> >>
> >> Aryeh,
> >>
> >> On 9/9/23 19:36, Aryeh Friedman wrote:
> >>> On Sat, Sep 9, 2023 at 1:23 PM Mark Thomas  wrote:
> 
>  On 09/09/2023 11:52, Aryeh Friedman wrote:
> > Every other jsp in my webapp (and other webapps on the same tomcat
> > instance [9.0.75]) works and I am using a the default container but as
> > curl/catalina.out show BasePage is *NEVER* being called (either the
> > _jspService() or the getX()):
> 
>  How have you configured your JSP(s) to use this alternative base class?
> >>>
> >>> sudo cat 
> >>> /usr/local/apache-tomcat-9.0/webapps/tlaitc-dashboard-1a1/index.jsp
> >>> 
> >>> <%@page extends="dashboard.web.pages.BasePage"%>
> >>> hi x is ${x}
> >>>
> >>> Output shown in log (sorry for not including the JSP the first time)
> >>> but to make it easier to find the output is "hi x is " when it should
> >>> be "hi x is 123234"... as you notice there are zero errors/warning in
> >>> catalina but there is none of the println's also... so the only thing
> >>> I can surmise is BasePage is never being called <%@page
> >>> extends="dashboard.web.pages.BasePage"%> somehow failed but I have
> >>> verified that correct spelling several times and also verified any
> >>> syntextual errors [including the contents of the string literal] will
> >>> show up in catalina.out (i.e. wrong class name is logged as an error)
> >>
> >> Your _jspService method in your base class will never be called, because
> >> it is overridden by the auto-generated class for your JSP, which does
> >> not call super._jspService.
> >>
> >> I do not believe that this:
> >>
> >> Hi X is ${x}
> >>
> >> ...will result in this.getX() being called from the JSP. References in
> >> EL ${...} expressions will be resolved against the PageContext (and
> >> other wider contexts), not against the JSP class currently executing.
> >>
> >> If you want to call this.getX() then you will need to do this:
> >>
> >> Hi X is <% getX() %>
> >>
> >> I wouldn't bother messing-around with class hierarchies in JSP. It
> >> usually doesn't get you much but almost always requires you to bind
> >> yourself very closely with the specific implementation of the JSP engine.
> >>
> >> It would be far better to use typical MVC-style development where a
> >> servlet (or similar) handles the real work of the request, possibly
> >> including writing a value of "x" to the request attributes. Then forward
> >> your request to your JSP to produce the response content. This will be
> >> much more straightforward and you will have fewer problems like this,
> >> where expected behavior is confused by all the magic that JSP provides.
> >
> > Thanks but I have a very specific use case which the following working
> > example below should make more clear:
> >
> > 
> > <%@page import="dashboard.web.page.Page"%>
> > <%
> >  // THIS WOULD NOT BE NEEDED if <%@page extends="..."%> worked
> >  //
> >  // for now we don't need to keep the page object just
> >  // the setAttributes in our ctx
> >  new Page(pageContext);
> > %>
> >
> > 
> > 
> >  <%@include file="/widgets/scripts/scripts.jsp"%>
> > 
> > 
> >   
> > 
> > 
> >
> > and the Page class:
> >
> > package dashboard.web.page;
> >
> > import javax.servlet.http.HttpServletRequest;
> > import javax.servlet.jsp.PageContext;
> >
> > import org.petitecloud.util.PetiteCloudNullException;
> >
> > // making this extend the right subclass plus working page
> > extends="" would mean zero in-line Java
> > // Copyright (C) 2023 TLAITC and contributors
> > public class Page
> > {
> >  public Page(PageContext ctx)
> >  {
> >  _dbc_construction(ctx);
> >
> >  this.ctx=ctx;
> >
> >  HttpServletRequest req=(HttpServletRequest) ctx.getRequest();
> >  String[] parts=req.getRequestURI().split("/");
> >  int split=2;
> >
> >  if(parts[0].equals("http:"))
> >  split+=2;
> >
> >  name="";
> >  for(int i=split;i >  name+="/"+parts[i];
> >
> >  if(name.length()==0)
> >  name="/index.jsp";
> >
> >  // we can safely asssume all valid requests will end with
> >  // .jsp at this point
> >  name=name.substring(1,name.length()-".jsp".length());
> >  path="/content/"+name+"/main.jsp";
> >
> >  ctx.setAttribute("pagePath",path);
> >  }
> >
> >  // only used in testing
> >  public Page(String name)
> >  {
> >  this.name=name;
> >  }
> >
> >  public String getName()
> >  {
> >  return name;
> >  }
> >
> >  public String getPath()
> >  {
> >  return path;
> >  }
> >
> >  public PageContext getPageContext()
> >  {
> >  return ctx;
> >  }
> >
> >

Re: page extends not working???

2023-09-12 Thread Christopher Schultz

Aryeh,

On 9/11/23 10:05, Aryeh Friedman wrote:

On Mon, Sep 11, 2023 at 9:47 AM Christopher Schultz
 wrote:


Aryeh,

On 9/9/23 19:36, Aryeh Friedman wrote:

On Sat, Sep 9, 2023 at 1:23 PM Mark Thomas  wrote:


On 09/09/2023 11:52, Aryeh Friedman wrote:

Every other jsp in my webapp (and other webapps on the same tomcat
instance [9.0.75]) works and I am using a the default container but as
curl/catalina.out show BasePage is *NEVER* being called (either the
_jspService() or the getX()):


How have you configured your JSP(s) to use this alternative base class?


sudo cat /usr/local/apache-tomcat-9.0/webapps/tlaitc-dashboard-1a1/index.jsp

<%@page extends="dashboard.web.pages.BasePage"%>
hi x is ${x}

Output shown in log (sorry for not including the JSP the first time)
but to make it easier to find the output is "hi x is " when it should
be "hi x is 123234"... as you notice there are zero errors/warning in
catalina but there is none of the println's also... so the only thing
I can surmise is BasePage is never being called <%@page
extends="dashboard.web.pages.BasePage"%> somehow failed but I have
verified that correct spelling several times and also verified any
syntextual errors [including the contents of the string literal] will
show up in catalina.out (i.e. wrong class name is logged as an error)


Your _jspService method in your base class will never be called, because
it is overridden by the auto-generated class for your JSP, which does
not call super._jspService.

I do not believe that this:

Hi X is ${x}

...will result in this.getX() being called from the JSP. References in
EL ${...} expressions will be resolved against the PageContext (and
other wider contexts), not against the JSP class currently executing.

If you want to call this.getX() then you will need to do this:

Hi X is <% getX() %>

I wouldn't bother messing-around with class hierarchies in JSP. It
usually doesn't get you much but almost always requires you to bind
yourself very closely with the specific implementation of the JSP engine.

It would be far better to use typical MVC-style development where a
servlet (or similar) handles the real work of the request, possibly
including writing a value of "x" to the request attributes. Then forward
your request to your JSP to produce the response content. This will be
much more straightforward and you will have fewer problems like this,
where expected behavior is confused by all the magic that JSP provides.


Thanks but I have a very specific use case which the following working
example below should make more clear:


<%@page import="dashboard.web.page.Page"%>
<%
 // THIS WOULD NOT BE NEEDED if <%@page extends="..."%> worked
 //
 // for now we don't need to keep the page object just
 // the setAttributes in our ctx
 new Page(pageContext);
%>



 <%@include file="/widgets/scripts/scripts.jsp"%>


  



and the Page class:

package dashboard.web.page;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.jsp.PageContext;

import org.petitecloud.util.PetiteCloudNullException;

// making this extend the right subclass plus working page
extends="" would mean zero in-line Java
// Copyright (C) 2023 TLAITC and contributors
public class Page
{
 public Page(PageContext ctx)
 {
 _dbc_construction(ctx);

 this.ctx=ctx;

 HttpServletRequest req=(HttpServletRequest) ctx.getRequest();
 String[] parts=req.getRequestURI().split("/");
 int split=2;

 if(parts[0].equals("http:"))
 split+=2;

 name="";
 for(int i=split;i
<%@page extends="dashboard.web.page.Page"%>



 <%@include file="/widgets/scripts/scripts.jsp"%>


  



Side note I am currently adding user detection to the above page class
to that it can auto-enforce ACL's


I'm not sure I understand the point of the whole exercise. Nothing you 
have in the PageContext class constructor cannot be done from within the 
JSP itself, or -- better yet -- in an <%include> used by as many pages 
as you want. *OR* ... you could do it in a Filter and apply it to all 
requests, storing the information in the request attributes, which is 
much more standard than directly modifying the page context.


-chris

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



Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)

2023-09-12 Thread Michael Osipov
On 2023/09/12 07:06:52 "Thomas Hoffmann (Speed4Trade GmbH)" wrote:
> Hallo James,
> 
> > -Ursprüngliche Nachricht-
> > Von: James H. H. Lampert 
> > Gesendet: Montag, 11. September 2023 18:31
> > An: Java 400 List ; Tomcat Users List
> > 
> > Betreff: Solution to "Invalid keystore format" (cross-posted to Tomcat Users
> > List at Apache, and Java 400 List at Midrange)
> > 
> > Ladies and Gentlemen of Both Lists:
> > 
> > Last Friday evening, I ran into a problem updating SSL/TLS keystores on two
> > customer boxes, and spent three hours yesterday, finding the cause, doping
> > out a way to salvage the certs they'd paid for, and doping out a solution to
> > keep it from happening in the future.
> > 
> > It seems that with the new keystores (generated on my Mac, initially created
> > with Keytool, and then maintained with Keystore Explorer), they were
> > getting:
> > 
> >  >   Throwable occurred: java.io.IOException: Invalid keystore format
> > >   at com.ibm.crypto.provider.JavaKeyStore.engineLoad(Unknown Source)
> > >   at java.security.KeyStore.load(KeyStore.java:414)
> > 
> > I put them back on their old keystores, and cycled Tomcat again, to get them
> > back up, and then spent three hours working the problem yesterday
> > (Sunday) afternoon.
> > 
> > It turns out that the default keytool on my new Mac is the one from Java 17.
> > And the customer boxes are running Tomcat under much older JVMs,
> > because there's always a significant time lag before any given JVM makes it
> > to an IBM Midrange box.
> > 
> > So I was able to salvage one of the certs (and its CA reply, and its
> > chain) by moving the cert to a keystore generated on my *old* Mac (with
> > Java 8 as the default JVM), and then re-signing and re-chaining it in KSE. 
> > And I
> > tested the KS on our V6 box, to make *sure* it worked.
> > 
> > I then looked for a way, since my new Mac *has* a Java 8 JVM (it's just not
> > the default), to conveniently use that JVM's Keytool, and came up with a
> > wrapper BASH script to do the job. I tested the wrapper script by using it 
> > to
> > generate their new keystore.
> > 
> > Key takeaway (no pun intended) here: if you get an "Invalid keystore
> > format" in Tomcat (or presumably anything else that uses Java Keystores),
> > when generating a keystore on one box for use on another, *look for a
> > difference in JVM.*
> > 
> > --
> > JHHL
> > 
> 
> I moved away from using the proprietary java keystore format.
> I switched to using Base64 PEM format. This is usually also the format you 
> get from the certificate issuer.
> No need to convert it into Java format any more and you can also open it with 
> any text editor.

This is exactly the same what I have been doing for the past 10 years. No 
pointless fiddling with Java keystores.

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



AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)

2023-09-12 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hallo James,

> -Ursprüngliche Nachricht-
> Von: James H. H. Lampert 
> Gesendet: Montag, 11. September 2023 18:31
> An: Java 400 List ; Tomcat Users List
> 
> Betreff: Solution to "Invalid keystore format" (cross-posted to Tomcat Users
> List at Apache, and Java 400 List at Midrange)
> 
> Ladies and Gentlemen of Both Lists:
> 
> Last Friday evening, I ran into a problem updating SSL/TLS keystores on two
> customer boxes, and spent three hours yesterday, finding the cause, doping
> out a way to salvage the certs they'd paid for, and doping out a solution to
> keep it from happening in the future.
> 
> It seems that with the new keystores (generated on my Mac, initially created
> with Keytool, and then maintained with Keystore Explorer), they were
> getting:
> 
>  >   Throwable occurred: java.io.IOException: Invalid keystore format
> >   at com.ibm.crypto.provider.JavaKeyStore.engineLoad(Unknown Source)
> >   at java.security.KeyStore.load(KeyStore.java:414)
> 
> I put them back on their old keystores, and cycled Tomcat again, to get them
> back up, and then spent three hours working the problem yesterday
> (Sunday) afternoon.
> 
> It turns out that the default keytool on my new Mac is the one from Java 17.
> And the customer boxes are running Tomcat under much older JVMs,
> because there's always a significant time lag before any given JVM makes it
> to an IBM Midrange box.
> 
> So I was able to salvage one of the certs (and its CA reply, and its
> chain) by moving the cert to a keystore generated on my *old* Mac (with
> Java 8 as the default JVM), and then re-signing and re-chaining it in KSE. 
> And I
> tested the KS on our V6 box, to make *sure* it worked.
> 
> I then looked for a way, since my new Mac *has* a Java 8 JVM (it's just not
> the default), to conveniently use that JVM's Keytool, and came up with a
> wrapper BASH script to do the job. I tested the wrapper script by using it to
> generate their new keystore.
> 
> Key takeaway (no pun intended) here: if you get an "Invalid keystore
> format" in Tomcat (or presumably anything else that uses Java Keystores),
> when generating a keystore on one box for use on another, *look for a
> difference in JVM.*
> 
> --
> JHHL
> 

I moved away from using the proprietary java keystore format.
I switched to using Base64 PEM format. This is usually also the format you get 
from the certificate issuer.
No need to convert it into Java format any more and you can also open it with 
any text editor.

Greetings,
Thomas

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