cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Embedded.java
remm2002/06/05 23:29:17
Modified:catalina/src/share/org/apache/catalina/startup Embedded.java
Log:
- Embedded will now use Coyote.
- Add support for AJP (using a new createConnector method).
Revision ChangesPath
1.15 +58 -39
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Embedded.java
Index: Embedded.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Embedded.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Embedded.java 9 Nov 2001 19:40:44 - 1.14
+++ Embedded.java 6 Jun 2002 06:29:17 - 1.15
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Embedded.java,v
1.14 2001/11/09 19:40:44 remm Exp $
- * $Revision: 1.14 $
- * $Date: 2001/11/09 19:40:44 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Embedded.java,v
1.15 2002/06/06 06:29:17 remm Exp $
+ * $Revision: 1.15 $
+ * $Date: 2002/06/06 06:29:17 $
*
*
*
@@ -70,6 +70,9 @@
import java.net.InetAddress;
import java.util.Enumeration;
import java.util.Properties;
+
+import org.apache.tomcat.util.IntrospectionUtils;
+
import org.apache.catalina.Connector;
import org.apache.catalina.Container;
import org.apache.catalina.Context;
@@ -82,7 +85,6 @@
import org.apache.catalina.Loader;
import org.apache.catalina.Logger;
import org.apache.catalina.Realm;
-import org.apache.catalina.connector.http.HttpConnector;
import org.apache.catalina.core.StandardContext;
import org.apache.catalina.core.StandardEngine;
import org.apache.catalina.core.StandardHost;
@@ -149,7 +151,7 @@
* /pre
*
* @author Craig R. McClanahan
- * @version $Revision: 1.14 $ $Date: 2001/11/09 19:40:44 $
+ * @version $Revision: 1.15 $ $Date: 2002/06/06 06:29:17 $
*/
public class Embedded implements Lifecycle {
@@ -406,14 +408,7 @@
public synchronized void addConnector(Connector connector) {
if (debug = 1) {
-if (connector instanceof HttpConnector) {
-HttpConnector hc = (HttpConnector) connector;
-logger.log(Adding connector for address ' +
- ((hc.getAddress() == null) ? ALL : hc.getAddress())
- + ' port=' + hc.getPort() + ');
-} else {
-logger.log(Adding connector ( + connector.getInfo() + ));
-}
+logger.log(Adding connector ( + connector.getInfo() + ));
}
// Make sure we have a Container to send requests to
@@ -504,27 +499,58 @@
((address == null) ? ALL : address.getHostAddress()) +
' port=' + port + ' secure=' + secure + ');
-HttpConnector connector = new HttpConnector();
-
-if (address != null)
-connector.setAddress(address.getHostAddress());
-connector.setDebug(debug);
-connector.setPort(port);
+String protocol = http;
if (secure) {
-connector.setScheme(https);
-connector.setSecure(true);
-try {
-Class serverSocketFactoryClass = Class.forName
-(org.apache.catalina.net.SSLServerSocketFactory);
-ServerSocketFactory factory =
-(ServerSocketFactory)
-serverSocketFactoryClass.newInstance();
-connector.setFactory(factory);
-} catch (Exception e) {
-logger.log(Couldn't load SSL server socket factory.);
-}
+protocol = https;
}
+return createConnector(address, port, protocol);
+
+}
+
+
+public Connector createConnector(InetAddress address, int port,
+ String protocol) {
+
+Connector connector = null;
+
+try {
+
+Class clazz =
+Class.forName(org.apache.coyote.tomcat4.CoyoteConnector);
+connector = (Connector) clazz.newInstance();
+
+if (address != null) {
+IntrospectionUtils.setProperty(connector, address,
++ address);
+}
+IntrospectionUtils.setProperty(connector, port, + port);
+IntrospectionUtils.setProperty(connector, useURIValidationHack,
++ false);
+
+if (protocol.equals(ajp)) {
+IntrospectionUtils.setProperty
+(connector,
Re: PROPOSAL: Consistent logging ( for 3.x, 4.x )
On Wed, 5 Jun 2002, Bill Barker wrote: At least in 3.3 land, I'm leaning to Remy's opinion. It's going to be painful. However, I'm +1 (i.e. I'll help on the 3.3 stuff) . As Remy points out, TINA. Ok, what does 'TINA' mean :-) ??? I see your point, I'll play a bit more with the class loaders ( I'm using log4j in common ). In JDK1.4 we don't have the option to move the logging in the container loader :-), and at least log4j can be upgraded in common at any time, not only when you upgrade the VM. 3.3.1 as recommended on the Coyote download page (tomcat-util.jar is in common, and commons-logging.jar is in container). Now, commons-logging is pretty stable, so I don't have a problem with (like in 3.3.2-dev) putting it in common. However, I really don't want to put log4j.jar in common since then it would over-ride the one in WEB-INF/lib. This is almost as bad as putting JAXP in common. I'll try to get it in container. It should work, except the messages that are displayed before the logger is set up ( where the 'default' of commons-logging will be used ). What I'm worried about is setting up the per/context loggers and where they'll write. I assume webapps using log4j will provide their own configuration, but how do we mix this with the global settings ? And how do we deal with the sandbox. Fortunately ( or not ) JDK1.4 logger doesn't seem to care about security, so why should we worry ... Ok, it'll be more painfull than I thought - but still we should do it, it's a mess. My first thought was to move o.a.t.u.log back to jakarta-tomcat, and convert the rest of o.a.t.u.** to commons-logging. But this still has the same problems. Now that recycling is working again, I'm very fond of qlog. I'd like to be able to keep it as an option (as a plugin to commons-logging). Long term I think o.a.t.u.log should be deprecated. I agree qlog is a nice ( and quite efficient ) piece, so maybe it can be turned into a common-logging logger ( and so available to other apps ). The last thing we need is yet-another logging API ( o.a.t.u.log is probably older than most others, but that doesn't matter ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9654] - Tomcat converts to ASCII when it should convert to ISO-8859-1
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=9654. 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=9654 Tomcat converts to ASCII when it should convert to ISO-8859-1 --- Additional Comments From [EMAIL PROTECTED] 2002-06-06 06:51 --- From what I can see in the sourcecode, all the translation between Locales and Charset is done by o.a.c.util.CharsetMapper. Now, if your locale (Locale.toString()) returns en_US, that locale will not be recognized by the default properties, but it will in second match because we attempt to match on the full locale first, and on the Locale.getLanguage() then (so, if en_US is not in the CharsetMapper.properties file -and it's not- it will be retried only with en and that resolves back to ISO-88590-1, so it should work allright. So, either you're setting some weird locale default in your VM, or your OS configuration is _really_ foobared... I just verified, and it works on Solaris 8 with JDK 1.3.1_03 on a SparcV9 system. For sure we make some wild assumptions in setLocale (we set the encoding field which is not used when creating the writer, for example, and if someone sets the locale, then sets a content type which includes a ; character, and then sets the locale again, we might as well send everything down the drain), but with fairly well constructed servlets, this shouldn't be an issue. It's hard to say what's wrong without seeing your code. It _should_ work (on paper). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9654] - Tomcat converts to ASCII when it should convert to ISO-8859-1
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=9654. 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=9654 Tomcat converts to ASCII when it should convert to ISO-8859-1 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2002-06-06 06:56 --- Reopening to set INVALID -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9654] - Tomcat converts to ASCII when it should convert to ISO-8859-1
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=9654. 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=9654 Tomcat converts to ASCII when it should convert to ISO-8859-1 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-06-06 06:57 --- You're right. Tomcat works. The problem was that our code did PrintWriter out = new PrintWriter(resp.getOutputStream()); instead of PrintWriter out = resp.getWriter() Sorry for the false alarm. :-( -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mx for jk
In case you didn't noticed, I checked in a small 'magic' util that turns Jk components into dynamic MBeans. It still doesn't support the 'descriptions' and the ability to fine tune the exposed attributes/methods, that will be added later ( and will probably require xdoclet or a similar tool ). I still have few more changes/enhancements, and I'll include more info on how to enable it. We'll also need to start adding getters for the informations we want to make available ( number of threads, current request, etc ). As noted in the comments, the intention is to integrate it with the configuration layer, so we can make distinction between what is explicitely set by user and what is just a normal getter. Opinions ? Is it usefull or should I find something better to do ? BTW, it is trivial to enable all 3.3 contexts and interceptors as mbeans ( about 30 lines of code so far ). Is it ok to check it in ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9655] New: - Page is not displaying
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=9655. 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=9655 Page is not displaying Summary: Page is not displaying Product: Tomcat 4 Version: 4.1.3 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When i open a web page from the tomcat server on my own machine the page is not displaying, it's blank. When I view the HTML source I can see that the page has loaded normally. Reloading the page doesn't help. However, if I click the addres bar and press enter, the page is viewed. Opening the same page from another machine doesn't give this problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [4.1.3] Binaries uploaded
I've moved the binaries for 4.1.3 Beta (check them if you can). And source ;) The connector binary directory linked from it is still empty though :-( Does anyone has builds to upload ? If the snap came from a recent JTC build, including my works on autoconf for jk2, it should be easy to populate jk/jk2. I plan to link the same directory for 4.0.4, so it would be bad if this stayed empty :-( I'll work on it. BTW: Costin, could you tell me which jar/so should be provided and installed for jni support ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: PROPOSAL: Consistent logging ( for 3.x, 4.x )
What I'm proposing is to gradually cut down to one logger API ( commons-logging ) and the 2 major implementations ( log4j and jdk1.4 ) and the associated ( and well-documented/well known ) config files. +1 This may take a long time, but there are few steps that we can ( should ) take for the next releases ( 4.1.0 and 3.3.3 ). Most of those are cosmetic ( i.e. minimal code changes ): 1. Include log4j.jar in the distributions. What about commons-logging, it's present in JTC and TC 4.0. Should it be present in TC 3.3/4.0/4.1 and JTC ? 2. In util, make o.a.t.util.Log use commons-logging as backend by default. 3. In 3.3, remove the configs for queue-logging. That will make all 3.3 use the default logger, which in turns use commons-logging. 4. Eventually provide a small fix in 4.x so that LoggerBase defaults to commons-logging if no other logger is specified, and don't specify any logger in the config file. 5. Same for jasper ( that's the most urgent, as it's logger is the worst ). In all cases the explicit setting in server.xml will activate the current logger. Long term ( for next releases ): - replace the use of the old loggers to direct calls to commons-log. - other advanced stuff, like advanced configurations Opinions ? go go go -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mx for jk
As noted in the comments, the intention is to integrate it with the configuration layer, so we can make distinction between what is explicitely set by user and what is just a normal getter. Opinions ? Is it usefull or should I find something better to do ? BTW, it is trivial to enable all 3.3 contexts and interceptors as mbeans ( about 30 lines of code so far ). Is it ok to check it in ? +1, it may ease admin tools later -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name
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=6279. 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=6279 Resubmit to j_security_check mistakenly fetches a page of that name [EMAIL PROTECTED] changed: What|Removed |Added Priority|Medium |Low --- Additional Comments From [EMAIL PROTECTED] 2002-06-06 09:37 --- I was the original submitter. Some of what I said was misplaced. Even if the code was changed as I describe to allow users to log in again, it wouldnt work. This is because the request is still for j_security_check. The request would now fail with an SC_BAD_REQUEST - exactly as you would get if you bookmarked the login page. That issue - that the user has actually managed to log in, but we dont know what page to take them to - can not be solved portably across servlet engines under the spec. Currently I get round it on tomcat by trapping the 400 error and taking the user to an appropriate page, because there are few other places where 400 errors are thrown (in the Certificate auth and WebDav code). When JSR 154 (servlet 2.4) goes to public review (later this month, hopefully) I'm going to request that a specific exception is thrown in this case, to provide a portable way to trap the error. WARNING A further issue with the fix I posted is that the user changes within the same session. This is a SECURITY HOLE. Details from one user may leak to a second user through reuse of the session. The session must be closed and a new session opened if the user logs in with new credentials. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.3] Binaries uploaded
GOMEZ Henri wrote: I've moved the binaries for 4.1.3 Beta (check them if you can). And source ;) The connector binary directory linked from it is still empty though :-( Does anyone has builds to upload ? If the snap came from a recent JTC build, including my works on autoconf for jk2, it should be easy to populate jk/jk2. You have to tag JTC or to check if your modifications are in the http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.3-beta/src/jakarta-tomcat-connectors-4.1.3-src.tar.gz I think they are not in. BTW I still not able to get jk2 working on my Solaris8 test machine (it cores when accessing a mod_jk2 context (even /jkstatus/) and nothing is written in the mod_jk.log file): +++ (/opt/SUNWspro/WS6U1/bin/sparcv9/dbx) where [1] 0xb8469ed0(0x20aa20, 0x1718a0, 0x1718a0, 0x20aa20, 0xf3000, 0xf3000), at 0 xb8469ecf [2] child_main(), at 0x45448 dbx: core file read error: address 0xffbef030 not in data space dbx: attempt to read frame failed -- cannot derive frame pointer (/opt/SUNWspro/WS6U1/bin/sparcv9/dbx) +++ (The problem is that I have 3 compilers and 2 linkers on this machine, so may be it is a libtool problem). Has someone tried mod_jk2 with this SUN compiler? I plan to link the same directory for 4.0.4, so it would be bad if this stayed empty :-( I'll work on it. BTW: Costin, could you tell me which jar/so should be provided and installed for jni support ? -- 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]
DO NOT REPLY [Bug 9658] New: - manager-howto contains illegal xml comments
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=9658. 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=9658 manager-howto contains illegal xml comments Summary: manager-howto contains illegal xml comments Product: Tomcat 4 Version: 4.1.3 Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Webapps:Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The manager-howto document contains example ant scripts that contain comments that start with -- instead of !-- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/webapp/docs faq.xml
jfclere 2002/06/06 03:19:37
Modified:webapp/docs faq.xml
Log:
Typo
Revision ChangesPath
1.3 +1 -1 jakarta-tomcat-connectors/webapp/docs/faq.xml
Index: faq.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/docs/faq.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- faq.xml 15 May 2002 16:20:26 - 1.2
+++ faq.xml 6 Jun 2002 10:19:37 - 1.3
@@ -77,7 +77,7 @@
type
cd ${ant.home}/lib
/typetype
-wget wget
http://jakarta.apache.org/builds/jakarta-ant/release/v1.4.1/bin/jakarta-ant-1.4.1-optional.jar
+wget
http://jakarta.apache.org/builds/jakarta-ant/release/v1.4.1/bin/jakarta-ant-1.4.1-optional.jar
/typetype
mv jakarta-ant-1.4.1-optional.jar optional.jar
/type
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [4.1.3] Binaries uploaded
You have to tag JTC or to check if your modifications are in the http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4. 1.3-beta/src/jakarta-tomcat-connectors-4.1.3-src.tar.gz I think they are not in. Thanks to tag and regenerate a new tarball BTW I still not able to get jk2 working on my Solaris8 test machine (it cores when accessing a mod_jk2 context (even /jkstatus/) and nothing is written in the mod_jk.log file): +++ (The problem is that I have 3 compilers and 2 linkers on this machine, so may be it is a libtool problem). Urg, life is easier with only GNU tools ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5829] - StandardManager needs to cope with sessions throwing exception in read/write
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=5829. 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=5829 StandardManager needs to cope with sessions throwing exception in read/write --- Additional Comments From [EMAIL PROTECTED] 2002-06-06 10:49 --- yes indeed it could create hundreds of files, it's also slower than a single object output stream on account of having to reserialize stuff that is common across multiple sessions - but it would at least work, it plugs a problem that can occur unwittingly in a defaultly-configured webapp. We've been using my patch here on a high volumne transaction site, and it's worked a treat. JDBC is the proper way of doing it, granted, and had things worked when I originally came to our project I'd have used it. JDBC needs a little more configuration than the standard serialization method too. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_mutex.h
jfclere 2002/06/06 06:32:25 Modified:jk/native2/include jk_mutex.h Log: test for APR_HAS_THREADS instead of HAS_APR. APR_HAS_THREADS is set in apr_thread_mutex.h when including apr.h. Revision ChangesPath 1.3 +1 -1 jakarta-tomcat-connectors/jk/native2/include/jk_mutex.h Index: jk_mutex.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_mutex.h,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jk_mutex.h31 May 2002 17:49:07 - 1.2 +++ jk_mutex.h6 Jun 2002 13:32:25 - 1.3 @@ -118,7 +118,7 @@ /* Private data */ void *privateData; -#ifdef HAS_APR +#ifdef APR_HAS_THREADS apr_thread_mutex_t *threadMutex; #elif defined( WIN32 ) CRITICAL_SECTION threadMutex; -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9662] New: - JDBCRealm doesn't work with postgres 7.2 driver
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=9662. 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=9662 JDBCRealm doesn't work with postgres 7.2 driver Summary: JDBCRealm doesn't work with postgres 7.2 driver Product: Tomcat 4 Version: 4.0.3 Final Platform: PC OS/Version: Linux Status: NEW Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've configured JDBCRealm to autenticate some resources. I've created a database postgresql (7.2) and I've configured server.xml like example in documentation to confirm access in a application: Context path=/AreaRiservata docBase=AreaRiservata debug=0 Realm className=org.apache.catalina.realm.JDBCRealm debug=99 driverName=org.postgresql.Driver connectionURL=jdbc:postgresql://monolite/areariservata connectionName=sysdba userTable=users userNameCol=user_name userCredCol=user_pass userRoleTable=user_roles roleNameCol=role_name / /Context I've launched ./catalina.sh run and in output I could see this error: Catalina.start: LifecycleException: Exception opening database connection: java.sql.SQLException: org.postgresql.Driver LifecycleException: Exception opening database connection: java.sql.SQLException: org.postgresql.Driver at org.apache.catalina.realm.JDBCRealm.start(JDBCRealm.java:615) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1108) at org.apache.catalina.core.StandardContext.start (StandardContext.java:3345) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardHost.start(StandardHost.java:614) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start (StandardEngine.java:343) at org.apache.catalina.core.StandardService.start (StandardService.java:388) at org.apache.catalina.core.StandardServer.start (StandardServer.java:506) at org.apache.catalina.startup.Catalina.start(Catalina.java:781) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) 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.main(Bootstrap.java:243) - Root Cause - java.sql.SQLException: org.postgresql.Driver at org.apache.catalina.realm.JDBCRealm.open(JDBCRealm.java:538) at org.apache.catalina.realm.JDBCRealm.start(JDBCRealm.java:613) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1108) at org.apache.catalina.core.StandardContext.start (StandardContext.java:3345) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardHost.start(StandardHost.java:614) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start (StandardEngine.java:343) at org.apache.catalina.core.StandardService.start (StandardService.java:388) at org.apache.catalina.core.StandardServer.start (StandardServer.java:506) at org.apache.catalina.startup.Catalina.start(Catalina.java:781) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) 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.main(Bootstrap.java:243) !!! Attention !!! In Windows 2000 Pro platform this problem there aren't: In Win there aren't any problem with only authentication. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.3] Binaries uploaded
GOMEZ Henri wrote: You have to tag JTC or to check if your modifications are in the http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4. 1.3-beta/src/jakarta-tomcat-connectors-4.1.3-src.tar.gz I think they are not in. Thanks to tag and regenerate a new tarball I would like to test a little more: For example on a machine without threads. It takes more time than excepted because it needs some CFLAGS (may we should read them from config_vars.mk?). BTW I still not able to get jk2 working on my Solaris8 test machine (it cores when accessing a mod_jk2 context (even /jkstatus/) and nothing is written in the mod_jk.log file): +++ (The problem is that I have 3 compilers and 2 linkers on this machine, so may be it is a libtool problem). Urg, life is easier with only GNU tools ;) Yep! - I will try with gcc 3.1 (and try to help with pr 9247!). - -- 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]
DO NOT REPLY [Bug 9655] - Page is not displaying
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=9655. 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=9655 Page is not displaying --- Additional Comments From [EMAIL PROTECTED] 2002-06-06 14:10 --- We really need some more details about versions of things (like OSs, browsers), page URL, page contents, etc etc so we can recreate the problem here. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [4.1.3] Binaries uploaded
I would like to test a little more: For example on a machine without threads. It takes more time than excepted because it needs some CFLAGS (may we should read them from config_vars.mk?). For jk2 when you use --with-apxs or --with-apxs2, CFLAGS are extracted in jk_apxs.m4 : apxs -q CFLAGS for Apache 1.3 (get -DEAPI if needed) apxs -q EXTRA_CFLAGS for Apache 2.0 Urg, life is easier with only GNU tools ;) Yep! - I will try with gcc 3.1 (and try to help with pr 9247!). - 3.1 is out ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [4.1.3] Binaries uploaded
For jk2 when you use --with-apxs or --with-apxs2, CFLAGS are extracted in jk_apxs.m4 : apxs -q CFLAGS for Apache 1.3 (get -DEAPI if needed) apxs -q EXTRA_CFLAGS for Apache 2.0 apxs2 (if you have Apache 1.3/2.0 from my falsehope.com RPMs) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] jk_jni_aprImpl.c
Hi,
This is the further cleaning of mod_jk2.
Seem that there are some leftovers in org_apache_jk_apr_AprImpl.h
The patch deals with that. I simply rerun javah against the current
AprImpl.
Compiling mod_jk2 there are couple of warnings, mostly the type
conversions from 64 to 32 bit,
and bunch of unreferenced variables.
The two of them are pontentialy dangerous (the missing prototype). They
are ints but...
jk_worker_ajp13.c(374) : warning C4013: 'jk2_serialize_postHead'
undefined; assuming extern returning int
jk_worker_ajp13.c(481) : warning C4013: 'jk2_serialize_request13'
undefined; assuming extern returning int
Could we put those two in the jk_requtil.h (just to keep the compiler
happy) ?.
MT.
cvs server: Diffing .
Index: jk_jni_aprImpl.c
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c,v
retrieving revision 1.30
diff -u -r1.30 jk_jni_aprImpl.c
--- jk_jni_aprImpl.c31 May 2002 19:19:45 - 1.30
+++ jk_jni_aprImpl.c6 Jun 2002 14:12:34 -
@@ -255,11 +255,11 @@
return 0;
}
-JNIEXPORT jint JNICALL
+JNIEXPORT void JNICALL
Java_org_apache_jk_apr_AprImpl_sendSignal(JNIEnv *jniEnv, jobject _jthis, jint signo,
- jlong target)
+ jint target)
{
-return 0;
+
}
#endif
Index: org_apache_jk_apr_AprImpl.h
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native2/jni/org_apache_jk_apr_AprImpl.h,v
retrieving revision 1.4
diff -u -r1.4 org_apache_jk_apr_AprImpl.h
--- org_apache_jk_apr_AprImpl.h 28 May 2002 22:34:59 - 1.4
+++ org_apache_jk_apr_AprImpl.h 6 Jun 2002 14:12:35 -
@@ -17,6 +17,8 @@
#define org_apache_jk_apr_AprImpl_HANDLE_RECEIVE_PACKET 10L
#undef org_apache_jk_apr_AprImpl_HANDLE_SEND_PACKET
#define org_apache_jk_apr_AprImpl_HANDLE_SEND_PACKET 11L
+#undef org_apache_jk_apr_AprImpl_HANDLE_FLUSH
+#define org_apache_jk_apr_AprImpl_HANDLE_FLUSH 12L
/* Inaccessible static: aprSingleton */
/* Inaccessible static: ok */
/* Inaccessible static: jniMode */
@@ -36,70 +38,77 @@
JNIEXPORT jint JNICALL Java_org_apache_jk_apr_AprImpl_terminate
(JNIEnv *, jobject);
+/*
+ * Class: org_apache_jk_apr_AprImpl
+ * Method:getJkEnv
+ * Signature: ()J
+ */
+JNIEXPORT jlong JNICALL Java_org_apache_jk_apr_AprImpl_getJkEnv
+ (JNIEnv *, jobject);
/*
* Class: org_apache_jk_apr_AprImpl
- * Method:unSocketClose
- * Signature: (JJI)J
+ * Method:releaseJkEnv
+ * Signature: (J)V
*/
-JNIEXPORT jlong JNICALL Java_org_apache_jk_apr_AprImpl_unSocketClose
- (JNIEnv *, jobject, jlong, jint);
+JNIEXPORT void JNICALL Java_org_apache_jk_apr_AprImpl_releaseJkEnv
+ (JNIEnv *, jobject, jlong);
/*
* Class: org_apache_jk_apr_AprImpl
- * Method:unSocketListen
- * Signature: (JLjava/lang/String;I)J
+ * Method:getJkHandler
+ * Signature: (JLjava/lang/String;)J
*/
-JNIEXPORT jlong JNICALL Java_org_apache_jk_apr_AprImpl_unSocketListen
- (JNIEnv *, jobject, jstring, jint);
+JNIEXPORT jlong JNICALL Java_org_apache_jk_apr_AprImpl_getJkHandler
+ (JNIEnv *, jobject, jlong, jstring);
/*
* Class: org_apache_jk_apr_AprImpl
- * Method:unSocketConnect
+ * Method:createJkHandler
* Signature: (JLjava/lang/String;)J
*/
-JNIEXPORT jlong JNICALL Java_org_apache_jk_apr_AprImpl_unSocketConnect
- (JNIEnv *, jobject, jstring);
+JNIEXPORT jlong JNICALL Java_org_apache_jk_apr_AprImpl_createJkHandler
+ (JNIEnv *, jobject, jlong, jstring);
/*
* Class: org_apache_jk_apr_AprImpl
- * Method:unAccept
- * Signature: (JJ)J
+ * Method:jkSetAttribute
+ * Signature: (JJLjava/lang/String;Ljava/lang/String;)I
*/
-JNIEXPORT jlong JNICALL Java_org_apache_jk_apr_AprImpl_unAccept
- (JNIEnv *, jobject, jlong);
+JNIEXPORT jint JNICALL Java_org_apache_jk_apr_AprImpl_jkSetAttribute
+ (JNIEnv *, jobject, jlong, jlong, jstring, jstring);
/*
* Class: org_apache_jk_apr_AprImpl
- * Method:unRead
- * Signature: (JJ[BII)I
+ * Method:jkGetAttribute
+ * Signature: (JJLjava/lang/String;)Ljava/lang/String;
*/
-JNIEXPORT jint JNICALL Java_org_apache_jk_apr_AprImpl_unRead
- (JNIEnv *, jobject, jlong, jbyteArray, jint, jint);
+JNIEXPORT jstring JNICALL Java_org_apache_jk_apr_AprImpl_jkGetAttribute
+ (JNIEnv *, jobject, jlong, jlong, jstring);
/*
* Class: org_apache_jk_apr_AprImpl
- * Method:unWrite
- * Signature: (JJ[BII)I
+ * Method:jkInit
+ * Signature: (JJ)I
*/
-JNIEXPORT jint JNICALL Java_org_apache_jk_apr_AprImpl_unWrite
- (JNIEnv *, jobject, jlong, jbyteArray, jint, jint);
+JNIEXPORT jint JNICALL Java_org_apache_jk_apr_AprImpl_jkInit
+ (JNIEnv *, jobject, jlong, jlong);
/*
* Class: org_apache_jk_apr_AprImpl
- * Method:getJkEnv
- * Signature: ()J
+ * Method:jkDestroy
+ * Signature: (JJ)I
*/
-JNIEXPORT jlong JNICALL
Re: [4.1.3] Binaries uploaded
On Thu, 6 Jun 2002, jean-frederic clere wrote: BTW I still not able to get jk2 working on my Solaris8 test machine (it cores when accessing a mod_jk2 context (even /jkstatus/) and nothing is written in the mod_jk.log file): +++ (/opt/SUNWspro/WS6U1/bin/sparcv9/dbx) where [1] 0xb8469ed0(0x20aa20, 0x1718a0, 0x1718a0, 0x20aa20, 0xf3000, 0xf3000), at 0 xb8469ecf [2] child_main(), at 0x45448 dbx: core file read error: address 0xffbef030 not in data space dbx: attempt to read frame failed -- cannot derive frame pointer (/opt/SUNWspro/WS6U1/bin/sparcv9/dbx) +++ (The problem is that I have 3 compilers and 2 linkers on this machine, so may be it is a libtool problem). Has someone tried mod_jk2 with this SUN compiler? I only tested with GNU. If you could get some debug info ( line numbers, methods ) it would be easier to debug. Did you tried to the the backtrace in gdb ? I'll try to find a native compiler and check. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk 4.03 deadlock
Hi.
The lock/unlock fix may help but it doesn't fix the problem. I patched
my tree with the jk_mt.h modification and I investigated the bug even
deeper.
The problem was in jk_connect.c, jk_tcp_socket_recvfull, recv call. It
seems that Tomcat 4.03 (I didn't try with CVS head version...) sometimes
doesn't send all the data required. So, mod_jk blocks in recv forever,
causing a deadlock.
I patched my tree with the following:
-- jk_connect.c, jk_tcp_socket_recvfull
-- after while(rdlen len) {
int this_time, select_ret;
fd_set set;
struct timeval timeout;
FD_ZERO(set);
FD_SET(sd, set);
timeout.tv_sec = 3;
timeout.tv_usec = 0;
select_ret = select(sd+1, set, NULL, NULL, timeout);
if (-1 == select_ret) {
return -1;
}
if (0 == select_ret) {
return -1;
}
-- before this_time = recv(sd,
The deadlock is gone and I'm very happy! :)
Thanks,
jeff
On Wed, 2002-06-05 at 21:25, [EMAIL PROTECTED] wrote:
Hi,
I found the problem, it seems the lock/unlock were in the wrong order.
Please checkout from head and try again, and let me know if it still
fails.
( thanks for reporting it )
Costin
On 5 Jun 2002, Jean-Francois Nadeau wrote:
Hi.
I started to load / stress test our web application. It is running under
Apache 1.3.22 and Tomcat 4.03 and the mod_jk binary that came with it.
The OS is Linux 2.4.7, RedHat 7.2 without any updates.
I discovered that httpd processes deadlock after a certain amount of
huge requests.
I decided to investigate the issue by looking at the source code. The
jk_handler function does not terminate. In fact, the call to
end-done($end, l) (just before the jk_close_pool) deadlock (not always
however). That function calls pthread mutex lock/unlock for connection
reuse.
I tried to comment all connection reuse code. (in jk_ajp_done,
jk_ajp_service, jk_ajp_getendpoint). The deadlock is not gone, but it
appears later.
Have you ever encountered this problem before? I'd like to fix it. May
it be a kernel bug, glibc bug? (The problem seems to come from pthread
mutexes...)
Thanks a lot,
jeff
--
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]
DO NOT REPLY [Bug 9655] - Page is not displaying
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=9655. 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=9655 Page is not displaying --- Additional Comments From [EMAIL PROTECTED] 2002-06-06 15:15 --- This works for me. 99% of the time, I'm using Tomcat in localhost with either IE 6, Mozilla or Netscape 4 on Win2k. More details please :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9662] - JDBCRealm doesn't work with postgres 7.2 driver
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=9662.
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=9662
JDBCRealm doesn't work with postgres 7.2 driver
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
--- Additional Comments From [EMAIL PROTECTED] 2002-06-06 15:19 ---
This seems like an issue loading the driver class. Please make sure you have put
the driver and all its dependencies in common/lib.
The corresponding lines in the realm are:
try {
Class clazz = Class.forName(driverName);
driver = (Driver) clazz.newInstance();
} catch (Throwable e) {
throw new SQLException(e.getMessage());
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs manager-howto.xml
remm2002/06/06 08:29:57
Modified:webapps/tomcat-docs manager-howto.xml
Log:
- Make the example from the manager HOWTO valid XML (bug 9658).
Revision ChangesPath
1.15 +6 -6 jakarta-tomcat-4.0/webapps/tomcat-docs/manager-howto.xml
Index: manager-howto.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/manager-howto.xml,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- manager-howto.xml 8 Apr 2002 18:28:36 - 1.14
+++ manager-howto.xml 6 Jun 2002 15:29:57 - 1.15
@@ -734,18 +734,18 @@
trtdpre
lt;project name=My Application default=compile basedir=.gt;
- lt;-- Configure the directory into which the web application is built --gt;
+ lt;!-- Configure the directory into which the web application is built --gt;
lt;property name=buildvalue=${basedir}/build/gt;
- lt;-- Configure the context path for this application --gt;
+ lt;!-- Configure the context path for this application --gt;
lt;property name=path value=/myapp/gt;
- lt;-- Configure properties to access the Manager application --gt;
+ lt;!-- Configure properties to access the Manager application --gt;
lt;property name=url value=http://localhost:8080/manager/gt;
lt;property name=username value=myusername/gt;
lt;property name=password value=mypassword/gt;
- lt;-- Configure the custom Ant tasks for the Manager application --gt;
+ lt;!-- Configure the custom Ant tasks for the Manager application --gt;
lt;taskdef name=deployclassname=org.apache.catalina.ant.DeployTask/gt;
lt;taskdef name=install classname=org.apache.catalina.ant.InstallTask/gt;
lt;taskdef name=list classname=org.apache.catalina.ant.ListTask/gt;
@@ -757,9 +757,9 @@
lt;taskdef name=stop classname=org.apache.catalina.ant.StopTask/gt;
lt;taskdef name=undeploy classname=org.apache.catalina.ant.UndeployTask/gt;
- lt;-- Executable Targets --gt;
+ lt;!-- Executable Targets --gt;
lt;target name=compile description=Compile web applicationgt;
-... construct web application in ${build} subdirectory ...
+lt;!-- ... construct web application in ${build} subdirectory ... --gt;
lt;/targetgt;
lt;target name=install description=Install web application
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9658] - manager-howto contains illegal xml comments
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=9658. 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=9658 manager-howto contains illegal xml comments [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-06-06 15:30 --- Fixed. The document now is valid XML. Thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.3] Binaries uploaded
[EMAIL PROTECTED] wrote: On Thu, 6 Jun 2002, jean-frederic clere wrote: BTW I still not able to get jk2 working on my Solaris8 test machine (it cores when accessing a mod_jk2 context (even /jkstatus/) and nothing is written in the mod_jk.log file): +++ (/opt/SUNWspro/WS6U1/bin/sparcv9/dbx) where [1] 0xb8469ed0(0x20aa20, 0x1718a0, 0x1718a0, 0x20aa20, 0xf3000, 0xf3000), at 0 xb8469ecf [2] child_main(), at 0x45448 dbx: core file read error: address 0xffbef030 not in data space dbx: attempt to read frame failed -- cannot derive frame pointer (/opt/SUNWspro/WS6U1/bin/sparcv9/dbx) +++ (The problem is that I have 3 compilers and 2 linkers on this machine, so may be it is a libtool problem). Has someone tried mod_jk2 with this SUN compiler? I only tested with GNU. If you could get some debug info ( line numbers, methods ) it would be easier to debug. Did you tried to the the backtrace in gdb ? +++ (gdb) backtrace #0 0xb8469ed0 in ?? () Cannot access memory at address 0xffbeefcc +++ Useless! I'll try to find a native compiler and check. Using the gcc (3.0.4) compiler it hangs: +++ $ mdb -p 9061 Loading modules: [ ] $c libc.so.1`_so_accept+4(746a8, a, 5c, 38, 58, 38) mod_cgid.so`cgid_init+0x264(72958, 9ca28, 8e9f0, 746a8, fec935b4, ffbef769) ap_run_post_config+0x4c(0, 9ca28, 8e9f0, 746a8, ffbef768, 4f000) main+0x46c(746a8, 709d0, 4f0b8, 4f0c8, 0, 0) _start+0x5c(0, 0, 0, 0, 0, 0) +++ Why in mod_cgid? - When I comment it out it crashes without core - Last output: +++ [Thu Jun 06 17:20:53 2002] [warn] config.setAttribute() Error setting logger.apache2: file /export/home/apache20/apache20/logs/mod_jk.log +++ Any things wrong in my workers2.properties? Costin # Comments will be lost when protocol-based config will be used # ( at least in the first version ). In a future version we'll save # the comments before every section and property and save ( maybe ) # Global options ( in addition to the pre-defined fs, ps, java_home [config] foo=bar # Logger options. For apache2 only level can be set ( it logs to error.log ) # For apache1 the file must be specified too. # XXX logger is an alias or shortcut to logger.file: # Do we need shortcuts ? XXX Document shortcuts [logger] level=DEBUG file=/export/home/apache20/apache20/logs/mod_jk.log # Default channel. Defaults are used # XXX The name must be parsed and used automatically # XXX Objects to be defined on-demand, using default values #[channel.socket:localhost:8009] # Example socket channel, override port [channel.socket:localhost:8019] port=8019 host=127.0.0.1 # Example unix socket #[channel.apr:/tmp/tomcatUnixSocket] # The status worker. Only defaults. XXX in the final version, # you shouldn't have to define the objects using defaults, they'll be # created automatically, on demand. [worker.status] # XXX document/implement a better way to 'disable' a worker. Remove disabled: # if you want to play with in-process ( for example fix the remaining bugs :-) [disabled:worker.jni] tomcat_home=/opt/tomcat # XXX will go away, will use magic to configure. #[worker.ajp13:localhost:8109] #channel=channel.socket:localhost:8109 [worker.ajp13:localhost:8019] channel=channel.socket:localhost:8019 # Again, the redundant info will disapear [worker.ajp13:/tmp/tomcatUnixSocket] channel=channel.apr:/tmp/tomcatUnixSocket # Note that we use separate lines instead of , separated values. # It's cleaner and scales better. # XXX The lb worker will get some magic properties to remove some workers # and allow them to be added dynamically. #[worker.lb] #balanced_workers=worker.ajp13:localhost:8109 #balanced_workers=worker.ajp13:/tmp/tomcatUnixSocket # Uri mapping. # XXX Uris to be read from separate file, one per webapp. [uri:/examples/*] worker=worker.ajp13:localhost:8019 # Status worker. XXX protect it with Location and security settings, # it'll display all properties - including eventual secrets. [uri:/jkstatus/*] worker=worker.status # Experiment with saving the properties. # must be last in the config - this will go away, we'll save # in the original file when the config changes with ajp14 or other method [config] save=/tmp/jk2.saved.properties -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [4.1.3] Binaries uploaded
? I have: $ /home1/apache20/apache20/bin/apxs -q EXTRA_CFLAGS -DNO_DBM_REWRITEMAP$ $ /home1/apache20/apache20/bin/apxs -q CFLAGS -DXTI_SUPPORT$ The DXTI_SUPPORT is the missing one ;-) Ok, so we need to concat CFLAGS EXTRA_CFLAGS in jk_apxs.m4. I must leave, could you update the CVS JF ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mx for jk
[EMAIL PROTECTED] wrote: In case you didn't noticed, I checked in a small 'magic' util that turns Jk components into dynamic MBeans. It still doesn't support the 'descriptions' and the ability to fine tune the exposed attributes/methods, that will be added later ( and will probably require xdoclet or a similar tool ). This sounds a bit like o.a.commons.modeler. (modeler provides code to fill in MBean meta-data based on an external xml file, see o.a.catalina.mbeans.mbeans-descriptors.xml) Is the magic jk code related, a replacement, or just something completely different? -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk 4.03 deadlock
Thanks for the patch.
However, there are still few big problems and we really need your
help ( even if you solve your problem ). First, I can't reproduce
it - so it's blind debugging.
I don't think select() is available on all platforms ( for jk2
we could use apr select ), so I doubt we can just check in your
fix. Second, this adds a certain overhead ( we double the number
of system calls ).
The real issue is why tomcat doesn't send the data. Could you try
with tomcat4.1 ( or the new coyote-based ajp connector ) ? Is it
really a deadlock ( tomcat and mod_jk both waiting for input,
i.e. locked in read ) ? Or it is that tomcat for some reasons
doesn't send the 'END' message ?
Of course, there is the issue of detecting timeouts - but that's
extremely tricky, as some requests may take a long time to process,
and waiting 3 seconds ( or any other timeout ) is not a good solution.
It is the java side who should send the END message when the
requests ends.
Can you try more debugging, also on the java side ? Maybe the
etherreal AJP pluging can help :-)
BTW, even if you solved the deadlock you may run into other problems,
as requests longer than 3 secs will fail.
Costin
On 6 Jun 2002, Jean-Francois Nadeau wrote:
Hi.
The lock/unlock fix may help but it doesn't fix the problem. I patched
my tree with the jk_mt.h modification and I investigated the bug even
deeper.
The problem was in jk_connect.c, jk_tcp_socket_recvfull, recv call. It
seems that Tomcat 4.03 (I didn't try with CVS head version...) sometimes
doesn't send all the data required. So, mod_jk blocks in recv forever,
causing a deadlock.
I patched my tree with the following:
-- jk_connect.c, jk_tcp_socket_recvfull
-- after while(rdlen len) {
int this_time, select_ret;
fd_set set;
struct timeval timeout;
FD_ZERO(set);
FD_SET(sd, set);
timeout.tv_sec = 3;
timeout.tv_usec = 0;
select_ret = select(sd+1, set, NULL, NULL, timeout);
if (-1 == select_ret) {
return -1;
}
if (0 == select_ret) {
return -1;
}
-- before this_time = recv(sd,
The deadlock is gone and I'm very happy! :)
Thanks,
jeff
On Wed, 2002-06-05 at 21:25, [EMAIL PROTECTED] wrote:
Hi,
I found the problem, it seems the lock/unlock were in the wrong order.
Please checkout from head and try again, and let me know if it still
fails.
( thanks for reporting it )
Costin
On 5 Jun 2002, Jean-Francois Nadeau wrote:
Hi.
I started to load / stress test our web application. It is running under
Apache 1.3.22 and Tomcat 4.03 and the mod_jk binary that came with it.
The OS is Linux 2.4.7, RedHat 7.2 without any updates.
I discovered that httpd processes deadlock after a certain amount of
huge requests.
I decided to investigate the issue by looking at the source code. The
jk_handler function does not terminate. In fact, the call to
end-done($end, l) (just before the jk_close_pool) deadlock (not always
however). That function calls pthread mutex lock/unlock for connection
reuse.
I tried to comment all connection reuse code. (in jk_ajp_done,
jk_ajp_service, jk_ajp_getendpoint). The deadlock is not gone, but it
appears later.
Have you ever encountered this problem before? I'd like to fix it. May
it be a kernel bug, glibc bug? (The problem seems to come from pthread
mutexes...)
Thanks a lot,
jeff
--
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]
cvs commit: jakarta-tomcat-connectors/jk/support jk_apxs.m4
jfclere 2002/06/06 09:43:17
Modified:jk/support jk_apxs.m4
Log:
Apache-2.0 needs both CFLAGS and EXTRA_CFLAGS.
Revision ChangesPath
1.2 +4 -4 jakarta-tomcat-connectors/jk/support/jk_apxs.m4
Index: jk_apxs.m4
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/support/jk_apxs.m4,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- jk_apxs.m424 May 2002 07:05:07 - 1.1
+++ jk_apxs.m46 Jun 2002 16:43:16 - 1.2
@@ -60,7 +60,7 @@
dnl
dnl Inspired by Pier works on webapp m4 macros :)
dnl
-dnl Version $Id: jk_apxs.m4,v 1.1 2002/05/24 07:05:07 hgomez Exp $
+dnl Version $Id: jk_apxs.m4,v 1.2 2002/06/06 16:43:16 jfclere Exp $
dnl --
dnl --
@@ -121,7 +121,7 @@
if ${TEST} -z $APA ; then
WEBSERVERS=${WEBSERVERS} server/apache13
RWEBSERVER=apache-1.3
- APXS$1_CFLAGS=`${APXS$1} -q CFLAGS`
+ APXS$1_CFLAGS=`${APXS$1} -q CFLAGS`
APXS$1_CPPFLAGS=
else
WEBSERVERS=${WEBSERVERS} server/apache2
@@ -130,8 +130,8 @@
JK_CHANNEL_APR_SOCKET=\${JK}jk_channel_apr_socket\${OEXT}
JK_POOL_APR=\${JK}jk_pool_apr\${OEXT}
HAS_APR=-DHAS_APR
- APXS$1_CFLAGS=`${APXS$1} -q EXTRA_CFLAGS`
- APXS$1_CPPFLAGS=`${APXS$1} -q EXTRA_CPPFLAGS`
+ APXS$1_CFLAGS=`${APXS$1} -q CFLAGS` `${APXS$1} -q EXTRA_CFLAGS`
+ APXS$1_CPPFLAGS=`${APXS$1} -q EXTRA_CPPFLAGS`
fi
AC_MSG_RESULT([building connector for \$RWEBSERVER\])
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Licensing compatibility with MPL
Hi, I am currently involved in an Open Source project called MMBase (www.mmbase.org). This project is written in java and licensed under the Mozilla Public License 1.0. For this project, I needed a snippet of code from the tomcat source. To be exact: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v the method 'public static String parseCharacterEncoding(String contentType)' My question to you is if the Apache Software License 1.1 and the Mozilla Public License 1.0 are compatible, and if so, what text I should include in my sourcecode. I propose to add the following javadoc to the method that uses the code: /** * Parse the contentType to find the character encoding * This code is based on code from the Jakarta Tomcat project * File: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v * Revision: 1.19 * The code in this method is licensed by the Apache Software License 1.1 */ Since this is the first time that I use code of other Open Source projects for code I write myself, I am puzzled whether or not this would acceptable. Please note that I am not subscribed to this mailinglist, please CC any replies to me directly. Kind regards, Johannes Verelst -- Johannes Verelst [EMAIL PROTECTED] / Gullie on SlashNET Sleep, she is for the weak -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.3] Binaries uploaded
GOMEZ Henri wrote: ? I have: $ /home1/apache20/apache20/bin/apxs -q EXTRA_CFLAGS -DNO_DBM_REWRITEMAP$ $ /home1/apache20/apache20/bin/apxs -q CFLAGS -DXTI_SUPPORT$ The DXTI_SUPPORT is the missing one ;-) Ok, so we need to concat CFLAGS EXTRA_CFLAGS in jk_apxs.m4. I must leave, could you update the CVS JF ? Done ;-) I will test the result tomorrow. The libtool or the libcrypt I have is somehow broken: libtool has build *.a instead *.so: +++ *** Warning: This library needs some functionality provided by -lcrypt. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. ++ -- 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: mx for jk
On Thu, 6 Jun 2002, Christopher K. St. John wrote:
This sounds a bit like o.a.commons.modeler. (modeler
provides code to fill in MBean meta-data based on an external
xml file, see o.a.catalina.mbeans.mbeans-descriptors.xml)
Is the magic jk code related, a replacement, or just something
completely different?
I am well aware of modeler, I mentioned few times I think it is
a good solution but not the best ( at least for our use case ) :-)
Modeler creates model MBeans, based on a XML config file.
This solution uses Dynamic MBeans, using introspection data -
at least at the first level. It'll probably use some XML
( or properties file ) similar with modeler, but automatically
generated from javadoc tags ( @jmx:attribute, etc ) and source.
The big difference is that with model MBeans, the JMX implementation
is providing the bridge between JMX callers and the actual managed
bean.
With dynamic MBeans, our Dynamic proxy gets called and we
can save/manipulate the data.
If users sets port to 8081, we can save this info in
our representation of config ( I'll try to use something similar with
preferences for 1.4 and preferences in 1.4 ).
The result is that we can manage the config file based on what is
actually set by user, not on data extracted from the runtime.
( we can also insert the very usefull ${substitution} and many
other tricks ).
A second difference is that we need to also manage the C components,
i.e. provide the same JMX interface for mod_jk. Again, a dynamic
mbean is essential for this - it'll probably do some AJP calls
in setAttribute(), etc.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JK2] Passing Roles to Java
Ignacio J. Ortega [EMAIL PROTECTED] wrote: AFAIK there is only provision to to pass the authenticated user name to Tomcat from a native auth system, I dont know apache(1 or 2) if there is something like roles there, by in NT Land, one can configure the IIS to use the OS Users for auth, and when used this way, we could pass the groups a user is in, as roles.. Just now there is no provision to pass this infos from JK2 to tomcat, how could i extend JK2 to pass the roles to TC? It is currently impossible... We chatted about it on httpd-dev quite some time ago, but the Group stuff used (for example) by the default authenticator is not exported to other modules, and other modules implement it differently... There's no concept of role basically, only user and realm... Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/doc tomcat-ssl-howto.html
keith 2002/06/06 11:39:19 Modified:src/doc tomcat-ssl-howto.html Log: Wrong closing tag. Revision ChangesPath 1.12 +1 -1 jakarta-tomcat/src/doc/tomcat-ssl-howto.html Index: tomcat-ssl-howto.html === RCS file: /home/cvs/jakarta-tomcat/src/doc/tomcat-ssl-howto.html,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- tomcat-ssl-howto.html 18 Apr 2002 13:58:00 - 1.11 +++ tomcat-ssl-howto.html 6 Jun 2002 18:39:19 - 1.12 @@ -580,7 +580,7 @@ PureTLS does not currently allow you to make self-signed certificates. However, a number of sample certificate files are included in the PureTLS distribution. For testing purposes you can use the file -codersa-server.pem/a which has the password codepassword/a. +codersa-server.pem/code which has the password codepassword/code. p Finally, PureTLS allows you to create a certificate request using the codeCOM.claymoresystems.ptls.cert.CertRequest/code class. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mx for jk
On Thu, 6 Jun 2002, Amy Roh wrote: Maybe we can add for admin to handle dynamic user added components later too. :-) Well, my assumption was that the /admin uses JMX. There is no distinction between dynamic, standard or model mbeans from the user point of view, it's just a choice in how you instrument the code. All that's needed is a UI to reflect what can be configured in jk, using the mbean names and attributes we register ( right now domain=jk2, name=component name ). Am I missing something ? Sorry, didn't look very close to the admin impl. so far, I'm just playing with the mx4j default adapter ( and I can 'see' both tomcat and jk objects in the same way ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Logging: more classloader problems.
The problem: it won't work if commons-logging.jar is installed in the parent class loader, and log4j.jar ( or another logger ) is installed in a child loader ( like WEB-INF/lib ). What happens: - the factory uses the thread class loader to check if the log4j ( or any other impl. ) exists ( and it does ). - it creates an instance of the Logger adapter. This will be created using parent loader ( the one that loads commons-logging ). - the Logger instance makes references to Category or other classes that are used in it's implementation. End of story, since the class loader can't find the reference. This works fine for JAXP because the adapter for a parser is part of the parser jar. It doesn't work for c-l because the adapter is in the root loader ( with the API), not with the logging impl. That doesn't affect people who just use a single logger or can put the logger impl. in the same place with common-logging. It only affect containers like tomcat, when you want to let each webapp use it's own logger impl. of choice. I tried all kind of introspection games, it won't work. The only solution I see is to make sure the adapters are in the same place with the logger. Solution: Split commons-logging.jar in commons-logging-api.jar ( only the API and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. Alternatively, leave commons-logging.jar as it is and create a second commons-logging-api.jar. The -api will be included in the common loader. Each webapp will have to include commons-logging.jar ( or -impl ), and it's own logger. Or course, the best would be to have the adapter included in the logger impl. What do you think ? Craig, Remy can we make another c-l dot release with this change ? ( I'll do some more testing to see how it works ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Logging: more classloader problems.
On Thu, 6 Jun 2002, Geir Magnusson Jr. wrote: On 6/6/02 2:08 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Solution: Split commons-logging.jar in commons-logging-api.jar ( only the API and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. :) If you knew that keeping the adapter in the same jar will brake tomcat, why didn't you say so ??? :-) I remember all kind of crazy arguments - but never saw this one. Actually the default logger ( used if no 'real' logger is found ) and the JDK1.4 adapter will have to remain in the main jar ( unless we want to support an alternate impl. for JDK1.4 logging - is it even possible ? ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/doc tomcat-ssl-howto.html
keith 2002/06/06 12:37:07 Modified:src/doc tomcat-ssl-howto.html Log: Clear up some clientauth confusion. Revision ChangesPath 1.13 +4 -0 jakarta-tomcat/src/doc/tomcat-ssl-howto.html Index: tomcat-ssl-howto.html === RCS file: /home/cvs/jakarta-tomcat/src/doc/tomcat-ssl-howto.html,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- tomcat-ssl-howto.html 6 Jun 2002 18:39:19 - 1.12 +++ tomcat-ssl-howto.html 6 Jun 2002 19:37:07 - 1.13 @@ -628,6 +628,10 @@ case difference between Tomcat 3.2 and Tomcat 3.3 (i.e. quot;clientAuthquot; versus quot;clientauthquot;). P +For JSSE, the ipresence/i of the clientauth parameter will enforce +client authentication, regardless of the parameter value. For PureTLS, +this decision is based on the ivalue/i of the clientauth parameter. +P By default, Tomcat chooses whatever SSL implementation is available, with preference given to PureTLS over JSSE if both are available. You can specify the exact implementation you want using the codeSSLImplementation/code -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [JK2] Passing Roles to Java
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: 6 de junio de 2002 19:51 Add attributes in the request ( and it'll keep jk2 compatible with older versions of tomcat ). Or extend the message format for request. Ahh, ok, better an attribute, i think, than to add a new message to the protocol, we only lost lazy evaluation, right?, and a normal group of roles, it's unlikely to be a string big than 300 to 400 character, to say.., it's acceptable for an attributte (more) ?, is only passed when the request was authenticated.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PROPOSAL: Consistent logging ( for 3.x, 4.x )
- Original Message - From: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, June 05, 2002 11:40 PM Subject: Re: PROPOSAL: Consistent logging ( for 3.x, 4.x ) On Wed, 5 Jun 2002, Bill Barker wrote: At least in 3.3 land, I'm leaning to Remy's opinion. It's going to be painful. However, I'm +1 (i.e. I'll help on the 3.3 stuff) . As Remy points out, TINA. Ok, what does 'TINA' mean :-) ??? There Is No Alternative (copy; Margaret Thatcher :) I see your point, I'll play a bit more with the class loaders ( I'm using log4j in common ). In JDK1.4 we don't have the option to move the logging in the container loader :-), and at least log4j can be upgraded in common at any time, not only when you upgrade the VM. 3.3.1 as recommended on the Coyote download page (tomcat-util.jar is in common, and commons-logging.jar is in container). Now, commons-logging is pretty stable, so I don't have a problem with (like in 3.3.2-dev) putting it in common. However, I really don't want to put log4j.jar in common since then it would over-ride the one in WEB-INF/lib. This is almost as bad as putting JAXP in common. I'll try to get it in container. It should work, except the messages that are displayed before the logger is set up ( where the 'default' of commons-logging will be used ). What I'm worried about is setting up the per/context loggers and where they'll write. I assume webapps using log4j will provide their own configuration, but how do we mix this with the global settings ? And how do we deal with the sandbox. This is a little farther down the road. I'm guessing that the replacement for LogSetter will probably have to include an option(s) to control merging. For the first shot, I'd go for use webapp configuration, since people who currently have log4j installed would have to have setup the file anyway. Fortunately ( or not ) JDK1.4 logger doesn't seem to care about security, so why should we worry ... :-) Ok, it'll be more painfull than I thought - but still we should do it, it's a mess. My first thought was to move o.a.t.u.log back to jakarta-tomcat, and convert the rest of o.a.t.u.** to commons-logging. But this still has the same problems. Now that recycling is working again, I'm very fond of qlog. I'd like to be able to keep it as an option (as a plugin to commons-logging). Long term I think o.a.t.u.log should be deprecated. I agree qlog is a nice ( and quite efficient ) piece, so maybe it can be turned into a common-logging logger ( and so available to other apps ). +1 The last thing we need is yet-another logging API ( o.a.t.u.log is probably older than most others, but that doesn't matter ). Costin -- 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.3 Apache 1.3.x and Mod_WebApp on MacOSX
Apologies. I have added the following to httpd.conf #Adding Web application in Tomcat 4.0.3 WebAppConnection conn warp localhost:8008 WebAppDeploy ROOT conn /tomcat WebAppDeploy examples conn /tomcat/examples WebAppDeploy manager conn /tomcat/manager WebAppDeploy webdav conn /tomcat/webdav WebAppDeploy tomcat-docs conn /tomcat/tomcat-docs WebAppDeploy XyloWeb conn /XyloWeb WebAppInfo /webapp-info as well as LoadModule webapp_module libexec/httpd/mod_webapp.so my server.xml file is : (I made my modifications bold) Server port=8005 shutdown=SHUTDOWN debug=0 Service name=Tomcat-Standalone Connector className=org.apache.catalina.connector.http.HttpConnector port=8080 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=6/ Engine name=Standalone defaultHost=localhost debug=0 Logger className=org.apache.catalina.logger.FileLogger prefix=catalina_log. suffix=.txt timestamp=true/ Realm className=org.apache.catalina.realm.MemoryRealm / Host name=localhost debug=0 appBase=webapps unpackWARs=false Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=common/ Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=localhost_log. suffix=.txt timestamp=true/ Context path=/ docBase=ROOT debug=0 reloadable=true/ Context path=/XyloWeb docBase=XyloWeb.war debug=0 reloadable=true/ Context path=/manager docBase=manager debug=0 privileged=true/ Context path=/examples docBase=examples debug=0 reloadable=true Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_examples_log. suffix=.txt timestamp=true/ Ejb name=ejb/EmplRecord type=Entity home=com.wombat.empl.EmployeeRecordHome remote=com.wombat.empl.EmployeeRecord/ Environment name=maxExemptions type=java.lang.Integer value=15/ Parameter name=context.param.name value=context.param.value override=false/ Resource name=jdbc/EmployeeAppDb auth=SERVLET type=javax.sql.DataSource/ ResourceParams name=jdbc/EmployeeAppDb parameternameuser/namevaluesa/value/parameter parameternamepassword/namevalue/value/parameter parameternamedriverClassName/name valueorg.hsql.jdbcDriver/value/parameter parameternamedriverName/name valuejdbc:HypersonicSQL:database/value/parameter /ResourceParams Resource name=mail/Session auth=Container type=javax.mail.Session/ ResourceParams name=mail/Session parameter namemail.smtp.host/name valuelocalhost/value /parameter /ResourceParams /Context /Host /Engine /Service Service name=Tomcat-Apache Connector className=org.apache.catalina.connector.warp.WarpConnector port=8008 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=10 debug=0/ Engine className=org.apache.catalina.connector.warp.WarpEngine name=Apache debug=0 appBase=webapps Logger className=org.apache.catalina.logger.FileLogger prefix=apache_log. suffix=.txt timestamp=true/ Realm className=org.apache.catalina.realm.MemoryRealm / /Engine /Service /Server Again, sorry for not sending all information. Thanks Alex On Wednesday, June 5, 2002, at 09:54 PM, Pier Fumagalli wrote: Should I guess your configuration files? (Ok, a SEGV is not good, but at least include all relevant data). Pier Alexander Hartner [EMAIL PROTECTED] wrote: I am having such problems running tomcat 4.0.3 on my ibook. I can get tomcat started, and I can access it via port 8080. I can also deploy my war files by copying them to the webapps directory, but updates are not reflected until I have restarted Tomcat. I found some advise to add unpackWAR=false in my server.xml file which now allows my to reload my application via the manager app (great), but now the mod_web_app complains that is cannot deploy my application. In the apache_log file in tomcat's log directory the error reported indicates that it cannot find the directory of my webapp, which no longer exist since the war file does not get extracted. Before I added the unpackWAR=false I had to restart tomcat all the time, which resulted in a whole list of problems by itself. I keep on getting the error that my web app is not
Re: Tomcat 4.0.3 Apache 1.3.x and Mod_WebApp on MacOSX
Alexander Hartner [EMAIL PROTECTED] wrote: Apologies. I have added the following to httpd.conf #Adding Web application in Tomcat 4.0.3 WebAppConnection conn warp localhost:8008 WebAppDeploy ROOT conn /tomcat WebAppDeploy examples conn /tomcat/examples WebAppDeploy manager conn /tomcat/manager WebAppDeploy webdav conn /tomcat/webdav WebAppDeploy tomcat-docs conn /tomcat/tomcat-docs WebAppDeploy XyloWeb conn /XyloWeb This is wrong WebAppDeploy XyloWeb conn /XyloWeb.war - or wherever this file is... Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Logging: more classloader problems.
On Thu, 6 Jun 2002 [EMAIL PROTECTED] wrote: Date: Thu, 6 Jun 2002 11:08:10 -0700 (PDT) From: [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Cc: List Tomcat-Dev [EMAIL PROTECTED] Subject: Logging: more classloader problems. The problem: it won't work if commons-logging.jar is installed in the parent class loader, and log4j.jar ( or another logger ) is installed in a child loader ( like WEB-INF/lib ). What happens: - the factory uses the thread class loader to check if the log4j ( or any other impl. ) exists ( and it does ). - it creates an instance of the Logger adapter. This will be created using parent loader ( the one that loads commons-logging ). - the Logger instance makes references to Category or other classes that are used in it's implementation. End of story, since the class loader can't find the reference. This works fine for JAXP because the adapter for a parser is part of the parser jar. It doesn't work for c-l because the adapter is in the root loader ( with the API), not with the logging impl. That doesn't affect people who just use a single logger or can put the logger impl. in the same place with common-logging. It only affect containers like tomcat, when you want to let each webapp use it's own logger impl. of choice. I tried all kind of introspection games, it won't work. The only solution I see is to make sure the adapters are in the same place with the logger. Solution: Split commons-logging.jar in commons-logging-api.jar ( only the API and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. Alternatively, leave commons-logging.jar as it is and create a second commons-logging-api.jar. The -api will be included in the common loader. Each webapp will have to include commons-logging.jar ( or -impl ), and it's own logger. Or course, the best would be to have the adapter included in the logger impl. What do you think ? Craig, Remy can we make another c-l dot release with this change ? ( I'll do some more testing to see how it works ) +1 for leaving commons-logging.jar with the same contents and adding commons-logging-api.jar with just the API classes. That way, we won't disrupt anyone who is successfully using the existing approach. +1 for a dot release with both, once you're satisfied that it works for the problem case described. Costin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9676] New: - org.apache.coyote.tomcat4.CoyoteServerSocketFactory doesn't recognize keystoreType attribute
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=9676. 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=9676 org.apache.coyote.tomcat4.CoyoteServerSocketFactory doesn't recognize keystoreType attribute Summary: org.apache.coyote.tomcat4.CoyoteServerSocketFactory doesn't recognize keystoreType attribute Product: Tomcat 4 Version: 4.1.3 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] org.apache.coyote.tomcat4.CoyoteServerSocketFactory seems to be ignoring the keystoreType attribute. I'm trying to get it to work with a PKCS12 file. It works fine if I used the legacy HTTP connection, but, it doesn't work if I use the new Coyote connector. I'm using the following in my server.xml. Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=443 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=10 debug=0 scheme=https secure=true Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory keystoreType=pkcs12 clientAuth=false protocol=TLS/ /Connector And I receive the following error in catalina.out. Jun 6, 2002 4:48:00 PM org.apache.commons.logging.impl.Jdk14Logger info INFO: Attribute port: 443 Jun 6, 2002 4:48:00 PM org.apache.commons.logging.impl.Jdk14Logger info INFO: Attribute maxThreads: 75 Jun 6, 2002 4:48:00 PM org.apache.commons.logging.impl.Jdk14Logger info INFO: Attribute backlog: 10 Jun 6, 2002 4:48:00 PM org.apache.commons.logging.impl.Jdk14Logger info INFO: Attribute tcpNoDelay: true Jun 6, 2002 4:48:00 PM org.apache.commons.logging.impl.Jdk14Logger info INFO: Attribute soTimeout: 6 Jun 6, 2002 4:48:00 PM org.apache.commons.logging.impl.Jdk14Logger info INFO: Attribute timeout: 6 Jun 6, 2002 4:48:00 PM org.apache.commons.logging.impl.Jdk14Logger info INFO: Attribute secure: true Jun 6, 2002 4:48:00 PM org.apache.commons.logging.impl.Jdk14Logger info INFO: Attribute algorithm: null Jun 6, 2002 4:48:00 PM org.apache.commons.logging.impl.Jdk14Logger info INFO: Attribute keystore: /root/.keystore Jun 6, 2002 4:48:00 PM org.apache.commons.logging.impl.Jdk14Logger info INFO: Attribute protocol: TLS Jun 6, 2002 4:48:00 PM org.apache.commons.logging.impl.Jdk14Logger info INFO: Attribute sslImplementation: null Jun 6, 2002 4:48:00 PM org.apache.commons.logging.impl.Jdk14Logger error SEVERE: Error initializing endpoint java.io.IOException: Invalid keystore format at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:606) at java.security.KeyStore.load(KeyStore.java:652) at org.apache.tomcat.util.net.JSSESocketFactory.initKeyStore (JSSESocketFactory.java:251) at org.apache.tomcat.util.net.JSSESocketFactory.initProxy (JSSESocketFactory.java:182) at org.apache.tomcat.util.net.JSSESocketFactory.createSocket (JSSESocketFactory.java:127) at org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint (PoolTcpEndpoint.java:263) at org.apache.coyote.http11.Http11Protocol.init (Http11Protocol.java:150) at org.apache.coyote.tomcat4.CoyoteConnector.initialize (CoyoteConnector.java:1002) at org.apache.catalina.core.StandardService.initialize (StandardService.java:582) at org.apache.catalina.core.StandardServer.initialize (StandardServer.java:2243) at org.apache.catalina.startup.Catalina.start(Catalina.java:509) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) 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.main(Bootstrap.java:203) Catalina.start: LifecycleException: Protocol handler initialization failed: java.io.IOException: Invalid keystore format LifecycleException: Protocol handler initialization failed: java.io.IOException: Invalid keystore format at org.apache.coyote.tomcat4.CoyoteConnector.initialize (CoyoteConnector.java:1004) at
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx DynamicMBeanProxy.java
costin 2002/06/06 15:17:00
Modified:util/java/org/apache/tomcat/util/mx DynamicMBeanProxy.java
Log:
Few more improvements.
- if name is not specified, construct one from the last part of the class
name, plus an int if multiple instances are present. ( can be improved ).
We should add some common 'patterns' to extract an id from a bean -
getName, getId, etc ( using introspection ).
- use findMBeanServer() instead of create - so we use the same server
as tomcat. ( assuming modeler is loaded first - I think the modeler should
do the same, first look for existing server - tomcat may run in jboss ! )
- reduce debug info
- Try to use the real class name - I don't know how it is used ( but
it shouldn't ), but it's better to see it instead of the DynamicMBeanProxy.
Revision ChangesPath
1.2 +69 -11
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx/DynamicMBeanProxy.java
Index: DynamicMBeanProxy.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx/DynamicMBeanProxy.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DynamicMBeanProxy.java5 Jun 2002 21:19:48 - 1.1
+++ DynamicMBeanProxy.java6 Jun 2002 22:17:00 - 1.2
@@ -77,7 +77,8 @@
*/
public class DynamicMBeanProxy implements DynamicMBean {
Object real;
-
+String name;
+
Method methods[];
Hashtable attMap=new Hashtable();
@@ -91,6 +92,10 @@
// key: operation val: invoke method
Hashtable invokeAttMap=new Hashtable();
+static MBeanServer mserver=null;
+
+static Hashtable instances=new Hashtable();
+
/** Create a Dynamic proxy, using introspection to manage a
* real tomcat component.
*/
@@ -98,6 +103,60 @@
}
+public void setName(String name ) {
+this.name=name;
+}
+
+public String getName() {
+if( name!=null ) return name;
+
+if( real==null ) return null;
+
+name=real.getClass().getName();
+name=name.substring( name.lastIndexOf( .) + 1 );
+Integer iInt=(Integer)instances.get(name );
+if( iInt!= null ) {
+int i=iInt.intValue();
+i++;
+instances.put( name, new Integer( i ));
+name=name + _ + i;
+} else {
+instances.put( name, new Integer( 0 ));
+}
+return name;
+}
+
+public void registerMBean( String domain ) {
+try {
+// XXX use aliases, suffix only, proxy.getName(), etc
+ObjectName oname=new ObjectName( domain + : name= + getName());
+
+getMBeanServer().registerMBean( this, oname );
+} catch( Throwable t ) {
+log.error( Error creating mbean , t );
+}
+}
+
+public static MBeanServer getMBeanServer() {
+if( mserver==null ) {
+if( MBeanServerFactory.findMBeanServer(null).size() 0 ) {
+
mserver=(MBeanServer)MBeanServerFactory.findMBeanServer(null).get(0);
+} else {
+mserver=MBeanServerFactory.createMBeanServer();
+}
+}
+
+return mserver;
+}
+
+private boolean supportedType( Class ret ) {
+return ret == String.class ||
+ret == Integer.class ||
+ret == Integer.TYPE ||
+ret == java.io.File.class ||
+ret == Boolean.class;
+}
+
/** Set the managed object.
*
* @todo Read an XML ( or .properties ) file containing descriptions,
@@ -119,9 +178,7 @@
if( ! Modifier.isPublic( methods[j].getModifiers() ) )
continue;
Class ret=methods[j].getReturnType();
-if( ret != String.class
-ret != Integer.class
-ret != Boolean.class ) {
+if( ! supportedType( ret ) ) {
continue;
}
name=unCapitalize( name.substring(3));
@@ -140,9 +197,7 @@
if( ! Modifier.isPublic( methods[j].getModifiers() ) )
continue;
Class ret=params[0];
-if( ret != String.class
-ret != Integer.class
-ret != Boolean.class ) {
+if( ! supportedType( ret ) ) {
continue;
}
name=unCapitalize( name.substring(3));
@@ -197,9 +252,11 @@
}
}
-log.info(real.getClass().getName() + getMBeanInfo );
-return new
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common JkMX.java
costin 2002/06/06 15:21:04
Modified:jk/java/org/apache/jk/common JkMX.java
Log:
You can no specify the port where the mx4j adapter listens.
That's for debugging - it should be set to -1 for normal use.
Note that mx4j has problems with the thread class loader ( surprise ? ),
so mx4j-tools.jar must be in the same place with mx4j.jar.
Some code was moved to DynamicProxy, remove from here.
Also, do a class.forName and try to register the log4j mbeans ( still
has few problems if you don't have a log4j.properties ).
Revision ChangesPath
1.2 +25 -25jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkMX.java
Index: JkMX.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkMX.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JkMX.java 5 Jun 2002 21:27:06 - 1.1
+++ JkMX.java 6 Jun 2002 22:21:04 - 1.2
@@ -69,11 +69,15 @@
import org.apache.tomcat.util.mx.*;
/** MX-enable jk.
+ *
+ * Add mx.port=PORT in jk2.properties to enable it.
+ * If port==-1 the JMX will be enabled but no HTTP adapter will be loaded.
+ * Port 0 will load the mx4j adapter, if possible.
*/
public class JkMX extends JkHandler
{
MBeanServer mserver;
-private boolean mxAdapter=true;
+private int port=-1;
public JkMX()
{
@@ -81,38 +85,26 @@
/* Public methods */
-/** Testing - load the jmx adapter
+/** Enable the MX4J internal adapter
*/
-public void setLoadAdapter( boolean b ) {
-mxAdapter=b;
+public void setPort( int i ) {
+port=i;
}
-public DynamicMBean createMBean( Object proxy, String name ) {
+public void createMBean( Object proxy, String name ) {
try {
-// XXX use aliases, suffix only, proxy.getName(), etc
-if( name==null )
-name=proxy.getClass().getName();
-
-// XXX use jk domain
-String domain = jk2;
-
DynamicMBeanProxy mbean=new DynamicMBeanProxy();
-
mbean.setReal( proxy );
-
-ObjectName oname=new ObjectName( domain + : name= + name );
-
-mserver.registerMBean( mbean, oname );
+if( name!=null ) {
+mbean.setName( name );
+}
+
+mbean.registerMBean( jk2 );
} catch( Throwable t ) {
log.error( Error creating mbean , t );
}
-return null;
}
-public void registerName( String name, String className ) {
-
-}
-
/* Start/stop */
/** Initialize the worker. After this call the worker will be
@@ -123,7 +115,7 @@
ObjectName serverName = new ObjectName(Http:name=HttpAdaptor);
mserver.createMBean(mx4j.adaptor.http.HttpAdaptor, serverName, null);
//mserver.setAttribute(serverName, new Attribute(Host, 10.0.0.181));
-mserver.setAttribute(serverName, new Attribute(Port, new
Integer(8012)));
+mserver.setAttribute(serverName, new Attribute(Port, new
Integer(port)));
ObjectName processorName = new ObjectName(Http:name=XSLTProcessor);
mserver.createMBean(mx4j.adaptor.http.XSLTProcessor, processorName,
null);
@@ -159,10 +151,18 @@
}
public void init() throws IOException {
try {
-mserver = MBeanServerFactory.createMBeanServer();
+mserver = DynamicMBeanProxy.getMBeanServer();
-if( mxAdapter ) {
+if( port 0 ) {
loadAdapter();
+}
+
+try {
+Class c=Class.forName( org.apache.log4j.jmx.HierarchyDynamicMBean
);
+Object o=c.newInstance();
+mserver.registerMBean(o, new ObjectName(log4j:hierarchy=default));
+} catch( Throwable t ) {
+log.info(Can't enable log4j mx);
}
for( int i=0; i wEnv.getHandlerCount(); i++ ) {
--
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 StandardContextMBean.java mbeans-descriptors.xml
amyroh 2002/06/06 15:36:47
Modified:catalina/src/share/org/apache/catalina/mbeans
MBeanUtils.java StandardContextMBean.java
mbeans-descriptors.xml
Log:
Add MBean support for JNDI resource and resource link under Context.
Revision ChangesPath
1.38 +82 -5
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.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- MBeanUtils.java 13 May 2002 18:25:47 - 1.37
+++ MBeanUtils.java 6 Jun 2002 22:36:47 - 1.38
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
1.37 2002/05/13 18:25:47 amyroh Exp $
- * $Revision: 1.37 $
- * $Date: 2002/05/13 18:25:47 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
1.38 2002/06/06 22:36:47 amyroh Exp $
+ * $Revision: 1.38 $
+ * $Date: 2002/06/06 22:36:47 $
*
*
*
@@ -102,6 +102,7 @@
import org.apache.catalina.core.StandardService;
import org.apache.catalina.deploy.ContextEnvironment;
import org.apache.catalina.deploy.ContextResource;
+import org.apache.catalina.deploy.ContextResourceLink;
import org.apache.catalina.deploy.NamingResources;
import org.apache.catalina.deploy.ResourceParams;
import org.apache.catalina.valves.ValveBase;
@@ -115,7 +116,7 @@
*
* @author Craig R. McClanahan
* @author Amy Roh
- * @version $Revision: 1.37 $ $Date: 2002/05/13 18:25:47 $
+ * @version $Revision: 1.38 $ $Date: 2002/06/06 22:36:47 $
*/
public class MBeanUtils {
@@ -317,6 +318,34 @@
return (mbean);
}
+
+
+/**
+ * Create, register, and return an MBean for this
+ * codeContextResourceLink/code object.
+ *
+ * @param resourceLink The ContextResourceLink to be managed
+ *
+ * @exception Exception if an MBean cannot be created or registered
+ */
+public static ModelMBean createMBean(ContextResourceLink resourceLink)
+throws Exception {
+
+String mname = createManagedName(resourceLink);
+ManagedBean managed = registry.findManagedBean(mname);
+if (managed == null) {
+Exception e = new Exception(ManagedBean is not found with +mname);
+throw new MBeanException(e);
+}
+String domain = managed.getDomain();
+if (domain == null)
+domain = mserver.getDefaultDomain();
+ModelMBean mbean = managed.createMBean(resourceLink);
+ObjectName oname = createObjectName(domain, resourceLink);
+mserver.registerMBean(mbean, oname);
+return (mbean);
+
+}
/**
@@ -901,7 +930,7 @@
/**
* Create an codeObjectName/code for this
- * codeService/code object.
+ * codeContextResource/code object.
*
* @param domain Domain in which this name is to be created
* @param resource The ContextResource to be named
@@ -920,6 +949,29 @@
return (name);
}
+
+
+ /**
+ * Create an codeObjectName/code for this
+ * codeContextResourceLink/code object.
+ *
+ * @param domain Domain in which this name is to be created
+ * @param resourceLink The ContextResourceLink to be named
+ *
+ * @exception MalformedObjectNameException if a name cannot be created
+ */
+public static ObjectName createObjectName(String domain,
+ ContextResourceLink resourceLink)
+throws MalformedObjectNameException {
+
+ObjectName name = null;
+String encodedResourceLinkName = encodeStr(resourceLink.getName());
+name = new ObjectName(domain + :type=ResourceLink,class= +
+ resourceLink.getType()+,name= +
+ encodedResourceLinkName);
+return (name);
+
+}
/**
@@ -1535,6 +1587,31 @@
mserver.unregisterMBean(oname);
}
+
+
+/**
+ * Deregister the MBean for this
+ * codeContextResourceLink/code object.
+ *
+ * @param resourceLink The ContextResourceLink to be managed
+ *
+ * @exception Exception if an MBean cannot be deregistered
+ */
+public static void destroyMBean(ContextResourceLink resourceLink)
+throws Exception {
+
+String mname = createManagedName(resourceLink);
+
DO NOT REPLY [Bug 8013] - DefaultServlet Throws NumberFormatException
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=8013. 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=8013 DefaultServlet Throws NumberFormatException --- Additional Comments From [EMAIL PROTECTED] 2002-06-07 00:01 --- Why can't the DefaultServlet just use the HttpServletRequest's getDateHeader() method and avoid this duplicate code? Then the multithreading issues are solved, because the request is only used by one thread! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common JkMX.java
costin 2002/06/06 17:24:24
Modified:jk/java/org/apache/jk/common JkMX.java
Log:
Support for JMX_RI. ( again, using jmx magic to avoid explicit dependencies )
Revision ChangesPath
1.3 +19 -1 jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkMX.java
Index: JkMX.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkMX.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JkMX.java 6 Jun 2002 22:21:04 - 1.2
+++ JkMX.java 7 Jun 2002 00:24:23 - 1.3
@@ -145,8 +145,25 @@
// starts the server
mserver.invoke(serverName, start, null, null);
+return;
} catch( Throwable t ) {
-log.error( Init error, t );
+log.error( Can't load the MX4J http adapter + t.toString() );
+}
+
+try {
+Class c=Class.forName( com.sun.jdmk.comm.HtmlAdaptorServer );
+Object o=c.newInstance();
+ObjectName serverName=new ObjectName(Adaptor:name=html,port= + port);
+log.info(Registering the JMX_RI html adapter + serverName);
+mserver.registerMBean(o, serverName);
+
+mserver.setAttribute(serverName,
+ new Attribute(Port, new Integer(port)));
+
+mserver.invoke(serverName, start, null, null);
+
+} catch( Throwable t ) {
+log.error( Can't load the JMX_RI http adapter + t.toString() );
}
}
public void init() throws IOException {
@@ -160,6 +177,7 @@
try {
Class c=Class.forName( org.apache.log4j.jmx.HierarchyDynamicMBean
);
Object o=c.newInstance();
+log.info(Registering the root hierarchy for JMX );
mserver.registerMBean(o, new ObjectName(log4j:hierarchy=default));
} catch( Throwable t ) {
log.info(Can't enable log4j mx);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9677] - JSP files not recompiled when newer
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=9677. 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=9677 JSP files not recompiled when newer --- Additional Comments From [EMAIL PROTECTED] 2002-06-07 00:37 --- Ok, I'll check that. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jsp compilation of nested custom tags (porting from weblogic 6 totomcat 4.0.3)
I assume that lOffset is a scripting variable defined either in a variable
element of a tld, or in a TagExtraInfo, and that its declaration (in the
generated java file) is a result of the compiler trying to do its
synchronization with the pagecontext attribute of the same name.
If so, what is the scope of this variable? Is it NESTED or AT_BEGIN?
I can see how the current Jasper implementation can be problematic,
There are two problems here.
First, if the scope is AT_BEGIN, then the scope of the variable should
remain defined until the end of the page, and the current implementation
actually make it unavailable after the end of the tag, which is wrong.
Second, if the tags are nested, as is your case here, then redclaring
it in the nested block would be illegal Java.
Can you file a bug report in bugzilla for this? It would help if you
can also include a small test case, so that fixes can be verified.
Thanks.
Date: Thu, 06 Jun 2002 18:54:11 -0400
From: Pete Gordon [EMAIL PROTECTED]
Subject: Re: Jsp compilation of nested custom tags (porting from weblogic 6 to
tomcat 4.0.3)
To: Tag Libraries Developers List [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
MIME-version: 1.0 (Apple Message framework v481)
Delivered-to: mailing list [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
X-Antivirus: nagoya (v4198 created Apr 24 2002)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
List-Post: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Unsubscribe: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
Thanks, Shawn.
Let me summarize for the tomcat-dev list. I have an existing
application with custom tags that runs on weblogic 6, when porting it
over to Tomcat I now am running into an error where the generated java
from a jsp with self nested tags will not compile, the code generated
from jspc simulates the HelloWorld sample below, which is not valid java
code--it would be valid in C, but that's another story.
The first htmlGlobalAttribSearch$jsp.java compile error is line 198,
variable lOffset is already defined. There are several (19) more errors
like this that are also outputed from trying to compile the $jsp.java
file that I have attached.
public class HelloWorld{
public static void main(String args[]){
do{
int i = 5;
do{
int i=10;
}while(false);
}while(false);
}
}
Tomorrow, I will try to create a minimal nested tag example and see if I
can duplicate the problem. Unless someone is aware of this problem
already, and can save me the effort.
Thanks,
Pete Gordon
On Thursday, June 6, 2002, at 03:03 PM, Shawn Bayern wrote:
Hi Pete,
If this is a Tomcat bug, it would be better to mail tomcat-dev about
it
or
to submit a Tomcat bug report in Apache's Bugzilla
(http://nagoya.apache.org/bugzilla). I'd be happy to take a look at
it
myself, but it's difficult to identify the problem in a large compiled
servlet. (I can't attempt to compile it myself since it depends on
some
custom classes not included.) If you could post the compilation
error,
that'd definitely help us determine whether it looks like a Tomcat bug
or
not.
From: Pete Gordon [EMAIL PROTECTED]
Date: Thu Jun 06, 2002 02:32:06 PM US/Eastern
To: 'Tag Libraries Developers List' [EMAIL PROTECTED]
Subject: Jsp compilation of nested custom tags (porting from weblogic 6
to tomcat 4.0.3)
Reply-To: Tag Libraries Developers List taglibs-
[EMAIL PROTECTED]
There is a problem with compiling the genenerated java code
(htmlGlobalAttribSearch$jsp.java) it tells me that variables have
already
been defined. I have compiled the source file and even created a test
HelloWorld.java to test it. It is correct variables have already been
defined, which we found strange as far as the scope variables were
accessible, see the code below
public class HelloWorld{
public static void main(String args[]){
do{
int i = 5;
do{
int i=10;
}while(false);
}while(false);
}
}
The JSP page has several nested custom tags (the same tags) and this is
working on weblogic 6. But the generated java file from tomcat/jasper
does
not compile. The problem is the fci:collection tag being nested a few
times within itself. See the JSP below. I think this is a problem with
the
jspc generated java code. Am I way off base?
Thanks,
Pete Gordon
%@ taglib uri=fciTagLib.tld prefix = fci %
%@ page import=com.fci.arch.service.*%
form action=fci:get resource=site/ method=GET id=form1
name=form1
input type=hidden name=action
value=catalogActions.globalParametric
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Protocol.java
remm2002/06/06 17:48:21
Modified:http11/src/java/org/apache/coyote/http11 Http11Protocol.java
Log:
- Add missing setKeytype method (should fix bug #9676).
Revision ChangesPath
1.15 +4 -0
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
Index: Http11Protocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Http11Protocol.java 5 Jun 2002 22:59:11 - 1.14
+++ Http11Protocol.java 7 Jun 2002 00:48:21 - 1.15
@@ -270,6 +270,10 @@
//setAttribute(keypass, k);
}
+public void setKeytype( String k ) {
+setAttribute(keystoreType, k);
+}
+
public void setClientauth( String k ) {
setAttribute(clientauth, k);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9676] - org.apache.coyote.tomcat4.CoyoteServerSocketFactory doesn't recognize keystoreType attribute
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=9676. 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=9676 org.apache.coyote.tomcat4.CoyoteServerSocketFactory doesn't recognize keystoreType attribute [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-06-07 01:11 --- This should be fixed now (there was an obvious bug setting the keystore type attribute). If you want to test it, you can try to build from CVS or wait for the next release. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8013] - DefaultServlet Throws NumberFormatException
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=8013. 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=8013 DefaultServlet Throws NumberFormatException [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|NEW -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: MX4J problems - important!
There is a very serious issue with MX4J1.0.b3, the method: javax.management.MBeanServerFactory.findMBeanServer() has the wrong signature ( returns List instead of ArrayList ). Remy - please, update to a more recent version ( CVS head seems to be fine ) for the next build (and for the distribution ). No problem :) Are the JARs you committed in j-t-c/lib ok ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8013] - DefaultServlet Throws NumberFormatException
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=8013.
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=8013
DefaultServlet Throws NumberFormatException
--- Additional Comments From [EMAIL PROTECTED] 2002-06-07 02:12 ---
I would recommend the following refactorings for the DefaultServlet class...
1. Use the extract method refactoring for each of the if checks in the
checkIfHeaders() method, resulting in the following four new helper methods.
private boolean checkIfMatch(HttpServletRequest request,
HttpServletResponse response,
ResourceInfo resourceInfo);
private boolean checkIfModifiedSince(HttpServletRequest request,
HttpServletResponse response,
ResourceInfo resourceInfo);
private boolean checkIfNoneMatch(HttpServletRequest request,
HttpServletResponse response,
ResourceInfo resourceInfo);
private boolean checkIfUnmodifiedSince(HttpServletRequest request,
HttpServletResponse response,
ResourceInfo resourceInfo);
Of course, these methods should rely on the HttpServletRequest.getDateHeader()
method where applicable, rather than performing their own date parsing, using
the static formats array.
2. The checkIfHeaders() method should contain the following logic...
protected boolean checkIfHeaders(HttpServletRequest request,
HttpServletResponse response,
ResourceInfo resourceInfo)
throws IOException {
return checkIfMatch(request, response, resourceInfo)
checkIfModifiedSince(request, response, resourceInfo)
checkIfNoneMatch(request, response, resourceInfo)
checkIfUnmodifiedSince(request, response, resourceInfo);
}
3. The static formats array should be removed, as they are not thread-safe.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9677] - JSP files not recompiled when newer
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=9677. 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=9677 JSP files not recompiled when newer [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-06-07 02:26 --- After testing with Tomcat 4.0.x from CVS, that works for me (modify a JSP from the examples webapp, and refresh). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: MX4J problems - important!
On Thu, 6 Jun 2002, Remy Maucherat wrote: There is a very serious issue with MX4J1.0.b3, the method: javax.management.MBeanServerFactory.findMBeanServer() has the wrong signature ( returns List instead of ArrayList ). Remy - please, update to a more recent version ( CVS head seems to be fine ) for the next build (and for the distribution ). No problem :) Are the JARs you committed in j-t-c/lib ok ? No, I'll check them in ( I did a build from CVS head, and it seems to work fine ). I'll also check in the commons-logging.jar and the -api This is also very important to fix - right now 4.1 will not allow apps to use commons-logging with log4j, I sent a mail this morning about this. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/lib mx4j.jar
costin 2002/06/06 20:38:15 Modified:lib mx4j.jar Log: Update to a more recent version of mx4j, the signature was bad. Revision ChangesPath 1.2 +1082 -878 jakarta-tomcat-connectors/lib/mx4j.jar Binary file -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/lib mx4j-tools.jar
costin 2002/06/06 20:43:43 Modified:lib mx4j-tools.jar Log: Add the tools ( needed to test and play ) Revision ChangesPath 1.2 +741 -660 jakarta-tomcat-connectors/lib/mx4j-tools.jar Binary file -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/lib commons-logging-api.jar commons-logging.jar
costin 2002/06/06 20:45:15 Modified:lib commons-logging.jar Added: lib commons-logging-api.jar Log: Update commons-logging and add the interface-only version ( required for tomcat3.3 and 4.1 common loader !) Revision ChangesPath 1.5 +44 -44jakarta-tomcat-connectors/lib/commons-logging.jar Binary file 1.1 jakarta-tomcat-connectors/lib/commons-logging-api.jar Binary file -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8013] - DefaultServlet Throws NumberFormatException
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=8013. 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=8013 DefaultServlet Throws NumberFormatException --- Additional Comments From [EMAIL PROTECTED] 2002-06-07 03:47 --- Created an attachment (id=2023) This should solve the problems we've seen... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 BUILDING.txt
remm2002/06/06 20:50:01
Modified:.BUILDING.txt
Log:
- Document the need for Ant 1.5 to build 4.1.x.
Revision ChangesPath
1.32 +7 -14 jakarta-tomcat-4.0/BUILDING.txt
Index: BUILDING.txt
===
RCS file: /home/cvs/jakarta-tomcat-4.0/BUILDING.txt,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- BUILDING.txt 29 May 2002 10:48:51 - 1.31
+++ BUILDING.txt 7 Jun 2002 03:50:01 - 1.32
@@ -1,4 +1,4 @@
-$Id: BUILDING.txt,v 1.31 2002/05/29 10:48:51 jfclere Exp $
+$Id: BUILDING.txt,v 1.32 2002/06/07 03:50:01 remm Exp $
Building The Tomcat 4.0 Servlet/JSP Container
@@ -27,30 +27,23 @@
(1) Download and Install the Ant Binary Distribution
NOTE: Previous versions of Tomcat 4.0 relied on Ant 1.3 for the build
-process. The 1.4 release is now required.
+process. The 1.5 release is now required.
-* Download a binary distribution of Ant 1.4 from:
+* Download a binary distribution of Ant 1.5 from:
-http://jakarta.apache.org/builds/jakarta-ant/release/v1.4/bin/
+http://jakarta.apache.org/builds/jakarta-ant/release/v1.5/bin/
On a Windows platform, you will need:
-jakarta-ant-1.4-bin.zip
-jakarta-ant-1.4-optional.jar
+jakarta-ant-1.5-bin.zip
On a Unix platform, you will need:
-jakarta-ant-1.4-bin.tar.gz
-jakarta-ant-1.4-optional.jar
+jakarta-ant-1.5-bin.tar.gz
* Unpack the binary distribution into a convenient location so that the
Ant release resides in its own directory (conventionally named
- jakarta-ant-1.4). For the purposes of the remainder of this document,
+ jakarta-ant-1.5). For the purposes of the remainder of this document,
the symbolic name ${ant.home} is used to refer to the full pathname of
the release directory.
-
-* Copy the file jakarta-ant-1.4-optional.jar, downloaded above, into
- the directory ${ant.home}/lib. This makes available several Ant
- extension commands that are commonly required when building Jakarta
- based projects.
* Modify the PATH environment variable to include directory
${ant.home}/bin in its list. This makes the ant command line script
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors gump.xml
costin 2002/06/06 21:07:11
Modified:.gump.xml
Log:
I hope this will make gump happy.
Revision ChangesPath
1.4 +3 -0 jakarta-tomcat-connectors/gump.xml
Index: gump.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/gump.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- gump.xml 5 Jun 2002 22:58:11 - 1.3
+++ gump.xml 7 Jun 2002 04:07:11 - 1.4
@@ -12,11 +12,14 @@
project name=jakarta-tomcat-util
packageorg.apache.tomcat.util/package
ant basedir=util
+ property name=jmx.home reference=home project=jmx/
+ property name=jmx.jar value=${jmx.home}/lib/jmxri.jar /
property name=jsse.home reference=home project=jsse/
/ant
depend project=jakarta-ant/
depend project=xml-xerces/
+depend project=jmx/
depend project=commons-logging/
depend project=jsse/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/lib commons-logging-api.jar commons-logging.jar
costin 2002/06/06 20:45:15 Modified:lib commons-logging.jar Added: lib commons-logging-api.jar Log: Update commons-logging and add the interface-only version ( required for tomcat3.3 and 4.1 common loader !) 3.3 and 4.1 have so much stuff in common now, it's scary ;-) So I put -api in common/lib and the other in server/lib ? And I also need log4j now I suppose, at least for the non JDK 1.4 build. Which version do you recommend ? The latest stable ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
