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=16688.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=18569.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=18562.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
thanks - dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi,
As far as I am concerned, the focus for the next stable 4.1.x release
will be on small fixes. I do not want to introduce new features or
changes which would affect Tomcat's behavior. I think the ETA for that
next stable release could be within one to two months.
So I would need to compile
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-04-02/jakarta-tomcat-jk-native2.html
Buildfile: build.xml
init.taskdef:
guess.os:
[echo]
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=18472.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=10249.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
I've already written this question to the user list by I haven't got any
answer. Perhaps do one of you know the answer to my problem:
I've set up BASIC authentication without any problem in my application. When
I want to change to DIGEST authentication, it doesn't work at all. I'm
getting a
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=18562.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=18609.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=18609.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Howdy,
Isn't Crimson in JDK1.4 ? I remember we decided to disable XML schema
validation.
Crimson is in JDK 1.4. Crimson is officially hibernated and my
understanding is there are no forthcoming releases. I don't know if
Tiger (aka JDK 1.5) will include Crimson, another XML parser
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=18562.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Costin Manolache wrote:
Jean-Francois Arcand wrote:
Because the xerces version bundled with 1.4 is an older one, doesn't
support XML schema properly, and contains bugs (and is not as performant
as the 2.x version)
Isn't Crimson in JDK1.4 ? I remember we decided to disable XML schema
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=18615.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
Is there any common extension mechanism to add own authorization
method to catalina in addition to BASIC, CLIENT-CERT, DIGEST, FORM?
I have some kind of portal containing a set of web applications under one virtual host.
The portal use SingleSignOn feature to authenticate users. Also there is
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=18620.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Amy Roh wrote:
Just out of curiosity, is there a simple way to disable jmx in tc5 other
than changing tomcat code to avoid registration/unregistration manually
which won't be trivial.
Just out of curiosity, why would you want to do this ?
The whole point of using ( and requiring ) JMX is to
Jean-Francois Arcand wrote:
At least in tomcat5 I never use xerces - only the bundled parser, and so
far I've seen no problems.
Crimson is a very good parser, and it still faster that Xerces in some
case. The only reason I see for bundling xerces is for when we turn on
validation the web.xml
Remy Maucherat wrote:
Hi,
As far as I am concerned, the focus for the next stable 4.1.x release
will be on small fixes. I do not want to introduce new features or
changes which would affect Tomcat's behavior. I think the ETA for that
next stable release could be within one to two months.
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=18569.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=18472.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache
Sent: Wednesday, April 02, 2003 10:18 AM
To: [EMAIL PROTECTED]
Subject: Re: [4.1.x] Next release
Remy Maucherat wrote:
Hi,
As far as I am concerned, the focus for the next stable 4.1.x release
Costin Manolache wrote:
Remy Maucherat wrote:
Hi,
As far as I am concerned, the focus for the next stable 4.1.x release
will be on small fixes. I do not want to introduce new features or
changes which would affect Tomcat's behavior. I think the ETA for that
next stable release could be within
jfarcand2003/04/02 11:43:20
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
Port patch from Tomcat 5.
Return the facade instead of the context itself.
Revision ChangesPath
1.118 +6 -5
luehe 2003/04/02 12:03:12
Modified:catalina/src/share/org/apache/catalina/startup
TldConfig.java
Log:
When searching parent class loaders for JAR files (for automatic TLD
recognition), ignore any JAR files that don't exist
Revision ChangesPath
Costin Manolache wrote:
Amy Roh wrote:
Just out of curiosity, is there a simple way to disable jmx in tc5 other
than changing tomcat code to avoid registration/unregistration manually
which won't be trivial.
Just out of curiosity, why would you want to do this ?
I don't. I was just thinking
Remy Maucherat wrote:
Could I get some details on that filter/facade bug ?
Yes, Filter.init() is called with the Context object instead of the
facade. While Servlet.init() is called correctly.
This may allow access to the internals, and is just weird ( getting
different context objects in
Amy Roh wrote:
Just out of curiosity, is there a simple way to disable jmx in tc5 other
than changing tomcat code to avoid registration/unregistration manually
which won't be trivial.
Just out of curiosity, why would you want to do this ?
I don't. I was just thinking of different options
Costin Manolache wrote:
Remy Maucherat wrote:
Could I get some details on that filter/facade bug ?
Yes, Filter.init() is called with the Context object instead of the
facade. While Servlet.init() is called correctly.
This may allow access to the internals, and is just weird ( getting
Costin Manolache wrote:
Remy Maucherat wrote:
Could I get some details on that filter/facade bug ?
Yes, Filter.init() is called with the Context object instead of the
facade. While Servlet.init() is called correctly.
This may allow access to the internals, and is just weird (
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Could I get some details on that filter/facade bug ?
Yes, Filter.init() is called with the Context object instead of the
facade. While Servlet.init() is called correctly.
This may allow access to the internals, and is
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=18626.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Could I get some details on that filter/facade bug ?
Yes, Filter.init() is called with the Context object instead of the
facade. While Servlet.init() is called correctly.
This may allow access to the internals, and
Costin Manolache wrote:
Amy Roh wrote:
Just out of curiosity, is there a simple way to disable jmx in tc5 other
than changing tomcat code to avoid registration/unregistration manually
which won't be trivial.
Just out of curiosity, why would you want to do this ?
I don't. I was just thinking
- Original Message -
From: Jean-Francois Arcand [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, April 02, 2003 12:37 PM
Subject: Re: [4.1.x] Next release
Costin Manolache wrote:
Remy Maucherat wrote:
Could I get some details on that
Costin Manolache wrote:
Hmmm. We could use the jsr77 option ( that is now in 4.1.x ) and generate
JSR77 names only if it is on.
Or we could just use the other kind of names allways - and have a separate
module that re-register the objects with JSR77 names ( if needed ).
But the real issue is
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=18568.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=18568.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=18568.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
remm2003/04/02 13:13:13
Added: .BUGS.txt
Log:
- Add a must fix bug list (please edit it directly, add bug numbers, etc).
Revision ChangesPath
1.1 jakarta-tomcat-4.0/BUGS.txt
Index: BUGS.txt
Jean-Francois Arcand wrote:
Costin Manolache wrote:
Jean-Francois Arcand wrote:
At least in tomcat5 I never use xerces - only the bundled parser, and so
far I've seen no problems.
Crimson is a very good parser, and it still faster that Xerces in some
case. The only reason I
Howdy,
I've used Ant's xmlproperty task to validate web.xml as part of
deployment...
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Costin Manolache [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 02, 2003 4:25 PM
To: [EMAIL PROTECTED]
Subject: Re: Why does Tomcat
Remy Maucherat wrote:
Costin Manolache wrote:
Hmmm. We could use the jsr77 option ( that is now in 4.1.x ) and
generate JSR77 names only if it is on.
Or we could just use the other kind of names allways - and have a
separate module that re-register the objects with JSR77 names ( if needed
Hi;
If I have a tld object (ie TemplateDesc.java) with no project and place it
in WEB-INF/classes - it won't work. But if I give it a package name and
place it in WEB-INF/classes/package - then it works.
The problem seems to be that with no package it generates the code:
TemplateDesc
BTW - in the web.xml files that I write I usually remove the declaration on
the top ( to make sure the validation doesn't happen ).
I can't recall which servlet engine I saw this in, but I have seen at
least one servlet engine that rejected web.xml unless it contained the
expected DTD
glenn 2003/04/02 14:48:02
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Fix possible seg fault when LogLevel is debug
Revision ChangesPath
1.69 +5 -5 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
Trying to pull jakarta-tomcat-connectors into eclipse 2.1, it found the
following obvious typo in o.a.jk.ant.SoTask.java, line 367:
/**
* The name of the target file.
* (XXX including extension - this should be automatically added )
*/
public void setModule(String modName) {
costin 2003/04/02 16:45:21
Modified:util/java/org/apache/tomcat/util/threads
ThreadWithAttributes.java
Log:
Add a threadData attribute. This can simplify the init and allow
the thread pool to run simple Runnable.
Revision ChangesPath
1.2
costin 2003/04/02 16:51:45
Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
Log:
Few changes - hopefully no backward incompatibilities.
The most important is the use of the threadData property in
ThreadWithAttribute. Previously - we created a simple thread,
costin 2003/04/02 16:52:26
Modified:util/java/org/apache/tomcat/util/threads ThreadPoolMX.java
Log:
All code moved to parent - but we need to keep this around for
backward compat.
Revision ChangesPath
1.6 +8 -115
costin 2003/04/02 16:53:51
Modified:jk/java/org/apache/jk/server JkMain.java
Log:
jk2.properties is not required.
Revision ChangesPath
1.36 +3 -4
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
costin 2003/04/02 16:54:34
Modified:jk/java/org/apache/jk/common ChannelSocket.java
Log:
Unregister on shutdown.
Revision ChangesPath
1.36 +12 -2
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
Index: ChannelSocket.java
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=18620.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
fhanik 2003/04/02 18:29:38
Modified:modules/cluster/etc cluster-server.xml
modules/cluster/src/share/org/apache/catalina/cluster/tcp
ReplicationListener.java SimpleTcpCluster.java
Log:
added in the host auto flag, and fixed the select timeout
+1 for the next 4.1 release to include only bug fixes.
A quick query of bugzilla found 744 bugs for Tomcat 4 which are not
either closed or resolved.
Ouch!
Perhaps we should set a goal for how much this number should be
reduced before doing the release.
Some of these are quite old and perhaps
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=13726.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Sorry for the delay.
IMO the right solution is to fix #10229 for coyote.
There are a lot of problems in the old connectors - even if mod_jk2
is not yet as stable as mod_jk1, the java side and coyote are far
better than the old impl.
I'm +0 on fixing the MBean exception - AFAIK upgrading
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=18639.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
hey ya'all,
Running today on Solaris I discovered a bug in the way java.nio is
implemented on Solaris 8(Intel) JDK 1.4.1. This problem could exist in other
JDK versions as well.
The problem is that when a thread reading from a socket channel calls
selector.wakeup(); the selector doesn't wakeup
Hai,
I have a Redhat 8.0 machine runnin apache 2.0.40 (rpm
-ivh httpd-2.040, i have the httpd-devel 2.0.40 too)
and tomcat 4.0.6. I was trying to compile
jakarta-tomcat-connectors-jk-1.2.0-src for getting
mod_jk.so module to integrate the above two server. I
am failing in every attempt. anyone
62 matches
Mail list logo
