Re: Jakarta Collections 3.0?
Remy Maucherat wrote: Costin Manolache wrote: If I remember correctly ( and if it didn't change ), tomcat needs modeler in a parent classloader. Modeler has an optional dependency on digester, which depends on beanutils and collections. They both depend on logging, and modeler also depends on jmx. So unless some classloader trick is used - we have to have collections in the parent loader - which forces the entire tomcat instalation to use the same collection version ( unless reverse loader tricks are used ). That implies that if tomcat upgrades to collections3.0 - all webapps that use collections2.0 may stop working. Why ? I don't understand. Tomcat will override anything except the system classloader. You mean the classes in the common loader get overriden by the reverse loader ? Does it work if some classes are loaded with a loader ( for example some from the old package ) and some are loaded with the other loader ? I mean, can we force a loader for a particular package - blocking delegation completely ( even for classes that are not found ) ? Even more interesting - we don't actually have this choice - since if digester changes to the new collections, we're forced to do the same :-) What if we use modeler without digester ? Are there other components that depend on digester + collections ? At least for emebed this would be a good solution ( it won't reduce the size too much, but it may reduce the dependency impact it has when it's embeded - since whatever app it is emebeded into will be forced to update collections and all packages that depend on it - or do classloader tricks ) The startup code depends on digester :-( The web.xml parsing depends on digester. Etc, etc :-( I think some of it can be done in a separate loader ( I tried it at some time ), at least loading the web.xml part. For the startup code - I don't know ( but it could use ant or jmx ). I guess a lot has changed since I last looked, but packages like collections 3 in the top class loader makes me pretty uncomfortable. ( the real problem will be for apps that embed tomcat, when digester or other components will start using collection3 - forcing tomcat too ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Test [was: Re: The Mailing List Parrot.]
Quoting NormW [EMAIL PROTECTED]: Good morning All. There seems to be a bug on your mail server because every message I send gets echoed (good), along with two others from xAT.sci.de with the same topic field but reporting undelivered messages (bad). Since this effect only occurs off the Tomcat-dev list, can someone buy and/or run a virus scanner and/or learn how to use it please? Thanks, Norm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Test for bogus auto-reply responses due to all the idiots who have let themselves get infectedby the latest round of viruses. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test [was: Re: The Mailing List Parrot.]
Quoting Craig R. McClanahan [EMAIL PROTECTED]: Quoting NormW [EMAIL PROTECTED]: Good morning All. There seems to be a bug on your mail server because every message I send gets echoed (good), along with two others from xAT.sci.de with the same topic field but reporting undelivered messages (bad). Since this effect only occurs off the Tomcat-dev list, can someone buy and/or run a virus scanner and/or learn how to use it please? Thanks, Norm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Test for bogus auto-reply responses due to all the idiots who have let themselves get infectedby the latest round of viruses. Second test ... sorry for the noise, but I think I've weeded out the bogus auto-responders and need to double check. Craig McClanahan Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test [was: Re: The Mailing List Parrot.]
Hi Craig, Quoting Craig R. McClanahan [EMAIL PROTECTED]: Second test ... sorry for the noise, but I think I've weeded out the bogus auto-responders and need to double check. I found that almost all worms have 'localhost' or 'unknown' in the headers as sender; perhaps its a good idea to filter those too (I do - and its almost always spam or viruses)... Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Running Tomcat via commons-daemon (jsvc)
Hi, I have following question. I'm running tomcat on my linux box in chroot jail and via jsvc (to use other then root user). There is no way to directly specify the -server swicth of the underlaying JDK (Sun 1.4.1_05) via jsvc. Is this option automatically set or not? Thanks -- Ji Mare (mailto:[EMAIL PROTECTED]) SAD SVT Praha, s.r.o. (http://www.svt.cz) Czech Republic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_apr_socket.c
hgomez 2004/02/02 02:58:26
Modified:jk/native2/common jk_channel_apr_socket.c
Log:
Fix problem with port higher than 32K.
Should fix BR 17579.
Provided by NorW and Gunter Knauf
Revision ChangesPath
1.36 +4 -4
jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c
Index: jk_channel_apr_socket.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- jk_channel_apr_socket.c 29 Jan 2004 14:17:41 - 1.35
+++ jk_channel_apr_socket.c 2 Feb 2004 10:58:26 - 1.36
@@ -76,7 +76,7 @@
int ndelay;
apr_sockaddr_t *addr;
char *host;
-short port;
+apr_port_t port;
int keepalive;
int timeout;
};
@@ -92,7 +92,7 @@
*/
static int JK_METHOD jk2_channel_apr_resolve(jk_env_t *env, char *host,
-short port,
+apr_port_t port,
jk_channel_apr_private_t *rc);
static int JK_METHOD jk2_channel_apr_close(jk_env_t *env, jk_channel_t *_this,
@@ -168,7 +168,7 @@
jk_channel_apr_private_t *socketInfo=
(jk_channel_apr_private_t *)(ch-_privatePtr);
int rc;
-short port=socketInfo-port;
+apr_port_t port=socketInfo-port;
if( socketInfo-host==NULL ) {
char *localName=ch-mbean-localName;
@@ -227,7 +227,7 @@
/** private: resolve the address on init
*/
static int JK_METHOD jk2_channel_apr_resolve(jk_env_t *env,
- char *host, short port,
+ char *host, apr_port_t port,
jk_channel_apr_private_t *rc)
{
int err;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] ./native2/common/jk_channel_apr_socket.c - use apr_port_t instead of short for port
Commited, thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] ./jk/native2/STATUS.txt should show current version
http://www.gknw.com/test/STATUS.txt.diff --- ./jk/native2/STATUS.txt.origTue Oct 08 18:24:14 2002 +++ ./jk/native2/STATUS.txt Mon Feb 02 13:48:00 2004 @@ -1,9 +1,11 @@ JAKARTA TOMCAT CONNECTORS 2 (JK2) STATUS: -*-text-*- -Last modified at [$Date: 2002/10/08 15:00:18 $] +Last modified at [$Date: 2004/02/02 13:40:58 $] Release: -2.0.2 : in progress +2.0.4 : in progress +2.0.3 : not released +2.0.2 : released September 29, 2003 2.0.1 : released October 6, 2002 2.0.0 : released September 30, 2002 Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25055] - bypass of apache authentication
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=25055. 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=25055 bypass of apache authentication [EMAIL PROTECTED] changed: What|Removed |Added Summary|getRemoteUser() returns null|bypass of apache |- bypass of apache |authentication |authentication | --- Additional Comments From [EMAIL PROTECTED] 2004-02-02 13:10 --- I had 3 private emails the past week about this issue from people who have the same problem. I refered them to my comment from 2003-12-02 07:43. As this is a security issue, I think this bug is important enough to justify a comment in the release notes of mod_jk... I'm also changing the summary to reflect the real problem in this bug report and not the initial problem I had encountered - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] ./native2/common/jk_channel_apr_socket.c - use apr_port_t instead of short for port
Commited, thanks thanks, Henri! Do you know what's about the ./native2/common/jk_channel_socket.c file? Does soemone still use it since APR is now mandatory, or can we remove it? If it stays then we should also patch the port there to 'unsigned short'... Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Collections 3.0?
Howdy, FYI, it will be a while before BeanUtils (which is a dependency of Digester itself, so it's the blocker on this collections 3.0 migration) has a final release (it'll be BeanUtils 1.7) that depends on collections 3.0. The current BeanUtils dev version already builds fine against collections 3.0, however, and therefore it's possible to obtain snapshot builds. I started a thread to discuss the next BeanUtils release on the commons-dev mailing list, if anyone is interested -- I'll be helping out with that release. Yoav Shapira Millennium ChemInformatics -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Costin Manolache Sent: Monday, February 02, 2004 2:04 AM To: [EMAIL PROTECTED] Subject: Re: Jakarta Collections 3.0? Remy Maucherat wrote: Costin Manolache wrote: If I remember correctly ( and if it didn't change ), tomcat needs modeler in a parent classloader. Modeler has an optional dependency on digester, which depends on beanutils and collections. They both depend on logging, and modeler also depends on jmx. So unless some classloader trick is used - we have to have collections in the parent loader - which forces the entire tomcat instalation to use the same collection version ( unless reverse loader tricks are used ). That implies that if tomcat upgrades to collections3.0 - all webapps that use collections2.0 may stop working. Why ? I don't understand. Tomcat will override anything except the system classloader. You mean the classes in the common loader get overriden by the reverse loader ? Does it work if some classes are loaded with a loader ( for example some from the old package ) and some are loaded with the other loader ? I mean, can we force a loader for a particular package - blocking delegation completely ( even for classes that are not found ) ? Even more interesting - we don't actually have this choice - since if digester changes to the new collections, we're forced to do the same :-) What if we use modeler without digester ? Are there other components that depend on digester + collections ? At least for emebed this would be a good solution ( it won't reduce the size too much, but it may reduce the dependency impact it has when it's embeded - since whatever app it is emebeded into will be forced to update collections and all packages that depend on it - or do classloader tricks ) The startup code depends on digester :-( The web.xml parsing depends on digester. Etc, etc :-( I think some of it can be done in a separate loader ( I tried it at some time ), at least loading the web.xml part. For the startup code - I don't know ( but it could use ant or jmx ). I guess a lot has changed since I last looked, but packages like collections 3 in the top class loader makes me pretty uncomfortable. ( the real problem will be for apps that embed tomcat, when digester or other components will start using collection3 - forcing tomcat too ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Download servlet with resume
Hi all! I have been trying to find information on how to make a java-servlet for download of content from the Tomcat-server without success. The content differs from images, mp3's etc etc and I need the servlet in order to do some database-stuff. The content also differs very much in size and I need some way to be able to resume the download on big files as some of the clients communicating with the servlet are mobile phone useing GPRS, and as this is not the fastest communication and it might loose connection during download. Therefore I'll ask you if anyone has any information, links, samples etc to help me with this. Regards Patrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Load Balancing Problem...Urgent
Howdy, You might want to take a look at the balancer webapp that ships with tomcat 5. And please continue this discussion on the tomcat-user mailing list, not tomcat-dev. Thanks, Yoav Shapira Millennium ChemInformatics -Original Message- From: Nicholas Tham Soon Hing [mailto:[EMAIL PROTECTED] Sent: Saturday, January 31, 2004 12:39 PM To: [EMAIL PROTECTED] Subject: Load Balancing Problem...Urgent Hi, I'm an undergraduate student from Malaysia. I'm using Tomcat 4.1.27 to do a load balancing system. This system consists of several tomcat servers and one of them will be the load balancer. When a user accesses a url page, the load balancer will select a server to response to that request. The problem that I faced now is I don't know how to make the selected server to process the request from user browser. As I know the tomcat connector will assign the socket to processor to process it. So how can I send the request from load balancer connector to the connector in that selected server? What should I send (socket? Input stream? Or the request line? How to get these?)?After the selected server has finished the process, how can the server send back the response to load balancer and then the load balancer sends back to user? Can anyone help me on this? Or is there any one has done this before? Can someone show me the sample code for solving this problem? It's urgent. Your help is appreciated. Thanks, Nicholas Tham - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Download servlet with resume
Please follow up with tomcat-user since this is a user topic. What you'll want to look at is utilizing the Byte-Range header. it is a standard way for a client to get only part of a request. DefaultServlet has support for this so if you need some example code, look there. -Tim Patrik Andersson wrote: Hi all! I have been trying to find information on how to make a java-servlet for download of content from the Tomcat-server without success. The content differs from images, mp3's etc etc and I need the servlet in order to do some database-stuff. The content also differs very much in size and I need some way to be able to resume the download on big files as some of the clients communicating with the servlet are mobile phone useing GPRS, and as this is not the fastest communication and it might loose connection during download. Therefore I'll ask you if anyone has any information, links, samples etc to help me with this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 4.1.30 release vote
My first attempt to vote appears to have gotten lost in all the virus e-mails. Here is my +1. Larry -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 28, 2004 10:05 AM To: Tomcat Developers List Subject: [VOTE] 4.1.30 release vote Amidst all this junk email ... ballot Release 4.1.30 as Stable: [x] Yes [ ] No /ballot Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] ./jk/native2/common/jk_worker_status.c - avoid printing NULL
Hi,
since the increment of shm-head-lbVer is protected it should also be avoided to
print a potential NULL value:
http://www.gknw.com/test/jk_worker_status.c.diff
=
--- ./jk/native2/common/jk_worker_status.c.orig Fri Oct 31 00:15:04 2003
+++ ./jk/native2/common/jk_worker_status.c Mon Feb 02 17:47:48 2004
@@ -717,7 +717,7 @@
}
}
/* Create a top section - not used currently */
-s-jkprintf(env, s, MXAgent: mod_jk\n );
+s-jkprintf(env, s, MXAgent: mod_jk2\n );
s-jkprintf(env, s, \n );
for( i=0; i env-_objects-size( env, env-_objects ); i++ ) {
@@ -1004,9 +1004,12 @@
/* Update the scoreboard's version - all other
jk2 processes will see this and update
*/
-if( shm!=NULL shm-head!=NULL )
+if( shm!=NULL shm-head!=NULL ) {
shm-head-lbVer++;
-s-jkprintf(env, s, Updated config %d, shm-head-lbVer );
+s-jkprintf(env, s, Updated config version to %d\n, shm-head-lbVer );
+} else {
+s-jkprintf(env, s, Update detected. No scoreboard.\n );
+}
}
@@ -1017,9 +1020,12 @@
/* Update the scoreboard's version - all other
jk2 processes will see this and update
*/
-if( shm!=NULL shm-head!=NULL )
+if( shm!=NULL shm-head!=NULL ) {
shm-head-lbVer++;
-s-jkprintf(env, s, Updated config version to %d\n, shm-head-lbVer );
+s-jkprintf(env, s, Updated config version to %d\n, shm-head-lbVer );
+} else {
+s-jkprintf(env, s, Reload requested. No scoreboard.\n );
+}
return JK_OK;
}
Guenter.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] ./native2/common/jk_channel_apr_socket.c - use apr_port_t instead of short for port
Günter Knauf a écrit : Commited, thanks thanks, Henri! Do you know what's about the ./native2/common/jk_channel_socket.c file? Does soemone still use it since APR is now mandatory, or can we remove it? If it stays then we should also patch the port there to 'unsigned short'... Yes, it should be removed but the conservative approach will be to have a patch for unsigned short - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat-connectors distribution
martin grotzke a écrit : dear developers (again), please could you give me some hint why you do not respond? is this topic to be asked at the users list? it would be very kind to give some clarification, regards, martin On Tue, 2004-01-27 at 17:49, martin grotzke wrote: dear developers, the current version of the jakarta-tomcat-connectors jk2 is 2.0.2. moreover, the connectors are released together with the tomcat-src. what can be seen as the current stable one? i'm using the jpackage.org's mod_jk2-rpms, these are built with the connector-sources shipped with the latest tomcat-4.1 release. at jpackage, there's the question now if it would be better to provide an rpm built with the connectors shipped with the latest tomcat-release, or if it should be built with the connectors 2.0.2. what would you suggest? We'll try to provide a jk2 release soon : - We need to fix some little problems, but Gunter is providing many patches in such area. - We need a release manager and candidates are welcome :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] ./native2/common/jk_channel_apr_socket.c - use apr_port_t instead of short for port
Hi Henri,
Do you know what's about the ./native2/common/jk_channel_socket.c file?
Does soemone still use it since APR is now mandatory, or can we remove
it?
If it stays then we should also patch the port there to 'unsigned
short'...
Yes, it should be removed but the conservative approach will be to
have a patch for unsigned short
here we go:
http://www.gknw.com/test/jk_channel_socket.c.diff
# Patch to solve http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17579
#
--- ./jk/native2/common/jk_channel_socket.c.origThu Jan 29 18:23:28 2004
+++ ./jk/native2/common/jk_channel_socket.cMon Feb 02 18:19:28 2004
@@ -100,7 +100,7 @@
int ndelay;
struct sockaddr_in addr;
char *host;
-short port; /* Should be unsigned - big ports will fail */
+unsigned short port;
int keepalive;
int timeout;
};
@@ -116,7 +116,7 @@
*/
static int JK_METHOD jk2_channel_socket_resolve(jk_env_t *env, char *host,
- short port,
+ unsigned short port,
struct sockaddr_in *rc);
static int JK_METHOD jk2_channel_socket_close(jk_env_t *env, jk_channel_t *ch,
@@ -276,7 +276,8 @@
/** private: resolve the address on init
*/
-static int JK_METHOD jk2_channel_socket_resolve(jk_env_t *env, char *host, short port,
+static int JK_METHOD jk2_channel_socket_resolve(jk_env_t *env, char *host,
+ unsigned short port,
struct sockaddr_in *rc)
{
int x;
@@ -285,7 +286,7 @@
/* for now use the correct type, in_addr_t */
in_addr_t laddr;
-rc-sin_port = htons((short)port);
+rc-sin_port = htons((unsigned short)port);
rc-sin_family = AF_INET;
/* Check if we only have digits in the string */
Guenter.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 MapperListener.java
remm2004/02/02 09:35:47
Modified:catalina/src/share/org/apache/coyote/tomcat5
MapperListener.java
Log:
- Bug 26567: The mapper will complain if the default host is not known, which
could make mapping fail without a way to easily identify the cause. Initialization
will not fail, this is simply a warning message.
- (obviously, this class needs lang strings)
Revision ChangesPath
1.16 +5 -0
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/MapperListener.java
Index: MapperListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/MapperListener.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- MapperListener.java 26 Jan 2004 20:19:10 - 1.15
+++ MapperListener.java 2 Feb 2004 17:35:47 - 1.16
@@ -290,6 +290,11 @@
if ( ! mBeanServer.isRegistered(engineName)) return;
String defaultHost =
(String) mBeanServer.getAttribute(engineName, defaultHost);
+ObjectName hostName = new ObjectName
+(domain + :type=Host, + host= + defaultHost);
+if (!mBeanServer.isRegistered(hostName)) {
+log.warn(Unknown default host: + defaultHost);
+}
// This should probablt be called later
if( defaultHost != null ) {
mapper.setDefaultHostName(defaultHost);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26567] - defaultHost='' incorrect causes no error
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=26567. 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=26567 defaultHost='' incorrect causes no error [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-02 17:36 --- Fixed. A warning message will now be logged during initialization. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
mmanders2004/02/02 09:38:04
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Updated how we get the server port to work with APR 1.0 as well as previous
versions. Patch submitted by Guenter Knauf.
Revision ChangesPath
1.91 +2 -5 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.90
retrieving revision 1.91
diff -u -r1.90 -r1.91
--- mod_jk.c 5 Nov 2003 09:15:41 - 1.90
+++ mod_jk.c 2 Feb 2004 17:38:04 - 1.91
@@ -482,8 +482,6 @@
{
request_rec *r = private_data-r;
-apr_port_t port;
-
char *ssl_temp = NULL;
s-jvm_route= NULL;/* Used for sticky session routing */
@@ -518,8 +516,7 @@
s-server_name = (char *)ap_get_server_name(r);
/* get the real port (otherwise redirect failed) */
-apr_sockaddr_port_get(port,r-connection-local_addr);
-s-server_port = port;
+s-server_port = r-connection-local_addr-port;
/* XXX : à la jk2 ???*/
/* s-server_port = ap_get_server_port(r); */
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c
mmanders2004/02/02 09:59:56
Modified:jk/native2/common jk_channel_socket.c
Log:
Fix problem with port higher than 32K. Provided by Guenter Knauf. Fixed compile
problem for NetWare even though this isn't built for NetWare (or any other platform.)
Revision ChangesPath
1.62 +11 -5 jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c
Index: jk_channel_socket.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -r1.61 -r1.62
--- jk_channel_socket.c 29 Jan 2004 14:17:41 - 1.61
+++ jk_channel_socket.c 2 Feb 2004 17:59:56 - 1.62
@@ -100,7 +100,7 @@
int ndelay;
struct sockaddr_in addr;
char *host;
-short port; /* Should be unsigned - big ports will fail */
+unsigned short port;
int keepalive;
int timeout;
};
@@ -116,7 +116,7 @@
*/
static int JK_METHOD jk2_channel_socket_resolve(jk_env_t *env, char *host,
- short port,
+ unsigned short port,
struct sockaddr_in *rc);
static int JK_METHOD jk2_channel_socket_close(jk_env_t *env, jk_channel_t *ch,
@@ -276,16 +276,22 @@
/** private: resolve the address on init
*/
-static int JK_METHOD jk2_channel_socket_resolve(jk_env_t *env, char *host, short
port,
+static int JK_METHOD jk2_channel_socket_resolve(jk_env_t *env, char *host, unsigned
short port,
struct sockaddr_in *rc)
{
int x;
/* TODO: Should be updated for IPV6 support. */
-/* for now use the correct type, in_addr_t */
+/* for now use the correct type, in_addr_t */
+
+/* except on NetWare because of MetroWerks strictness */
+#ifdef NETWARE
+u_long laddr;
+#else
in_addr_t laddr;
+#endif
-rc-sin_port = htons((short)port);
+rc-sin_port = htons((unsigned short)port);
rc-sin_family = AF_INET;
/* Check if we only have digits in the string */
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] ./native2/common/jk_channel_apr_socket.c - use apr_port_t instead of short for port
Committed.
Mike Anderson
[EMAIL PROTECTED] 2/2/2004 10:29:26 AM
Hi Henri,
Do you know what's about the ./native2/common/jk_channel_socket.c
file?
Does soemone still use it since APR is now mandatory, or can we
remove
it?
If it stays then we should also patch the port there to 'unsigned
short'...
Yes, it should be removed but the conservative approach will be to
have a patch for unsigned short
here we go:
http://www.gknw.com/test/jk_channel_socket.c.diff
# Patch to solve
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17579
#
--- ./jk/native2/common/jk_channel_socket.c.origThu Jan 29 18:23:28
2004
+++ ./jk/native2/common/jk_channel_socket.cMon Feb 02 18:19:28 2004
@@ -100,7 +100,7 @@
int ndelay;
struct sockaddr_in addr;
char *host;
-short port; /* Should be unsigned - big ports will fail */
+unsigned short port;
int keepalive;
int timeout;
};
@@ -116,7 +116,7 @@
*/
static int JK_METHOD jk2_channel_socket_resolve(jk_env_t *env, char
*host,
- short port,
+ unsigned short port,
struct sockaddr_in
*rc);
static int JK_METHOD jk2_channel_socket_close(jk_env_t *env,
jk_channel_t *ch,
@@ -276,7 +276,8 @@
/** private: resolve the address on init
*/
-static int JK_METHOD jk2_channel_socket_resolve(jk_env_t *env, char
*host, short port,
+static int JK_METHOD jk2_channel_socket_resolve(jk_env_t *env, char
*host,
+ unsigned short port,
struct sockaddr_in
*rc)
{
int x;
@@ -285,7 +286,7 @@
/* for now use the correct type, in_addr_t */
in_addr_t laddr;
-rc-sin_port = htons((short)port);
+rc-sin_port = htons((unsigned short)port);
rc-sin_family = AF_INET;
/* Check if we only have digits in the string */
Guenter.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26507] - Jasper Generator java Error (useBean ObjectArray)
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=26507. 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=26507 Jasper Generator java Error (useBean ObjectArray) --- Additional Comments From [EMAIL PROTECTED] 2004-02-02 18:10 --- Tomcat 5.0.15 introduced the problem (rev 215 of Generator). I propose reverting the change, as the performance enhancement does not comply with the spec wording. What you are doing with your useBean is a hack, though. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
remm2004/02/02 10:18:01
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Revert useBean optimization done by Kin-Man, as it seems to violate the
spec wording (which basically says that an error should occur at runtime if the
class
is not a JavaBean).
- Bug 26507.
Revision ChangesPath
1.217 +31 -35
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.216
retrieving revision 1.217
diff -u -r1.216 -r1.217
--- Generator.java31 Jan 2004 01:56:28 - 1.216
+++ Generator.java2 Feb 2004 18:18:00 - 1.217
@@ -1261,41 +1261,37 @@
className =
attributeValue(beanName, false, String.class);
}
-out.printil(try {);
-out.pushIndent();
-out.printin(name);
-out.print( = ();
-out.print(type);
-out.print() java.beans.Beans.instantiate();
-out.print(this.getClass().getClassLoader(), );
-out.print(className);
-out.println(););
-out.popIndent();
-/*
- * Note: Beans.instantiate throws ClassNotFoundException
- * if the bean class is abstract.
- */
-out.printil(} catch (ClassNotFoundException exc) {);
-out.pushIndent();
-out.printil(
-throw new InstantiationException(exc.getMessage()););
-out.popIndent();
-out.printil(} catch (Exception exc) {);
-out.pushIndent();
-out.printin(throw new ServletException();
-out.print(\Cannot create bean of class \ + );
-out.print(className);
-out.println(, exc););
-out.popIndent();
-out.printil(}); // close of try
} else {
// Implies klass is not null
-// Generate codes to instantiate the bean class
-out.printin(name);
-out.print( = new );
-out.print(klass);
-out.println((););
+className = quote(klass);
}
+out.printil(try {);
+out.pushIndent();
+out.printin(name);
+out.print( = ();
+out.print(type);
+out.print() java.beans.Beans.instantiate();
+out.print(this.getClass().getClassLoader(), );
+out.print(className);
+out.println(););
+out.popIndent();
+/*
+ * Note: Beans.instantiate throws ClassNotFoundException
+ * if the bean class is abstract.
+ */
+out.printil(} catch (ClassNotFoundException exc) {);
+out.pushIndent();
+out.printil(
+throw new InstantiationException(exc.getMessage()););
+out.popIndent();
+out.printil(} catch (Exception exc) {);
+out.pushIndent();
+out.printin(throw new ServletException();
+out.print(\Cannot create bean of class \ + );
+out.print(className);
+out.println(, exc););
+out.popIndent();
+out.printil(}); // close of try
/*
* Set attribute for bean in the specified scope
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26507] - Jasper Generator java Error (useBean ObjectArray)
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=26507. 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=26507 Jasper Generator java Error (useBean ObjectArray) [EMAIL PROTECTED] changed: What|Removed |Added Severity|Enhancement |Normal Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-02 18:18 --- This is fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_status.c
mmanders2004/02/02 10:21:08
Modified:jk/native2/common jk_worker_status.c
Log:
Fix problem dereferencing a NULL value if shared memory/scoreboard information isn't
available. Patch provided by Guenter Knauf and NormW.
Revision ChangesPath
1.46 +11 -5 jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c
Index: jk_worker_status.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- jk_worker_status.c30 Oct 2003 20:08:36 - 1.45
+++ jk_worker_status.c2 Feb 2004 18:21:08 - 1.46
@@ -717,7 +717,7 @@
}
}
/* Create a top section - not used currently */
-s-jkprintf(env, s, MXAgent: mod_jk\n );
+s-jkprintf(env, s, MXAgent: mod_jk2\n );
s-jkprintf(env, s, \n );
for( i=0; i env-_objects-size( env, env-_objects ); i++ ) {
@@ -1004,9 +1004,12 @@
/* Update the scoreboard's version - all other
jk2 processes will see this and update
*/
-if( shm!=NULL shm-head!=NULL )
+if( shm!=NULL shm-head!=NULL ) {
shm-head-lbVer++;
-s-jkprintf(env, s, Updated config %d, shm-head-lbVer );
+s-jkprintf(env, s, Updated config version to %d\n, shm-head-lbVer
);
+} else {
+s-jkprintf(env, s, Update detected. No scoreboard.\n );
+}
}
@@ -1017,9 +1020,12 @@
/* Update the scoreboard's version - all other
jk2 processes will see this and update
*/
-if( shm!=NULL shm-head!=NULL )
+if( shm!=NULL shm-head!=NULL ) {
shm-head-lbVer++;
-s-jkprintf(env, s, Updated config version to %d\n, shm-head-lbVer );
+s-jkprintf(env, s, Updated config version to %d\n, shm-head-lbVer
);
+} else {
+s-jkprintf(env, s, Reload requested. No scoreboard.\n );
+}
return JK_OK;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 jk_service_apache2.c
mmanders2004/02/02 10:23:55
Modified:jk/native2/server/apache2 jk_service_apache2.c
Log:
Updated how we get the server port to work with APR 1.0 as well as previous
versions.Patch submitted by Guenter Knauf.
Revision ChangesPath
1.38 +2 -4
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c
Index: jk_service_apache2.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- jk_service_apache2.c 22 Jan 2004 09:19:55 - 1.37
+++ jk_service_apache2.c 2 Feb 2004 18:23:55 - 1.38
@@ -343,7 +343,6 @@
static int JK_METHOD jk2_init_ws_service(jk_env_t *env, jk_ws_service_t *s,
jk_worker_t *worker, void *serverObj)
{
-apr_port_t port;
char *ssl_temp = NULL;
jk_workerEnv_t *workerEnv;
request_rec *r=serverObj;
@@ -376,8 +375,7 @@
s-server_name= (char *)ap_get_server_name(r);
/* get the real port (otherwise redirect failed) */
-apr_sockaddr_port_get(port,r-connection-local_addr);
-s-server_port = port;
+s-server_port = r-connection-local_addr-port;
s-server_software = (char *)ap_get_server_version();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2 STATUS.txt
mmanders2004/02/02 10:24:54 Modified:jk/native2 STATUS.txt Log: Updated to reflect current status. Patch submitted by Guenter Knauf. Revision ChangesPath 1.3 +4 -2 jakarta-tomcat-connectors/jk/native2/STATUS.txt Index: STATUS.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/STATUS.txt,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- STATUS.txt8 Oct 2002 15:00:18 - 1.2 +++ STATUS.txt2 Feb 2004 18:24:54 - 1.3 @@ -3,7 +3,9 @@ Release: -2.0.2 : in progress +2.0.4 : in progress +2.0.3 : not released +2.0.2 : released Bivenber 27, 2002 2.0.1 : released October 6, 2002 2.0.0 : released September 30, 2002 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/webdav/WEB-INF web.xml
jfarcand2004/02/02 10:28:26
Modified:.build.properties.default
webapps/webdav/WEB-INF web.xml
Log:
- Update to Xerces 2.6.1
- Fix validation error.
Revision ChangesPath
1.118 +4 -4 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.117
retrieving revision 1.118
diff -u -r1.117 -r1.118
--- build.properties.default 15 Jan 2004 14:37:37 - 1.117
+++ build.properties.default 2 Feb 2004 18:28:26 - 1.118
@@ -130,12 +130,12 @@
regexp.loc=${base-jakarta.loc}/regexp/binaries/jakarta-regexp-1.3.tar.gz
-# - Xerces XML Parser, version 2.6.0 -
-xerces.home=${base.path}/xerces-2_6_0
+# - Xerces XML Parser, version 2.6.1 -
+xerces.home=${base.path}/xerces-2_6_1
xerces.lib=${xerces.home}
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
-xerces.loc=${base-xml.loc}/xerces-j/binaries/Xerces-J-bin.2.6.0.tar.gz
+xerces.loc=${base-xml.loc}/xerces-j/binaries/Xerces-J-bin.2.6.1.tar.gz
# --
1.3 +3 -1 jakarta-tomcat-catalina/webapps/webdav/WEB-INF/web.xml
Index: web.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/webdav/WEB-INF/web.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- web.xml 1 Feb 2004 23:18:15 - 1.2
+++ web.xml 2 Feb 2004 18:28:26 - 1.3
@@ -66,6 +66,8 @@
/security-role
--
- welcome-file-list /
+ welcome-file-list
+welcome-file/
+ /welcome-file-list
/web-app
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2 STATUS.txt
thanks a bunch for all commits, Mike!! but the month name you used I dont know yet: Bivenber ?? smile... Guenter. mmanders2004/02/02 10:24:54 Modified:jk/native2 STATUS.txt Log: Updated to reflect current status. Patch submitted by Guenter Knauf. Revision ChangesPath 1.3 +4 -2 jakarta-tomcat-connectors/jk/native2/STATUS.txt Index: STATUS.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/STATUS.txt,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- STATUS.txt 8 Oct 2002 15:00:18 - 1.2 +++ STATUS.txt 2 Feb 2004 18:24:54 - 1.3 @@ -3,7 +3,9 @@ Release: -2.0.2 : in progress +2.0.4 : in progress +2.0.3 : not released +2.0.2 : released Bivenber 27, 2002 2.0.1 : released October 6, 2002 2.0.0 : released September 30, 2002 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
-1.
Remy, please reread JSP 2.0 spec, p 1-101,1-102. Bullet .2 of the Semantics
section was added to allow for this kind of optimization. Bullet .5 and .6
will be executed ONLY IF the container choose not to issue translation errors.
-Kin-man
Date: Mon, 02 Feb 2004 18:18:01 +
From: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler
Generator.java
To: [EMAIL PROTECTED]
remm2004/02/02 10:18:01
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Revert useBean optimization done by Kin-Man, as it seems to violate the
spec wording (which basically says that an error should occur at runtime
if the class
is not a JavaBean).
- Bug 26507.
Revision ChangesPath
1.217 +31 -35
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.jav
a
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Gen
erator.java,v
retrieving revision 1.216
retrieving revision 1.217
diff -u -r1.216 -r1.217
--- Generator.java 31 Jan 2004 01:56:28 - 1.216
+++ Generator.java 2 Feb 2004 18:18:00 - 1.217
@@ -1261,41 +1261,37 @@
className =
attributeValue(beanName, false, String.class);
}
-out.printil(try {);
-out.pushIndent();
-out.printin(name);
-out.print( = ();
-out.print(type);
-out.print() java.beans.Beans.instantiate();
-out.print(this.getClass().getClassLoader(), );
-out.print(className);
-out.println(););
-out.popIndent();
-/*
- * Note: Beans.instantiate throws
ClassNotFoundException
- * if the bean class is abstract.
- */
-out.printil(} catch (ClassNotFoundException exc) {);
-out.pushIndent();
-out.printil(
-throw new
InstantiationException(exc.getMessage()););
-out.popIndent();
-out.printil(} catch (Exception exc) {);
-out.pushIndent();
-out.printin(throw new ServletException();
-out.print(\Cannot create bean of class \ + );
-out.print(className);
-out.println(, exc););
-out.popIndent();
-out.printil(}); // close of try
} else {
// Implies klass is not null
-// Generate codes to instantiate the bean class
-out.printin(name);
-out.print( = new );
-out.print(klass);
-out.println((););
+className = quote(klass);
}
+out.printil(try {);
+out.pushIndent();
+out.printin(name);
+out.print( = ();
+out.print(type);
+out.print() java.beans.Beans.instantiate();
+out.print(this.getClass().getClassLoader(), );
+out.print(className);
+out.println(););
+out.popIndent();
+/*
+ * Note: Beans.instantiate throws ClassNotFoundException
+ * if the bean class is abstract.
+ */
+out.printil(} catch (ClassNotFoundException exc) {);
+out.pushIndent();
+out.printil(
+throw new InstantiationException(exc.getMessage()););
+out.popIndent();
+out.printil(} catch (Exception exc) {);
+out.pushIndent();
+out.printin(throw new ServletException();
+out.print(\Cannot create bean of class \ + );
+out.print(className);
+out.println(, exc););
+out.popIndent();
+out.printil(}); // close of try
/*
* Set attribute for bean in the specified scope
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
DO NOT REPLY [Bug 26611] New: - Improper handling of javax.servlet.forward.request_uri during a forward and then an include
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=26611.
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=26611
Improper handling of javax.servlet.forward.request_uri during a forward and then an
include
Summary: Improper handling of javax.servlet.forward.request_uri
during a forward and then an include
Product: Tomcat 5
Version: 5.0.18
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Basically, it looks like javax.servlet.forward.request_uri is part of the
enumeration returned by request.getAttributeNames even though
request.getAttribute(javax.servlet.forward.request_uri) returns null. Here's a
simple test setup:
forward.jsp:
jsp:forward page=${param.forward}/
include.jsp:
%@ page contentType=text/plain %
jsp:include page=${param.include}/
process.jsp:
%@ page contentType=text/plain %
%@ page import=java.util.* %
%
ArrayList attrNames = Collections.list(request.getAttributeNames());
pageContext.setAttribute(include.request_uri.name,
Boolean.valueOf(attrNames.contains(javax.servlet.include.request_uri)));
pageContext.setAttribute(forward.request_uri.name,
Boolean.valueOf(attrNames.contains(javax.servlet.forward.request_uri)));
%
include.request_uri name: ${pageScope['include.request_uri.name']}
include.request_uri value: ${requestScope['javax.servlet.include.request_uri']}
forward.request_uri name: ${pageScope['forward.request_uri.name']}
forward.request_uri value: ${requestScope['javax.servlet.forward.request_uri']}
So, if you request:
forward.jsp?forward=include.jspinclude=process.jsp
You'll get the following:
include.request_uri name: true
include.request_uri value: /process.jsp
forward.request_uri name: true
forward.request_uri value:
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
Kin-Man Chung wrote: -1. Remy, please reread JSP 2.0 spec, p 1-101,1-102. Bullet .2 of the Semantics section was added to allow for this kind of optimization. Bullet .5 and .6 will be executed ONLY IF the container choose not to issue translation errors. I cannot really understand what the fragment really means, so I don't know. I had the impression that it implied that the error should be at runtime. I recommend the change is reverted as I did, as many users will likely make the same mistake, since the specification is impossible to understand (if you are right and your change indeed does not break the specification). This will also create compilation errors when upgrading from TC 4 to TC 5. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
Agreed that the spec can be clearer. :-) This has been discussed by the Spec expert group, and bullet .2 was added because some vendors wanted it. I'll check with the spec lead for a clarification. Also agreed that this breaks backward compatibility; but it not really too bad. I think a lot of users would rather have the error at compilation time than at runtime. What can you do with an instantiation error at runtime? If we are really concern about BC, then we can add another compilation option to revert to old behavior. I really don't like another switch, but if it'll make people happy... -Kin-man Date: Mon, 02 Feb 2004 19:41:54 +0100 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java To: Tomcat Developers List [EMAIL PROTECTED] Kin-Man Chung wrote: -1. Remy, please reread JSP 2.0 spec, p 1-101,1-102. Bullet .2 of the Semantics section was added to allow for this kind of optimization. Bullet .5 and .6 will be executed ONLY IF the container choose not to issue translation errors. I cannot really understand what the fragment really means, so I don't know. I had the impression that it implied that the error should be at runtime. I recommend the change is reverted as I did, as many users will likely make the same mistake, since the specification is impossible to understand (if you are right and your change indeed does not break the specification). This will also create compilation errors when upgrading from TC 4 to TC 5. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Collections 3.0?
Quoting Costin Manolache [EMAIL PROTECTED]: If I remember correctly ( and if it didn't change ), tomcat needs modeler in a parent classloader. Modeler has an optional dependency on digester, which depends on beanutils and collections. They both depend on logging, and modeler also depends on jmx. So unless some classloader trick is used - we have to have collections in the parent loader - which forces the entire tomcat instalation to use the same collection version ( unless reverse loader tricks are used ). That implies that if tomcat upgrades to collections3.0 - all webapps that use collections2.0 may stop working. Even more interesting - we don't actually have this choice - since if digester changes to the new collections, we're forced to do the same :-) What if we use modeler without digester ? Are there other components that depend on digester + collections ? At least for emebed this would be a good solution ( it won't reduce the size too much, but it may reduce the dependency impact it has when it's embeded - since whatever app it is emebeded into will be forced to update collections and all packages that depend on it - or do classloader tricks ) Subscribers to COMMONS-DEV will see that I'm proposing to remove the dependency on [collections] from both [beanutils] and [digester]. Both dependencies are very thin, and doing this will avoid penalizing [beanutils]/[digester] customers for what [collections] did. Costin Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
Kin-Man Chung wrote: Agreed that the spec can be clearer. :-) This has been discussed by the Spec expert group, and bullet .2 was added because some vendors wanted it. I'll check with the spec lead for a clarification. Ok. Also agreed that this breaks backward compatibility; but it not really too bad. I think a lot of users would rather have the error at compilation time than at runtime. What can you do with an instantiation error at runtime? Nothing, but some don't care: they never intended their page to be called without the right attribute in the right scope, so the case where their JavaBean is instantiated never happens. If we are really concern about BC, then we can add another compilation option to revert to old behavior. I really don't like another switch, but if it'll make people happy... No new switch, please ;) So we have to decide one or the other. So do you want me to revert the patch ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java
remm2004/02/02 11:38:39
Modified:catalina/src/share/org/apache/catalina/core
ApplicationHttpRequest.java
Log:
- Bug 26611: forward + include was hiding the special forward
request attributes.
Revision ChangesPath
1.17 +12 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java
Index: ApplicationHttpRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- ApplicationHttpRequest.java 26 Jan 2004 19:47:03 - 1.16
+++ ApplicationHttpRequest.java 2 Feb 2004 19:38:39 - 1.17
@@ -265,7 +265,14 @@
if (pos == -1) {
return getRequest().getAttribute(name);
} else {
-return specialAttributes[pos];
+if ((specialAttributes[pos] == null) (pos = 5)) {
+// If it's a forward special attribute, and null, it means this
+// is an include, so we check the wrapped request since
+// the request could have been forwarded before the include
+return getRequest().getAttribute(name);
+} else {
+return specialAttributes[pos];
+}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26611] - Improper handling of javax.servlet.forward.request_uri during a forward and then an include
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=26611. 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=26611 Improper handling of javax.servlet.forward.request_uri during a forward and then an include [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-02 19:39 --- Fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
Date: Mon, 02 Feb 2004 20:17:29 +0100 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java To: Tomcat Developers List [EMAIL PROTECTED] Kin-Man Chung wrote: Agreed that the spec can be clearer. :-) This has been discussed by the Spec expert group, and bullet .2 was added because some vendors wanted it. I'll check with the spec lead for a clarification. Ok. Also agreed that this breaks backward compatibility; but it not really too bad. I think a lot of users would rather have the error at compilation time than at runtime. What can you do with an instantiation error at runtime? Nothing, but some don't care: they never intended their page to be called without the right attribute in the right scope, so the case where their JavaBean is instantiated never happens. Then EL should be used in this case. If we are really concern about BC, then we can add another compilation option to revert to old behavior. I really don't like another switch, but if it'll make people happy... No new switch, please ;) So we have to decide one or the other. So do you want me to revert the patch ? I'd rather you check with me first before the patch, but since it is already done, let's wait for the spec clarification before we do anything. A revert on a revert would make us look really silly. :-) -Kin-man Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
Kin-Man Chung wrote: I'd rather you check with me first before the patch, but since it is already done, let's wait for the spec clarification before we do anything. A revert on a revert would make us look really silly. :-) This has been lying in BZ for a while, that's why I just patched. Ok, I'll wait to revert it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Converting Coyote to Java2 collections
Are there any big complaints if I convert Coyote to use Java2 collections ? (less sync) Or is the pure JDK 1.1 compatibility still a big plus ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13797] - Whitespace inserted in random location into the output stream
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=13797. 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=13797 Whitespace inserted in random location into the output stream [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-02 19:58 --- Do you still see this problem in the latest version of TC4? A quick search of bugzilla and the archives did not show up any other instances of this problem. For now, I am closing this as invalid. If you are able to reproduce it with TC4.1.30, please attach an appropriate test case and I will look into it. Note, the source files are much more useful than the final output. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java
remm2004/02/02 12:03:05
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
Log:
- Bug 25363: Expose the SSL attributes in getAttributeNames(). I do not see
getAttributeNames() as being performance critical (since we don't do any
stupid attribute merging in the RD anymore), so retrieving the SSL attrs if the
request is secure is just simpler. Other attibutes coming from the native layer
will not be exposed through the enumeration.
Revision ChangesPath
1.30 +7 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
Index: CoyoteRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- CoyoteRequest.java22 Jan 2004 18:22:24 - 1.29
+++ CoyoteRequest.java2 Feb 2004 20:03:05 - 1.30
@@ -987,6 +987,9 @@
* empty codeEnumeration/code if there are none.
*/
public Enumeration getAttributeNames() {
+if (isSecure()) {
+getAttribute(Globals.CERTIFICATES_ATTR);
+}
return new Enumerator(attributes.keySet(), true);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25363] - request.getAttributeNames() not working properly
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=25363. 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=25363 request.getAttributeNames() not working properly [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-02-02 20:05 --- The three standard SSL attributes will now be exposed through getAttributeNames even without calling getAttribute first. As a design decision, all other attributes coming from the native layer will not be exposed through getAttributeNames. Please do nt reopen this report. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7190] - GenericServlet spurious log's in init(), destroy()
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=7190. 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=7190 GenericServlet spurious log's in init(), destroy() [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-02 20:05 --- This was fixed in June 2002. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26475] - JAASRealms behave different in Tomcat 5.x then Tomcat 4.x
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=26475. 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=26475 JAASRealms behave different in Tomcat 5.x then Tomcat 4.x [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-02 20:08 --- As there has been no activity, and I think the classloading behavior is the right one, I am closing this bug. Please use tomcat-user if you are still experiencing problems. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2 STATUS.txt
mmanders2004/02/02 12:12:07 Modified:jk/native2 STATUS.txt Log: Fixed fat fingers. Read then commit. Thanks Guenter. Revision ChangesPath 1.4 +2 -2 jakarta-tomcat-connectors/jk/native2/STATUS.txt Index: STATUS.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/STATUS.txt,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- STATUS.txt2 Feb 2004 18:24:54 - 1.3 +++ STATUS.txt2 Feb 2004 20:12:07 - 1.4 @@ -5,7 +5,7 @@ 2.0.4 : in progress 2.0.3 : not released -2.0.2 : released Bivenber 27, 2002 +2.0.2 : released November 27, 2002 2.0.1 : released October 6, 2002 2.0.0 : released September 30, 2002 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13797] - Whitespace inserted in random location into the output stream
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=13797. 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=13797 Whitespace inserted in random location into the output stream [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2004-02-02 20:16 --- I logged this bug over a year ago against tomcat 4.0.4. I haven't had these problems with any tomcat 4.1.x versions, so I am sure that it somehow got resolved on its own. Thanks, Dave Cherkassky - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Converting Coyote to Java2 collections
no complaints here :) just be careful of those ConcurrentModificationException(s) that are lurking in the iterators :-) Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Monday, February 02, 2004 11:54 AM To: Tomcat Developers List Subject: Converting Coyote to Java2 collections Are there any big complaints if I convert Coyote to use Java2 collections ? (less sync) Or is the pure JDK 1.1 compatibility still a big plus ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Converting Coyote to Java2 collections
I suppose that Coyote can be optional for TC 3.3. I'm a bit less comfortable on using them in o.a.t.u (since that would force a Java2 requirement on 3.3). - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, February 02, 2004 11:54 AM Subject: Converting Coyote to Java2 collections Are there any big complaints if I convert Coyote to use Java2 collections ? (less sync) Or is the pure JDK 1.1 compatibility still a big plus ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17579] - port in jk_channel_socket_private should be int instead of short
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=17579. 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=17579 port in jk_channel_socket_private should be int instead of short [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-02 20:36 --- solved with cvs checkin from 2004-Feb-02. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Converting Coyote to Java2 collections
Bill Barker wrote: I suppose that Coyote can be optional for TC 3.3. I'm a bit less comfortable on using them in o.a.t.u (since that would force a Java2 requirement on 3.3). The thing which was annoying me the most was the attributes Hashtable in the request. I think util is using mostly custom structures for GC and speed. There's also deprecated stuff in util (logging, etc). Should this also be left in for compatibility ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Converting Coyote to Java2 collections
If you want to move o.a.t.u.log back to j-t, I've got no objection. I don't think that anybody is using o.a.t.u.handler. - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, February 02, 2004 1:03 PM Subject: Re: Converting Coyote to Java2 collections Bill Barker wrote: I suppose that Coyote can be optional for TC 3.3. I'm a bit less comfortable on using them in o.a.t.u (since that would force a Java2 requirement on 3.3). The thing which was annoying me the most was the attributes Hashtable in the request. I think util is using mostly custom structures for GC and speed. There's also deprecated stuff in util (logging, etc). Should this also be left in for compatibility ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JspC bug: Was this ever fixed?
I've been running into a problem where JspC cannot seem to handle pages that use packaged taglibs, as added in the JSP 1.2 spec. Since the 1.2 spec has been out for quite some time now (!), it seems odd that that is not supported (and in the RI at that, although I realise the spec doesn't exactly cover Ant tasks ;). I dredged the archives, and this problem seems to have been known about for around a year and a half. See: http://marc.theaimsgroup.com/?l=tomcat-userm=102894543325768w=2 I have seen many people asking the question, but no real answer, other than Kris's workaround that requires treating packaged taglibs as if they were not packaged taglibs, which seems counter to the whole point, really. Thoughts, anyone? -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat-connectors distribution
On Mon, 2004-02-02 at 18:16, Henri Gomez wrote: at jpackage, there's the question now if it would be better to provide an rpm built with the connectors shipped with the latest tomcat-release, or if it should be built with the connectors 2.0.2. what would you suggest? We'll try to provide a jk2 release soon : - We need to fix some little problems, but Gunter is providing many patches in such area. great! i appreciate this very much, it will clarify the situation at jpackage, too. an open issue is if jpackage should build from the released connectors or those provided with the tomcat-sources. suggestions? - We need a release manager and candidates are welcome :) well, i'd really like to do such job, but i suppose the release manager should know what gets released - i would not - d'oh ,-) so hopefully anybody will volunteer to manage this... cheers, martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs class-loader-howto.xml
markt 2004/02/02 13:39:28 Modified:webapps/docs class-loader-howto.xml Log: - Fix 13805. Update docs to show that the shared directory is relative to CATALINA_BASE not CATALINA_HOME. - Reported by Michael Eriksson. Revision ChangesPath 1.9 +6 -6 jakarta-tomcat-catalina/webapps/docs/class-loader-howto.xml Index: class-loader-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/class-loader-howto.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- class-loader-howto.xml1 Feb 2004 22:43:21 - 1.8 +++ class-loader-howto.xml2 Feb 2004 21:39:28 - 1.9 @@ -27,9 +27,9 @@ application archive./li liFor classes and resources that must be shared across all web applications, place unpacked classes and resources under -code$CATALINA_HOME/shared/classes/code, or place JAR files +code$CATALINA_BASE/shared/classes/code, or place JAR files containing those classes and resources under -code$CATALINA_HOME/shared/lib/code./li +code$CATALINA_BASE/shared/lib/code./li /ul /section @@ -172,8 +172,8 @@ web applications (unless Tomcat internal classes also need access, in which case you should put them in the strongCommon/strong class loader instead). All unpacked classes and resources in -code$CATALINA_HOME/shared/classes/code, as well as classes and -resources in JAR files under code$CATALINA_HOME/shared/lib/code, are +code$CATALINA_BASE/shared/classes/code, as well as classes and +resources in JAR files under code$CATALINA_BASE/shared/lib/code, are made visible through this class loader. If multiple Tomcat instances are run from the same binary using the $CATALINA_BASE environment variable, then this classloader repositories are relative to $CATALINA_BASE rather @@ -220,8 +220,8 @@ liem$CATALINA_HOME/common/classes/em/li liem$CATALINA_HOME/common/endorsed/*.jar/em/li liem$CATALINA_HOME/common/lib/*.jar/em/li -liem$CATALINA_HOME/shared/classes/em/li -liem$CATALINA_HOME/shared/lib/*.jar/em/li +liem$CATALINA_BASE/shared/classes/em/li +liem$CATALINA_BASE/shared/lib/*.jar/em/li /ul /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs class-loader-howto.xml
markt 2004/02/02 13:40:31 Modified:webapps/tomcat-docs class-loader-howto.xml Log: - Fix 13805. Update docs to show that the shared directory is relative to CATALINA_BASE not CATALINA_HOME. - Reported by Michael Eriksson. Revision ChangesPath 1.13 +5 -5 jakarta-tomcat-4.0/webapps/tomcat-docs/class-loader-howto.xml Index: class-loader-howto.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/class-loader-howto.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- class-loader-howto.xml1 Feb 2004 22:43:59 - 1.12 +++ class-loader-howto.xml2 Feb 2004 21:40:31 - 1.13 @@ -29,7 +29,7 @@ place unpacked classes and resources under code$CATALINA_HOME/shared/classes/code, or place JAR files containing those classes and resources under -code$CATALINA_HOME/shared/lib/code./li +code$CATALINA_BASE/shared/lib/code./li /ul /section @@ -166,8 +166,8 @@ web applications (unless Tomcat internal classes also need access, in which case you should put them in the strongCommon/strong class loader instead). All unpacked classes and resources in -code$CATALINA_HOME/shared/classes/code, as well as classes and -resources in JAR files under code$CATALINA_HOME/shared/lib/code, +code$CATALINA_BASE/shared/classes/code, as well as classes and +resources in JAR files under code$CATALINA_BASE/shared/lib/code, are made visible through this class loader. By default, that includes the following: ul @@ -208,8 +208,8 @@ liem$CATALINA_HOME/common/classes/em/li liem$CATALINA_HOME/common/endorsed/*.jar/em/li liem$CATALINA_HOME/common/lib/*.jar/em/li -liem$CATALINA_HOME/shared/classes/em/li -liem$CATALINA_HOME/shared/lib/*.jar/em/li +liem$CATALINA_BASE/shared/classes/em/li +liem$CATALINA_BASE/shared/lib/*.jar/em/li /ul /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13805] - Code and HOW-TO disagrees about shared classes.
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=13805. 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=13805 Code and HOW-TO disagrees about shared classes. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-02 21:41 --- Fixed in CVS will be included in the next release of TC4. Also fixed in TC5. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.dsp
mmanders2004/02/02 13:58:55 Modified:jk/native2/server/apache2 mod_jk2.dsp Log: Removed obsolete files. Patch from Guenter Knauf. Revision ChangesPath 1.7 +0 -12 jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.dsp Index: mod_jk2.dsp === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.dsp,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- mod_jk2.dsp 22 Oct 2002 11:56:42 - 1.6 +++ mod_jk2.dsp 2 Feb 2004 21:58:55 - 1.7 @@ -109,10 +109,6 @@ # End Source File # Begin Source File -SOURCE=..\..\common\jk_channel_socket.c -# End Source File -# Begin Source File - SOURCE=..\..\common\jk_channel_un.c # End Source File # Begin Source File @@ -185,15 +181,7 @@ # End Source File # Begin Source File -SOURCE=..\..\common\jk_nwmain.c -# End Source File -# Begin Source File - SOURCE=..\..\common\jk_objCache.c -# End Source File -# Begin Source File - -SOURCE=..\..\common\jk_pool.c # End Source File # Begin Source File - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
test
test Warning: antivirus system report There was a file infected with a virus in this message. The file readme.zip was removed by the antivirus system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
Hi Kin-Man,
I'm just about to look into this. I'll try to have an answer for you by
tonight.
- Mark
Kin-Man Chung wrote:
-1.
Remy, please reread JSP 2.0 spec, p 1-101,1-102. Bullet .2 of the Semantics
section was added to allow for this kind of optimization. Bullet .5 and .6
will be executed ONLY IF the container choose not to issue translation errors.
-Kin-man
Date: Mon, 02 Feb 2004 18:18:01 +
From: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler
Generator.java
To: [EMAIL PROTECTED]
remm2004/02/02 10:18:01
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Revert useBean optimization done by Kin-Man, as it seems to violate the
spec wording (which basically says that an error should occur at runtime
if the class
is not a JavaBean).
- Bug 26507.
Revision ChangesPath
1.217 +31 -35
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.jav
a
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Gen
erator.java,v
retrieving revision 1.216
retrieving revision 1.217
diff -u -r1.216 -r1.217
--- Generator.java 31 Jan 2004 01:56:28 - 1.216
+++ Generator.java 2 Feb 2004 18:18:00 - 1.217
@@ -1261,41 +1261,37 @@
className =
attributeValue(beanName, false, String.class);
}
-out.printil(try {);
-out.pushIndent();
-out.printin(name);
-out.print( = ();
-out.print(type);
-out.print() java.beans.Beans.instantiate();
-out.print(this.getClass().getClassLoader(), );
-out.print(className);
-out.println(););
-out.popIndent();
-/*
- * Note: Beans.instantiate throws
ClassNotFoundException
- * if the bean class is abstract.
- */
-out.printil(} catch (ClassNotFoundException exc) {);
-out.pushIndent();
-out.printil(
-throw new
InstantiationException(exc.getMessage()););
-out.popIndent();
-out.printil(} catch (Exception exc) {);
-out.pushIndent();
-out.printin(throw new ServletException();
-out.print(\Cannot create bean of class \ + );
-out.print(className);
-out.println(, exc););
-out.popIndent();
-out.printil(}); // close of try
} else {
// Implies klass is not null
-// Generate codes to instantiate the bean class
-out.printin(name);
-out.print( = new );
-out.print(klass);
-out.println((););
+className = quote(klass);
}
+out.printil(try {);
+out.pushIndent();
+out.printin(name);
+out.print( = ();
+out.print(type);
+out.print() java.beans.Beans.instantiate();
+out.print(this.getClass().getClassLoader(), );
+out.print(className);
+out.println(););
+out.popIndent();
+/*
+ * Note: Beans.instantiate throws ClassNotFoundException
+ * if the bean class is abstract.
+ */
+out.printil(} catch (ClassNotFoundException exc) {);
+out.pushIndent();
+out.printil(
+throw new InstantiationException(exc.getMessage()););
+out.popIndent();
+out.printil(} catch (Exception exc) {);
+out.pushIndent();
+out.printin(throw new ServletException();
+out.print(\Cannot create bean of class \ + );
+out.print(className);
+out.println(, exc););
+out.popIndent();
+out.printil(}); // close of try
/*
* Set attribute for bean in the specified scope
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
luehe 2004/02/02 15:08:29
Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Log:
Expose handshake failure as error, so it gets logged unconditionally
Revision ChangesPath
1.34 +4 -4
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
Index: PoolTcpEndpoint.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- PoolTcpEndpoint.java 26 Jan 2004 19:49:18 - 1.33
+++ PoolTcpEndpoint.java 2 Feb 2004 23:08:29 - 1.34
@@ -633,7 +633,7 @@
}
} catch (Throwable t) {
if (step == 2) {
-PoolTcpEndpoint.log.debug(Handshake failed, t);
+PoolTcpEndpoint.log.error(Handshake failed, t);
} else {
PoolTcpEndpoint.log.error(Unexpected error, t);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
Okay, I took a look at the patch and the bug report and I think I know what's going on now. Please let me know if I do not understand the scenario correctly. It seems there are some JSP 1.2 pages that misuse jsp:useBean by doing one of the following: 1. The class attribute is used for a Java type that cannot be instantiated as a JavaBean. 2. Type or class specifies a type that cannot be found. There are some cases where pages can get away with (1) if the container decides to flag this as a runtime error. These pages are invalid but the container never calls them on it because the objects already exist in some scope. This is probably less likely with (2), but still possible (e.g. if the jsp:useBean never gets executed at all). It would be nice to get a translation error in this case so that you realize your page is invalid. However, the JSP 1.2 specification (on which Tomcat 4.x is based) does not allow for a translation error - it requires that a runtime exception must be thrown. In JSP 2.0 (on which Tomcat 5.x is based), a number of JSP container vendors complained about this and wanted the freedom to throw a translation error in this case. Doing so is better for the page author (since they know up front their page is invalid) and better for the container (since doing a 'new' is MUCH more efficient than doing a call to Beans.instantiate()). So, we added a provision to allow containers to optionally produce a translation error on these invalid pages. One unfortunate side-effect is that some pages that used to compile in Tomcat 4 will no longer compile in Tomcat 5. But it's important to realize that these pages are invalid in both specs. It's just that Tomcat 4 was not allowed to cause an error at translation time. It had to wait until runtime to do so. So where does this leave us with respect to this patch? Tomcat 5 is free to exhibit either behavior. It can throw a translation error or a runtime error for these invalid pages. In my opinion, it is much better for both the page author and the container if we produce a translation-time error. The page author knows their page is invalid right away (without having to exercise the code path), and the container can gain the performance benefits associated with doing a 'new' call directly (instead of Beans.instantiate()). So it's your call, but if I had a vote I'd say stick with Kin-Man's patch. Hope this helps. --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. Remy Maucherat wrote: Kin-Man Chung wrote: Agreed that the spec can be clearer. :-) This has been discussed by the Spec expert group, and bullet .2 was added because some vendors wanted it. I'll check with the spec lead for a clarification. Ok. Also agreed that this breaks backward compatibility; but it not really too bad. I think a lot of users would rather have the error at compilation time than at runtime. What can you do with an instantiation error at runtime? Nothing, but some don't care: they never intended their page to be called without the right attribute in the right scope, so the case where their JavaBean is instantiated never happens. If we are really concern about BC, then we can add another compilation option to revert to old behavior. I really don't like another switch, but if it'll make people happy... No new switch, please ;) So we have to decide one or the other. So do you want me to revert the patch ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26622] New: - WebappClassLoader is inconsistent on delegation of resource loading
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=26622. 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=26622 WebappClassLoader is inconsistent on delegation of resource loading Summary: WebappClassLoader is inconsistent on delegation of resource loading Product: Tomcat 5 Version: 5.0.18 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The servlet specification recommends (Section 9.7.2) that containers be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs. Catalina implements this such that, when the delegate property is set to false (which is the default), WebappClassLoader will look locally first for the loadClass() and getResource() methods. However, WebappClassLoader does *not* override the getResources() method inherited from the URLClassLoader base class -- so getResources() behaves as if the delegate property is always true. This causes problems for applications that have a resource defined in both the parent and webapp class loaders. From the descriptions of getResource() and getResources() in the ClassLoader javadocs, and from the servlet spec statement above, it is natural to expect that the first URL returned by getResources(), for a given resource name, will be the one retrieved if you call getResource() with that same resource name. This assumption is satisfied if the delegate property is set to true, but is *not* satisfied when the delegate property is set to false. This behavior is more problematic than it might otherwise be, because false is the default setting. The recommended solution is to override the getResources() method in WebappClassLoader. If delegate is set to true, return the concatentation of calling getParent().getResources() followed by the list of matching resources in the webapp class loader. If delegate is false, however, concatenation order should be reversed. Note that this problem exists in Tomcat 4.1 as well. However, because that version is primarily in maintenance mode now, I did not bother to submit a separate bug report for it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@lsd]: jakarta-tomcat-connectors/jakarta-tomcat-jk-native failed
Project: jakarta-tomcat-jk-native
State: Failed
URL:
http://lsd.student.utwente.nl/gump/jakarta-tomcat-connectors/jakarta-tomcat-jk-native.html
- G U M P Y
Annotations:
- Error - Failed with reason build failed
- G U M P Y
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 5 seconds
Command Line: java -Djava.awt.headless=true
-Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar
org.apache.tools.ant.Main -Dbuild.clonevm=true
-Dgump.merge=/data/gump/gump/work/merge.xml -Dbuild.sysclasspath=only main
[Working Directory: /data/gump/jakarta-tomcat-connectors/jk/native]
-
Buildfile: build.xml
init:
[echo] /home/ajack
[mkdir] Created dir: /data/gump/jakarta-tomcat-connectors/jk/build/jk
[echo] linux=true solaris=${solaris} win32=${win32} hpux=${hpux}
netware=${netware}
apache20:
apache13:
iis:
netscape:
jni:
[mkdir] Created dir: /data/gump/jakarta-tomcat-connectors/jk/build/jk/jni
[so] Compiling 4 out of 4
Compiling /data/gump/jakarta-tomcat-connectors/jk/native/common/jk_map.c
[so] Compile failed 1
/data/gump/jakarta-tomcat-connectors/jk/native/common/jk_map.c
[so] Command:libtool --mode=compile cc -c -o
/data/gump/jakarta-tomcat-connectors/jk/build/jk/jni/common/jk_map.o
-I/data/gump/jakarta-tomcat-connectors/jk/native/common
-I/data/gump/jakarta-tomcat-connectors/jk/native/jni
-I/usr/java/j2sdk1.4.2/jre/../include -I${build.compiler.base}/include
-I/usr/java/j2sdk1.4.2/jre/../include/linux -g -W
/data/gump/jakarta-tomcat-connectors/jk/native/common/jk_map.c
[so] Output:
[so] libtool: compile: unable to infer tagged configuration
[so] StdErr:
[so] libtool: compile: specify a tag with `--tag'
BUILD FAILED
/data/gump/jakarta-tomcat-connectors/jk/native/build.xml:82: Compile failed
/data/gump/jakarta-tomcat-connectors/jk/native/common/jk_map.c
Total time: 3 seconds
-
- G U M P Y
RSS:
http://lsd.student.utwente.nl/gump/jakarta-tomcat-connectors/jakarta-tomcat-jk-native.rss
| Atom:
http://lsd.student.utwente.nl/gump/jakarta-tomcat-connectors/jakarta-tomcat-jk-native.atom
--
Gump http://jakarta.apache.org/gump
[lsd]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@lsd]: jakarta-tomcat-connectors/jakarta-tomcat-jk-native2 failed
Project: jakarta-tomcat-jk-native2
State: Failed
URL:
http://lsd.student.utwente.nl/gump/jakarta-tomcat-connectors/jakarta-tomcat-jk-native2.html
- G U M P Y
Annotations:
- Error - Failed with reason build failed
- G U M P Y
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native2 (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 4 seconds
Command Line: java -Djava.awt.headless=true
-Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar
org.apache.tools.ant.Main -Dbuild.clonevm=true
-Dgump.merge=/data/gump/gump/work/merge.xml -Dbuild.sysclasspath=only main
[Working Directory: /data/gump/jakarta-tomcat-connectors/jk/native2]
-
Buildfile: build.xml
init.taskdef:
guess.os:
[echo] build.properties i386.Linux
[echo] Linux:true Win32:${win32} Netware:${netware} Solaris:${solaris}
HPUX:${hpux}
init.win32.properties:
init.win32.mc:
init.win32:
init.netware:
init.os:
guess.server:
[echo] Apache2
/data/gump/jakarta-tomcat-connectors/jk/native2/${env.APACHE2_HOME} ${apache2.detect}
[echo] Apache13 /usr true
[echo] IIS ${iis.home} ${iis.detect}
[echo] Iplanet ${iplanet.home} ${iplanet.detect}
[echo] AOLserver ${aolserver.home} ${aolserver.detect}
[echo] JNI ${build.jni}
init:
[mkdir] Created dir: /data/gump/jakarta-tomcat-connectors/jk/build/jk2
apache20:
apache13:
[mkdir] Created dir: /data/gump/jakarta-tomcat-connectors/jk/build/jk2/apache13
[so] Compiling 39 out of 39
Compiling /data/gump/jakarta-tomcat-connectors/jk/native2/common/jk_channel.c
[so] Compile failed 1
/data/gump/jakarta-tomcat-connectors/jk/native2/common/jk_channel.c
[so] Command:libtool --mode=compile cc -c -o
/data/gump/jakarta-tomcat-connectors/jk/build/jk2/apache13/common/jk_channel.o
-I/data/gump/jakarta-tomcat-connectors/jk/native2/include
-I/data/gump/jakarta-tomcat-connectors/jk/native2/common
-I${build.compiler.base}/include -I/usr/include -I/usr/include/apache
-I/data/gump/jakarta-tomcat-connectors/jk/native2/include
-I/usr/java/j2sdk1.4.2/jre/../include -I/usr/java/j2sdk1.4.2/jre/../include/linux -g
-W -DEAPI -D_REENTRANT -DCHUNK_SIZE=4096 -DHAVE_MMAP
/data/gump/jakarta-tomcat-connectors/jk/native2/common/jk_channel.c
[so] Output:
[so] libtool: compile: unable to infer tagged configuration
[so] StdErr:
[so] libtool: compile: specify a tag with `--tag'
BUILD FAILED
/data/gump/jakarta-tomcat-connectors/jk/native2/build.xml:519: Compile failed
/data/gump/jakarta-tomcat-connectors/jk/native2/common/jk_channel.c
Total time: 3 seconds
-
- G U M P Y
RSS:
http://lsd.student.utwente.nl/gump/jakarta-tomcat-connectors/jakarta-tomcat-jk-native2.rss
| Atom:
http://lsd.student.utwente.nl/gump/jakarta-tomcat-connectors/jakarta-tomcat-jk-native2.atom
--
Gump http://jakarta.apache.org/gump
[lsd]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@lsd]: jakarta-tomcat-5/jakarta-tomcat-5 failed
Project: jakarta-tomcat-5 State: Failed URL: http://lsd.student.utwente.nl/gump/jakarta-tomcat-5/jakarta-tomcat-5.html - G U M P Y Annotations: - Error - Failed with reason build failed - G U M P Y Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 38 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar:/data/gump/xml-xalan/java/build/xalan-unbundled.jar:/data/gump/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dbuild.clonevm=true -Dgump.merge=/data/gump/gump/work/merge.xml -Dbuild.sysclasspath=only -Dtomcat33.home=*Unset* -Djsp-api.jar=/data/gump/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar -Djndi.jar=/data/gump/opt/jndi1_2_1/lib/jndi.jar -Dcommons-launcher.jar=/data/gump/jakarta-commons/launcher/dist/bin/commons-launcher.jar -Dcommons-collections.jar=/data/gump/jakarta-commons/collections/build/commons-collections-20040203.jar -Djmx.jar=/data/gump/opt/jmx-1_2-ri/lib/jmxri.jar -Dactivation.home=/data/gump/opt/jaf-1.0.1 -Djmx.home=/data/gump/opt/jmx-1_2-ri -Dcommons-modeler.home=/data/gump/jakarta-commons/modeler -Djmx-tools.jar=/data/gump/opt/jmx-1_2-ri/lib/jmxtools.jar -Dregexp.jar=/data/gump/jakarta-regexp/build/jakarta-regexp-20040203.jar -Djasper.home=/data/gump/jakarta-tomcat-jasper_tc5/jasper2 -Dant.home=/data/gump/ant/dist -DxmlParserAPIs.jar=/data/gump/xml-xerces2/java/build/xercesImpl.jar -Djdbc20ext.jar=/data/gump/opt/jdbc2_0/jdbc2_0-stdext.jar -Dsite2.home=/data/gump/jakarta-site2 -Dcommons-daemon.jsvc.tar.gz=/data/gump/jakarta-commons/daemon/dist/bin/jsvc.tar.gz -Dldap.jar=/data/gump/opt/ldap-1_2_4/lib/ldap.jar -Dregexp.home=/data/gump/jakarta-regexp/build -Dcommons-beanutils.jar=/data/gump/jakarta-commons/beanutils/dist/commons-beanutils.jar -DxercesImpl.jar=/data/gump/xml-xerces2/java/build/xercesImpl.jar -Djsse.home=/data/gump/opt/jsse1.0.3 -Dcommons-pool.jar=/data/gump/jakarta-commons/pool/dist/commons-pool.jar -Dmail.home=/data/gump/opt/javamail-1.3 -Djndi.home=/data/gump/opt/jndi1_2_1 -Djaas.jar=/data/gump/opt/jaas1_0/lib/jaas.jar -Dtomcat-coyote.home=/data/gump/jakarta-tomcat-connectors/coyote -Dcommons-daemon.jar=/data/gump/jakarta-commons/daemon/dist/commons-daemon-20040203.jar -Dcommons-dbcp.jar=/data/gump/jakarta-commons/dbcp/dist/commons-dbcp.jar -Dtomcat-util.jar=/data/gump/jakarta-tomcat-connectors/util/build/lib/tomcat-util.jar -Dservlet-api.jar=/data/gump/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar -Dcommons-logging-api.jar=/data/gump/jakarta-commons/logging/dist/commons-logging-api.jar -Dcommons-fileupload.jar=/data/gump/jakarta-commons/fileupload/target/commons-fileupload-20040203.jar -Dcommons-modeler.jar=/data/gump/jakarta-commons/modeler/dist/commons-modeler.jar -Dcommons-logging.jar=/data/gump/jakarta-commons/logging/dist/commons-logging.jar -Dcommons-el.jar=/data/gump/jakarta-commons/el/dist/commons-el.jar -Dcommons-digester.jar=/data/gump/jakarta-commons/digester/dist/commons-digester.jar -Dmail.jar=/data/gump/opt/javamail-1.3/mail.jar -Djta.jar=/data/gump/opt/jta-spec1_0_1/jta-spec1_0_1.jar -Dactivation.jar=/data/gump/opt/jaf-1.0.1/activation.jar gumpy-build [Working Directory: /data/gump/jakarta-tomcat-5] - deploy-prepare: [mkdir] Created dir: /data/gump/jakarta-tomcat-5/build/server/classes build-catalina-core: [javac] Compiling 324 source files to /data/gump/jakarta-tomcat-5/build/classes [javac] /data/gump/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/RequestFacade.java:266: cannot resolve symbol [javac] symbol : method getRemotePort () [javac] location: interface javax.servlet.ServletRequest [javac] return request.getRemotePort(); [javac] ^ [javac] /data/gump/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/RequestFacade.java:275: cannot resolve symbol [javac] symbol : method getLocalName () [javac] location: interface javax.servlet.ServletRequest [javac] return request.getLocalName(); [javac] ^ [javac] /data/gump/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/RequestFacade.java:283: cannot resolve symbol [javac] symbol : method getLocalAddr () [javac] location: interface javax.servlet.ServletRequest [javac] return request.getLocalAddr(); [javac] ^ [javac] /data/gump/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/RequestFacade.java:292: cannot resolve symbol [javac] symbol : method getLocalPort () [javac] location: interface javax.servlet.ServletRequest [javac] return
