DO NOT REPLY [Bug 27461] - Ant DeployTask throws UnknownHostException with j2sdk1.4.2
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=27461. 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=27461 Ant DeployTask throws UnknownHostException with j2sdk1.4.2 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 08:09 --- This works for me (using JDK 1.4.2). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 27461] -
This account does not exist - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Realm / GenericPrincipal class not serializable (With SecurityManager)
Hi,
Thanks too.
Florent.
Jeanfrancois Arcand wrote:
Fixed.
Thanks
-- Jeanfrancois
Jeanfrancois Arcand wrote:
Florent BENOIT wrote:
Hi all,
I'm working with Tomcat 5.0.19 and with a SecurityManager and I have
a problem with an attribute which is not Serializable.
The class which is not serializable is the class GenericPrincipal
from the package org.apache.catalina.realm.
Note that I use an embedded version of Tomcat but i don't think the
problem come from this. I will explain the problem :
I log into my application, then I do some actions. After this, I
remove the application. and I have this trace (full stack at the end
of the mail).
2004-03-04 15:57:44,646 : StandardManager.stop : Stopping
2004-03-04 15:57:44,648 : StandardManager.doUnload : Unloading
persisted sessions
2004-03-04 15:57:44,649 : StandardManager.doUnload : Saving
persisted sessions to SESSIONS.ser
2004-03-04 15:57:44,650 : StandardManager.doUnload : Unloading 1
sessions
2004-03-04 15:57:44,680 : ManagerBase.log : Cannot serialize session
attribute javax.security.auth.subject for session
E3EC3F36C2ECD4AF76D7ADC0D2533BEF
java.io.NotSerializableException:
org.apache.catalina.realm.GenericPrincipal
For example, in the class org.apache.coyote.tomcat5.CoyoteRequest,
there is a method :
public void setUserPrincipal(Principal principal) {
If the SecurityManager is set, the Principal is added to the session :
if (System.getSecurityManager() != null){
[...]
subject = new Subject();
subject.getPrincipals().add(principal); [...]
if (session != null){
session.setAttribute(Globals.SUBJECT_ATTR, subject);
}
}
The problem is that the principal object is not Serializable (Class
org.apache.catalina.realm.GenericPrincipal).
And some attributes of GenericPrincipallike the realm may not be
Serializable too.
As I'm implementing my own realm, I can define a Principal
implementation which is Serializable But it will be fine if I can
use GenericPrincipal implementation if it is a serializable object.
Hi,
yes, it seems to be a bug. This particular attribute should not get
serialized. I will take a look latter today.
Thanks
-- Jeanfrancois
Regards,
Florent
Full stack trace :
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:12004-03-04
15:57:44,646 : StandardManager.stop : Stopping
2004-03-04 15:57:44,648 : StandardManager.doUnload : Unloading
persisted sessions
2004-03-04 15:57:44,649 : StandardManager.doUnload : Saving
persisted sessions to SESSIONS.ser
2004-03-04 15:57:44,650 : StandardManager.doUnload : Unloading 1
sessions
2004-03-04 15:57:44,680 : ManagerBase.log : Cannot serialize session
attribute javax.security.auth.subject for session
E3EC3F36C2ECD4AF76D7ADC0D2533BEF
java.io.NotSerializableException:
org.apache.catalina.realm.GenericPrincipal.java:1054)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at java.util.LinkedList.writeObject(LinkedList.java:685)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:809)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1296)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.access$100(ObjectOutputStream.java:122)
at
java.io.ObjectOutputStream$PutFieldImpl.writeFields(ObjectOutputStream.java:1475)
at
java.io.ObjectOutputStream.writeFields(ObjectOutputStream.java:405)
at
javax.security.auth.Subject$SecureSet.writeObject(Subject.java:1288)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:809)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1296)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:367)
at javax.security.auth.Subject.writeObject(Subject.java:910)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apach e2 mod_jk2.c
Glenn Nielsen wrote: On Thu, Mar 04, 2004 at 05:49:21PM +0100, jean-frederic clere wrote: jean-frederic clere wrote: [EMAIL PROTECTED] wrote: jfclere 2004/03/03 09:55:32 Modified:jk/native2/server/apache2 mod_jk2.c Log: Remove jk2_translate... It is still not 100% OK: - LocationMatch does not work. - Some _not_found ends in Tomcat when using mod_dav. That is still not OK. I will go on later. Sorry :-( Now it looks better. The only thing I have removed is the logic for mod_dir Tomcat will do it if needed. Does that mean that Tomcat would have to resovlve identification of the directory index file? Yes. It would be nice to keep this on the apache side when someone uses Alias or JkAutoAlias to serve static pages, fourwarding and DirectoryIndex files which are *.jsp to Tomcat of course. That is easy to put back the logic ;-) Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apach e2 mod_jk2.c
jean-frederic clere wrote: Glenn Nielsen wrote: On Thu, Mar 04, 2004 at 05:49:21PM +0100, jean-frederic clere wrote: jean-frederic clere wrote: [EMAIL PROTECTED] wrote: jfclere 2004/03/03 09:55:32 Modified:jk/native2/server/apache2 mod_jk2.c Log: Remove jk2_translate... It is still not 100% OK: - LocationMatch does not work. - Some _not_found ends in Tomcat when using mod_dav. That is still not OK. I will go on later. Sorry :-( Now it looks better. The only thing I have removed is the logic for mod_dir Tomcat will do it if needed. Does that mean that Tomcat would have to resovlve identification of the directory index file? Yes. It would be nice to keep this on the apache side when someone uses Alias or JkAutoAlias to serve static pages, fourwarding and DirectoryIndex files which are *.jsp to Tomcat of course. That is easy to put back the logic ;-) Will we back port the jk2 modification to jk ? BTW, the jk2 2.0.4 should be delayed at least one week again but it's worth the wait... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
unknown
ok - 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 CoyoteReader.java
remm2004/03/05 05:02:30
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteReader.java
Log:
- Fix for bug 27447. Hopefully. This bugfix is very regression friendly. Hopefully
I'm not making any mistake.
- Pos should be reset in case of a long line (of course), and reset/skip is
useless (it is allowed to just put another mark).
Revision ChangesPath
1.3 +1 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteReader.java
Index: CoyoteReader.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteReader.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- CoyoteReader.java 27 Feb 2004 14:58:53 - 1.2
+++ CoyoteReader.java 5 Mar 2004 13:02:30 - 1.3
@@ -158,8 +158,7 @@
aggregator = new StringBuffer();
}
aggregator.append(lineBuffer);
-reset();
-skip(MAX_LINE_LENGTH);
+pos = 0;
} else {
reset();
skip(skip);
-
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 InputBuffer.java
remm2004/03/05 05:04:24
Modified:catalina/src/share/org/apache/coyote/tomcat5
InputBuffer.java
Log:
- Fix mark/reset functionality.
- It is valid to reset more than once.
- If the buffer was grown, discard and reallocate (mark can make the buffer
grow a lot, which is a valid use case).
- If the buffer is empty when marking, reinit it (to avoid it growing more than it
should).
Revision ChangesPath
1.5 +21 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/InputBuffer.java
Index: InputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/InputBuffer.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- InputBuffer.java 27 Feb 2004 14:58:53 - 1.4
+++ InputBuffer.java 5 Mar 2004 13:04:24 - 1.5
@@ -139,6 +139,12 @@
private int markPos = -1;
+/**
+ * Buffer size.
+ */
+private int size = -1;
+
+
// --- Constructors
@@ -159,6 +165,7 @@
*/
public InputBuffer(int size) {
+this.size = size;
bb = new ByteChunk(size);
bb.setLimit(size);
bb.setByteInputChannel(this);
@@ -208,7 +215,15 @@
bytesRead = 0;
charsRead = 0;
-cb.recycle();
+// If usage of mark made the buffer too big, reallocate it
+if (cb.getChars().length size) {
+cb = new CharChunk(size);
+cb.setLimit(size);
+cb.setCharInputChannel(this);
+cb.setCharOutputChannel(this);
+} else {
+cb.recycle();
+}
markPos = -1;
bb.recycle();
closed = false;
@@ -406,7 +421,11 @@
public void mark(int readAheadLimit)
throws IOException {
-cb.setLimit(cb.getEnd() + readAheadLimit);
+if (cb.getLength() = 0) {
+cb.setOffset(0);
+cb.setEnd(0);
+}
+cb.setLimit(cb.getStart() + readAheadLimit);
markPos = cb.getStart();
}
@@ -420,7 +439,6 @@
throw new IOException();
} else {
cb.setOffset(markPos);
-markPos = -1;
}
} else {
bb.recycle();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf ByteChunk.java
remm2004/03/05 05:06:13
Modified:util/java/org/apache/tomcat/util/buf ByteChunk.java
Log:
- In makeSpace, we should compare the desiredSpace to the limit, so that
we actually allow enough. Otherwise, the amount would be slower, violating
the makeSpace assertion.
- This doesn't fix anything for ByteChunk as AFAIK start is (almost ?) always 0
for growable buffers.
Revision ChangesPath
1.18 +2 -2
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/ByteChunk.java
Index: ByteChunk.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/ByteChunk.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- ByteChunk.java24 Feb 2004 08:50:06 - 1.17
+++ ByteChunk.java5 Mar 2004 13:06:13 - 1.18
@@ -406,8 +406,8 @@
// Can't grow above the limit
if( limit 0
- desiredSize limit -start ) {
- desiredSize=limit -start;
+ desiredSize limit) {
+ desiredSize=limit;
}
if( buff==null ) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf CharChunk.java
remm2004/03/05 05:08:00
Modified:util/java/org/apache/tomcat/util/buf CharChunk.java
Log:
- Same fix.
- Make calls to realReads compatible with marking (which is just for cleaness,
as the parameters are not used in our use case).
- Make makeSpace compatible with marking, which needs to be supported
by char chunks.
Revision ChangesPath
1.12 +8 -9
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/CharChunk.java
Index: CharChunk.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/CharChunk.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- CharChunk.java24 Feb 2004 08:50:06 - 1.11
+++ CharChunk.java5 Mar 2004 13:08:00 - 1.12
@@ -261,6 +261,7 @@
// makeSpace will grow the buffer to the limit,
// so we have space
System.arraycopy( src, off, buff, end, len );
+
end+=len;
return;
}
@@ -368,7 +369,7 @@
if ((end - start) == 0) {
if (in == null)
return -1;
-int n = in.realReadChars(buff, 0, buff.length);
+int n = in.realReadChars(buff, end, buff.length - end);
if (n 0)
return -1;
}
@@ -383,7 +384,7 @@
if ((end - start) == 0) {
if (in == null)
return -1;
-int n = in.realReadChars( buff, 0, buff.length );
+int n = in.realReadChars( buff, end, buff.length - end);
if (n 0)
return -1;
}
@@ -401,7 +402,7 @@
if ((end - start) == 0) {
if (in == null)
return -1;
-int n = in.realReadChars( buff, 0, buff.length );
+int n = in.realReadChars( buff, end, buff.length - end);
if (n 0)
return -1;
}
@@ -441,8 +442,8 @@
// Can't grow above the limit
if( limit 0
- desiredSize limit -start ) {
- desiredSize=limit-start;
+ desiredSize limit) {
+ desiredSize=limit;
}
if( buff==null ) {
@@ -452,7 +453,7 @@
// limit buf.length ( the buffer is already big )
// or we already have space XXX
- if( desiredSize = buff.length ) {
+ if( desiredSize = buff.length) {
return;
}
// grow in larger chunks
@@ -468,11 +469,9 @@
tmp=new char[newSize];
}
- System.arraycopy(buff, start, tmp, 0, end-start);
+ System.arraycopy(buff, start, tmp, start, end-start);
buff = tmp;
tmp = null;
- end=end-start;
- start=0;
}
// Conversion and getters
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27447] - CoyoteReader.readLine() read ahead problems
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=27447. 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=27447 CoyoteReader.readLine() read ahead problems [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 13:09 --- The bug is likely fixed, but this could cause regressions. Please test it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf CharChunk.java
[EMAIL PROTECTED] wrote: remm2004/03/05 05:08:00 Modified:util/java/org/apache/tomcat/util/buf CharChunk.java Log: - Same fix. - Make calls to realReads compatible with marking (which is just for cleaness, as the parameters are not used in our use case). - Make makeSpace compatible with marking, which needs to be supported by char chunks. I hope I didn't break anything with these changes ... Maybe it would be a good idea to tag 3.3.x before these, to be safe. Of course, it should only impact char buffers which are allowed to grow significantly, which aren't used a lot (AFAIK). In Tomcat 5, I believe we play with setLimit dynamically only for char input. Please test it :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16113] - removing then replacing a jsp page continues to give a 404
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=16113.
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=16113
removing then replacing a jsp page continues to give a 404
--- Additional Comments From [EMAIL PROTECTED] 2004-03-05 13:26 ---
Simply compare JspRuntimeContext.checkCompile(), this calls
ctxt.incrementRemoved() if a FileNotFoundException occur. JspServletWrapper
only set a 404 if a FileNotFoundException occur and finish.
Code from JspRuntineContext:
synchronized(jsw) {
try {
ctxt.compile();
} catch (FileNotFoundException ex) {
ctxt.incrementRemoved();
} catch (Throwable t) {
jsw.getServletContext().log(Background compile failed,
t);
}
}
Code from JspServletWrapper:
} catch (FileNotFoundException ex) {
String includeRequestUri = (String)
request.getAttribute(javax.servlet.include.request_uri);
if (includeRequestUri != null) {
// This file was included. Throw an exception as
// a response.sendError() will be ignored by the
// servlet engine.
throw new ServletException(ex);
} else {
try {
response.sendError(HttpServletResponse.SC_NOT_FOUND,
ex.getMessage());
} catch (IllegalStateException ise) {
log.error(Localizer.getMessage(jsp.error.file.not.found,
ex.getMessage()),
ex);
}
add a simple ctxt.incrementRemoved in catch block and test case works.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16113] - removing then replacing a jsp page continues to give a 404
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=16113.
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=16113
removing then replacing a jsp page continues to give a 404
--- Additional Comments From [EMAIL PROTECTED] 2004-03-05 13:39 ---
Another solution : in JspServletWrapper, line 343, before sending
HttpServletResponse.SC_NOT_FOUND, remove wrapper from collection of previously
created wrapper :
Code from JspServletWrapper:
} catch (FileNotFoundException ex) {
String includeRequestUri = (String)
request.getAttribute(javax.servlet.include.request_uri);
if (includeRequestUri != null) {
// This file was included. Throw an exception as
// a response.sendError() will be ignored by the
// servlet engine.
throw new ServletException(ex);
} else {
try {
// BELOW 1 LINE PROPOSED FOR THIS BUG
ctxt.getRuntimeContext().removeWrapper(jspUri);
response.sendError(HttpServletResponse.SC_NOT_FOUND,
ex.getMessage());
} catch (IllegalStateException ise) {
log.error(Localizer.getMessage(jsp.error.file.not.found,
ex.getMessage()),
ex);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16113] - removing then replacing a jsp page continues to give a 404
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=16113.
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=16113
removing then replacing a jsp page continues to give a 404
--- Additional Comments From [EMAIL PROTECTED] 2004-03-05 13:44 ---
using incrementRemoved() is cleaner, it removes wrapper and java-/class-file.
Code from JspCompilationContext:
// Removal
public void incrementRemoved() {
if (removed 1) {
jspCompiler.removeGeneratedFiles();
if( rctxt != null )
rctxt.removeWrapper(jspUri);
}
removed++;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16113] - removing then replacing a jsp page continues to give a 404
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=16113. 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=16113 removing then replacing a jsp page continues to give a 404 --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 13:50 --- OK, I agree. What's happen now? I suppose this patch must be validated and voted by Tomcat commiters. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16113] - removing then replacing a jsp page continues to give a 404
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=16113.
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=16113
removing then replacing a jsp page continues to give a 404
--- Additional Comments From [EMAIL PROTECTED] 2004-03-05 13:56 ---
Example for fixed code
JspServletWrapper:
} catch (FileNotFoundException ex) {
String includeRequestUri = (String)
request.getAttribute(javax.servlet.include.request_uri);
ctxt.incrementRemoved()
if (includeRequestUri != null) {
// This file was included. Throw an exception as
// a response.sendError() will be ignored by the
// servlet engine.
throw new ServletException(ex);
} else {
try {
response.sendError(HttpServletResponse.SC_NOT_FOUND,
ex.getMessage());
} catch (IllegalStateException ise) {
log.error(Localizer.getMessage(jsp.error.file.not.found,
ex.getMessage()),
ex);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apach e2 mod_jk2.c
Henri Gomez wrote: jean-frederic clere wrote: Glenn Nielsen wrote: On Thu, Mar 04, 2004 at 05:49:21PM +0100, jean-frederic clere wrote: jean-frederic clere wrote: [EMAIL PROTECTED] wrote: jfclere 2004/03/03 09:55:32 Modified:jk/native2/server/apache2 mod_jk2.c Log: Remove jk2_translate... It is still not 100% OK: - LocationMatch does not work. - Some _not_found ends in Tomcat when using mod_dav. That is still not OK. I will go on later. Sorry :-( Now it looks better. The only thing I have removed is the logic for mod_dir Tomcat will do it if needed. Does that mean that Tomcat would have to resovlve identification of the directory index file? Yes. It would be nice to keep this on the apache side when someone uses Alias or JkAutoAlias to serve static pages, fourwarding and DirectoryIndex files which are *.jsp to Tomcat of course. That is easy to put back the logic ;-) Will we back port the jk2 modification to jk ? After releasing jk2 ;-) BTW: I am still not happy with PR 21546: JkSet uri:domain/*.jsp.group ajp13:worker If domain is host/context that will work if it is host/ it won't because *.jsp will be mapped by jk2_map_to_storage. Ideas? BTW, the jk2 2.0.4 should be delayed at least one week again but it's worth the wait... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
DO NOT REPLY [Bug 16113] - removing then replacing a jsp page continues to give a 404
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=16113. 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=16113 removing then replacing a jsp page continues to give a 404 --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 14:19 --- oh, you reminder JspServletWrapper/JspCompilationContext in your reminder, read the discussion on tomcat-user currently. i agree with Q. Bordeaux. some live-enviroment requires jasper background compilation or development enabled. some not, use precompile instead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf CharChunk.java
From: Remy Maucherat [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: remm2004/03/05 05:08:00 Modified:util/java/org/apache/tomcat/util/buf CharChunk.java Log: - Same fix. - Make calls to realReads compatible with marking (which is just for cleaness, as the parameters are not used in our use case). - Make makeSpace compatible with marking, which needs to be supported by char chunks. I hope I didn't break anything with these changes ... Maybe it would be a good idea to tag 3.3.x before these, to be safe. If 3.3.x is tagged before this change it probably would be a good idea to pick up the JkInputStream change I committed earlier. It fixes a problem where small packets were getting dropped and causing the last one or two bytes of post data to be lost for certain sized posts. Of course, it should only impact char buffers which are allowed to grow significantly, which aren't used a lot (AFAIK). In Tomcat 5, I believe we play with setLimit dynamically only for char input. Please test it :) 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-connectors/jk/native2/server/apach e2 mod_jk2.c
Glenn Nielsen wrote: On Thu, Mar 04, 2004 at 05:49:21PM +0100, jean-frederic clere wrote: jean-frederic clere wrote: [EMAIL PROTECTED] wrote: jfclere 2004/03/03 09:55:32 Modified:jk/native2/server/apache2 mod_jk2.c Log: Remove jk2_translate... It is still not 100% OK: - LocationMatch does not work. - Some _not_found ends in Tomcat when using mod_dav. That is still not OK. I will go on later. Sorry :-( Now it looks better. The only thing I have removed is the logic for mod_dir Tomcat will do it if needed. Does that mean that Tomcat would have to resovlve identification of the directory index file? I do not see how the code I removed helps to do it. I am able to see that the index.html.var is requested but it is not displayed. (when mapping /examples/jsp/* for example). It would be nice to keep this on the apache side when someone uses Alias or JkAutoAlias to serve static pages, fourwarding and DirectoryIndex files which are *.jsp to Tomcat of course. By mapping *.jsp to Tomcat that works. Glenn signature.asc Description: OpenPGP digital signature
Realm interface
Hi, Realm interface provide methods for authorization like : UserDataPermission (hasUserDataPermission() method) , WebResourcePermission (hasResourcePermission() method) and the last method is hasRole() method. I'm working on an implementation of a realm which use JACC for the authorization I have no major problems for UserDataPermission and WebResourcePermission as the methods hasUserDataPermission() and hasResourcePermission() provide attributes to build WebUserDataPermission object (the HttpServletRequest argument is given to hasUserDataPermission() method). For WebResourcePermission, we can use HttpServletRequest attribute too. My problem is for using hasRole() method. For JACC permissions, we have to use WebRoleRefPermission object. For build WebRoleRefPermission objects, we need to know the servlet-name that identifies the application specific web resource in whose context the role references are to be evaluated But hasRole(Principal principal, String role) method contains only the principal and the role. I have two questions : Is that tomcat Realm interface will evolve to add an argument to hasRole() method in order to know the current servlet-name ? I think that Remy will answer me that this is another hack. So my next question is : Is there an easy way to know the current servlet name in a realm ? (in hasRole() method). Thanks for any suggestions if someone has already done this. Regards, Florent smime.p7s Description: S/MIME Cryptographic Signature
Re: Realm interface
This account does not exist - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27478] New: - cross context redirects don't work when import context redirects back to original context :
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=27478. 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=27478 cross context redirects don't work when import context redirects back to original context : Summary: cross context redirects don't work when import context redirects back to original context : Product: Tomcat 5 Version: 5.0.19 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have discovered another problem, that somehow sessions are either getting lost or mixed up when you do cross context imports in at least one advanced scenario : 1) page Z in context 'a' import a page X from context 'b' 2) page X in context 'b' imports a page Y in context 'a' in this case, the session that was created when you import page X in context b is the session that's available in page Y in context a. here's my test case --- test_page1.jsp ( context '/profile' ) : %@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; % Test of cross context imports : % request.getSession().setAttribute(test_attrib, 12345); % % out.println(test_attrib in ( test_page1.jsp ) is + session.getAttribute(test_attrib) ); %br/ % out.println(session id ( in test_page1.jsp) is : + request.getSession().getId() ); % br/ c:import url=/test_other.jsp context=/ / test_other.jsp ( context '/' ) : %@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; % % request.getSession().setAttribute(test_other_attrib, 54321 ); % % out.println(test attrib ( in test_other.jsp ) is : + request.getSession().getAttribute(test_attrib) ); %br/ % out.println(test other attrib ( in test_other.jsp) is : + request.getSession().getAttribute(test_other_attrib) ); %br/ % out.println(session id ( in test_other.jsp) is : + request.getSession().getId() ); % br/ c:import url=/test_page2.jsp context=/profile/ test_page2.jsp ( context '/profile' ) : %@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; % % out.println(test_attrib ( in test_page2.jsp ) is + session.getAttribute(test_attrib) ); % br/ % out.println(test other attrib ( in test_page2.jsp) is : + request.getSession().getAttribute(test_other_attrib) ); % br/ % out.println(session id ( in test_page2.jsp) is : + request.getSession().getId() ); % br/ The output i get when I hit test_page1.jsp is : Test of cross context imports : test_attrib in ( test_page1.jsp ) is 12345 session id ( in test_page1.jsp) is : 2796EBFF6C413841B7B2D496D7E8FD3F test attrib ( in test_other.jsp ) is : null test other attrib ( in test_other.jsp) is : 54321 session id ( in test_other.jsp) is : 2796EBFF6C413841B7B2D496D7E8FD3F test_attrib ( in test_page2.jsp ) is null test other attrib ( in test_page2.jsp) is : 54321 session id ( in test_page2.jsp) is : 2796EBFF6C413841B7B2D496D7E8FD3F The output I get when i hit test_other.jsp is : test attrib ( in test_other.jsp ) is : null test other attrib ( in test_other.jsp) is : 54321 session id ( in test_other.jsp) is : 55B2068D3011D727DF15068ADAD713E2 test_attrib ( in test_page2.jsp ) is null test other attrib ( in test_page2.jsp) is : null session id ( in test_page2.jsp) is : 55B2068D3011D727DF15068ADAD713E2 the output that i get when i hit test_page2.jsp : test_attrib ( in test_page2.jsp ) is 12345 test other attrib ( in test_page2.jsp) is : null session id ( in test_page2.jsp) is : 2796EBFF6C413841B7B2D496D7E8FD3F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27478] - cross context redirects don't reference correct session info when imported context redirects back to original context :
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=27478. 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=27478 cross context redirects don't reference correct session info when imported context redirects back to original context : [EMAIL PROTECTED] changed: What|Removed |Added Summary|cross context redirects |cross context redirects |don't work when import |don't reference correct |context redirects back to |session info when imported |original context : |context redirects back to ||original context : --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 18:12 --- 2 fixes are necessary -- 1) StandardContext.getContext(String path) does a check for context==null when it should be checking for child==null ( a context==null would never fail, and if it was null, there'd be an NPE long before ) 2) The other issue is that cross context requests are set crossContext by checking the current context vs. the originating request, instead of the preceding request, which means that when you import from context A to context B, then from B back to A, the second import is not considered cross context and the session information is retrieved from the local session in the (wrong) context. I hope this is somewhat explanatory. Please feel to contact me for clarification. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Realm interface
Hi, But hasRole(Principal principal, String role) method contains only the principal and the role. I have two questions : Is that tomcat Realm interface will evolve to add an argument to hasRole() method in order to know the current servlet-name ? I think that Remy will answer me that this is another hack. Remy or someone else ;) So my next question is : Is there an easy way to know the current servlet name in a realm ? (in hasRole() method). No, there's no easy way. Keep in mind that the resource being authenticated might not be a servlet at all: it could be a filter, for example. How would your realm handle that? What is your Principal implementation class, and does it contain methods to help in this scenario? Yoav Shapira 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]
DO NOT REPLY [Bug 27479] New: - Deployed webapp contexts don't get properties ( child elements ) from DefaultContext
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=27479. 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=27479 Deployed webapp contexts don't get properties ( child elements ) from DefaultContext Summary: Deployed webapp contexts don't get properties ( child elements ) from DefaultContext Product: Tomcat 5 Version: 5.0.19 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Given a a DefaultContext declaration in server.xml as follows : DefaultContext debug=1000 crossContext=true Resource name=jdbc/clubmom auth=Container type=oracle.jdbc.pool.OracleConnectionCacheImpl/ ResourceParams name=jdbc/clubmom parameternamefactory/namevalueoracle.jdbc.pool.OracleDataSourceFactory/value/parameter parameternamedriverClassName/namevalueoracle.jdbc.OracleDriver/value/parameter parameternameurl/namevaluejdbc:oracle:thin:@oracle-dev:1521:CM_DEV/value/parameter parameternameuser/namevalueclubmom/value/parameter parameternamepassword/namevalueclubmom/value/parameter parameternamemaxLimit/namevalue10/value/parameter parameternamestmtCacheSize/namevalue50/value/parameter parameternameimplicitCachingEnabled/namevaluetrue/value/parameter /ResourceParams /DefaultContext any deployed application ( via the manager app, dropped into webapps, or using ant tasks ) has no access to the given resource name. It seems none of the relevant properties from the DefaultContext are copied over. The problem seems to be that in StandardHostDeployer.install() the only properties that are set are the path and the docBase. I figure more properties, such as naming resources should be copied over also.. i.e. context.setNamingResources( host.getDefaultContext().getNamingResources() ) or some variation of ... A locally patched version adding that one line definitely gets rid of the common issu of the DBCP data source cannot load driver null for resource null that everyone gets.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27479] - Deployed webapp contexts don't get properties ( child elements ) from DefaultContext
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=27479. 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=27479 Deployed webapp contexts don't get properties ( child elements ) from DefaultContext --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 18:26 --- I will test this, but I doubt this report is valid. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk cachesize vs. processes
I've been trying hard to verify something: Is the cachesize configured with mod_jk per process in a multi-child Apache? I'd *assume* so, but I know where assuming tends to get me -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf CharChunk.java
Actually, I had intended to include the fix to JkInputStream with the 3.3.2 release. It's just that you got to it faster than me :). I agree with Remy that the changes to ByteChunk and CharChunk shouldn't do anything, but I also agree with the idea of not risking it with the 3.3.2 release. I'm inclined to tag 3.3.2 Final for these two before Remy's patch. - Original Message - From: Kurt Miller [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, March 05, 2004 8:36 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf CharChunk.java From: Remy Maucherat [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: remm2004/03/05 05:08:00 Modified:util/java/org/apache/tomcat/util/buf CharChunk.java Log: - Same fix. - Make calls to realReads compatible with marking (which is just for cleaness, as the parameters are not used in our use case). - Make makeSpace compatible with marking, which needs to be supported by char chunks. I hope I didn't break anything with these changes ... Maybe it would be a good idea to tag 3.3.x before these, to be safe. If 3.3.x is tagged before this change it probably would be a good idea to pick up the JkInputStream change I committed earlier. It fixes a problem where small packets were getting dropped and causing the last one or two bytes of post data to be lost for certain sized posts. Of course, it should only impact char buffers which are allowed to grow significantly, which aren't used a lot (AFAIK). In Tomcat 5, I believe we play with setLimit dynamically only for char input. Please test it :) 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] 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]
Tag Today - 3.3.2 Final
I'm planning to tag 3.3.2 Final later today (unless Larry beats me to it :). This will give us the weekend to roll up the release, and make the announcement Sunday night (PDT), so it doesn't get lost in the tomcat-user traffic. I'll use the weekend to clean out the 3.3 entries in BZ. 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 27479] - Deployed webapp contexts don't get properties ( child elements ) from DefaultContext
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=27479. 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=27479 Deployed webapp contexts don't get properties ( child elements ) from DefaultContext --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 20:47 --- it could be possible that it was only happening for the ROOT webapp, and causing others to fail. Would it possible to test that scenario as well? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26316] - Jasper refuses to compile JSP pages
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=26316. 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=26316 Jasper refuses to compile JSP pages [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 21:14 --- Tomcat is producing this misleading message when it encounters any compilation errors while compiling any JSP file. It stuffs those errors messages in the server log. Perhaps you could change the error output to something less confusing because it is NOT in fact having trouble finding the compiler. -JW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26316] - Jasper refuses to compile JSP pages
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=26316. 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=26316 Jasper refuses to compile JSP pages [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 22:24 --- This can occur only if somehow the output capture fails (which it never does with the default configuration). I consider this good enough, please do not reopen this report. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27479] - Deployed webapp contexts don't get properties ( child elements ) from DefaultContext
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=27479. 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=27479 Deployed webapp contexts don't get properties ( child elements ) from DefaultContext --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 22:30 --- You should test and report issues accurately. Otherwise, post on tomcat-user to investigate. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27479] - Deployed webapp contexts don't get properties ( child elements ) from DefaultContext
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=27479. 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=27479 Deployed webapp contexts don't get properties ( child elements ) from DefaultContext [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 22:41 --- Ok, I tested for all sorts of cases similar to what you mention, and it (still) works ok. Your use case is bad, since it will attempt to create one connection pool for each webapp. Use a global definition, with ResourceLink instead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_un.c
truk2004/03/05 15:35:52 Modified:jk/native2/common jk_channel_un.c Log: Calculate length for bind() in a portable way that works for sockaddr_un structs with and without sun_len. Revision ChangesPath 1.19 +7 -2 jakarta-tomcat-connectors/jk/native2/common/jk_channel_un.c Index: jk_channel_un.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_un.c,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- jk_channel_un.c 24 Feb 2004 08:44:40 - 1.18 +++ jk_channel_un.c 5 Mar 2004 23:35:51 - 1.19 @@ -58,6 +58,12 @@ int listenSocket; } jk_channel_un_private_t; +#ifndef SUN_LEN +/* actual length of an initialized sockaddr_un */ +#define SUN_LEN(su) \ +(sizeof(*(su)) - sizeof((su)-sun_path) + strlen((su)-sun_path)) +#endif + static int JK_METHOD jk2_channel_un_close(jk_env_t *env, jk_channel_t *ch, jk_endpoint_t *endpoint); @@ -162,8 +168,7 @@ rc=bind(socketInfo-listenSocket, (struct sockaddr *) socketInfo-unix_addr, -strlen( socketInfo-unix_addr.sun_path ) + -sizeof( socketInfo-unix_addr.sun_family) ); +SUN_LEN((socketInfo-unix_addr)) ); umask(omask); /* can't fail, so can't clobber errno */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_un.c
This account does not exist - 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 ApplicationContext.java ApplicationDispatcher.java
remm2004/03/05 15:52:55
Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java ApplicationDispatcher.java
Log:
- Fix crossContext flag when dispatching back to the original context.
- Bug 27478.
Revision ChangesPath
1.24 +2 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
Index: ApplicationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- ApplicationContext.java 27 Feb 2004 14:58:42 - 1.23
+++ ApplicationContext.java 5 Mar 2004 23:52:55 - 1.24
@@ -228,7 +228,7 @@
String mapuri = uri;
while (true) {
child = (Context) host.findChild(mapuri);
-if (context != null)
+if (child != null)
break;
int slash = mapuri.lastIndexOf('/');
if (slash 0)
1.31 +15 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
Index: ApplicationDispatcher.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- ApplicationDispatcher.java27 Feb 2004 14:58:42 - 1.30
+++ ApplicationDispatcher.java5 Mar 2004 23:52:55 - 1.31
@@ -969,8 +969,20 @@
(current instanceof HttpServletRequest)) {
// Compute a crossContext flag
HttpServletRequest hcurrent = (HttpServletRequest) current;
-boolean crossContext =
-!(context.getPath().equals(hcurrent.getContextPath()));
+boolean crossContext = false;
+if ((outerRequest instanceof ApplicationHttpRequest) ||
+(outerRequest instanceof HttpRequest) ||
+(outerRequest instanceof HttpServletRequest)) {
+HttpServletRequest houterRequest =
+(HttpServletRequest) outerRequest;
+Object contextPath = houterRequest.getAttribute
+(Globals.INCLUDE_CONTEXT_PATH_ATTR);
+if (contextPath == null) {
+// Forward
+contextPath = houterRequest.getContextPath();
+}
+crossContext = !(context.getPath().equals(contextPath));
+}
wrapper = new ApplicationHttpRequest
(hcurrent, context, crossContext);
} else {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27478] - cross context redirects don't reference correct session info when imported context redirects back to original context :
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=27478. 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=27478 cross context redirects don't reference correct session info when imported context redirects back to original context : [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-05 23:54 --- This should be fixed now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2
Jean, sorry for the late reply to your previous message, but here is what you requested + exactly what I did. However I did not find any jkjni.la file in the CVS sources and this file wasn't produced. STEPS: tar xzvf jakarta-tomcat-connectors_20040305232049.tar.gz cd jakarta-tomcat-connectors/jk/native2 chmod 0777 buildconf.sh ./buildconf.sh - This produces the following output: rm autom4te.cache libtoolize --force --automake --copy aclocal automake --copy --add-missing automake: configure.in: installing `scripts/build/unix/install-sh' automake: configure.in: installing `scripts/build/unix/mkinstalldirs' automake: configure.in: installing `scripts/build/unix/missing' autoconf - End output ./configure --with-java-home=/opt/sun-jdk-1.4.2.03 --with-apxs2=/usr/sbin/apxs2 --with-tomcat41=/usr/local/tomcat - This produces the following output: checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking whether make sets $(MAKE)... yes checking for working aclocal-1.4... found checking for working autoconf... found checking for working automake-1.4... found checking for working autoheader... found checking for working makeinfo... found checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ld used by GCC... /usr/i686-pc-linux-gnu/bin/ld checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes checking for /usr/i686-pc-linux-gnu/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking for a sed that does not truncate output... /bin/sed checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking command to parse /usr/bin/nm -B output... ok checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.lo... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking whether the linker (/usr/i686-pc-linux-gnu/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking whether -lc should be explicitly linked in... no creating libtool checking for test... /usr/bin/test checking for rm... /bin/rm checking for grep... /bin/grep checking for echo... /bin/echo checking for sed... /bin/sed checking for cp... /bin/cp checking for mkdir... /bin/mkdir no apxs given need to check for Perl first, apxs depends on it... checking for perl... /usr/bin/perl building connector for apache-2.0 checking checking for apache13.. not provided checking checking for apache20.. not provided checking checking for iis.. not provided checking checking for iPlanet.. not provided checking for tomcat33 location... not provided checking for tomcat40 location... not provided checking for tomcat41 location... /usr/local/tomcat configure: creating ./config.status config.status: creating Makefile config.status: creating server/apache13/Makefile config.status: creating server/apache13/Makefile.apxs config.status: creating server/apache2/Makefile config.status: creating server/apache2/Makefile.apxs config.status: creating ../build.properties config.status: creating scripts/build/unix/dummy - End output make clean build makeOutput - This produces the attached makeOutput file and the following error to the terminal: libtool: install: warning: remember to run `libtool --finish /usr/lib/apache2' libtool: install: error: cannot install `../../../build/jk2/apache2/libjkjni.la' to a directory not ending in /usr/lib/apache2 make[1]: ***
Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2
For some reason the makeOutput file did not attach so here it is in the flesh... list=' server/apache2'; \ for i in $list; do \ echo Making $target in $i; \ if test $i != .; then \ (cd $i make clean) || exit 1; \ fi; \ done; Making in server/apache2 make[1]: Entering directory `/usr/src/redhat/BUILD/jakarta-tomcat-connectors/jk/native2/server/apache2' rm -rf ../../../build/jk2/apache2/*.lo ../../../build/jk2/apache2/*.la ../../../build/jk2/apache2/*.o ../../../build/jk2/apache2/.libs ../../../build/jk2/apache2/*.so make[1]: Leaving directory `/usr/src/redhat/BUILD/jakarta-tomcat-connectors/jk/native2/server/apache2' list=' server/apache2'; \ for i in $list; do \ echo Making $target in $i; \ if test $i != .; then \ (cd $i make) || exit 1; \ fi; \ done; Making in server/apache2 make[1]: Entering directory `/usr/src/redhat/BUILD/jakarta-tomcat-connectors/jk/native2/server/apache2' mkdir -p ../../../build/jk2/apache2 /bin/sh /usr/lib/apache2/build/libtool --silent --mode=compile gcc -O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I/usr/include/apache2 -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE -c ../../common/jk_channel.c -o ../../../build/jk2/apache2/jk_channel.lo /bin/sh /usr/lib/apache2/build/libtool --silent --mode=compile gcc -O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I/usr/include/apache2 -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE -c ../../common/jk_channel_apr_socket.c -o ../../../build/jk2/apache2/jk_channel_apr_socket.lo /bin/sh /usr/lib/apache2/build/libtool --silent --mode=compile gcc -O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I/usr/include/apache2 -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE -c ../../common/jk_channel_jni.c -o ../../../build/jk2/apache2/jk_channel_jni.lo /bin/sh /usr/lib/apache2/build/libtool --silent --mode=compile gcc -O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I/usr/include/apache2 -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE -c ../../common/jk_channel_un.c -o ../../../build/jk2/apache2/jk_channel_un.lo /bin/sh /usr/lib/apache2/build/libtool --silent --mode=compile gcc -O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I/usr/include/apache2 -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE -c ../../common/jk_config.c -o ../../../build/jk2/apache2/jk_config.lo /bin/sh /usr/lib/apache2/build/libtool --silent --mode=compile gcc -O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I/usr/include/apache2 -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE -c ../../common/jk_config_file.c -o ../../../build/jk2/apache2/jk_config_file.lo /bin/sh /usr/lib/apache2/build/libtool --silent --mode=compile gcc -O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I/usr/include/apache2 -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE -c ../../common/jk_endpoint.c -o ../../../build/jk2/apache2/jk_endpoint.lo /bin/sh /usr/lib/apache2/build/libtool --silent
No such list! ='
Valid Lists - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No such list! ='
Tomcat Postmaster: What is this message??? -Martin Gainty - Original Message - From: =' [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 05, 2004 11:06 PM Subject: No such list! =' Valid Lists - 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 27462] - about JK2 ISAPI between IIS and Tomcat 5 has file upload bug?
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=27462. 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=27462 about JK2 ISAPI between IIS and Tomcat 5 has file upload bug? [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |NEW everconfirmed|0 |1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@lsd]: jakarta-tomcat-5/jakarta-tomcat-5 failed
To whom it may engage... This is an automated request, but not an unsolicited one. For help understanding the request please visit http://gump.apache.org/nagged.html, and/or contact [EMAIL PROTECTED] Project jakarta-tomcat-5 has an issue affecting it's community integration, and has been outstanding for 3 runs. The current state is 'Failed', for reason 'Build Failed' Full details are available at: http://lsd.student.utwente.nl/gump/jakarta-tomcat-5/jakarta-tomcat-5.html, however some snippets follow: - - - - - -- -- G U M P Gump provided these annotations: - Warning - Jar [/data3/gump/jakarta-tomcat-5/dist/server/lib/servlets-default.jar] identifier set to jar basename: [servlets-default.jar] - Warning - Jar [/data3/gump/jakarta-tomcat-5/dist/common/lib/naming-common.jar] identifier set to jar basename: [naming-common.jar] - Warning - Jar [/data3/gump/jakarta-tomcat-5/dist/common/lib/naming-resources.jar] identifier set to jar basename: [naming-resources.jar] - Warning - Jar [/data3/gump/jakarta-tomcat-5/dist/server/lib/catalina.jar] identifier set to jar basename: [catalina.jar] - Warning - Jar [/data3/gump/jakarta-tomcat-5/dist/bin/bootstrap.jar] identifier set to jar basename: [bootstrap.jar] - Warning - Jar [/data3/gump/jakarta-tomcat-5/dist/server/lib/servlets-common.jar] identifier set to jar basename: [servlets-common.jar] - Warning - Jar [/data3/gump/jakarta-tomcat-5/dist/server/lib/servlets-invoker.jar] identifier set to jar basename: [servlets-invoker.jar] - Info - Dependency on javamail exists, no need to add for property mail.jar. - Info - Dependency on jaf exists, no need to add for property activation.jar. - Info - Dependency on jakarta-servletapi-5-servlet exists, no need to add for property servlet-api.jar. - Info - Dependency on jakarta-servletapi-5-jsp exists, no need to add for property jsp-api.jar. - Info - Dependency on xml-xerces exists, no need to add for property xercesImpl.jar. - Info - Dependency on xml-xerces exists, no need to add for property xmlParserAPIs.jar. - Info - Dependency on jakarta-tomcat-util exists, no need to add for property tomcat-util.jar. - Info - Dependency on commons-el exists, no need to add for property commons-el.jar. - Info - Dependency on commons-logging exists, no need to add for property commons-logging-api.jar. - Info - Dependency on commons-modeler exists, no need to add for property commons-modeler.jar. - Info - Dependency on ant exists, no need to add for property ant.home. - Info - Dependency on jsse exists, no need to add for property jsse.home. - Info - Dependency on jmx exists, no need to add for property jmx.home. - Info - Dependency on jmx exists, no need to add for property jmx.jar. - Info - Dependency on jmx exists, no need to add for property jmx-tools.jar. - Info - Dependency on jndi exists, no need to add for property jndi.home. - Info - Dependency on jakarta-regexp exists, no need to add for property regexp.home. - Info - Dependency on jakarta-regexp exists, no need to add for property regexp.jar. - Info - Dependency on javamail exists, no need to add for property mail.home. - Info - Dependency on jakarta-tomcat-coyote exists, no need to add for property tomcat-coyote.home. - Info - Dependency on jakarta-tomcat-jasper_tc5 exists, no need to add for property jasper.home. - Info - Dependency on jaf exists, no need to add for property activation.home. - Info - Dependency on commons-modeler exists, no need to add for property commons-modeler.home. - Info - Dependency on commons-daemon exists, no need to add for property commons-daemon.jsvc.tar.gz. - Info - Dependency on jakarta-struts exists, no need to add for property struts.home. - Error - Failed with reason build failed - - - - - -- -- G U M P Gump performed this work: Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build) State: Failed Elapsed: 0 hours, 1 minutes, 4 seconds Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -Xbootclasspath/p:/data3/gump/xml-xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xmlParserAPIs.jar:/data3/gump/xml-xalan/java/build/xalan-unbundled.jar:/data3/gump/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/data3/gump/gump-install/work/merge.xml -Dbuild.sysclasspath=only -Dtomcat33.home=*Unset* -Djsp-api.jar=/data3/gump/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar -Dtomcat-coyote.home=/data3/gump/jakarta-tomcat-connectors/coyote -Djndi.jar=/data3/gump/opt/jndi1_2_1/lib/jndi.jar -Dsite2.home=/data3/gump/jakarta-site2 -DxmlParserAPIs.jar=/data3/gump/xml-xerces2/java/build/xercesImpl.jar -Dactivation.home=/data3/gump/opt/jaf-1.0.1 -Djmx.home=/data3/gump/opt/jmx-1_2-ri -Djdbc20ext.jar=/data3/gump/opt/jdbc2_0/jdbc2_0-stdext.jar -Djmx-tools.jar=/data3/gump/opt/jmx-1_2-ri/lib/jmxtools.jar
DO NOT REPLY [Bug 27490] New: - autoconf problem
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=27490. 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=27490 autoconf problem Summary: autoconf problem Product: Tomcat 5 Version: 5.0.19 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_PATH - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
