cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common ModJkMX.java
billbarker2003/10/10 23:10:00
Modified:jk/java/org/apache/jk/common ModJkMX.java
Log:
Further attempts to get Gump to build.
This patch is truely horrifying. Please remove all small children from the room :(.
At this point I'm +1 for excluding this file until it gets a proper maintainer. It
only adds some additional JMX-configuration options to mod_jk2. Removing it doesn't
effect any normal configuration.
Revision ChangesPath
1.6 +6 -2
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ModJkMX.java
Index: ModJkMX.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ModJkMX.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ModJkMX.java 10 Oct 2003 04:08:31 - 1.5
+++ ModJkMX.java 11 Oct 2003 06:10:00 - 1.6
@@ -175,8 +175,12 @@
Iterator mbeansIt=mbeans.values().iterator();
while( mbeansIt.hasNext()) {
MBeanProxy proxy=(MBeanProxy)mbeansIt.next();
-ObjectName oname=proxy.getObjectName();
-Registry.getRegistry().getMBeanServer().unregisterMBean(oname);
+Object ooname = proxy.getObjectName();
+if( ooname != null ) {
+String soname = ooname.toString();
+ObjectName oname = new ObjectName(soname);
+Registry.getRegistry().getMBeanServer().unregisterMBean(oname);
+}
}
} catch( Throwable t ) {
log.error( Destroy error, t );
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs ssl-howto.xml
remm2003/10/11 01:52:41 Modified:webapps/docs ssl-howto.xml Log: - Fix XML. Revision ChangesPath 1.9 +0 -1 jakarta-tomcat-catalina/webapps/docs/ssl-howto.xml Index: ssl-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/ssl-howto.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- ssl-howto.xml 11 Oct 2003 04:34:24 - 1.8 +++ ssl-howto.xml 11 Oct 2003 08:52:41 - 1.9 @@ -383,7 +383,6 @@ tdAdd this element if your are using a different format for the TrustStore then you are using for the KeyStore. The valid values are codeJKS/code and codePKCS12/code./td -/td /tr /table - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Webapp classloader question.
I too had a problem loading XML libraries under tomcat 4.1. I thought I identified the problem and reported bug 16577. See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16577 I proposed a simple fix, but alas, Remy Maucherat, thought the delegation model worked as intended and WONTFIXed it. The upshot is that classes with the following package prefixes are loaded by the parent loader: javax, // Java extensions org.xml.sax, // SAX 1 2 org.w3c.dom, // DOM 1 2 org.apache.xerces, // Xerces 1 2 org.apache.xalan // Xalan As xalan and xerces are in this list (taken from the source code), you can't load your own version of these libraries without modifying the source. -Babak --- Lee, William [EMAIL PROTECTED] wrote: Hmm... Seems like even the Sun's engineer also have different point of views between them as well... Now, I'm totally confused about which way should be the right way to go... It there any Sun/Java representative on this mailing list that can answer this question then? Thanks again for all your help. William. -Original Message- From: Cox, Charlie [mailto:[EMAIL PROTECTED] Sent: Friday, October 10, 2003 2:38 PM To: 'Tomcat Developers List' Subject: RE: Webapp classloader question. here's one reply that I got a while ago about the issue when it was changed in 4.0.2(saying basically the same thing) http://www.mail-archive.com/[EMAIL PROTECTED]/msg74261.html I know that the WEB-INF classloader changes the delegation model by looking for classes within WEB-INF BEFORE delegating to its parent, but I don't know why the endorsed spec was chosen to override the servlet spec. Charlie -Original Message- From: Lee, William [mailto:[EMAIL PROTECTED] Sent: Friday, October 10, 2003 2:13 PM To: 'Tomcat Developers List' Subject: RE: Webapp classloader question. To be honest, I got exactly the same impression when I read this document half a year ago. However, when I tried to clarify all the grey areas in this document with Sun, here is the response from their Java engineer: *** The standard delegation model used by Java does say that a child classloader should look first to its parent classloader when searching for classes. As you know, this model works against us in your situtation, since the application classloader for a web app is a child of the system class loader (where the 1.4 parsers are loaded). However, the servlet specification requires that a web app obtain its class definition from the WAR file. Therefore, most vendors have implemented a way for the application classloader to look in the WAR file first before going to a parent, thereby overriding the standard delegation model. *** So, it seems to me that the servlet spec. should supersede the endorsed mechanism in the web application environment. William. -Original Message- From: Cox, Charlie [mailto:[EMAIL PROTECTED] Sent: Friday, October 10, 2003 1:17 PM To: 'Tomcat Developers List' Subject: RE: Webapp classloader question. ok, I just found this link from the archives. Sun defined that you have to use the 'endorsed' directory or take the Sun-supplied versions of the packages listed. http://java.sun.com/j2se/1.4.2/docs/guide/standards/index.html tomcat's classloading is enforcing this requirement explicitly since it does not delegate to the parent classloader first. so you can only replace the version in /endorsed Charlie -Original Message- From: Lee, William [mailto:[EMAIL PROTECTED] Sent: Friday, October 10, 2003 12:05 PM To: 'Tomcat Developers List' Subject: RE: Webapp classloader question. It seems to me that we are going for bandaid solution here. By moving around the files, it will work for one particular webapp, but at the expensive of the compatibility of other webapp under the same tomcat. As soon as we move the parser out of one webapp, we are forcing all other webapp using the same parser, which I believed is not the right way to go. Rather, why forcing the delegate model for these two particular packages (xerces xalan)? Isn't it true that the endorse mechanism only required that the endorsed directory should be traverse before the system? I still didn't see the reason how this endorsed mechanism has anything to do with the servlet spec., and that it would force servlet container to skip the one in webapps? Thanks again. William. -Original Message- From: Cox, Charlie [mailto:[EMAIL PROTECTED] Sent: Friday, October 10, 2003 8:46 AM To: 'Tomcat Developers List' Subject: RE: Webapp classloader
DO NOT REPLY [Bug 23742] New: - tomcat3.3.1a is crashing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23742. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23742 tomcat3.3.1a is crashing Summary: tomcat3.3.1a is crashing Product: Tomcat 3 Version: 3.3.1 Final Platform: Other OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] we are using tomcat3.3.1a,apache1.3.26 on windows2000 server.my probles Tomcat is automaticaly shutdown in our production environment.we had the same problem with tomcat3.2, that is why we upgraded this to tomcat3.3.1a. In this version also we are facing same problem . so pls somebody give me a reply. that how to solve this shafeek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problems during 5.0.13 startup
I am testing 5.0.13 .. During startup I always get the following .. Is this something 'new' .. what does it mean ?? Nov 10, 2003 5:25:37 PM org.apache.catalina.core.StandardContext start WARNING: Error storing config file java.io.FileNotFoundException: ..\..\conf\Catalina\localhost\ecs.xml (The system cannot find the path specified) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at java.io.FileWriter.init(FileWriter.java:73) at org.apache.catalina.core.StandardServer.storeContext(StandardServer.java:866 ) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3925) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1125) at org.apache.catalina.core.StandardHost.start(StandardHost.java:792) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1125) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:502) at org.apache.catalina.core.StandardService.start(StandardService.java:519) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2343) at org.apache.catalina.startup.Catalina.start(Catalina.java:580) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:297) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:394)
JNDIRealm source code - (was: Re: Tomcat vs Bea WebLogic)
Hi,
I am using tomcat 4.1.27, Java sdk-1.4.1_02 and JNDIRealm to use the Micro$oft
Site Server service to authenticate our webapps.
I get an error code 2 exception (Protocol Error) only when the user and the
password is right. That is to say, when an OK is expected. I am thinking
about modify the JNDIRealm to support that Micro$oft returned 'code', instead
of raising an exception. It looks easy :) . You can see below the appointed
catalina log.
Can you supply me any URL, CVS repository, or whatever which points me to the
JNDI source code?.
I have read the JNDI API I must use is the one included in Java sdk 1.4.2.
Last question: Can we solve the 'M$ protocol' issue just using Tomcat 5.0?.
Regards,
Davi Leal
Tim Funk wrote:
I have gotten JNDIRealm to work against iPlanet. I have heard others get it
working against:
- Active Directory (I personally had problems due to some IT policies)
- Novell
- OpenLDAP
But in the worst case - the code is open for change so creating a custom
Realm should be simple if one understands JNDI programming. Which is what I
had to do with respect to ActiveDirectory and wacky business rules vs
domain setup.
-Tim
David Diaz wrote:
Reference: http://www.weblogic.com/docs51/admindocs/ldap2.html#intro
The WebLogic LDAP realm has been tested against the following LDAP
servers:
* OpenLDAP
* iPlanet Directory Server
* Microsoft Site Server
I would like to get a similar Tomcat link to show to my boss.
APPENDIX
The catalina log
59 JNDIRealm[Standalone]: Connecting to URL ldap://host:1003
* Testing with a no-existent user:
44 JNDIRealm[Standalone]: lookupUser(davi)
44 JNDIRealm[Standalone]: dn=cn=davi,ou=Members,o=tpi
44 JNDIRealm[Standalone]: validating credentials by binding as the user
44 JNDIRealm[Standalone]: binding as cn=davi,ou=Members,o=org
44 JNDIRealm[Standalone]: bind attempt failed
44 JNDIRealm[Standalone]: Autentificaci¾n fallida para el usuario davi
* Testing with an user which is right, but using a worng password:
36 JNDIRealm[Standalone]: lookupUser(ph32796)
36 JNDIRealm[Standalone]: dn=cn=ph32796,ou=Members,o=org
36 JNDIRealm[Standalone]: validating credentials by binding as the user
36 JNDIRealm[Standalone]: binding as cn=ph32796,ou=Members,o=org
36 JNDIRealm[Standalone]: bind attempt failed
36 JNDIRealm[Standalone]: Autentificaci¾n fallida para el usuario ph32796
* Testing with both user and password right:
09 JNDIRealm[Standalone]: lookupUser(phe2796)
09 JNDIRealm[Standalone]: dn=cn=phe2796,ou=Members,o=org
09 JNDIRealm[Standalone]: validating credentials by binding as the user
09 JNDIRealm[Standalone]: binding as cn=phe2796,ou=Members,o=org
09 JNDIRealm[Standalone]: Excepci¾n al realizar la autentificaci¾n
javax.naming.CommunicationException: [LDAP: error code 2 - Protocol Error];
remaining name ''
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:2965)
...
09 JNDIRealm[Standalone]: Closing directory context
The realm we are using in server.xml
Realm className=org.apache.catalina.realm.JNDIRealm debug=99
connectionName=cn=PHE2796,ou=Members,o=org
connectionPassword=
connectionURL=ldap://host:1003;
userPattern=cn={0},ou=Members,o=org
userSubtree=true
roleBase=ou=UserCFuncional,ou=CFuncional,ou=Groups,o=org
roleName=cn
roleSearch=(uniqueMember={0})
/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/res LocalStrings.properties
glenn 2003/10/11 07:37:01
Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
util/java/org/apache/tomcat/util/net/res
LocalStrings.properties
Log:
Catch AccessControlException's so that unauthorized access
to a socket when using the Java SecurityManager does not
shutdown the worker thread.
Revision ChangesPath
1.22 +13 -3
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
Index: PoolTcpEndpoint.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- PoolTcpEndpoint.java 4 Oct 2003 18:05:29 - 1.21
+++ PoolTcpEndpoint.java 11 Oct 2003 14:37:00 - 1.22
@@ -71,6 +71,7 @@
import java.net.ServerSocket;
import java.net.Socket;
import java.net.SocketException;
+import java.security.AccessControlException;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
@@ -384,6 +385,15 @@
// normal part -- should happen regularly so
// that the endpoint can release if the server
// is shutdown.
+}
+catch (AccessControlException ace) {
+// When using the Java SecurityManager this exception
+// can be thrown if you are restricting access to the
+// socket with SocketPermission's.
+// Log the unauthorized access and continue
+String msg = sm.getString(endpoint.warn.security,
+ serverSocket,ace);
+log.warn(msg);
}
catch (IOException e) {
1.4 +1 -0
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/res/LocalStrings.properties
Index: LocalStrings.properties
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/res/LocalStrings.properties,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- LocalStrings.properties 10 Jan 2003 20:22:38 - 1.3
+++ LocalStrings.properties 11 Oct 2003 14:37:00 - 1.4
@@ -3,3 +3,4 @@
endpoint.err.nonfatal=Endpoint {0} ignored exception: {1}
endpoint.warn.reinit=Reinitializing ServerSocket
endpoint.warn.restart=Restarting endpoint
+endpoint.warn.security=Endpoint {0} security exception: {1}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat mod_jk 1.2.5 Web Server Connector released
[October 11, 2003] The Tomcat team is pleased to announce the release of version 1.2.5 of the Apache Tomcat mod_jk web server connector. Tomcat is the reference implementation of a web application server which implements the Java Servlet and JavaServer Pages specifications. mod_jk is a connector which allows a web server such as Apache HTTPD or IIS to act as a front end to the Tomcat web application server. This version fixes a number of minor bugs. See the file CHANGES.txt in the source distribution for a complete list of changes. Soucre distribtions can be downloaded from an Apache Software Foundation mirror at: http://jakarta.apache.org/site/sourceindex.cgi Binary distributions for a number of different operating systems and web servers can be downloaded from an Apache Software Foundation mirror at: http://jakarta.apache.org/site/binindex.cgi Documentation for using mod_jk with Tomcat 3.3, 4.1, and 5.0 can be found at: http://jakarta.apache.org/tomcat/ The Apache Tomcat team. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23742] - tomcat3.3.1a is crashing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23742. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23742 tomcat3.3.1a is crashing [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME Summary|tomcat3.3.1a is crashing|tomcat3.3.1a is crashing --- Additional Comments From [EMAIL PROTECTED] 2003-10-12 05:12 --- If you can provide more details about your configuration, or logfile entries that may help determine your problem, feel free to reopen. If not, a reopen will be ignored. You might also consider posting your problem on [EMAIL PROTECTED] to get additional help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
