Re: HttpServletResponseWrapper error.
Hi Jay, This works with Resin. However, in Tomcat, when I wrap the response, I commit the original response object and can not forward to a thank you page. I catch a java.lang.IllegalStateException: Cannot forward after response has been committed. In my debug tests, the response is committed during the RequestDispatchers forward method. I've had a similar case. The problem is that Tomcat calls flushBuffer() on the response, which seems to be completely legal regarding the Servlet spec. Calling flushBuffer() commits the response, and after that, no forward is possible. If Resin behaves differently, this is probably due to a different buffer size or different buffer handling. Perhaps Resin doesn't call flushBuffer() at all, which (in my understanding) is just as spec compliant as Tomcat's behaviour. What you have to do is override flushBuffer() in your response wrapper to prevent HttpServletResponseWrapper from passing the flush to the original response. In my case, I simply added an empty flushBuffer() method to the wrapper, and it worked. However, you should note that some containers _might_ rely on the side effects of the original flushBuffer() (e.g. that exceptions are raised when calling methods like sendRedirect() afterwards). Although this is highly unlikely, you have to simulate these effects in your wrapper if you want to be _absolutely_ sure your application runs in every container. Regards Andreas Junghans -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: The problem with /
I'm not primarily a 4.x developer, but in theory the following should work:
URL res = config.getResource(request.getPathInfo());
if(res != null) {
RequestDispatcher rd = config.getNamedDispatcher(default);
rd.forward(request,response);
return;
}
// Your processing here.
Undeclared variables correspond to their JSP counterparts.
4.x developers who want to gloat (and you know who you are, Craig ;), should
note that none of this is (currently) possible to do under 3.3.
- Original Message -
From: Peter Sojan [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, January 21, 2002 6:30 PM
Subject: Re: The problem with /
Thank you for your hint!
Now I understand, that with my setting:
--
servlet-mapping
servlet-nameMyMainServlet/servlet-name
url-pattern//url-pattern
/servlet-mapping
--
I override the default configuration which is:
--
servlet-mapping
servlet-namedefault/servlet-name
url-pattern//url-pattern
/servlet-mapping
--
If I want to handle all requests for non-existent resources with
my MyMainServlet and all static-existent (non-servlet) resources
with DefaultServlet, your solution should work If I can forsee
every type of static resource I will offer in my webapp.
So I would have to write mappings for *.gif, *.jpg, *.png, *.pdf,
*.bla, and so on. I think the way the spec handles this issue, is
that if I do a mapping on /, then requests for static-existent
content would still be served by the container without invoking
my MyMainServlet. However since the tomcat solution is to handle
static content with a DefaultServlet, I will always loose this
functionality when I override the / mapping with my own servlet.
Any suggestions for a workaround!?
Thx
Peter
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3.1 Release Plan
Tomcat 3.3.1 Release Plan Ballot: [] +1 I am in favor of this plan and will help [ X] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1 I am against this plan being executed, and my -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Tomcat 3.3.1 Release Plan
Faraj are you commiter ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Faraj Meir [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 22, 2002 11:45 AM To: Tomcat Developers List Subject: Re: [VOTE] Tomcat 3.3.1 Release Plan Tomcat 3.3.1 Release Plan Ballot: [] +1 I am in favor of this plan and will help [ X] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1 I am against this plan being executed, and my -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JDK 1.4 beta breaks TLS re-negotiation?
Hi,
I have tried to use TLS/SSL client authentication in Tomcat 4.0.1 and
JDK 1.4 beta3, and think that something changed in the JDK that breaks
renegotiation. It seems to work correctly with JDK 1.3.1.
I have an SSL connector with clientAuth=false in server.xml, and
have set up web.xml to require authentication with the CLIENT-CERT
method. This means that the SSL connection has to be renegotiated
when a particular URL is requested. My log file then says:
2002-01-07 12:08:17 CertificatesValve[/myapp]: verify: SSLPeerUnverifiedException
2002-01-07 12:08:17 CertificatesValve[/myapp]: verify: SSLPeerUnverifiedException
I get two lines like this every time the servlet is invoked.
I can see that these messages are generated by the CertificatesValve.
The first one is generated when it checks for client certificates when
there are none (the connector had clientAuth=false). It then does
initiates a new handshake:
// Force a new handshake to request the client certificates
//if (debug = 2)
//log( verify: Invalidating current session);
session.invalidate();
//if (debug = 2)
//log( verify: Forcing new SSL handshake);
socket.setNeedClientAuth(true);
try {
socket.startHandshake();
} catch (IOException e) {
log( verify: , e);
}
// Revalidate the existence of the required certificates
It then goes on to check for client certificates again, doesn't find
any, and writes the second error message.
Testing with OpenSSL s_client, I can see that the handshake doesn't
actually take place until after the servlet exits (complaining that
the client certs are missing).
This is different from the behaviour under JDK 1.3.1, when a new SSL
handshake takes place directly after the URL is requested, and the
servlet is called in the proper way.
I noted that the code above does not use a HandshakeCompletedListener
to wait for the HandshakeCompletedEvent, but just goes on with
checking if the handshake completed immediately. My guess is that the
behaviour of JSSE changed in JDK 1.4 beta, so that this no longer
works. It might be necessary to wait for the event before checking
the client certificates again.
I would really like to use other functionality from JDK 1.4 in my
application, so any ideas on a workaround would be appreciated.
Thanks,
Marcus
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3.1 Release Plan
Hi , Not but I'm liking to try tomcat . It's a very beautiful servlet implementation . Faraj Meir - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, January 22, 2002 12:44 PM Subject: RE: [VOTE] Tomcat 3.3.1 Release Plan Faraj are you commiter ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Faraj Meir [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 22, 2002 11:45 AM To: Tomcat Developers List Subject: Re: [VOTE] Tomcat 3.3.1 Release Plan Tomcat 3.3.1 Release Plan Ballot: [] +1 I am in favor of this plan and will help [ X] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1 I am against this plan being executed, and my -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3.1 Release Plan
Tomcat 3.3.1 Release Plan Ballot: [ ] +1 I am in favor of this plan and will help [X] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1 I am against this plan being executed, and my reason is: Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/webapp Makefile.in
jfclere 02/01/22 03:05:06
Modified:webapp Makefile.in
Log:
Add javadoc and scandoc generation.
Revision ChangesPath
1.25 +7 -1 jakarta-tomcat-connectors/webapp/Makefile.in
Index: Makefile.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/Makefile.in,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- Makefile.in 1 Nov 2001 22:20:51 - 1.24
+++ Makefile.in 22 Jan 2002 11:05:06 - 1.25
@@ -56,7 +56,7 @@
# = #
# @author Pier Fumagalli mailto:[EMAIL PROTECTED]
-# @version $Id: Makefile.in,v 1.24 2001/11/01 22:20:51 pier Exp $
+# @version $Id: Makefile.in,v 1.25 2002/01/22 11:05:06 jfclere Exp $
include @TGTDIR@/Makedefs
@@ -114,9 +114,15 @@
@$(MAKE) template MFLG=$(MAKEFLAGS) MDIR=apache-2.0 MTGT=clean
apidocs-c-build:
+ mkdir docs/api-c
+ support/scandoc.pl -i support/template.pl -p docs/api-c/ */*.h
apidocs-c-clean:
+ $(RM) -rf docs/api-c
apidocs-java-build:
+ mkdir docs/api-java
+ javadoc java/*.java -d docs/api-java
apidocs-java-clean:
+ $(RM) -rf docs/api-java
template:
@ { \
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: The problem with /
On Tue, Jan 22, 2002 at 02:00:08AM -0800, Bill Barker wrote:
I thought of something similar, but your solution is way more
elegant. Thank you!
I'm not primarily a 4.x developer, but in theory the following should work:
URL res = config.getResource(request.getPathInfo());
if(res != null) {
RequestDispatcher rd = config.getNamedDispatcher(default);
rd.forward(request,response);
return;
}
Peter
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Tomcat 3.3.1 Release Plan
Not but I'm liking to try tomcat . It's a very beautiful servlet implementation . Only commiters could vote on release plan ;) BTW : we need strong testers and fine bug reports -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
At this moment, I don't have plans to do the release any differently from 3.3 Final. It has been over a week since it tried anything from J-T-C (my builds were failing due a Tomcat 4.x dependency problem). I check again tonight. If something is ready, we can try to include it. Unfortunately, I am again out of tough with the status of J-T-C and what is or isn't ready. Cheers, Larry -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Monday, January 21, 2002 6:13 PM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt Which AJP is planned to go with this? - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 21, 2002 1:39 PM Subject: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt larryi 02/01/21 13:39:37 Added: .RELEASE-PLAN-3.3.1.txt Log: Proposed Tomcat 3.3.1 release plan Revision ChangesPath 1.1 jakarta-tomcat/RELEASE-PLAN-3.3.1.txt Index: RELEASE-PLAN-3.3.1.txt === NOTE: This document is a draft of a release plan for the next dot release of Tomcat. Nothing in this document should be considered authoritative until it has been discussed and approved on the TOMCAT-DEV mailing list. Tomcat 3.3.1 Release Plan = Objective: The objective of the proposed 3.3.1 release is to provide a bug fix update to Tomcat 3.3. Tomcat 3.3.1 Beta 1 Release: Code Freeze/Tag Date: Jan 27, 2002 Release Manager: Larry Isaacs Prior to this release, the following issues need to be addressed: Issue Description 1 Must be able to compile and run under JDK 1.1.8 2 Address Cactus failures running with Tomcat 3.3 Bugs to investigate fix or resolve/leave as LATER: 1657 hyphen character '-' in tag name results in Invalid expression (port fix from Tomcat 4.x Jasper) 3644 Errors reloading resources from jars: possible JDK bug (see if recent changes address this) 4382 Starting up twice prevents stopping (implement suggested fix) 4600 Tomcat 3.3 redirect behavior differs from Tomcat 3.2 (try to make 301 or 302 configurable) 4416 URI En/Decoding not working (investigate and fix if feasible) 4923 getRealPath().exists() yields security exception (investigate and fix if feasible) 5250 Load balancing workers do not correctly handle Cookies conformant with RFC 2965 (investigate and fix if feasible) 5684 WEB-INF/lib jar file loading and operations problems. (see if recent changes address this) 5722 Forward to a page that have no extension displays a blank page (try to fix to do something better than display a blank page) Tomcat 3.3.1 Release Candidate 1 Release: Code Freeze/Tag Date: Feb 2, 2002 Release Manager: Larry Isaacs Only safe fixes or documentation updates allowed prior to final release, including: Item Description 1 Update build.xml to work with Ant 1.4 with no warnings, i.e. require Ant 1.4. 2 Document special handling of '_' and '.' by AutoWebApp. Make special characters configurable. Bugs to fix: 5532 underscore is wrong (fixed by item 2 above) 4206 missing config files do not cause an error (add error or warning messages) 5769 NT Service display name should not be used as service name (determine solution and patch) 4364 build-solaris for Apache connector does not compile with -DE (do what we can to review and update the connector make files) Tomcat 3.3.1 Final Release: Code Freeze/Tag Date: Feb 9, 2002 Release Manager: Larry Isaacs The current jakarta-tomcat HEAD will be built and released as Tomcat 3.3.1 Final The following bugs will be updated with the following resolution: Bug Resolution From Description 2202 WORKSFORME REMIND sendRedirect with enctype=Multipart/form-data does not work 3168 WONTFIX LATER Reloading JSP Pages with includes in it 3290 INVALID LATER Sessions not sharing properly (lack of test case) WORKSFORME LATER request.getParameter(action) return only static page value 4426 WONTFIX NEWDB polling 5246 WONTFIX NEWillegal tag
IPv6 question
Hello, I saw last e-mails concerning IPv6 and Tomcat in this place in March. So is it all clear? I have installed Tomcat 4.0.1 on RedHat (kernel 2.4.14) and tried to connect to Tomcat using IPv6. Unfortunately, I got the 400 HTTP error Bad Request returned by Tomcat. The form of URL wan analogous to the one I used in IPv4 communication: http://address:8080/test/appl where address is the IPv6 address enclosed in []. JAVA_HOME variable points to my JDK1.4 beta location. On the standard 80 HTTP port runs Apache server which correctly accepts IPv6 requests. I would be grateful for your help. Thanks in advance, Lukasz Czekierda Distributed Systems Research Group, UMM in Krakow, Poland -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: IPv6 question
I saw last e-mails concerning IPv6 and Tomcat in this place in March. So is it all clear? I have installed Tomcat 4.0.1 on RedHat (kernel 2.4.14) and tried to connect to Tomcat using IPv6. Unfortunately, I got the 400 HTTP error Bad Request returned by Tomcat. The form of URL wan analogous to the one I used in IPv4 communication: http://address:8080/test/appl where address is the IPv6 address enclosed in []. JAVA_HOME variable points to my JDK1.4 beta location. Very interesting since there is not much works today on IPv6 in Tomcat and there is many parts in the code where 32 bits IP address are assumed. And as usually only test on IPv6 networks will make code more carefull about 32/48bits On the standard 80 HTTP port runs Apache server which correctly accepts IPv6 requests. Another reason to use connectors like mod_webapp or mod_jk Could you check these one ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core NamingContextListener.java StandardServer.java
remm02/01/22 08:12:26
Modified:catalina/src/share/org/apache/catalina/core
NamingContextListener.java StandardServer.java
Log:
- Changes to allow Catalina components to access an the global naming using
standard JNDI lookups.
- JNDI calls can only be made after the server has been started.
- Change the order in which server listeners are registered, so that the naming
listener
goes first.
- Note: The bidings are different at the moment from a standard ENC (the resources
are not bound in a comp subcontext, for example).
Revision ChangesPath
1.7 +20 -11
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/NamingContextListener.java
Index: NamingContextListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/NamingContextListener.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- NamingContextListener.java20 Jan 2002 03:00:56 - 1.6
+++ NamingContextListener.java22 Jan 2002 16:12:26 - 1.7
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/NamingContextListener.java,v
1.6 2002/01/20 03:00:56 craigmcc Exp $
- * $Revision: 1.6 $
- * $Date: 2002/01/20 03:00:56 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/NamingContextListener.java,v
1.7 2002/01/22 16:12:26 remm Exp $
+ * $Revision: 1.7 $
+ * $Date: 2002/01/22 16:12:26 $
*
*
*
@@ -116,7 +116,7 @@
* with each context and server.
*
* @author Remy Maucherat
- * @version $Revision: 1.6 $ $Date: 2002/01/20 03:00:56 $
+ * @version $Revision: 1.7 $ $Date: 2002/01/22 16:12:26 $
*/
public class NamingContextListener
@@ -259,7 +259,7 @@
public void lifecycleEvent(LifecycleEvent event) {
container = event.getLifecycle();
-
+
if (container instanceof Context) {
namingResources = ((Context) container).getNamingResources();
} else if (container instanceof Server) {
@@ -280,9 +280,7 @@
// Never happens
}
ContextAccessController.setSecurityToken(getName(), container);
-if (container instanceof Context)
-ContextBindings.bindContext(container, namingContext,
-container);
+ContextBindings.bindContext(container, namingContext, container);
//ContextBindings.bindThread(container, container);
// Setting the context in read/write mode
@@ -300,18 +298,26 @@
//ContextBindings.unbindThread(container, container);
// Binding the naming context to the class loader
-if (container instanceof Context)
+if (container instanceof Context) {
try {
ContextBindings.bindClassLoader
(container, container,
((Container) container).getLoader().getClassLoader());
-} catch (NamingException e) {
-log(sm.getString(naming.bindFailed, e));
+} catch (NamingException e) {
+log(sm.getString(naming.bindFailed, e));
+}
}
if (container instanceof Server) {
org.apache.naming.factory.ResourceLinkFactory.setGlobalContext
(namingContext);
+try {
+ContextBindings.bindClassLoader
+(container, container,
+ this.getClass().getClassLoader());
+} catch (NamingException e) {
+log(sm.getString(naming.bindFailed, e));
+}
if (container instanceof StandardServer) {
((StandardServer) container).setGlobalNamingContext
(namingContext);
@@ -513,6 +519,9 @@
if (debug = 1)
log(Creating JNDI naming context);
+
+if (namingResources == null)
+namingResources = new NamingResources();
// Environment entries
ContextEnvironment[] contextEnvironments =
1.18 +12 -13
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java
Index: StandardServer.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- StandardServer.java
failure loading webapp-module (tomcat 4.0.1) into apache (1.3.9)
running bin/apachectl configtest i get the error Syntax error on line 224 of /users/sts/stud/gu.bachmann/apache/conf/httpd.conf: Cannot load /users/sts/stud/gu.bachmann/apache/libexec/mod_webapp.so into server: ld.so.1: /users/sts/stud/gu.bachmann/apache/bin/httpd: fatal: relocation error: file /users/sts/stud/gu.bachmann/apache/libexec/mod_webapp.so: symbol __moddi3: referenced symbol not found (line 224 is the LoadModule directive) (apache is installed in /users/sts/stud/gu.bachmann/apache) host system: solaris 2.6 apache-version: 1.3.9 webapp module-version: 1.0.1 gcc-version: 2.8.1 autoconf-version: 2.52 libtool-version: 1.4.2 building the webapp module (source) works fine [./support/buildconf.sh, ./configure --with-apxs=..., make] building the apache (source) works fine. after copying the mod_webapp.so into libexec and adding the lines LoadModule webapp_module libexec/mod_webapp.so AddModule mod_webapp.c into the httpd.conf, i run into the error mentioned above if you know about anything that might help me to make the whole thing work, let me know. kind regards ... gunther bachmann -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: iSeries (AS/400) unusual JDK layout problem
On Tue, 22 Jan 2002, GOMEZ Henri wrote: Choices : - Add code in tomcat to make iSeries case handled (add tools.jar search in java.home/lib/ after java.home/../lib/) Unfortunately it doesn't seem to be iSeries specific - I've seen another similar problem on a hpux. The JAVA_HOME != java.home is a huge source of confusion for everyone. I already have the code - I'll check it in after it's tested. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: failure loading webapp-module (tomcat 4.0.1) into apache (1.3.9)
Gunther Bachmann wrote: running bin/apachectl configtest i get the error Syntax error on line 224 of /users/sts/stud/gu.bachmann/apache/conf/httpd.conf: Cannot load /users/sts/stud/gu.bachmann/apache/libexec/mod_webapp.so into server: ld.so.1: /users/sts/stud/gu.bachmann/apache/bin/httpd: fatal: relocation error: file /users/sts/stud/gu.bachmann/apache/libexec/mod_webapp.so: symbol __moddi3: referenced symbol not found (line 224 is the LoadModule directive) (apache is installed in /users/sts/stud/gu.bachmann/apache) host system: solaris 2.6 apache-version: 1.3.9 webapp module-version: 1.0.1 gcc-version: 2.8.1 autoconf-version: 2.52 libtool-version: 1.4.2 building the webapp module (source) works fine [./support/buildconf.sh, ./configure --with-apxs=..., make] building the apache (source) works fine. after copying the mod_webapp.so into libexec and adding the lines LoadModule webapp_module libexec/mod_webapp.so AddModule mod_webapp.c into the httpd.conf, i run into the error mentioned above if you know about anything that might help me to make the whole thing work, let me know. I think that the problem you have is due to the fact you are mixing gcc and cc... Probably the apache-1.3.9 has be compiled using the native (Sun compiler). You cannot mix these things. I also suggest that you should try with newer versions ;-) kind regards ... gunther bachmann -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: The problem with /
On Tue, 22 Jan 2002, Peter Sojan wrote: Date: Tue, 22 Jan 2002 03:30:43 +0100 From: Peter Sojan [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: The problem with / Thank you for your hint! Now I understand, that with my setting: -- servlet-mapping servlet-nameMyMainServlet/servlet-name url-pattern//url-pattern /servlet-mapping -- I override the default configuration which is: -- servlet-mapping servlet-namedefault/servlet-name url-pattern//url-pattern /servlet-mapping -- If I want to handle all requests for non-existent resources with my MyMainServlet and all static-existent (non-servlet) resources with DefaultServlet, your solution should work If I can forsee every type of static resource I will offer in my webapp. So I would have to write mappings for *.gif, *.jpg, *.png, *.pdf, *.bla, and so on. I think the way the spec handles this issue, is that if I do a mapping on /, then requests for static-existent content would still be served by the container without invoking my MyMainServlet. However since the tomcat solution is to handle static content with a DefaultServlet, I will always loose this functionality when I override the / mapping with my own servlet. Any suggestions for a workaround!? How about just serving the content yourself? It's not difficult to do. Thx Peter Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans MBeanUtils.java
amyroh 02/01/22 10:05:25
Modified:catalina/src/share/org/apache/catalina/mbeans
MBeanUtils.java
Log:
Fix NPE problem to be more robust so that it allows to have custom components.
Thanks to Remy for noticing the problem.
Revision ChangesPath
1.10 +72 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java
Index: MBeanUtils.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- MBeanUtils.java 21 Jan 2002 21:24:04 - 1.9
+++ MBeanUtils.java 22 Jan 2002 18:05:25 - 1.10
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
1.9 2002/01/21 21:24:04 remm Exp $
- * $Revision: 1.9 $
- * $Date: 2002/01/21 21:24:04 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
1.10 2002/01/22 18:05:25 amyroh Exp $
+ * $Revision: 1.10 $
+ * $Date: 2002/01/22 18:05:25 $
*
*
*
@@ -103,7 +103,7 @@
*
* @author Craig R. McClanahan
* @author Amy Roh
- * @version $Revision: 1.9 $ $Date: 2002/01/21 21:24:04 $
+ * @version $Revision: 1.10 $ $Date: 2002/01/22 18:05:25 $
*/
public class MBeanUtils {
@@ -177,6 +177,11 @@
String mname = createManagedName(connector);
ManagedBean managed = registry.findManagedBean(mname);
+if (managed == null) {
+// FIX ME
+// shoud we log ManagedBean not found with ManagedName + mname?
+return null;
+}
String domain = managed.getDomain();
if (domain == null)
domain = mserver.getDefaultDomain();
@@ -201,6 +206,9 @@
String mname = createManagedName(context);
ManagedBean managed = registry.findManagedBean(mname);
+if (managed == null) {
+return null;
+}
String domain = managed.getDomain();
if (domain == null)
domain = mserver.getDefaultDomain();
@@ -225,6 +233,9 @@
String mname = createManagedName(engine);
ManagedBean managed = registry.findManagedBean(mname);
+if (managed == null) {
+return null;
+}
String domain = managed.getDomain();
if (domain == null)
domain = mserver.getDefaultDomain();
@@ -249,6 +260,9 @@
String mname = createManagedName(host);
ManagedBean managed = registry.findManagedBean(mname);
+if (managed == null) {
+return null;
+}
String domain = managed.getDomain();
if (domain == null)
domain = mserver.getDefaultDomain();
@@ -273,6 +287,9 @@
String mname = createManagedName(loader);
ManagedBean managed = registry.findManagedBean(mname);
+if (managed == null) {
+return null;
+}
String domain = managed.getDomain();
if (domain == null)
domain = mserver.getDefaultDomain();
@@ -296,6 +313,9 @@
String mname = createManagedName(logger);
ManagedBean managed = registry.findManagedBean(mname);
+if (managed == null) {
+return null;
+}
String domain = managed.getDomain();
if (domain == null)
domain = mserver.getDefaultDomain();
@@ -320,6 +340,9 @@
String mname = createManagedName(manager);
ManagedBean managed = registry.findManagedBean(mname);
+if (managed == null) {
+return null;
+}
String domain = managed.getDomain();
if (domain == null)
domain = mserver.getDefaultDomain();
@@ -343,6 +366,9 @@
String mname = createManagedName(realm);
ManagedBean managed = registry.findManagedBean(mname);
+if (managed == null) {
+return null;
+}
String domain = managed.getDomain();
if (domain == null)
domain = mserver.getDefaultDomain();
@@ -365,6 +391,9 @@
String mname = createManagedName(server);
ManagedBean managed = registry.findManagedBean(mname);
+if (managed == null) {
+return null;
+}
String domain = managed.getDomain();
if (domain == null)
domain = mserver.getDefaultDomain();
@@ -389,6 +418,9 @@
String mname = createManagedName(service);
ManagedBean managed = registry.findManagedBean(mname);
+if
RE: jdk1.3.1 and tomcat 3.3a core dumping?
The main reason that we wanted to change to tomcat 3.3 is for the hierarchical classloading support. I guess we'll have to wait. Dan -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Monday, January 21, 2002 11:34 PM To: Tomcat Developers List Subject: Re: jdk1.3.1 and tomcat 3.3a core dumping? Of course, there is always the issue that there is absolutely no need to run 3.3a on a Solaris box (which is why I really can't be bothered to download it to check this out, since my primary production environment is Solaris). If you're not running Windows, than there is no advantage to using 3.3a over 3.3.0. There are lots of advantages to using 3.3.1-dev (aka nightly, soon to be 3.3.1-B1) reguardless of the OS. see: http://cvs.apache.org/viewcvs/jakarta-tomcat/RELEASE-NOTES-3.3.1.txt - Original Message - From: Bojan Smojver [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, January 21, 2002 6:15 PM Subject: RE: jdk1.3.1 and tomcat 3.3a core dumping? Quoting Dan Diodati [EMAIL PROTECTED]: I don't think the java code has any issues because it has been in production with jdk1.2.2 and tomcat 3.2.4. Maybe I wasn't clear enough. The point is that this is a JVM issue, it has nothing to do with Java classes you run on it (except that some of them might trigger a particular bug within the JVM). I tried using tomcat 3.2.4 and jdk 1.3.1_02 it this issue does NOT occur, making me suspicious of tomcat 3.3a. As above. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0 with SSL
Henry Lu [EMAIL PROTECTED] writes: I followed the every steps in the doc for how-to do ssl. But I got failure when I start the tomcat. Since I couldn't see all error message, here is the on on the screen: at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) - Root Cause - java.io.IOException: java.security.UnrecoverableKeyException: Cannot recover key at org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLServerSoc ketFactory.java:422) at org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLServerSo cketFactory.java:334) at org.apache.catalina.net.SSLServerSocketFactory.createSocket(SSLServer SocketFactory.java:287) at org.apache.catalina.connector.http.HttpConnector.open(HttpConnector.j ava:946) at org.apache.catalina.connector.http.HttpConnector.initialize(HttpConne ctor.java:1114) at org.apache.catalina.core.StandardService.initialize(StandardService.j ava:454) at org.apache.catalina.core.StandardServer.initialize(StandardServer.jav a:552) at org.apache.catalina.startup.Catalina.start(Catalina.java:775) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) Is there any answer? I'd guess that this is a password problem. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans MBeanUtils.java
remm02/01/22 10:16:58
Modified:catalina/src/share/org/apache/catalina/mbeans
MBeanUtils.java
Log:
- Fix small compilation problem.
Revision ChangesPath
1.11 +15 -15
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java
Index: MBeanUtils.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- MBeanUtils.java 22 Jan 2002 18:05:25 - 1.10
+++ MBeanUtils.java 22 Jan 2002 18:16:57 - 1.11
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
1.10 2002/01/22 18:05:25 amyroh Exp $
- * $Revision: 1.10 $
- * $Date: 2002/01/22 18:05:25 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
1.11 2002/01/22 18:16:57 remm Exp $
+ * $Revision: 1.11 $
+ * $Date: 2002/01/22 18:16:57 $
*
*
*
@@ -103,7 +103,7 @@
*
* @author Craig R. McClanahan
* @author Amy Roh
- * @version $Revision: 1.10 $ $Date: 2002/01/22 18:05:25 $
+ * @version $Revision: 1.11 $ $Date: 2002/01/22 18:16:57 $
*/
public class MBeanUtils {
@@ -875,7 +875,7 @@
String mname = createManagedName(connector);
ManagedBean managed = registry.findManagedBean(mname);
if (managed == null) {
-return null;
+return;
}
String domain = managed.getDomain();
if (domain == null)
@@ -900,7 +900,7 @@
String mname = createManagedName(context);
ManagedBean managed = registry.findManagedBean(mname);
if (managed == null) {
-return null;
+return;
}
String domain = managed.getDomain();
if (domain == null)
@@ -925,7 +925,7 @@
String mname = createManagedName(engine);
ManagedBean managed = registry.findManagedBean(mname);
if (managed == null) {
-return null;
+return;
}
String domain = managed.getDomain();
if (domain == null)
@@ -950,7 +950,7 @@
String mname = createManagedName(host);
ManagedBean managed = registry.findManagedBean(mname);
if (managed == null) {
-return null;
+return;
}
String domain = managed.getDomain();
if (domain == null)
@@ -975,7 +975,7 @@
String mname = createManagedName(loader);
ManagedBean managed = registry.findManagedBean(mname);
if (managed == null) {
-return null;
+return;
}
String domain = managed.getDomain();
if (domain == null)
@@ -1000,7 +1000,7 @@
String mname = createManagedName(logger);
ManagedBean managed = registry.findManagedBean(mname);
if (managed == null) {
-return null;
+return;
}
String domain = managed.getDomain();
if (domain == null)
@@ -1025,7 +1025,7 @@
String mname = createManagedName(manager);
ManagedBean managed = registry.findManagedBean(mname);
if (managed == null) {
-return null;
+return;
}
String domain = managed.getDomain();
if (domain == null)
@@ -1049,7 +1049,7 @@
String mname = createManagedName(realm);
ManagedBean managed = registry.findManagedBean(mname);
if (managed == null) {
-return null;
+return;
}
String domain = managed.getDomain();
if (domain == null)
@@ -1074,7 +1074,7 @@
String mname = createManagedName(server);
ManagedBean managed = registry.findManagedBean(mname);
if (managed == null) {
-return null;
+return;
}
String domain = managed.getDomain();
if (domain == null)
@@ -1099,7 +1099,7 @@
String mname = createManagedName(service);
ManagedBean managed = registry.findManagedBean(mname);
if (managed == null) {
-return null;
+return;
}
String domain = managed.getDomain();
if (domain == null)
@@ -1124,7 +1124,7 @@
String mname = createManagedName(valve);
ManagedBean managed = registry.findManagedBean(mname);
if (managed == null) {
-return null;
+return;
}
String domain = managed.getDomain();
if (domain == null)
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml
amyroh 02/01/22 10:24:12 Modified:catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml Log: Fix parameter names to be more meaningful. Revision ChangesPath 1.16 +10 -9 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml Index: mbeans-descriptors.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- mbeans-descriptors.xml18 Jan 2002 21:50:10 - 1.15 +++ mbeans-descriptors.xml22 Jan 2002 18:24:12 - 1.16 @@ -6,7 +6,7 @@ !-- Descriptions of JMX MBeans for Catalina - $Id: mbeans-descriptors.xml,v 1.15 2002/01/18 21:50:10 craigmcc Exp $ + $Id: mbeans-descriptors.xml,v 1.16 2002/01/22 18:24:12 amyroh Exp $ -- mbeans-descriptors @@ -338,6 +338,7 @@ mbean name=MBeanFactory +className=org.apache.catalina.mbeans.MBeanFactory description=Factory for MBeans and corresponding components domain=Catalina @@ -687,7 +688,7 @@ description=Associate the specified Loader with this Context impact=ACTION returnType=void - parameter name=valve + parameter name=loader description=MBean Name of the Loader to be associated type=java.lang.String/ /operation @@ -696,7 +697,7 @@ description=Associate the specified Logger with this Context impact=ACTION returnType=void - parameter name=valve + parameter name=logger description=MBean Name of the Logger to be associated type=java.lang.String/ /operation @@ -705,7 +706,7 @@ description=Associate the specified Manager with this Context impact=ACTION returnType=void - parameter name=valve + parameter name=manager description=MBean Name of the Manager to be associated type=java.lang.String/ /operation @@ -714,7 +715,7 @@ description=Associate the specified Realm with this Context impact=ACTION returnType=void - parameter name=valve + parameter name=realm description=MBean Name of the Realm to be associated type=java.lang.String/ /operation @@ -781,7 +782,7 @@ description=Associate the specified Logger with this Engine impact=ACTION returnType=void - parameter name=valve + parameter name=logger description=MBean Name of the Logger to be associated type=java.lang.String/ /operation @@ -790,7 +791,7 @@ description=Associate the specified Realm with this Engine impact=ACTION returnType=void - parameter name=valve + parameter name=realm description=MBean Name of the Realm to be associated type=java.lang.String/ /operation @@ -890,7 +891,7 @@ description=Associate the specified Logger with this Host impact=ACTION returnType=void - parameter name=valve + parameter name=logger description=MBean Name of the Logger to be associated type=java.lang.String/ /operation @@ -899,7 +900,7 @@ description=Associate the specified Realm with this Host impact=ACTION returnType=void - parameter name=valve + parameter name=realm description=MBean Name of the Realm to be associated type=java.lang.String/ /operation -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans ServerLifecycleListener.java
remm02/01/22 10:24:53
Modified:catalina/src/share/org/apache/catalina/mbeans
ServerLifecycleListener.java
Log:
- Fix AOOBs I found using Slide.
Revision ChangesPath
1.11 +7 -7
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java
Index: ServerLifecycleListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ServerLifecycleListener.java 21 Jan 2002 19:39:51 - 1.10
+++ ServerLifecycleListener.java 22 Jan 2002 18:24:53 - 1.11
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
1.10 2002/01/21 19:39:51 amyroh Exp $
- * $Revision: 1.10 $
- * $Date: 2002/01/21 19:39:51 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
1.11 2002/01/22 18:24:53 remm Exp $
+ * $Revision: 1.11 $
+ * $Date: 2002/01/22 18:24:53 $
*
*
*
@@ -102,7 +102,7 @@
*
* @author Craig R. McClanahan
* @author Amy Roh
- * @version $Revision: 1.10 $ $Date: 2002/01/21 19:39:51 $
+ * @version $Revision: 1.11 $ $Date: 2002/01/22 18:24:53 $
*/
public class ServerLifecycleListener
@@ -285,7 +285,7 @@
}
if (context instanceof StandardContext) {
Valve cValves[] =
((StandardContext)context).getValves();
-for (int l=0; l=cValves.length; l++) {
+for (int l = 0; l cValves.length; l++) {
if (debug = 3)
log(Creating MBean for Valve + cValves[l]);
MBeanUtils.createMBean(cValves[l]);
@@ -307,7 +307,7 @@
}
if (host instanceof StandardHost) {
Valve hValves[] = ((StandardHost)host).getValves();
-for (int k=0; k=hValves.length; k++) {
+for (int k = 0; k hValves.length; k++) {
if (debug = 3)
log(Creating MBean for Valve + hValves[k]);
MBeanUtils.createMBean(hValves[k]);
@@ -329,7 +329,7 @@
}
if (engine instanceof StandardEngine) {
Valve eValves[] = ((StandardEngine)engine).getValves();
-for (int j=0; j=eValves.length; j++) {
+for (int j = 0; j eValves.length; j++) {
if (debug = 3)
log(Creating MBean for Valve + eValves[j]);
MBeanUtils.createMBean(eValves[j]);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: jdk1.3.1 and tomcat 3.3a core dumping?
On Tue, 22 Jan 2002, Dan Diodati wrote: The main reason that we wanted to change to tomcat 3.3 is for the hierarchical classloading support. I guess we'll have to wait. If your VM is crashing with 3.3a ( or anything else !) - you should fix the vm. No combination of java bytecodes should be able to break the VM - if it happens with some 3.3 bytecode it may happen with some random user code as well, in the midle of the night on the production server. A vm that crashes on any java program is _bad_, and adding workarounds in the java program is the worse solution since it hides a _critical_ problem in the system. I wouldn't wait... Be happy you found about the problem, and look for OS patches/newer or older VMs, etc until you get a vm that is stable. Of course, there is always the issue that there is absolutely no need to run 3.3a on a Solaris box (which is why I really can't be bothered to download it to check this out, since my primary production environment is Solaris). The issue is that the VM is crashing when running a valid java program - period. If something in 3.3a is causing this - same thing may happen when you run some code in one of yours webapps or libs or anything - at a random time, eventually corupting data and taking down a production server. Costin If you're not running Windows, than there is no advantage to using 3.3a over 3.3.0. There are lots of advantages to using 3.3.1-dev (aka nightly, soon to be 3.3.1-B1) reguardless of the OS. see: http://cvs.apache.org/viewcvs/jakarta-tomcat/RELEASE-NOTES-3.3.1.txt - Original Message - From: Bojan Smojver [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, January 21, 2002 6:15 PM Subject: RE: jdk1.3.1 and tomcat 3.3a core dumping? Quoting Dan Diodati [EMAIL PROTECTED]: I don't think the java code has any issues because it has been in production with jdk1.2.2 and tomcat 3.2.4. Maybe I wasn't clear enough. The point is that this is a JVM issue, it has nothing to do with Java classes you run on it (except that some of them might trigger a particular bug within the JVM). I tried using tomcat 3.2.4 and jdk 1.3.1_02 it this issue does NOT occur, making me suspicious of tomcat 3.3a. As above. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk2 problems with libapr.so
On Mon, Jan 14, 2002 at 05:12:29PM +0100, jean-frederic clere wrote: Hi, I am playing with jk2 and I have noted that the loadNative() in AprImpl fails: +++ java.lang.UnsatisfiedLinkError: /home/jakarta/jakarta-tomcat-4.0.1/webapps/jk/WEB-INF/jk2/jni/libapr.so: /home/jakarta/jakarta-tomcat-4.0.1/webapps/jk/WEB-INF/jk2/jni/libapr.so: undefined symbol: crypt at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1277) at java.lang.Runtime.load0(Runtime.java:698) at java.lang.System.load(System.java:797) at org.apache.jk.apr.AprImpl.loadNative(AprImpl.java:90) at org.apache.jk.apr.AprImpl.loadNative(AprImpl.java:78) at org.apache.jk.common.ChannelUn.init(ChannelUn.java:135) +++ The problem is that apr needs other dynamic library. How should we solve the problem?: 1 - Loading the missing libraries in the JVM (via System.load()) The list of needed library is in APRVARS. 2 - Link jni_connect.so against a static libapr.a (like in mod_webapp for Apache-1.3). something like: gcc -shared -lm -lcrypt -lnsl -ldl -o jni_connect.so ... libapr.a Any comments? Sorry for replying to this so late. As an FYI, APRVARS will soon be removed from APR. Take a look at the replacement apr-config and apu-config (in apr and apr-util respectively). It's not yet complete (that's why APRVARS hasn't been removed yet), but if you see something missing let us know. -aaron -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Will there ever be any support added for Oracle 8i hosted EJB's communicating with Tomcat?
My company is trying to create a distributed app with EJB's being hosted on Oracle 8i server. However, as you may all know already, calling EJB's from Oracle doesn't work or work well with the Tomcat JSP/Servlet container. It gives many errors, include ClassCastException errors. There is only 1 workaround I know of and it is so limiting that it isn't practical. So my question is: Is there goign to be Oracle support in a future release of Tomcat? If so, when? Thanks a lot. I would prefer e-mail responses as well as posts because I have to refer my findings to the upper brass =:) Sincerely, Daniel Hofmann ([EMAIL PROTECTED]) Software Development Charles Jones Inc. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jdk1.3.1 and tomcat 3.3a core dumping?
Even if you have buggy Java classes, this should not cause a good JVM to do this. The problem is with the JVM. I'd try a different JDK, something like 1.3.0_04 or maybe a newer sub-release of 1.3.1. Bojan PS. Keep in mind that I don't work with Solaris :-) Dan Diodati wrote: I am having some problems with jdk1.3.1 core dumping with tomcat 3.3a. My current set up is apache 1.3.22 which is passing a the request to tomcat 3.3a(running externally). This is all running on a Solaris 8 box (Sun Ultra2) using jdk1.3.1. When tomcat tries to compile some jsp pages, the Hotspot compiler core dumps killing the JVM. Here is the error: # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Error ID: 47454E45524154452F4F502D41500E435050084B 01 # # Problematic Thread: prio=5 tid=0x31d1b8 nid=0x26 runnable # Has anyone else had any issues with jdk1.3.1 and tomcat 3.3a ? Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JDK 1.4 beta breaks TLS re-negotiation?
Hi,
I have tried to use TLS/SSL client authentication in Tomcat 4.0.1 and
JDK 1.4 beta3, and think that something changed in the JDK that breaks
renegotiation. It seems to work correctly with JDK 1.3.1.
I have an SSL connector with clientAuth=false in server.xml, and
have set up web.xml to require authentication with the CLIENT-CERT
method. This means that the SSL connection has to be renegotiated
when a particular URL is requested. My log file then says:
2002-01-07 12:08:17 CertificatesValve[/myapp]: verify: SSLPeerUnverifiedException
2002-01-07 12:08:17 CertificatesValve[/myapp]: verify: SSLPeerUnverifiedException
I get two lines like this every time the servlet is invoked.
I can see that these messages are generated by the CertificatesValve.
The first one is generated when it checks for client certificates when
there are none (the connector had clientAuth=false). It then does
initiates a new handshake:
// Force a new handshake to request the client certificates
//if (debug = 2)
//log( verify: Invalidating current session);
session.invalidate();
//if (debug = 2)
//log( verify: Forcing new SSL handshake);
socket.setNeedClientAuth(true);
try {
socket.startHandshake();
} catch (IOException e) {
log( verify: , e);
}
// Revalidate the existence of the required certificates
It then goes on to check for client certificates again, doesn't find
any, and writes the second error message.
Testing with OpenSSL s_client, I can see that the handshake doesn't
actually take place until after the servlet exits (complaining that
the client certs are missing).
This is different from the behaviour under JDK 1.3.1, when a new SSL
handshake takes place directly after the URL is requested, and the
servlet is called in the proper way.
I noted that the code above does not use a HandshakeCompletedListener
to wait for the HandshakeCompletedEvent, but just goes on with
checking if the handshake completed immediately. My guess is that the
behaviour of JSSE changed in JDK 1.4 beta, so that this no longer
works. It might be necessary to wait for the event before checking
the client certificates again.
I would really like to use other functionality from JDK 1.4 in my
application, so any ideas on a workaround would be appreciated.
Thanks,
Marcus
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
StandardWrapper patch (was RE: shell connector)
Finally got around to packages my changes as a patch to the HEAD. As previously discussed, it should be sufficient for a servlet to implement ContainerServlet and for the class to be placed in the server/lib directory for it to load and initialize correctly (in a Context where privileged is true). This is currently not the case, because in the current implementation being placed in the server/lib directory is not sufficient for the servlet to be loaded by the catalina class loader. The attached StandardWrapper patch resolves this issue by attempting to load the servlet class in the catalina class loader if the context is privileged. p l u m b d e s i g n alan newberger chief architect 157 chambers st ny ny 10007 p.212.381.0541 | f.212.285.8999 -Original Message- From: Alan Newberger Sent: Friday, January 11, 2002 1:52 PM To: Tomcat Developers List Subject: RE: shell connector thanks for your reply, I still feel there is a problem with ContainerServlets from arbitrary packages even when placed in $CATALINA_HOME/server/lib, see below... From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] I committed some Ant custom tasks yesterday that talk to Manager ... they might be useful to you. I'll check them out, thanks. So that one can write servlet-based services that need access to Catalina internals. Existing examples include: * Manager servlet (needs to install, remove, and reload webapps) * Invoker servlet (needs to create new Wrapper instances on the fly) * Administration servlet (will provide web-based user interface for updating pretty much all of the things in server.xml). The third thing is in the admin webapp in the HEAD branch. That also sounds really useful, I'm going to have to take a close look at the HEAD branch :) Hopefully it's capable of persisting changes back into server.xml... In order to execute a ContainerServlet that has access to the internals of Tomcat 4, the following rules must all be followed: * Your servlet must implement the org.apache.catalina.ContainerServlet interface. * Your servlet, and all the code it depends on, must be loaded from the server classloader. That means it needs to be installed as unpacked classes under $CATALINA_HOME/server/classes or in JAR files in $CATALINA_HOME/server/lib. (Classes in common/classes and common/lib are also visible to these components.) No changes to Tomcat code, or to standard server.xml settings, are required. IF a servlet which implements ContainerServlet is loaded by the Catalina class loader, everything will work fine, i.e. it will have its 'setWrapper()' command called by StandardWrapper.load(). The problem is in the way StandardWrapper decides which classloader to use to load the servlet. It uses its private 'isContainerServlet(string)' method, which only looks at the String representation of the className and checks if it starts with 'org.apache.catalina'. So, if I have a servlet implementing ContainerServlet in some package, say 'com.foo.servlets', and put it in a jar $CATALINA_HOME/server/lib, and create some webapp with a web.xml with com.foo.servlets.SomeContainerServlet as a 'server-class' for a servlet, things will still fail. The StandardWrapper.isContainerServlet(string classname) method will return false, so the StandardWrapper.load() method will try to load the class from the webapp classloader, which of course will not find the class since it is not in the webapp classpath. You can put the com.foo.servlets.SomeContainerServlet in the common/lib folder and it will load correctly, but things will break because no catalina classes will be visible to it (an object instance cannot see other objects loaded in _child_ classloaders, only _parent_ classloaders). The solution to this isn't trivial -- you want all ContainerServlets to be loaded in the catalina classloader, but how do you know whether a servlet is a ContainerServlet by its classname alone, before actually loading it and doing something like 'instanceof' or 'isAssignableFrom()'? I'm sure this was why the StandardWrapper.isContainerServlet() method was written but it just doesn't do the right thing. I think the way to a nicer solution is through the 'privileged' attribute for a Context in servlet.xml (evaluated in ServletWrapper via the isServletAllowed() function). I suggest that if a Context is designated as privileged, the context's wrapper should attempt to load servlets via the catalina classloader. If the class isn't found, catch the exception and attempt to load it via the webapp classloader. If the class is loaded, check if it implements ContainerServlet; if so, call setWrapper() on it and continue, if not destroy the class object and attempt to load
Re: Tomcat 4.0.2-b2 + JSSE + Security Manager
Try starting tomcat 4 with -security and the following properties defined:
-Djava.security.debug=access,failure -Djava.net.debug=ssl
That should generate alot of debug data to help you track down the source
of the problem.
Regards,
Glenn
Renato wrote:
Hi all,
I'm installing Tomcat 4.0.2B2. Everything is fine except for the following:
- I try to run a servlet that uses JSSE. If I start Catalina without the '-
security' it works fine, if I start with the '-security' it generates the
error:
java.net.SocketException: SSL implementation not available
(...)
The JSSE libraries are on ${java.home}/jre/lib/ext and this path has
permission to all.
I also tried on Tomcat 3.3 and the servlet works with or without the
security manager.
Any hint ?
Thanks
Renato - Brazil
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 4.0.2-b2 + JSSE + Security Manager
Hi all,
I'm installing Tomcat 4.0.2B2. Everything is fine except for the following:
- I try to run a servlet that uses JSSE. If I start Catalina without the '-
security' it works fine, if I start with the '-security' it generates the
error:
java.net.SocketException: SSL implementation not available
(...)
The JSSE libraries are on ${java.home}/jre/lib/ext and this path has
permission to all.
I also tried on Tomcat 3.3 and the servlet works with or without the
security manager.
Any hint ?
Thanks
Renato - Brazil
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0 with SSL
I followed the every steps in the doc for how-to do ssl. But I got failure when I start the tomcat. Since I couldn't see all error message, here is the on on the screen: at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) - Root Cause - java.io.IOException: java.security.UnrecoverableKeyException: Cannot recover key at org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLServerSoc ketFactory.java:422) at org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLServerSo cketFactory.java:334) at org.apache.catalina.net.SSLServerSocketFactory.createSocket(SSLServer SocketFactory.java:287) at org.apache.catalina.connector.http.HttpConnector.open(HttpConnector.j ava:946) at org.apache.catalina.connector.http.HttpConnector.initialize(HttpConne ctor.java:1114) at org.apache.catalina.core.StandardService.initialize(StandardService.j ava:454) at org.apache.catalina.core.StandardServer.initialize(StandardServer.jav a:552) at org.apache.catalina.startup.Catalina.start(Catalina.java:775) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) Is there any answer? Thanks, Henry -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Interceptor in Tomcat 4.0 ???
Hi all, I have an Interceptor I wrote for Tomcat 3.3 and I want to migrate to Catalina. I think the concept know is a Valve, right ? Is there a guideline how to migrate an interceptor ? Thanks Renato - Brazil. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Interceptor in Tomcat 4.0 ???
On Tue, 22 Jan 2002, Renato wrote: Date: Tue Jan 22 16:57:45 2002 From: Renato [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Interceptor in Tomcat 4.0 ??? Hi all, I have an Interceptor I wrote for Tomcat 3.3 and I want to migrate to Catalina. I think the concept know is a Valve, right ? That's probably the right concept to look at, depending on what you are using your interceptor for. You can see lots of examples of Valve implementations in the org.apache.catalina.authenticator and org.apache.catalina.valves packages in the Tomcat 4 source tree. Is there a guideline how to migrate an interceptor ? Because the processing models are very different (interceptors call your module lots of times for different events, while a valve is called once and you pass the request on or not as appropriate), there is not going to be much in the way of useful porting advice -- depending on what your interceptor is doing, it will be anywhere from trivially easy to something that requires multiple valves to accomplish the same functionality. Without details, it's not possible to be more specific. Thanks Renato - Brazil. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
