date:20010730



Craig R. McClanahan wrote:
 
  What's the top priority for the Administrators section?
 
 IMHO, documenting the various settings in server.xml is critical.

+1000

I spent several hours last night attempting to get SSL working on TC4m6
standalone, with no success. I did everything the Configuring Catalina
doc said to do, as well as what was listed in the server.xml comments.
Since there is no error at startup and it's like the second Connector
directive is just skipped, I started poking around for a
definitive/exhautive doc on server.xml to a) verify the Connector tag
syntax (the current Config Cat. doc is a little out of date), and b)
check for any other tag that might need to be set. A comprehensive doc
on server.xml would have hit the spot. I'll even help, to the limited
extent that I am able (since I'm not even smart enough to even get SSL
working ... D'oh!)

- Christopher

P.S.  Quick question: The 3 JSSE libraries need to live in
$TCHOME/server/lib, yes? (They are already set okay externally.) The
Catalina doc says conf/server, but I assume that's just an artifact
from a previous dir structure.

Re: [DOC] TC4 Status



Christopher Cain wrote:
 
 [snip]

 P.S.  Quick question: The 3 JSSE libraries need to live in
 $TCHOME/server/lib, yes?

Okay, I guess as long as I'm asking, can someone please post the exact
syntax for the second (SSL) Connector in server.xml (keystoreName 
keystorePass are attributes of the Connector?, etc.) for TC4, and also
any thoughts off the top of your head as to what would cause the
connector to simply (and silently) not bind.

TIA

- Christopher

Re: Different approach to TC as a service (was: Separating Servic e code from Tomcat 4.0)

2001-07-30 Thread Sean Legassick


In message [EMAIL PROTECTED], 
Twiggs, Glenn [EMAIL PROTECTED] writes
Yes. With a patch applied to avoid the NT Logout snafu that causes the VM to
shutdown.

Do you have any information on this patch (I'm also using jk_service)?

-- 
Sean Legassick
[EMAIL PROTECTED]
 Soy un hombre: nada humano me es extrano

RE: [DOC] TC4 Status




On Mon, 30 Jul 2001, Rob S. wrote:

  It's not formally resolved, but it's time for us to just do
  something instead of just talk about it.
 
 Agreed.  Keeping things HT/XML with an agreed-upon set of tags sounds good
 to me.  I'll do that, keeping in mind the example docs (e.g. index.xml).
 Soon tho', we'll have to decide on a more extended set of tags to do things
 like tables and whatnot...
 

I don't contemplate a change in the current document / body /
section / subsection hierarchy, so you can start there.  Arbitrary
HTML can be nested inside, as long as all the tags balance in an XHTML
style (i.e. p ... /p, use br/ to create a br, and so on).

Adding specific styling tags for kinds of tables should probably wait
until we choose the final technology.  Interestingly, the same discussion
is going on over at xml.apache.org about how they generate their web site,
so maybe we'll be able to leverage the results of their thoughts (and they
probably know a *lot* more about XML than we do :-).

  You can see the fruits of my labors in the tomcat-docs web app.  This
  can be generated (if you've got the source distribution) by typing ant
  tomcat-docs at the top level.  I'm also going to upload a snapshot of the
  output to the Tomcat web site for easy perusal.
 
 It's going to have to wait until tonite after I can finish setting up my
 local machine.  I only checked out /jt4 last nite and apparently need a few
 more things before that task will complete successfully =)
 

Yep ... you'll be able to test out my new BUILDING.txt instructions :-).

The snapshot of the generated docs is also online at:

  http://jakarta.apache.org/tomcat/tomcat-4.0-doc-exp/index.html


  If you've got some text, I'd like to try integrating it into the
  tomcat-docs experiment.  The Anakia stylesheet that was written for
 
 Just the running multiple one, that I'll convert to the format if someone
 gives it the ok and touches it up a little bit =)
 
  You'll also note that I punted on the Getting Started and just linked in
  the text files from the top-level directory of the distribution.  I'm fine
 
 I had some thoughts about an introduction (see below).
 
  really needs to be done in at least two flavors -- reference material on
  all the possible options (pretty much done in HTML, needs to be
  converted), and a more user's guide approach to if you want to do
  this, here's how you do it.
 
  The current docs try to mix these styles a little, and I'm not so sure it
  is very effective.
 
 Agreed.  If the reference stuff is pretty much done, I don't mind helping on
 the conversion once we decide on a structure.  As well, that leaves the
 goal-oriented approach to be done, so we'll need a list of goals to start
 catering to.  I think having the docs organized (at least partially) by
 goal, would prove a much more rewarding experience for users.  This is
 contrary to the, teach them everything and have them figure it out
 themselves approach.  Apache was so frustrating that way.  I kept having to
 search the newsgroups to find out how to do seemingly common and simple
 things =/
 
  It's on my list to look at, honest!  As a general organizational note, are
  you thinking of having a section of the Administrator's Guide for one
  pager topics like this?  Or are you thinking these are more chapters or
  sections in something that feels like one overall document?
 
 No worries, you've got code + organizational bits to do and I think the code
 is more important anyways.  I just wanted to make sure it didn't slip
 through =)
 
 I'm not sure about how to break up the sections into individual files or
 documents yet.  I thought for now, we'd keep things one-file-per-major-topic
 and as we agreed on what goes where, deal with moving things around?
 

That sounds like a good approach.  Once in a while, we'll run into
multi-page major topics, but that is probably fairly rare.

 There still needs to be some sort of introduction to the container.  Rather
 than clutter up the docs with background information at every step, I think
 we should try to centralize this, a prerequisite of some sort, to continuing
 on with the documentation.  Not too long as to make people skip it, but
 enough so that we don't have to explain what a Context is every time we use
 the word.  I think the Getting Started section should be the place for
 this, and if I knew how to use any other gfx tool than Visio, I would make a
 pretty picture explaining the different routes through the docs.  Maybe I
 can get my gf to do it for me ;)
 
 - r
 
 
Craig

Re: [DOC] TC4 Status




On Mon, 30 Jul 2001, Christopher Cain wrote:

 
 Craig R. McClanahan wrote:
  
   What's the top priority for the Administrators section?
  
  IMHO, documenting the various settings in server.xml is critical.
 
 +1000
 
 I spent several hours last night attempting to get SSL working on TC4m6
 standalone, with no success. I did everything the Configuring Catalina
 doc said to do, as well as what was listed in the server.xml comments.
 Since there is no error at startup and it's like the second Connector
 directive is just skipped, I started poking around for a
 definitive/exhautive doc on server.xml to a) verify the Connector tag
 syntax (the current Config Cat. doc is a little out of date), and b)
 check for any other tag that might need to be set. A comprehensive doc
 on server.xml would have hit the spot. I'll even help, to the limited
 extent that I am able (since I'm not even smart enough to even get SSL
 working ... D'oh!)
 

That's why the goal-oriented stuff is important as well as the reference
stuff.  Of course, as you point out, out-of-date docs can almost be worse
than none at all!  :-)

 - Christopher
 
 P.S.  Quick question: The 3 JSSE libraries need to live in
 $TCHOME/server/lib, yes? (They are already set okay externally.) The
 Catalina doc says conf/server, but I assume that's just an artifact
 from a previous dir structure.
 

Yes, that should be conf/server/lib.  Alternatively (and the way I run
it), you can put these three JAR files in $JAVA_HOME/jre/lib/ext.

Craig McClanahan

Re: [DOC] TC4 Status




On Mon, 30 Jul 2001, Christopher Cain wrote:

 
 Christopher Cain wrote:
  
  [snip]
 
  P.S.  Quick question: The 3 JSSE libraries need to live in
  $TCHOME/server/lib, yes?
 
 Okay, I guess as long as I'm asking, can someone please post the exact
 syntax for the second (SSL) Connector in server.xml (keystoreName 
 keystorePass are attributes of the Connector?, etc.) for TC4, and also
 any thoughts off the top of your head as to what would cause the
 connector to simply (and silently) not bind.
 

Just uncommenting the 8443 connector example in the standard
conf/server.xml works for me.  You also have to set up your JSSE
environment according to the instructions immediately above this connector
entry.

What do your log files say?

 TIA
 
 - Christopher
 
Craig

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config - New directory


craigmcc01/07/30 10:48:34

  jakarta-tomcat-4.0/webapps/tomcat-docs/config - New directory

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config index.xml project.xml


craigmcc01/07/30 12:16:25

  Modified:webapps/tomcat-docs build.xml index.xml project.xml
  Added:   webapps/tomcat-docs/config index.xml project.xml
  Log:
  Check in the infrastructure to begin converting the server configuration
  reference documents.
  
  Revision  ChangesPath
  1.3   +13 -0 jakarta-tomcat-4.0/webapps/tomcat-docs/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/build.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- build.xml 2001/07/28 22:47:42 1.2
  +++ build.xml 2001/07/30 19:16:24 1.3
  @@ -103,6 +103,9 @@
   copytodir=${webapp.work}/appdev
 fileset dir=${site2.home}/xdocs/stylesheets includes=site.xsl/
   /copy
  +copytodir=${webapp.work}/config
  +  fileset dir=${site2.home}/xdocs/stylesheets includes=site.xsl/
  +/copy
   
   !-- Top Level Directory --
   style basedir=${webapp.work}
  @@ -117,6 +120,16 @@
   !-- Application Developer's Guide --
   style basedir=${webapp.work}/appdev
  destdir=${webapps.build}/${webapp.name}/appdev
  + extension=.html
  + style=site.xsl
  +  excludes=project.xml
  +  includes=*.xml
  +  param name=relative-path expression=./
  +/style
  +
  +!-- Server Configuration Reference --
  +style basedir=${webapp.work}/config
  +   destdir=${webapps.build}/${webapp.name}/config
extension=.html
style=site.xsl
 excludes=project.xml
  
  
  
  1.2   +6 -0  jakarta-tomcat-4.0/webapps/tomcat-docs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/index.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.xml 2001/07/28 22:54:13 1.1
  +++ index.xml 2001/07/30 19:16:24 1.2
  @@ -50,6 +50,12 @@
   pThe following documents are aimed at emSystem Administrators/em who
   are responsible for installing, configuring, and operating a Tomcat 4 server.
   /p
  +ul
  +lia href=config/index.htmlstrongServer Configuration Reference/strong/a
  +- Reference manual that documents all available elements and attributes
  +  that may be placed into a Tomcat 4 codeconf/server.xml/code file.
  +/li
  +/ul
   
   /section
   
  
  
  
  1.2   +1 -3  jakarta-tomcat-4.0/webapps/tomcat-docs/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/project.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- project.xml   2001/07/28 22:54:13 1.1
  +++ project.xml   2001/07/30 19:16:24 1.2
  @@ -19,9 +19,7 @@
   /menu
   
   menu name=Administrators
  -!--
  -item name=Configuration href=/config/index.html/
  ---
  +item name=Config. Reference href=/config/index.html/
   /menu
   
   menu name=App Developers
  
  
  
  1.1  jakarta-tomcat-4.0/webapps/tomcat-docs/config/index.xml
  
  Index: index.xml
  ===
  ?xml version=1.0?
  document
  
properties
  author email=[EMAIL PROTECTED]Craig R. McClanahan/author
  titleOverview/title
/properties
  
  body
  
  
  section name=Overview
  
  pThis manual contains reference information about all of the configuration
  directives that can be included in a codeconf/server.xml/code file to
  configure the behavior of the Tomcat 4 servlet/JSP container.  It does not
  attempt to describe which configuration directives should be used to perform
  specific tasks - for that, see the emServer Configuration Guide/em and
  related documents.  (TODO - will need hyperlink(s) to this)./p
  
  pTODO - add some verbage about the overall organization of conf/server.xml
  and the valid nesting that is allowed./p
  
  pTODO - add a brief description of the categories of elements listed in
  the navigation menu (top level, connectors, containers, nested)./p
  
  /section
  
  
  /body
  /document
  
  
  
  1.1  jakarta-tomcat-4.0/webapps/tomcat-docs/config/project.xml
  
  Index: project.xml
  ===
  ?xml version=1.0 encoding=ISO-8859-1?
  project name=Server Configuration Reference
  href=http://jakarta.apache.org/tomcat/;
  
  titleServer Configuration Reference/title
  
  logo href=http://jakarta.apache.org/tomcat/images/tomcat.gif;
The Tomcat Servlet/JSP Container
  /logo
  
  
  body
  
  menu name=Links
  item name=Docs Home href=/../
  item name=Config Reference  href=/index.html/

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm RealmBase.java


craigmcc01/07/30 13:04:05

  Modified:catalina/src/share/org/apache/catalina Realm.java
   catalina/src/share/org/apache/catalina/authenticator
LocalStrings.properties SSLAuthenticator.java
   catalina/src/share/org/apache/catalina/realm RealmBase.java
  Log:
  Realm:  Add a new authenticate() method signature that takes a client
  certificate chain (presumably provided when the CLIENT-CERT login method
  is selected.
  
  RealmBase:  Provide a default implementation of the new authenticate()
  signature that does the following:
  * (Optionally, but default=true) Ask the certificate chain to check
validity on each included certificate.
  * Call the getPrincipal() method of the actual implementation class
to return a Principal based on the username of the first certificate
in the chain (i.e. the client itself).  As a side effect of this change,
role lookups for CLIENT-CERT authenticated principals will now work
the same as for BASIC, DIGEST, and FORM based authentications.
  
  SSLAuthenticator:  Use the new Realm.authenticate() signature in a manner
  similar to that used by the other Authenticator implementations.
  
  This is a partial solution to BugTraq #4485977.
  
  Revision  ChangesPath
  1.4   +15 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Realm.java
  
  Index: Realm.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Realm.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- Realm.java2001/07/22 20:13:30 1.3
  +++ Realm.java2001/07/30 20:04:04 1.4
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Realm.java,v 1.3 
2001/07/22 20:13:30 pier Exp $
  - * $Revision: 1.3 $
  - * $Date: 2001/07/22 20:13:30 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Realm.java,v 1.4 
2001/07/30 20:04:04 craigmcc Exp $
  + * $Revision: 1.4 $
  + * $Date: 2001/07/30 20:04:04 $
*
* 
*
  @@ -67,6 +67,7 @@
   
   import java.beans.PropertyChangeListener;
   import java.security.Principal;
  +import java.security.cert.X509Certificate;
   
   
   /**
  @@ -77,7 +78,7 @@
* Container.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.3 $ $Date: 2001/07/22 20:13:30 $
  + * @version $Revision: 1.4 $ $Date: 2001/07/30 20:04:04 $
*/
   
   public interface Realm {
  @@ -158,6 +159,16 @@
 String nonce, String nc, String cnonce,
 String qop, String realm,
 String md5a2);
  +
  +
  +/**
  + * Return the Principal associated with the specified chain of X509
  + * client certificates.  If there is none, return codenull/code.
  + *
  + * @param certs Array of client certificates, with the first one in
  + *  the array being the certificate of the client itself.
  + */
  +public Principal authenticate(X509Certificate certs[]);
   
   
   /**
  
  
  
  1.3   +1 -0  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/LocalStrings.properties
  
  Index: LocalStrings.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/LocalStrings.properties,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- LocalStrings.properties   2000/09/12 00:10:09 1.2
  +++ LocalStrings.properties   2001/07/30 20:04:04 1.3
  @@ -7,4 +7,5 @@
   authenticator.notAuthenticated=Configuration error:  Cannot perform access control 
without an authenticated principal
   authenticator.notContext=Configuration error:  Must be attached to a Context
   authenticator.notStarted=Security Interceptor has not yet been started
  +authenticator.unauthorized=Cannot authenticate with the provided credentials
   authenticator.userDataConstraint=This request violates a User Data constraint for 
this application
  
  
  
  1.8   +19 -23
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java
  
  Index: SSLAuthenticator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- SSLAuthenticator.java 2001/07/22 20:09:19 1.7
  +++ SSLAuthenticator.java 2001/07/30 20:04:04 1.8
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java,v
 1.7

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util InstanceSupport.java


craigmcc01/07/30 13:35:49

  Modified:catalina/src/share/org/apache/catalina InstanceEvent.java
   catalina/src/share/org/apache/catalina/core
ApplicationFilterChain.java
   catalina/src/share/org/apache/catalina/util
InstanceSupport.java
  Log:
  Enhance InstanceEvent to include request and response properties for
  the BEFORE_FILTER_EVENT, AFTER_FILTER_EVENT, BEFORE_SERVICE_EVENT, and
  AFTER_SERVICE_EVENT events.  This allows event listeners to access other
  information relevant to the current request and response being processed
  when these events occur.
  
  This is the second of three patches required for BugTraq #4485977.
  
  Revision  ChangesPath
  1.5   +92 -6 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/InstanceEvent.java
  
  Index: InstanceEvent.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/InstanceEvent.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- InstanceEvent.java2001/07/22 20:13:30 1.4
  +++ InstanceEvent.java2001/07/30 20:35:49 1.5
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/InstanceEvent.java,v
 1.4 2001/07/22 20:13:30 pier Exp $
  - * $Revision: 1.4 $
  - * $Date: 2001/07/22 20:13:30 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/InstanceEvent.java,v
 1.5 2001/07/30 20:35:49 craigmcc Exp $
  + * $Revision: 1.5 $
  + * $Date: 2001/07/30 20:35:49 $
*
* 
*
  @@ -68,6 +68,8 @@
   import java.util.EventObject;
   import javax.servlet.Filter;
   import javax.servlet.Servlet;
  +import javax.servlet.ServletRequest;
  +import javax.servlet.ServletResponse;
   
   
   /**
  @@ -76,7 +78,7 @@
* as opposed to the Wrapper component that manages it.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.4 $ $Date: 2001/07/22 20:13:30 $
  + * @version $Revision: 1.5 $ $Date: 2001/07/30 20:35:49 $
*/
   
   public final class InstanceEvent
  @@ -147,7 +149,8 @@
   
   
   /**
  - * Construct a new InstanceEvent with the specified parameters.
  + * Construct a new InstanceEvent with the specified parameters.  This
  + * constructor is used for filter lifecycle events.
*
* @param wrapper Wrapper managing this servlet instance
* @param filter Filter instance for which this event occurred
  @@ -165,9 +168,34 @@
   
   
   /**
  - * Construct a new InstanceEvent with the specified parameters.
  + * Construct a new InstanceEvent with the specified parameters.  This
  + * constructor is used for filter processing events.
*
* @param wrapper Wrapper managing this servlet instance
  + * @param filter Filter instance for which this event occurred
  + * @param type Event type (required)
  + * @param request Servlet request we are processing
  + * @param response Servlet response we are processing
  + */
  +public InstanceEvent(Wrapper wrapper, Filter filter, String type,
  + ServletRequest request, ServletResponse response) {
  +
  +  super(wrapper);
  +  this.wrapper = wrapper;
  +  this.filter = filter;
  +  this.servlet = null;
  +  this.type = type;
  +  this.request = request;
  +  this.response = response;
  +
  +}
  +
  +
  +/**
  + * Construct a new InstanceEvent with the specified parameters.  This
  + * constructor is used for processing servlet lifecycle events.
  + *
  + * @param wrapper Wrapper managing this servlet instance
* @param servlet Servlet instance for which this event occurred
* @param type Event type (required)
*/
  @@ -182,6 +210,30 @@
   }
   
   
  +/**
  + * Construct a new InstanceEvent with the specified parameters.  This
  + * constructor is used for processing servlet processing events.
  + *
  + * @param wrapper Wrapper managing this servlet instance
  + * @param servlet Servlet instance for which this event occurred
  + * @param type Event type (required)
  + * @param request Servlet request we are processing
  + * @param response Servlet response we are processing
  + */
  +public InstanceEvent(Wrapper wrapper, Servlet servlet, String type,
  + ServletRequest request, ServletResponse response) {
  +
  +  super(wrapper);
  +  this.wrapper = wrapper;
  +  this.filter = null;
  +  this.servlet = servlet;
  +  this.type = type;
  +  this.request = request;
  +  this.response = response;
  +
  +}
  +
  +
   // - Instance Variables
   
   
  @@ -193,6

Standalone SSL Problem (was: Re: [DOC] TC4 Status)

(Two different mails snipped and referenced below :-)

Craig R. McClanahan wrote:

Yes, that should be conf/server/lib. Alternatively (and the way I run
it), you can put these three JAR files in $JAVA_HOME/jre/lib/ext.

A few things here. First, it is unnecessary, then, to have the JSSE jars
in the Tomcat hierarchy if they are installed extensions (/jre/lib/ext)?

Second, and just out of curiousity, the server/lib directory appears
to have moved up to the $TCHOME rather than underneath the conf
subdirectory. Was that a typo on your part, or does the container
actually search that path (in which case one would now have to manually
create it)?

Just uncommenting the 8443 connector example in the standard
conf/server.xml works for me.

But I still need to point it to my keystore, right? Basically, I
uncommented the section and added keystoreFile and keystorePass
attributes to the Connector tag. The second Http connector section now
reads this:

Connector className=org.apache.catalina.connector.http.HttpConnector
port=8443 minProcessors=5 maxProcessors=75
enableLookups=true acceptCount=10 debug=0
scheme=https secure=true
keystoreFile=/usr/local/tomcat/conf/my.keystore
keystorePass=mypass
Factory className=org.apache.catalina.net.SSLServerSocketFactory
clientAuth=false protocol=TLS/
/Connector

Again, all I changed was to add the two keystore attribs.

You also have to set up your JSSE environment according to the
instructions immediately above this connector entry.

I think so. I have JSSE 1.0.2, with the 3 jars in jre/lib/ext (and also
in the system classpath, although not that Catalina cares, of course). I
have the com.sun.net.ssl... provider in the security file (I assume
the pecking order doesn't matter). My keystore was generated with:

keytool -genkey -alias tomcat -keyalg RSA -keystore my.keystore
-keypasswd thepassword -storepasswd thepassword

Key and store passwords are the same. my.keystore is in the tomcat
conf directory and world-readable.

What do your log files say?

First of all, the silent failure bit I mentioned this morning was simply
my own goofiness. No message was thrown on the command line, and there
were no errors in the catalina_log... file, but I somehow missed the
catalina.out file (my only defense is that it was 2:00am at the time
:-) Below is the stack trace from that file.

PATHETIC DISCLAIMER:

I haven't tried to track it down yet, as I just now discovered this log
file. Although nothing jumps out at me from viewing the calling stack,
it may well be something braindead. I suppose this is technically a bit
of dev-list abuse now, but I am still familiarizing myself with the 4.0
codebase and am not yet up to speed on the container startup process. If
nothing appears obvious from my setup and/or stack trace, feel free to
call me a bum and tell me to track it down my own damn self. I simply
couldn't resist an invitation such as What do your log files say =)
(Although on the upshot, I can definitely promise you a Standalone SSL
Configuration and Troubleshooting doc once this is all said and done.)

- Christopher

P.S. TC4 takes about 2 minutes to start up on my P133 Redhat 7.1 box
with 256M of RAM. Is that normal or excessive? I'll definitely track
that one down myself, I just want to know if that is out of the ordinary
and therefore something I should even check into. I know for a fact that
javac compilations are almost surrealistically slow on that machine,
so maybe it has something to do with that. *shrug*

Anyway, thanks a ton for the SSL assistance!

Starting service Tomcat-Standalone
Apache Tomcat/4.0-b6
initProxy: java.security.NoSuchAlgorithmException: Class
com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
not a SSLContext
java.security.NoSuchAlgorithmException: Class
com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
not a SSLContext
at com.sun.net.ssl.b.a([DashoPro-V1.2-120198])
at com.sun.net.ssl.SSLContext.getInstance([DashoPro-V1.2-120198])
at
org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLServerSocketFactory.java:385)
at
org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLServerSocketFactory.java:328)
at
org.apache.catalina.net.SSLServerSocketFactory.createSocket(SSLServerSocketFactory.java:281)
at
org.apache.catalina.connector.http.HttpConnector.open(HttpConnector.java:905)
at
org.apache.catalina.connector.http.HttpConnector.start(HttpConnector.java:1078)
at
org.apache.catalina.core.StandardService.start(StandardService.java:360)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
at org.apache.catalina.startup.Catalina.process(Catalina.java:178)
at java.lang.reflect.Method.invoke(Native

RE: Standalone SSL Problem (was: Re: [DOC] TC4 Status)

2001-07-30 Thread Kevin Seguin


i have seen this.

little background first...

i had some webapps that needed to use jsse, plus catalina needed it for
https.  so, i figured i'd put the jsse jars somewhere in the tc4 dist tree
so that both the webapps and catalina could find them.  i believe that was
$TC4_HOME/common/lib.  well, long story short, that barfed and i saw errors
like the stack trace you saw.

i got rid of the problem by taking the jsse jars out of the tc4 dist tree,
and putting them into the ext dir under the jre installation, plus adding
the proper line to $JAVA_HOME/jre/lib/security/java.security.

 
 Starting service Tomcat-Standalone
 Apache Tomcat/4.0-b6
 initProxy:  java.security.NoSuchAlgorithmException: Class
 com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
 not a SSLContext
 java.security.NoSuchAlgorithmException: Class
 com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
 not a SSLContext
   at com.sun.net.ssl.b.a([DashoPro-V1.2-120198])
   at 
 com.sun.net.ssl.SSLContext.getInstance([DashoPro-V1.2-120198])
   at
 org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLSe
 rverSocketFactory.java:385)
   at
 org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLS
 erverSocketFactory.java:328)
   at
 org.apache.catalina.net.SSLServerSocketFactory.createSocket(SS
 LServerSocketFactory.java:281)
   at
 org.apache.catalina.connector.http.HttpConnector.open(HttpConn
 ector.java:905)
   at
 org.apache.catalina.connector.http.HttpConnector.start(HttpCon
 nector.java:1078)
   at
 org.apache.catalina.core.StandardService.start(StandardService
 .java:360)
   at
 org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
   at 
 org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
   at 
 org.apache.catalina.startup.Catalina.process(Catalina.java:178)
   at java.lang.reflect.Method.invoke(Native Method)
   at 
 org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)
 Catalina.start: LifecycleException:  HttpConnector[8443].open: 
 java.io.IOException: java.security.NoSuchAlgorithmException: Class
 com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
 not a SSLContext
 LifecycleException:  HttpConnector[8443].open:  java.io.IOException:
 java.security.NoSuchAlgorithmException: Class
 com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
 not a SSLContext
   at
 org.apache.catalina.connector.http.HttpConnector.start(HttpCon
 nector.java:1080)
   at
 org.apache.catalina.core.StandardService.start(StandardService
 .java:360)
   at
 org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
   at 
 org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
   at 
 org.apache.catalina.startup.Catalina.process(Catalina.java:178)
   at java.lang.reflect.Method.invoke(Native Method)
   at 
 org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)
 - Root Cause -
 java.io.IOException: java.security.NoSuchAlgorithmException: Class
 com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
 not a SSLContext
   at
 org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLSe
 rverSocketFactory.java:409)
   at
 org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLS
 erverSocketFactory.java:328)
   at
 org.apache.catalina.net.SSLServerSocketFactory.createSocket(SS
 LServerSocketFactory.java:281)
   at
 org.apache.catalina.connector.http.HttpConnector.open(HttpConn
 ector.java:905)
   at
 org.apache.catalina.connector.http.HttpConnector.start(HttpCon
 nector.java:1078)
   at
 org.apache.catalina.core.StandardService.start(StandardService
 .java:360)
   at
 org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
   at 
 org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
   at 
 org.apache.catalina.startup.Catalina.process(Catalina.java:178)
   at java.lang.reflect.Method.invoke(Native Method)
   at 
 org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)
 Stopping service Tomcat-Standalone

cvs commit: jakarta-tomcat-service/java/org/apache/service ServicePermission.java


pier01/07/30 16:23:22

  Modified:java/org/apache/service ServicePermission.java
  Log:
  Wrong license.
  
  Revision  ChangesPath
  1.3   +5 -5  
jakarta-tomcat-service/java/org/apache/service/ServicePermission.java
  
  Index: ServicePermission.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-service/java/org/apache/service/ServicePermission.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ServicePermission.java2001/07/26 19:30:28 1.2
  +++ ServicePermission.java2001/07/30 23:23:22 1.3
  @@ -26,10 +26,10 @@
*Alternately, this acknowlegement may appear in the software itself, if *
*and wherever such third-party acknowlegements normally appear. *
*   *
  - * 4. The names  The  Jakarta  Project,  Tomcat,  and  Apache  Software *
  - *Foundation  must not be used  to endorse or promote  products derived *
  - *from this  software without  prior  written  permission.  For  written *
  - *permission, please contact [EMAIL PROTECTED].*
  + * 4. The names  The Jakarta  Project,  and  Apache  Software Foundation *
  + *must not  be used  to endorse  or promote  products derived  from this *
  + *software without  prior written  permission.  For written  permission, *
  + *please contact [EMAIL PROTECTED].*
*   *
* 5. Products derived from this software may not be called Apache nor may *
*Apache appear in their names without prior written permission of the *
  @@ -124,7 +124,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Pier Fumagalli/a
* @author Copyright copy; 2000-2001 a href=http://www.apache.org/;The
* Apache Software Foundation/a. All rights reserved.
  - * @version 1.0 i(CVS $Revision: 1.2 $)/i
  + * @version 1.0 i(CVS $Revision: 1.3 $)/i
*/
   public final class ServicePermission extends Permission {

cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java


pier01/07/30 16:23:55

  Added:   java/org/apache/service Service.java
  Log:
  Initial draft of the Service interface.
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-service/java/org/apache/service/Service.java
  
  Index: Service.java
  ===
  /* = *
   *   *
   * The Apache Software License,  Version 1.1 *
   *   *
   * Copyright (c) 2001 The Apache Software Foundation.*
   *   All rights reserved.*
   *   *
   * = *
   *   *
   * Redistribution and use in source and binary forms,  with or without modi- *
   * fication, are permitted provided that the following conditions are met:   *
   *   *
   * 1. Redistributions of source code  must retain the above copyright notice *
   *notice, this list of conditions and the following disclaimer.  *
   *   *
   * 2. Redistributions  in binary  form  must  reproduce the  above copyright *
   *notice,  this list of conditions  and the following  disclaimer in the *
   *documentation and/or other materials provided with the distribution.   *
   *   *
   * 3. The end-user documentation  included with the redistribution,  if any, *
   *must include the following acknowlegement: *
   *   *
   *   This product includes  software developed  by the Apache  Software *
   *Foundation http://www.apache.org/.  *
   *   *
   *Alternately, this acknowlegement may appear in the software itself, if *
   *and wherever such third-party acknowlegements normally appear. *
   *   *
   * 4. The names  The Jakarta  Project,  and  Apache  Software Foundation *
   *must not  be used  to endorse  or promote  products derived  from this *
   *software without  prior written  permission.  For written  permission, *
   *please contact [EMAIL PROTECTED].*
   *   *
   * 5. Products derived from this software may not be called Apache nor may *
   *Apache appear in their names without prior written permission of the *
   *Apache Software Foundation.*
   *   *
   * THIS SOFTWARE IS PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES *
   * INCLUDING, BUT NOT LIMITED TO,  THE IMPLIED WARRANTIES OF MERCHANTABILITY *
   * AND FITNESS FOR  A PARTICULAR PURPOSE  ARE DISCLAIMED.  IN NO EVENT SHALL *
   * THE APACHE  SOFTWARE  FOUNDATION OR  ITS CONTRIBUTORS  BE LIABLE  FOR ANY *
   * DIRECT,  INDIRECT,   INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL *
   * DAMAGES (INCLUDING,  BUT NOT LIMITED TO,  PROCUREMENT OF SUBSTITUTE GOODS *
   * OR SERVICES;  LOSS OF USE,  DATA,  OR PROFITS;  OR BUSINESS INTERRUPTION) *
   * HOWEVER CAUSED AND  ON ANY  THEORY  OF  LIABILITY,  WHETHER IN  CONTRACT, *
   * STRICT LIABILITY, OR TORT  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN *
   * ANY  WAY  OUT OF  THE  USE OF  THIS  SOFTWARE,  EVEN  IF  ADVISED  OF THE *
   * POSSIBILITY OF SUCH DAMAGE.   *
   *   *
   * = *
   *   *
   * This software  consists of voluntary  contributions made  by many indivi- *
   * duals on behalf of the  Apache Software Foundation.  For more information *
   * on the Apache Software Foundation, please see http://www.apache.org/.   *
   *   *
   * = */
  package org.apache.service;
  
  /**
   *
   * @author a href=mailto:[EMAIL PROTECTED];Pier Fumagalli/a
   * @author Copyright copy;

cvs commit: jakarta-tomcat-service/java/org/apache/service ServiceContext.java


pier01/07/30 16:24:29

  Added:   java/org/apache/service ServiceContext.java
  Log:
  Initial draft of the ServiceContext interface.
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-service/java/org/apache/service/ServiceContext.java
  
  Index: ServiceContext.java
  ===
  /* = *
   *   *
   * The Apache Software License,  Version 1.1 *
   *   *
   * Copyright (c) 2001 The Apache Software Foundation.*
   *   All rights reserved.*
   *   *
   * = *
   *   *
   * Redistribution and use in source and binary forms,  with or without modi- *
   * fication, are permitted provided that the following conditions are met:   *
   *   *
   * 1. Redistributions of source code  must retain the above copyright notice *
   *notice, this list of conditions and the following disclaimer.  *
   *   *
   * 2. Redistributions  in binary  form  must  reproduce the  above copyright *
   *notice,  this list of conditions  and the following  disclaimer in the *
   *documentation and/or other materials provided with the distribution.   *
   *   *
   * 3. The end-user documentation  included with the redistribution,  if any, *
   *must include the following acknowlegement: *
   *   *
   *   This product includes  software developed  by the Apache  Software *
   *Foundation http://www.apache.org/.  *
   *   *
   *Alternately, this acknowlegement may appear in the software itself, if *
   *and wherever such third-party acknowlegements normally appear. *
   *   *
   * 4. The names  The Jakarta  Project,  and  Apache  Software Foundation *
   *must not  be used  to endorse  or promote  products derived  from this *
   *software without  prior written  permission.  For written  permission, *
   *please contact [EMAIL PROTECTED].*
   *   *
   * 5. Products derived from this software may not be called Apache nor may *
   *Apache appear in their names without prior written permission of the *
   *Apache Software Foundation.*
   *   *
   * THIS SOFTWARE IS PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES *
   * INCLUDING, BUT NOT LIMITED TO,  THE IMPLIED WARRANTIES OF MERCHANTABILITY *
   * AND FITNESS FOR  A PARTICULAR PURPOSE  ARE DISCLAIMED.  IN NO EVENT SHALL *
   * THE APACHE  SOFTWARE  FOUNDATION OR  ITS CONTRIBUTORS  BE LIABLE  FOR ANY *
   * DIRECT,  INDIRECT,   INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL *
   * DAMAGES (INCLUDING,  BUT NOT LIMITED TO,  PROCUREMENT OF SUBSTITUTE GOODS *
   * OR SERVICES;  LOSS OF USE,  DATA,  OR PROFITS;  OR BUSINESS INTERRUPTION) *
   * HOWEVER CAUSED AND  ON ANY  THEORY  OF  LIABILITY,  WHETHER IN  CONTRACT, *
   * STRICT LIABILITY, OR TORT  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN *
   * ANY  WAY  OUT OF  THE  USE OF  THIS  SOFTWARE,  EVEN  IF  ADVISED  OF THE *
   * POSSIBILITY OF SUCH DAMAGE.   *
   *   *
   * = *
   *   *
   * This software  consists of voluntary  contributions made  by many indivi- *
   * duals on behalf of the  Apache Software Foundation.  For more information *
   * on the Apache Software Foundation, please see http://www.apache.org/.   *
   *   *
   * = */
  package org.apache.service;
  
  
  /**
   *
   * @author a href=mailto:[EMAIL PROTECTED];Pier Fumagalli/a

cvs commit: jakarta-tomcat-service/java/org/apache/service ServiceController.java


pier01/07/30 16:25:00

  Added:   java/org/apache/service ServiceController.java
  Log:
  Initial implementation of the ServiceController interface.
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-service/java/org/apache/service/ServiceController.java
  
  Index: ServiceController.java
  ===
  /* = *
   *   *
   * The Apache Software License,  Version 1.1 *
   *   *
   * Copyright (c) 2001 The Apache Software Foundation.*
   *   All rights reserved.*
   *   *
   * = *
   *   *
   * Redistribution and use in source and binary forms,  with or without modi- *
   * fication, are permitted provided that the following conditions are met:   *
   *   *
   * 1. Redistributions of source code  must retain the above copyright notice *
   *notice, this list of conditions and the following disclaimer.  *
   *   *
   * 2. Redistributions  in binary  form  must  reproduce the  above copyright *
   *notice,  this list of conditions  and the following  disclaimer in the *
   *documentation and/or other materials provided with the distribution.   *
   *   *
   * 3. The end-user documentation  included with the redistribution,  if any, *
   *must include the following acknowlegement: *
   *   *
   *   This product includes  software developed  by the Apache  Software *
   *Foundation http://www.apache.org/.  *
   *   *
   *Alternately, this acknowlegement may appear in the software itself, if *
   *and wherever such third-party acknowlegements normally appear. *
   *   *
   * 4. The names  The Jakarta  Project,  and  Apache  Software Foundation *
   *must not  be used  to endorse  or promote  products derived  from this *
   *software without  prior written  permission.  For written  permission, *
   *please contact [EMAIL PROTECTED].*
   *   *
   * 5. Products derived from this software may not be called Apache nor may *
   *Apache appear in their names without prior written permission of the *
   *Apache Software Foundation.*
   *   *
   * THIS SOFTWARE IS PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES *
   * INCLUDING, BUT NOT LIMITED TO,  THE IMPLIED WARRANTIES OF MERCHANTABILITY *
   * AND FITNESS FOR  A PARTICULAR PURPOSE  ARE DISCLAIMED.  IN NO EVENT SHALL *
   * THE APACHE  SOFTWARE  FOUNDATION OR  ITS CONTRIBUTORS  BE LIABLE  FOR ANY *
   * DIRECT,  INDIRECT,   INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL *
   * DAMAGES (INCLUDING,  BUT NOT LIMITED TO,  PROCUREMENT OF SUBSTITUTE GOODS *
   * OR SERVICES;  LOSS OF USE,  DATA,  OR PROFITS;  OR BUSINESS INTERRUPTION) *
   * HOWEVER CAUSED AND  ON ANY  THEORY  OF  LIABILITY,  WHETHER IN  CONTRACT, *
   * STRICT LIABILITY, OR TORT  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN *
   * ANY  WAY  OUT OF  THE  USE OF  THIS  SOFTWARE,  EVEN  IF  ADVISED  OF THE *
   * POSSIBILITY OF SUCH DAMAGE.   *
   *   *
   * = *
   *   *
   * This software  consists of voluntary  contributions made  by many indivi- *
   * duals on behalf of the  Apache Software Foundation.  For more information *
   * on the Apache Software Foundation, please see http://www.apache.org/.   *
   *   *
   * = */
  package org.apache.service;
  
  
  /**
   *
   * @author a href=mailto:[EMAIL

cvs commit: jakarta-tomcat-service/java/org/apache/service ServiceListener.java


pier01/07/30 16:25:42

  Added:   java/org/apache/service ServiceListener.java
  Log:
  Initial draft of the ServiceListener interface.
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-service/java/org/apache/service/ServiceListener.java
  
  Index: ServiceListener.java
  ===
  /* = *
   *   *
   * The Apache Software License,  Version 1.1 *
   *   *
   * Copyright (c) 2001 The Apache Software Foundation.*
   *   All rights reserved.*
   *   *
   * = *
   *   *
   * Redistribution and use in source and binary forms,  with or without modi- *
   * fication, are permitted provided that the following conditions are met:   *
   *   *
   * 1. Redistributions of source code  must retain the above copyright notice *
   *notice, this list of conditions and the following disclaimer.  *
   *   *
   * 2. Redistributions  in binary  form  must  reproduce the  above copyright *
   *notice,  this list of conditions  and the following  disclaimer in the *
   *documentation and/or other materials provided with the distribution.   *
   *   *
   * 3. The end-user documentation  included with the redistribution,  if any, *
   *must include the following acknowlegement: *
   *   *
   *   This product includes  software developed  by the Apache  Software *
   *Foundation http://www.apache.org/.  *
   *   *
   *Alternately, this acknowlegement may appear in the software itself, if *
   *and wherever such third-party acknowlegements normally appear. *
   *   *
   * 4. The names  The Jakarta  Project,  and  Apache  Software Foundation *
   *must not  be used  to endorse  or promote  products derived  from this *
   *software without  prior written  permission.  For written  permission, *
   *please contact [EMAIL PROTECTED].*
   *   *
   * 5. Products derived from this software may not be called Apache nor may *
   *Apache appear in their names without prior written permission of the *
   *Apache Software Foundation.*
   *   *
   * THIS SOFTWARE IS PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES *
   * INCLUDING, BUT NOT LIMITED TO,  THE IMPLIED WARRANTIES OF MERCHANTABILITY *
   * AND FITNESS FOR  A PARTICULAR PURPOSE  ARE DISCLAIMED.  IN NO EVENT SHALL *
   * THE APACHE  SOFTWARE  FOUNDATION OR  ITS CONTRIBUTORS  BE LIABLE  FOR ANY *
   * DIRECT,  INDIRECT,   INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL *
   * DAMAGES (INCLUDING,  BUT NOT LIMITED TO,  PROCUREMENT OF SUBSTITUTE GOODS *
   * OR SERVICES;  LOSS OF USE,  DATA,  OR PROFITS;  OR BUSINESS INTERRUPTION) *
   * HOWEVER CAUSED AND  ON ANY  THEORY  OF  LIABILITY,  WHETHER IN  CONTRACT, *
   * STRICT LIABILITY, OR TORT  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN *
   * ANY  WAY  OUT OF  THE  USE OF  THIS  SOFTWARE,  EVEN  IF  ADVISED  OF THE *
   * POSSIBILITY OF SUCH DAMAGE.   *
   *   *
   * = *
   *   *
   * This software  consists of voluntary  contributions made  by many indivi- *
   * duals on behalf of the  Apache Software Foundation.  For more information *
   * on the Apache Software Foundation, please see http://www.apache.org/.   *
   *   *
   * = */
  package org.apache.service;
  
  public interface ServiceListener extends EventListener {
  
  }

Re: Problem with mod_jk 1.2.0 (latest CVS snapshot)

2001-07-30 Thread Bojan Smojver


GOMEZ Henri wrote:
 
 Just realised that the core I have was compiled without -g option. VERY
 useful. I also wanted to replicate the core dump with the
 httpd that was
 compiled with -g, but that didn't work. Now I'm starting to think that
 the core file I had was a result of a different crash (I was
 experimenting with a lot of stuff and Apache would sometimes spit the
 dummy).
 
 So, how do I get to you something you can use? I've seen the Apache
 debugging document (http://dev.apache.org/debugging.html) and forceful
 core dumping techniques, but I couldn't find truss for Linux.
 Or maybe I
 should use something else?
 
 What are your suggestions?
 
 Ask to Apache specialist in new-http list, may be JF Clere could
 forward your question to them ?

OK, after talking to some Apache people I have the core and the strace
to go with it (kind of a package deal ;-)

Since the core is rather big, I'll tar/bzip it and send it to your
e-mail address rather then the mailing list (don't want to go on the
hate list just yet).

Is that OK with you?

Bojan

Re: Standalone SSL Problem (was: Re: [DOC] TC4 Status)


Hot damn. Taking the classes out of the TC hierarchy got rid of that No
Such Algorithm business. Thanks Kevin!

Is that more-or-less expected behavior, or should I log it into bugzilla
so that it gets tracked as a bug? I'd be happy to look into it further,
although with my rather limited exposure to Catalina classloading it
might take a little while to get a patch for it.

Back to SSL ... unfortunately, in looking at the new stack trace, we're
now apparently back to my basic confusion about how to specify the
keystore stuff in the https connector. The server.xml snippet I posted
in my last message is presumably not right. Either that or I specified
something I shouldn't have when generating the keystore (also posted).
Can someone straighten me out? Also, feel free to beat me about the head
if I missed it in the docs somewhere =)

- Christopher

Starting service Tomcat-Standalone
Apache Tomcat/4.0-b6
initProxy:  java.security.UnrecoverableKeyException: Cannot recover key
java.security.UnrecoverableKeyException: Cannot recover key
at sun.security.provider.KeyProtector.recover(KeyProtector.java:308)
at
sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:110)
at java.security.KeyStore.getKey(KeyStore.java:264)
at
com.sun.net.ssl.internal.ssl.X509KeyManagerImpl.init([DashoPro-V1.2-120198])
at
com.sun.net.ssl.internal.ssl.KeyManagerFactoryImpl.engineInit([DashoPro-V1.2-120198])
at com.sun.net.ssl.KeyManagerFactory.init([DashoPro-V1.2-120198])
at
org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLServerSocketFactory.java:390)
at
org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLServerSocketFactory.java:328)
at
org.apache.catalina.net.SSLServerSocketFactory.createSocket(SSLServerSocketFactory.java:281)
at
org.apache.catalina.connector.http.HttpConnector.open(HttpConnector.java:905)
at
org.apache.catalina.connector.http.HttpConnector.start(HttpConnector.java:1078)
at
org.apache.catalina.core.StandardService.start(StandardService.java:360)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
at org.apache.catalina.startup.Catalina.process(Catalina.java:178)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)
Catalina.start: LifecycleException:  HttpConnector[8443].open: 
java.io.IOException: java.security.UnrecoverableKeyException: Cannot
recover key
LifecycleException:  HttpConnector[8443].open:  java.io.IOException:
java.security.UnrecoverableKeyException: Cannot recover key
at
org.apache.catalina.connector.http.HttpConnector.start(HttpConnector.java:1080)
at
org.apache.catalina.core.StandardService.start(StandardService.java:360)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
at org.apache.catalina.startup.Catalina.process(Catalina.java:178)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)
- Root Cause -
java.io.IOException: java.security.UnrecoverableKeyException: Cannot
recover key
at
org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLServerSocketFactory.java:409)
at
org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLServerSocketFactory.java:328)
at
org.apache.catalina.net.SSLServerSocketFactory.createSocket(SSLServerSocketFactory.java:281)
at
org.apache.catalina.connector.http.HttpConnector.open(HttpConnector.java:905)
at
org.apache.catalina.connector.http.HttpConnector.start(HttpConnector.java:1078)
at
org.apache.catalina.core.StandardService.start(StandardService.java:360)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
at org.apache.catalina.startup.Catalina.process(Catalina.java:178)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)

Kevin Seguin wrote:
 
 i have seen this.
 
 little background first...
 
 i had some webapps that needed to use jsse, plus catalina needed it for
 https.  so, i figured i'd put the jsse jars somewhere in the tc4 dist tree
 so that both the webapps and catalina could find them.  i believe that was
 $TC4_HOME/common/lib.  well, long story short, that barfed and i saw errors
 like the stack trace you saw.
 
 i got rid of the problem by taking the jsse jars out of

Re: cvs commit: jakarta-tomcat-service/java/org/apache/serviceService.java


[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote:
 
 [...]
 
 public interface Service {
 public void load(ServiceContext context) throws Exception;
 public void start() throws Exception;
 public void stop() throws Exception;
 }

I keep going back and forth between two ideas: the first one is the above
one, where a service is simply tied to the JVM process.
Basically, when the JVM process is created, load(...) then start() are
called, and at shutdown stop() is called.

Another idea would be this one:

public interface Service {
public void init(ServiceContext context) throws Exception;
public void start() throws Exception;
public void stop() throws Exception;
public void destroy() throws Exception;
}

This differs from the first one _not_only_ because a new method is added,
but also because the lifecycle of a Service is different: when the JVM
process is created init() is called (instead of load, but it's the same
shit), destroy() is called before the VM process is shut down, but start()
and stop() simply imply that a Service could be started and stopped many
times within the life of the JVM process...

So, now I'm stuck. Which one do you think is better (lately, I'm more
oriented towards the second approach!)

Pier

Re: Standalone SSL Problem (was: Re: [DOC] TC4 Status)

2001-07-30 Thread Remy Maucherat


Quoting Christopher Cain [EMAIL PROTECTED]:

 Hot damn. Taking the classes out of the TC hierarchy got rid of that No
 Such Algorithm business. Thanks Kevin!
 
 Is that more-or-less expected behavior, or should I log it into
 bugzilla
 so that it gets tracked as a bug?

I don't know if it's fixable. The secrity algorithms probably have to be loaded 
from the system class loader.

Remy

Re: Standalone SSL Problem (was: Re: [DOC] TC4 Status)



Remy Maucherat wrote:
 
 Quoting Christopher Cain [EMAIL PROTECTED]:
 
  Hot damn. Taking the classes out of the TC hierarchy got rid of that No
  Such Algorithm business. Thanks Kevin!
 
  Is that more-or-less expected behavior, or should I log it into
  bugzilla
  so that it gets tracked as a bug?
 
 I don't know if it's fixable. The secrity algorithms probably have to be loaded
 from the system class loader.
 
 Remy

You're quite right, I'm sure. I was actually thinking more along the
lines of having the startup routine ignore them should they be found in
any of the internal lib directories, so that at least they don't
conflict with the system loader. Of course, the other alternative would
be to simply include a warning in the SSL config doc I'm planning.
Either way, I guess ...

- Christopher

Re: Standalone SSL Problem (was: Re: [DOC] TC4 Status)




On Mon, 30 Jul 2001, Christopher Cain wrote:

 (Two different mails snipped and referenced below :-)
 
 Craig R. McClanahan wrote:
 
  Yes, that should be conf/server/lib.  Alternatively (and the way I run
  it), you can put these three JAR files in $JAVA_HOME/jre/lib/ext.
 
 A few things here. First, it is unnecessary, then, to have the JSSE jars
 in the Tomcat hierarchy if they are installed extensions (/jre/lib/ext)?
 

That is correct.  That's the way my setup works.

 Second, and just out of curiousity, the server/lib directory appears
 to have moved up to the $TCHOME rather than underneath the conf
 subdirectory. Was that a typo on your part, or does the container
 actually search that path (in which case one would now have to manually
 create it)?
 

Yes, the above is a typo -- it's really $CATALINA_HOME/server/lib.

  Just uncommenting the 8443 connector example in the standard
  conf/server.xml works for me.
 
 But I still need to point it to my keystore, right? Basically, I
 uncommented the section and added keystoreFile and keystorePass
 attributes to the Connector tag. The second Http connector section now
 reads this:
 
 Connector className=org.apache.catalina.connector.http.HttpConnector
   port=8443 minProcessors=5 maxProcessors=75
   enableLookups=true acceptCount=10 debug=0
   scheme=https secure=true
 keystoreFile=/usr/local/tomcat/conf/my.keystore
   keystorePass=mypass
Factory className=org.apache.catalina.net.SSLServerSocketFactory
   clientAuth=false protocol=TLS/
 /Connector
 
 Again, all I changed was to add the two keystore attribs.
 

I didn't, because the defaults work for me:

  keystoreFile - Default is .keystore in the user home directory
 of the user that is running Tomcat.

  keystorePass - changeit (as the docco in server.xml tells you to do

You can, of course, override these values as you have done, if you have
done something different.

  You also have to set up your JSSE environment according to the
  instructions immediately above this connector entry.
 
 I think so. I have JSSE 1.0.2, with the 3 jars in jre/lib/ext (and also
 in the system classpath, although not that Catalina cares, of course). I
 have the com.sun.net.ssl... provider in the security file (I assume
 the pecking order doesn't matter). My keystore was generated with:
 
 keytool -genkey -alias tomcat -keyalg RSA -keystore my.keystore
 -keypasswd thepassword -storepasswd thepassword
 

The shouldn't you set keystorePass to thepassword instead of mypass?

 Key and store passwords are the same. my.keystore is in the tomcat
 conf directory and world-readable.
 
  What do your log files say?
 
 First of all, the silent failure bit I mentioned this morning was simply
 my own goofiness. No message was thrown on the command line, and there
 were no errors in the catalina_log... file, but I somehow missed the
 catalina.out file (my only defense is that it was 2:00am at the time
 :-) Below is the stack trace from that file.
 
 PATHETIC DISCLAIMER:
 
 I haven't tried to track it down yet, as I just now discovered this log
 file. Although nothing jumps out at me from viewing the calling stack,
 it may well be something braindead. I suppose this is technically a bit
 of dev-list abuse now, but I am still familiarizing myself with the 4.0
 codebase and am not yet up to speed on the container startup process. If
 nothing appears obvious from my setup and/or stack trace, feel free to
 call me a bum and tell me to track it down my own damn self. I simply
 couldn't resist an invitation such as What do your log files say =)
 (Although on the upshot, I can definitely promise you a Standalone SSL
 Configuration and Troubleshooting doc once this is all said and done.)
 

Looks like the kind of problem you will have if the classes are BOTH in
the system extensions directory AND in the Tomcat hierarchy.  You really
don't want to do that.

 - Christopher
 
 P.S. TC4 takes about 2 minutes to start up on my P133 Redhat 7.1 box
 with 256M of RAM. Is that normal or excessive? I'll definitely track
 that one down myself, I just want to know if that is out of the ordinary
 and therefore something I should even check into. I know for a fact that
 javac compilations are almost surrealistically slow on that machine,
 so maybe it has something to do with that. *shrug*
 

The largest time consumer in the Tomcat code is creating multiple
SAXParserFactory instances in XmlMapper, which is apparently pretty
expensive.  There's already an enhancement request logged to reuse the
first one you create instead, which we'll get to at some point.

Tomcat 4 on my system (800mHz, 512mb) starts up with just the standard
apps in less than 5 seconds.  Of course, if you've got an app with
load-on-startup servlets that take a long time (such as Cocoon), then it's
not really Tomcat's fault anyway :-).

 Anyway, thanks a ton for the SSL assistance!
 

Craig


 --
 
 Starting service

[PATCH] Smart mappings + map-root confuses Apache TC3.3B1

2001-07-30 Thread William Barker


The configuration:
 ApacheConfig forwardAll=false useJkMount=true
 jkDebug=error  noRoot=false /

causes ApacheConfig to output a line of the form:
Alias / /path/to/ROOT

which makes Apache very unhappy when trying to find static files.

One alternative to the attached patch would be to simply output a
DocumentRoot directive for this special case, but I thought that that would
be more error-prone.

 ApacheConfig.diff

Re: cvs commit: jakarta-tomcat-service/java/org/apache/serviceService.java


+1 for the second approach.  If the logic of your service allows for
restarting without forcing an unload/reload of the entire JVM, the APIs
should accomodate that.

Craig


On Tue, 31 Jul 2001, Pier P. Fumagalli wrote:

 [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote:
  
  [...]
  
  public interface Service {
  public void load(ServiceContext context) throws Exception;
  public void start() throws Exception;
  public void stop() throws Exception;
  }
 
 I keep going back and forth between two ideas: the first one is the above
 one, where a service is simply tied to the JVM process.
 Basically, when the JVM process is created, load(...) then start() are
 called, and at shutdown stop() is called.
 
 Another idea would be this one:
 
 public interface Service {
 public void init(ServiceContext context) throws Exception;
 public void start() throws Exception;
 public void stop() throws Exception;
 public void destroy() throws Exception;
 }
 
 This differs from the first one _not_only_ because a new method is added,
 but also because the lifecycle of a Service is different: when the JVM
 process is created init() is called (instead of load, but it's the same
 shit), destroy() is called before the VM process is shut down, but start()
 and stop() simply imply that a Service could be started and stopped many
 times within the life of the JVM process...
 
 So, now I'm stuck. Which one do you think is better (lately, I'm more
 oriented towards the second approach!)
 
 Pier

RE: cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java

2001-07-30 Thread Kevin Seguin


 
 
 [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote:
  
  [...]
  
  public interface Service {
  public void load(ServiceContext context) throws Exception;
  public void start() throws Exception;
  public void stop() throws Exception;
  }
 
 I keep going back and forth between two ideas: the first one 
 is the above
 one, where a service is simply tied to the JVM process.
 Basically, when the JVM process is created, load(...) then start() are
 called, and at shutdown stop() is called.
 
 Another idea would be this one:
 
 public interface Service {
 public void init(ServiceContext context) throws Exception;
 public void start() throws Exception;
 public void stop() throws Exception;
 public void destroy() throws Exception;
 }
 
 This differs from the first one _not_only_ because a new 
 method is added,
 but also because the lifecycle of a Service is different: when the JVM
 process is created init() is called (instead of load, but 
 it's the same
 shit), destroy() is called before the VM process is shut 
 down, but start()
 and stop() simply imply that a Service could be started and 
 stopped many
 times within the life of the JVM process...
 
 So, now I'm stuck. Which one do you think is better (lately, I'm more
 oriented towards the second approach!)
 
 Pier
 

i kind of like the second approach.  

i like the idea, for example, of being able to tweak a config file, then
restart a service without having to restart the entire vm.  

also, it has nice symmetry with the servlet api :)

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java

2001-07-30 Thread remm


remm01/07/30 17:30:28

  Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
  Log:
  - The system policy file is now refreshed in the CL constructor, since it's more
likely to succeed here (in getPermissions, it could end up failing a check
on SecurityPermission getPolicy). An alternatie would be to wrap inside a
PA, but that change should allow it to work without a PA.
  - If Policy.getPolicy fails, the access control exception is caught and ignored, 
since
the policy reloading feature is optional, and shouldn't break things.
  
  Revision  ChangesPath
  1.12  +31 -16
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
  
  Index: WebappClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- WebappClassLoader.java2001/07/22 21:23:17 1.11
  +++ WebappClassLoader.java2001/07/31 00:30:28 1.12
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
 1.11 2001/07/22 21:23:17 remm Exp $
  - * $Revision: 1.11 $
  - * $Date: 2001/07/22 21:23:17 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
 1.12 2001/07/31 00:30:28 remm Exp $
  + * $Revision: 1.12 $
  + * $Date: 2001/07/31 00:30:28 $
*
* 
*
  @@ -123,7 +123,7 @@
*
* @author Remy Maucherat
* @author Craig R. McClanahan
  - * @version $Revision: 1.11 $ $Date: 2001/07/22 21:23:17 $
  + * @version $Revision: 1.12 $ $Date: 2001/07/31 00:30:28 $
*/
   public class WebappClassLoader
   extends URLClassLoader
  @@ -162,6 +162,10 @@
   system = getSystemClassLoader();
   securityManager = System.getSecurityManager();
   
  +if (securityManager != null) {
  +refreshPolicy();
  +}
  +
   }
   
   
  @@ -177,6 +181,10 @@
   system = getSystemClassLoader();
   securityManager = System.getSecurityManager();
   
  +if (securityManager != null) {
  +refreshPolicy();
  +}
  +
   }
   
   
  @@ -315,12 +323,6 @@
   
   
   /**
  - * Flag that the security policy has been refreshed from file.
  - */
  -private boolean policy_refresh = false;
  -
  -
  -/**
* The parent class loader.
*/
   private ClassLoader parent = null;
  @@ -1276,12 +1278,6 @@
*/
   protected PermissionCollection getPermissions(CodeSource codeSource) {
   
  -if (!policy_refresh) {
  -// Refresh the security policies
  -Policy policy = Policy.getPolicy();
  -policy.refresh();
  -policy_refresh = true;
  -}
   String codeUrl = codeSource.getLocation().toString();
   PermissionCollection pc;
   if ((pc = (PermissionCollection)loaderPC.get(codeUrl)) == null) {
  @@ -1702,6 +1698,25 @@
   return entry.loadedClass;
   }
   return (null);  // FIXME - findLoadedResource()
  +
  +}
  +
  +
  +/**
  + * Refresh the system policy file, to pick up eventual changes.
  + */
  +protected void refreshPolicy() {
  +
  +try {
  +// The policy file may have been modified to adjust 
  +// permissions, so we're reloading it when loading or 
  +// reloading a Context
  +Policy policy = Policy.getPolicy();
  +policy.refresh();
  +} catch (AccessControlException e) {
  +// Some policy files may restrict this, even for the core,
  +// so this exception is ignored
  +}
   
   }

Re: cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java


Kevin Seguin at [EMAIL PROTECTED] wrote:
 
 i kind of like the second approach.

That's what I'm oriented for...

 i like the idea, for example, of being able to tweak a config file, then
 restart a service without having to restart the entire vm.

Well, that's not _always_ true... For example, if in your config file you
change the port from 80 to 800 (both privileged, btw), you will have to
restart the VM. start() and stop() are merely a pause and continue, as
most of your configurations should be handled in init(), and that gets
called only _once_ within your JVM process...

 also, it has nice symmetry with the servlet api :)

Yeah, I like the symmetry too :)

Pier

mod_webapp vs. multi-thread component.

2001-07-30 Thread Thom Park



Pier et. al.

I hope that someone more enlightened can assist me with this one as I'm
totally flummoxed
by this - this applies to Solaris threads being used within mod_webapp (but
not directly)...

I have succesfully (yay!) built mod_webapp (and apr) using the native SUN C
compiler on Solaris
2.8. I am now attempting to add my own provider to the mix and am hitting an
odd problem that I
need explained to me )or hit on the head with a stick - which ever is less
painful ;-)

B.T.W. My 'provider' is an interface between apache and an IIOP (CORBA)
connector that allows apache to converse with
tomcat (using an IIOP java connector). (works champion on NT!).

Unfortunately I don't have a single-threaded version of the CORBA orb
libraries - only multi-threaded
are available. Note that from Apache's point of view this shouldn't be a
problem as there only is one
client per apache child - no callbacks are made between the client and
server so the execution thread being used
by apache should be the only one that invokes the (client) object reference.

Unfortunately, due to the mechanism involved in binding to a corba object,
the client lib spawns a bunch
of thread so handle the looking up and resolving of the object reference. It
is here that my problem occurs.
The CORBA api call launches 5 or so threads a this point (mainly to service
a try/retry object discovery role)
and, for every call to thr_create() that's performed by the 'connect' code,
I get the following message written to the
apache log (things in  paraphrased by me):

[apache timestamp][notice] child pid pidnum exit signal Abort(6)
thr_create: Inappropriate ioctl for device
thr_create: Inappropriate ioctl for device
thr_create: Inappropriate ioctl for device
...

I thought it might be that I hadn't put -lthread in the link line but that's
even nastier - Apache doesn't even
manage to startup if I do that.

So - can anyone please! offer any advice on :

a) what the above could mean
b) any suggestions on using multi-threading apps (in a single threaded
fashion) within mod_Webapp or apache.

Thanks,

Thom

p.s. Note that this isn't a problem per se with the mod_webapp connector -
more an issue with the use of threading
within Apache - so can anyone advise where i should post this request if not
here?

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 30, 2001 5:03 PM
To: [EMAIL PROTECTED]
Subject: Re: Standalone SSL Problem (was: Re: [DOC] TC4 Status)




On Mon, 30 Jul 2001, Christopher Cain wrote:

 (Two different mails snipped and referenced below :-)

 Craig R. McClanahan wrote:
 
  Yes, that should be conf/server/lib.  Alternatively (and the way I run
  it), you can put these three JAR files in $JAVA_HOME/jre/lib/ext.

 A few things here. First, it is unnecessary, then, to have the JSSE jars
 in the Tomcat hierarchy if they are installed extensions (/jre/lib/ext)?


That is correct.  That's the way my setup works.

 Second, and just out of curiousity, the server/lib directory appears
 to have moved up to the $TCHOME rather than underneath the conf
 subdirectory. Was that a typo on your part, or does the container
 actually search that path (in which case one would now have to manually
 create it)?


Yes, the above is a typo -- it's really $CATALINA_HOME/server/lib.

  Just uncommenting the 8443 connector example in the standard
  conf/server.xml works for me.

 But I still need to point it to my keystore, right? Basically, I
 uncommented the section and added keystoreFile and keystorePass
 attributes to the Connector tag. The second Http connector section now
 reads this:

 Connector className=org.apache.catalina.connector.http.HttpConnector
   port=8443 minProcessors=5 maxProcessors=75
   enableLookups=true acceptCount=10 debug=0
   scheme=https secure=true
 keystoreFile=/usr/local/tomcat/conf/my.keystore
   keystorePass=mypass
Factory className=org.apache.catalina.net.SSLServerSocketFactory
   clientAuth=false protocol=TLS/
 /Connector

 Again, all I changed was to add the two keystore attribs.


I didn't, because the defaults work for me:

  keystoreFile - Default is .keystore in the user home directory
 of the user that is running Tomcat.

  keystorePass - changeit (as the docco in server.xml tells you to do

You can, of course, override these values as you have done, if you have
done something different.

  You also have to set up your JSSE environment according to the
  instructions immediately above this connector entry.

 I think so. I have JSSE 1.0.2, with the 3 jars in jre/lib/ext (and also
 in the system classpath, although not that Catalina cares, of course). I
 have the com.sun.net.ssl... provider in the security file (I assume
 the pecking order doesn't matter). My keystore was generated with:

 keytool -genkey -alias tomcat -keyalg RSA -keystore my.keystore
 -keypasswd thepassword -storepasswd thepassword


The shouldn't you set keystorePass to

Re: cvs commit: jakarta-tomcat-service/java/org/apache/serviceService.java


Craig R. McClanahan at [EMAIL PROTECTED] wrote:

 +1 for the second approach.  If the logic of your service allows for
 restarting without forcing an unload/reload of the entire JVM, the APIs
 should accomodate that.

Again, it would not mean restart, but merely pause and continue, as
most of the construction should be performed in init(), since that's the one
with privileged super-user access in unix...

Pier

Re: mod_webapp vs. multi-thread component.


Thom Park at [EMAIL PROTECTED] wrote:
 
 Pier et. al.
 
 I hope that someone more enlightened can assist me with this one as I'm
 totally flummoxed by this - this applies to Solaris threads being used within
 mod_webapp (but not directly)...

Whoha... Looking for troubles, huh? :)

 I have succesfully (yay!) built mod_webapp (and apr) using the native SUN C
 compiler on Solaris 2.8. I am now attempting to add my own provider to the mix
 and am hitting an odd problem that I need explained to me )or hit on the head
 with a stick - which ever is less painful ;-)

Uh... Any modification to the build process? I believe APR doesn't like the
native SUN-C compiler that much (ok, I work for Sun and I use GCC...
WHAT-EVE! :)

 B.T.W. My 'provider' is an interface between apache and an IIOP (CORBA)
 connector that allows apache to converse with tomcat (using an IIOP java
 connector).

One of these days you'll enlighten me of the difference... I'm wondering why
you're using IIOP...

 (works champion on NT!).

Good :)

 Unfortunately I don't have a single-threaded version of the CORBA orb
 libraries - only multi-threaded are available. Note that from Apache's point
 of view this shouldn't be a problem as there only is one client per apache
 child - no callbacks are made between the client and server so the execution
 thread being used by apache should be the only one that invokes the (client)
 object reference.
 
 Unfortunately, due to the mechanism involved in binding to a corba object, the
 client lib spawns a bunch of thread so handle the looking up and resolving of
 the object reference. It is here that my problem occurs. The CORBA api call
 launches 5 or so threads a this point (mainly to service a try/retry object
 discovery role) and, for every call to thr_create() that's performed by the
 'connect' code, I get the following message written to the apache log (things
 in  paraphrased by me):
 
 [apache timestamp][notice] child pid pidnum exit signal Abort(6)
 thr_create: Inappropriate ioctl for device
 thr_create: Inappropriate ioctl for device
 thr_create: Inappropriate ioctl for device
 ...

Darn... Why would it be IOCTLing a device when creating a thread?

 I thought it might be that I hadn't put -lthread in the link line but that's
 even nastier - Apache doesn't even manage to startup if I do that.

Is it simply crashing or does it give some output?

 So - can anyone please! offer any advice on :
 
 a) what the above could mean

That's the weird part... Why is ioctl() called when a thread is created?

 b) any suggestions on using multi-threading apps (in a single threaded
 fashion) within mod_Webapp or apache.

I bet it would be the same if you created a module without APR and WEBAPP.
IMVHO, the problem is somewhere else... :(

Could this be something related to creating threads and using fork() at the
same time?

 p.s. Note that this isn't a problem per se with the mod_webapp connector -
 more an issue with the use of threading
 within Apache - so can anyone advise where i should post this request if not
 here?

I'm forwarding to apr-dev, lots of bright people over there, please, since
this is outside of the scope of APR, respond privately to me and/or Thom.
Thank you very much...

Pier

Re: Apache 1.3.20 hangs when warp-connecting to Tomcat4b6

2001-07-30 Thread Eryq


Pier P. Fumagalli wrote:

 The CVS repo is jakarta-tomcat-connectors/webapp
 Build both the module and the java part... Follow the README.

It didn't work.  Same behavior: Catalina runs
fine standalone, and the Warp port is definitely 
being listened to, but when Apache tries to deploy a Webapp,
it hangs and libhttpd dumps core.

Actually, the behavior is *worse* now than it was before;
Apache dumps core just when attempting to use some of
the mod_webapp directives, and never comes up.
Before, the info app could be loaded/run; now it does not.
A recap:

- webapp connector hot from CVS today
- apr hot from CVS today
- catalina from last night's nightly build
- SunOS clin5 5.8 Generic_108528-07 sun4u sparc SUNW,Ultra-60
- Apache 1.3.20
- gcc 2.95.2

I have now spent almost 2 weeks on this; this is driving
me crazy...

1.  Why is Apache hanging and *dumping core*
when it tries to deploy a webapp?
It has no problem with other shared libs.
Why such a bad bad reaction?

2.  Dynamic loading is definitely working fine.
My test libfoo.so works perfectly.
No core dump, nothing.  The only problem is mod_webapp.

3.  Can anyone help me determine *where* the problem is?
I can put my catalina up and you can hit the examples
via warp, if that will tell you something useful.
I don't know if it's...

apache 1.3.20
mod_webapp
mod_so
catalina
warp.jar
dld
?

4.  When I build apache, what do I have to do so that
apxs has gcc instead of ld as its linker?
I had to shoehorn that directly into the apxs script.
But again, mod_foo is fine.

n.  Can someone PLEASE make a mod_webapp.so binary for Solaris 5.8
available, built against apache 1.3.20 and dld? 

   
Sorry to whine.  I'm an open-source distributor myself
(http://www.zeegee.com/code/perl), so I'm appreciative
of the thankless tasks y'all have.  I'd like to help you ferret
out these problems, for my sake and others...

-- 
Eryq, http://www.zeegee.com/eryq 
WANTED:  Schrodinger's Cat.  Dead and/or Alive.

Re: Apache 1.3.20 hangs when warp-connecting to Tomcat4b6


Eryq at [EMAIL PROTECTED] wrote:

 Pier P. Fumagalli wrote:
 
 The CVS repo is jakarta-tomcat-connectors/webapp
 Build both the module and the java part... Follow the README.
 
 It didn't work.  Same behavior: Catalina runs
 fine standalone, and the Warp port is definitely
 being listened to, but when Apache tries to deploy a Webapp,
 it hangs and libhttpd dumps core.

What's libhttpd? It should be the httpd binary dumping core...

 Actually, the behavior is *worse* now than it was before;
 Apache dumps core just when attempting to use some of
 the mod_webapp directives, and never comes up.
 Before, the info app could be loaded/run; now it does not.

Weird... It runs fine for me and several others on Solaris 8 on sparc.

 A recap:
 
 - webapp connector hot from CVS today
 - apr hot from CVS today
 - catalina from last night's nightly build
 - SunOS clin5 5.8 Generic_108528-07 sun4u sparc SUNW,Ultra-60
 - Apache 1.3.20
 - gcc 2.95.2
 
 I have now spent almost 2 weeks on this; this is driving
 me crazy...

I bet...

 1.  Why is Apache hanging and *dumping core*
   when it tries to deploy a webapp?
   It has no problem with other shared libs.
   Why such a bad bad reaction?

Did you try compiling it with the --enable-debug flag? At what point does it
dump core? Any GDB stack trace from the core? Without information, there's
not much I can do...

 2.  Dynamic loading is definitely working fine.
   My test libfoo.so works perfectly.
   No core dump, nothing.  The only problem is mod_webapp.

It's weird...

 3.  Can anyone help me determine *where* the problem is?
   I can put my catalina up and you can hit the examples
   via warp, if that will tell you something useful.
   I don't know if it's...
 apache 1.3.20
 mod_webapp
 mod_so
 catalina
 warp.jar
 dld
 ?


Can you do a GDB stack trace of the core?

 4.  When I build apache, what do I have to do so that
   apxs has gcc instead of ld as its linker?
   I had to shoehorn that directly into the apxs script.
   But again, mod_foo is fine.

Nope... It should build cleanly with GCC... LD is called by GCC
appropriately...

 n.  Can someone PLEASE make a mod_webapp.so binary for Solaris 5.8
   available, built against apache 1.3.20 and dld?

Brian P., Thom? Can you send them one of your binaries, please?

 Sorry to whine.  I'm an open-source distributor myself
 (http://www.zeegee.com/code/perl), so I'm appreciative
 of the thankless tasks y'all have.  I'd like to help you ferret
 out these problems, for my sake and others...

Oh, don't worry... WebApp is new, and for sure there are bugs. But it's
kinda hard to know what's wrong since others with your same setup are
running it fine... :)

Pier

cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java


pier01/07/30 18:26:39

  Modified:java/org/apache/service Service.java
  Log:
  Final layout of the Service interface. Craig and Kevin convinced me that
  this is the best way to go:
  - init() and destroy() will be tied to the lifecycle of the VM process in
the underlying operating system
  - start() and stop() will allow starting and stopping of the Service several
times during the VM process life.
  
  Revision  ChangesPath
  1.2   +36 -2 jakarta-tomcat-service/java/org/apache/service/Service.java
  
  Index: Service.java
  ===
  RCS file: /home/cvs/jakarta-tomcat-service/java/org/apache/service/Service.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- Service.java  2001/07/30 23:23:55 1.1
  +++ Service.java  2001/07/31 01:26:39 1.2
  @@ -61,14 +61,43 @@
* @author a href=mailto:[EMAIL PROTECTED];Pier Fumagalli/a
* @author Copyright copy; 2000-2001 a href=http://www.apache.org/;The
* Apache Software Foundation/a. All rights reserved.
  - * @version 1.0 i(CVS $Revision: 1.1 $)/i
  + * @version 1.0 i(CVS $Revision: 1.2 $)/i
*/
   public interface Service {
   
   /**
  + * Initialize this codeService/code instance.
  + * p
  + *   This method gets called once the JVM process is created and the
  + *   codeService/code instance is created thru its empty public
  + *   constructor.
  + * /p
  + * p
  + *   Under certain operating systems (typically Unix based operating
  + *   systems) and if the native invocation framework is configured to do
  + *   so, this method might be called with isuper-user/i privileges.
  + * /p
  + * p
  + *   For example, it might be wise to create codeServerSocket/code
  + *   instances within the scope of this method, and perform all operations
  + *   requiring isuper-user/i privileges in the underlying operating
  + *   system.
  + * /p
  + * p
  + *   Apart from set up and allocation of native resources, this method
  + *   must not start the actual operation of the codeService/code (such
  + *   as starting threads calling the codeServerSocket.accept()/code
  + *   method) as this would impose some serious security hazards. The
  + *   start of operation must be performed in the codestart()/code
  + *   method.
  + * /p
*
  + * @param context The codeServiceContext/code instance associated with
  + *service codeService/code instance.
  + * @exception Exception Any exception preventing a successful
  + *  initialization.
*/
  -public void load(ServiceContext context)
  +public void init(ServiceContext context)
   throws Exception;
   
   /**
  @@ -82,5 +111,10 @@
*/
   public void stop()
   throws Exception;
  +
  +/**
  + * 
  + */
  +public void destroy();
   
   }

RE: mod_webapp vs. multi-thread component.

2001-07-30 Thread Thom Park


Hi Pier,

Whoha... Looking for troubles, huh? :)

no - trouble usually comes looking for me :)


 B.T.W. My 'provider' is an interface between apache and an IIOP (CORBA)
 connector that allows apache to converse with tomcat (using an IIOP java
 connector).

One of these days you'll enlighten me of the difference... I'm wondering
why
you're using IIOP...

it's not so much the access to tomcat - though IIOP does give me some nice
load-balancing/
location transparancy for free, it's more the case that if I can get this
working, I can
then call CORBA objects directly from apache without having to go via
tomcat.

I can also call C++ based CORBA objects as well as Java ones.

Darn... Why would it be IOCTLing a device when creating a thread?

Confused the hell out of me as well - I was wondering if it was the device
driver
that implements threads that was signalling an invalid ioctl operation.
Perhaps when
a thread is started up on Solaris, it looks like just another device under
the covers.

Or perhaps you can associate some device with a thread at thread creation
time and it's
that that causes the ioctl error. Who knows - I'm not a solaris kernel
guru...

Is it simply crashing or does it give some output?

The child processes that apache forks coredump with SEGVIO, nowhere near the
code that handles
mod webapp but during the startup of apache. It doesn't seem to like
libthread.so ;-)

 b) any suggestions on using multi-threading apps (in a single threaded
 fashion) within mod_Webapp or apache.

I bet it would be the same if you created a module without APR and WEBAPP.
IMVHO, the problem is somewhere else... :(

I agree - but there must be someway to get apache to 'like' threading...

 p.s. Note that this isn't a problem per se with the mod_webapp connector -
 more an issue with the use of threading
 within Apache - so can anyone advise where i should post this request if
not
 here?

I'm forwarding to apr-dev, lots of bright people over there, please, since
this is outside of the scope of APR, respond privately to me and/or Thom.
Thank you very much...

...and thank you too for the 'tea and sympathy' ;-)

-T.

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session StandardSession.java