Hi,
Maybe no one has looked at it, or no one cares. Feel free to add your comments
to this bug (and any others, of course), and/or contact the original poster to
correct his understanding. In general here (and other Apache projects, and
most OSS projects) stuff gets done when it gets done, with
It's not clear from the report (at least to someone with my lack of Jasper
experiance :) that the report isn't against a problem with a JSP-Document
(aka XML-format). Unlikely, but it needs to be checked before setting as
INVALID.
- Original Message -
From: Leon Rosenberg [EMAIL
Peter Rossbach wrote:
Hey,
I have a strange loadbalancer behaviour at a customer site with Apache
2/mod_jk 1.2.14, JVM 1.5, Tomcat 5.5.9 (cluster), (Suse 9.1)
Hi guys,
Peter you are correct about this...
I found by myself too, that balancer is misbehaving in some cases.
One of them is
Sounds good to me.
Wrote a spec before implementation is very helpfull :-)
The domain case with sticky session and real clustered szenarios is
not easy.
Peter
Mladen Turk schrieb:
Peter Rossbach wrote:
Hey,
I have a strange loadbalancer behaviour at a customer site with
Apache
Jean-Francois Arcand wrote:
Hi,
I've just wrote a unit test to verify this bug has fixed
(http://issues.apache.org/bugzilla/show_bug.cgi?id=33463). But looking
at the code in StandardContext:
4276 // Stop our application listeners
4277 listenerStop();
4278
No, the plugin is just using the manager deploy function. Happens if I do it
through the manager console.
-Original Message-
From: Arto Pastinen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 28, 2004 2:24 AM
To: Tomcat Developers List
Subject: Re: Bug??
Hi!
Isn't that maven
, December 28, 2004 9:11 AM
To: 'Tomcat Developers List'
Subject: RE: Bug??
No, the plugin is just using the manager deploy function. Happens if I do it
through the manager console.
-Original Message-
From: Arto Pastinen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 28, 2004 2:24 AM
: Carbone, Adam [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 28, 2004 9:11 AM
To: 'Tomcat Developers List'
Subject: RE: Bug??
No, the plugin is just using the manager deploy function. Happens if I do it
through the manager console.
-Original Message-
From: Arto Pastinen
. And
supposedly there were flags added to give the old behavior but I think there
is a bug with those flags! Because they don't do anything.
~adam
-Original Message-
From: Arto Pastinen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 28, 2004 2:46 PM
To: Tomcat Developers List
Subject: RE: Bug
Hi!
Isn't that maven plugins fault?
Artsi
On Mon, 2004-12-27 at 18:18, Carbone, Adam wrote:
I noticed that in several discussions and bugs about locking and how
resources got deployed and this was causing them to be locked so they need
to be un-deployed manually. The reason I'm asking it
Remy Maucherat wrote:
So, sorry, you get the regular answer now: please submit a ready to
test set of WARs demonstrating the bad behavior.
It took some time to get a blessed demo of problem.
Nevertheless, here I am delivering it.
The README coming with the demo does not state which version
of
Hallo Remy,
Remy Maucherat wrote:
Andreas Steffan wrote:
Hallo Remy,
Remy Maucherat wrote:
What do you think ?
Your event is sent at the end of the initialization of a context.
Your other context might not exist yet. This is not a bug.
Even though one might interpret the spec a little diffrent
Andreas Steffan wrote:
suggest you go back to the list (I am unable to comment in a public
forum) and explain the issue correctly before claiming this.
---
Does their product suck as much as their company policies ? ;)
To be honest, it does not change my positition that the portal relies
on non
Hallo Remy,
Remy Maucherat wrote:
Andreas Steffan wrote:
suggest you go back to the list (I am unable to comment in a public
forum) and explain the issue correctly before claiming this.
---
Does their product suck as much as their company policies ? ;)
Sorry, can't comment on that one. ;)
To be
.
Yoav Shapira http://www.yoavshapira.com
-Original Message-
From: Andreas Steffan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 17, 2004 5:16 AM
To: Tomcat Developers List
Subject: Re: Bug with contextInitialized using
otherServletContext.getContext ?
Hallo Remy,
Remy Maucherat
Hallo Yoav,
Shapira, Yoav wrote:
Hi,
You wouldn't need to submit a Vignette product or complex WAR to show
this, if I understand their email correctly. Submit a zip file with two
WARs, ie. two webapps / two contents, each one very small and basic.
Each WAR should be mapped to a different path,
Hallo Remy,
Remy Maucherat wrote:
What do you think ?
Your event is sent at the end of the initialization of a context. Your
other context might not exist yet. This is not a bug.
Even though one might interpret the spec a little diffrent here, I think
you raise a valid argument here and it is
Andreas Steffan wrote:
Hallo Remy,
Remy Maucherat wrote:
What do you think ?
Your event is sent at the end of the initialization of a context.
Your other context might not exist yet. This is not a bug.
Even though one might interpret the spec a little diffrent here
There's nothing to interpret
Remy Maucherat wrote:
Your event is sent at the end of the initialization of a context.
Your other context might not exist yet. This is not a bug.
Even though one might interpret the spec a little diffrent here
There's nothing to interpret here, as the specification cannot specify
this. The
Hi,
First, if you stick with 4.1, you might want to try 4.1.31 instead of
4.1.27 as it's the latest stable release.
However, I don't think what you're reporting is a bug, and so 4.1.27 vs
4.1.31 doesn't matter for this specific issue. The reason I don't think
it's a bug is that webapp
Hallo Yoav,
Shapira, Yoav wrote:
Hi,
First, if you stick with 4.1, you might want to try 4.1.31 instead of
4.1.27 as it's the latest stable release.
Meanwhile, I have checked tomcat 4.1.31 and 5.0.27. Same problem
occurs with both of them.
However, I don't think what you're reporting is a bug, and
Hi,
The application (portlet-application) getting the contextInitialized()
event is using another apps (the portals) ServletContext.getContext()
to
obtain a reference to the portlet-applications ServletContext and fails
because of the null return value.
Are both of these contexts configured
Hallo Yoav,
Shapira, Yoav wrote:
Hi,
The application (portlet-application) getting the contextInitialized()
event is using another apps (the portals) ServletContext.getContext()
to
obtain a reference to the portlet-applications ServletContext and fails
because of the null return value.
Are both
Andreas Steffan wrote:
However, first let's see if setting crossContext=true brings the
behavior you desire. I should have mentioned this in my first response.
No problem, even though I mentioned it in my initial posting. ;)
To be honest, my feeling is that Vignette might be correct here and
PLEASE UNSUBSCRIBE ME EMMEDIATLEY
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 07 November 2004 15:20
To: [EMAIL PROTECTED]
Subject: Bug report for Watchdog [2004/11/07]
+---
+
|
Shapira, Yoav wrote:
Hi,
Will anyone care if we stop getting Tomcat 3, 4, and Watchdog bug
reports emailed to this list, and start getting Tomcat 5 bug reports?
Assuming everyone concurs on the above, whom do I ask? Infrastructure?
+1. I don't see much use for these lists, so is a TC 5 list
Hi,
Will anyone care if we stop getting Tomcat 3, 4, and Watchdog bug
reports emailed to this list, and start getting Tomcat 5 bug reports?
Assuming everyone concurs on the above, whom do I ask?
Infrastructure?
+1. I don't see much use for these lists, so is a TC 5 list actually
useful ?
Nick Lothian wrote:
It should be extremely obvious that your little scheme relies only on
the fact that you will be able to set cookies from an
included resource.
This is something which is unlikely to happen, given that:
- data is quite likely to have already been sent back (the
response is
Hola,
What I see is that you have engaged in a widespread political
campaign
to have this changed, rather than rely on technical issues. I really
hate this kind of tactic.
I'm not quite sure what you are referring to.
So far I have:
(a) Discussed this on the Pluto-Dev
Nick Lothian wrote:
Issue 4690 http://issues.apache.org/bugzilla/show_bug.cgi?id=4690 relates
to the Tomcat implementation of cross-context sessions.
The Pluto (JSR-168 Portlet RI) team need the behaviour in this area changed
to be able to properly implement JSR-168.
I understand that this is an
The original user was having trouble figuring out which class(es) in
their application were causing NotSerializableExceptions.
And, in fact, I was starting to think about the Serializable issue for
a client...
And then Tim wrote:
--- Additional Comments From [EMAIL PROTECTED] 2004-10-11
Don't bother. Here is it for the archives.
package x;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.ObjectOutputStream;
import javax.servlet.http.HttpSessionBindingEvent;
import javax.servlet.http.HttpSessionAttributeListener;
import
What do people think? Have I persuaded anyone yet?
What I see is that you have engaged in a widespread political
campaign
to have this changed, rather than rely on technical issues. I really
hate this kind of tactic.
I'm not quite sure what you are referring to.
So far I have:
(a)
Why, if tomcat 4 is toast, and tomcat 3 is crispy, do I still get bug
summaries for them but not tomcat 5? Or 5.5?
--Angus
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 22, 2004 10:19 AM
To: [EMAIL PROTECTED]
Subject: Bug report for Tomcat
Jess Holle wrote:
mod_jk2 2.0.4 seems to have the same issues that several mod_jk 1.2.x
releases had with mod_dir.
Specifically something like:
Alias /MyWebApp D:\my_app_view\Myapp/codebase
Directory D:\my_app_view\Myapp/codebase
Options Indexes FollowSymLinks
/Directory
Sorry, I should have said mod_alias, not mod_dir...
--
Jess Holle
Jess Holle wrote:
mod_jk2 2.0.4 seems to have the same issues that several mod_jk 1.2.x
releases had with mod_dir.
Specifically something like:
Alias /MyWebApp D:\my_app_view\Myapp/codebase
Directory
Jess Holle wrote:
Sorry, I should have said mod_alias, not mod_dir...
With Apache 1.3 or 2.0 ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Henri Gomez wrote:
Jess Holle wrote:
Sorry, I should have said mod_alias, not mod_dir...
With Apache 1.3 or 2.0 ?
2.0.49 on Windows. I have not tried Solaris or AIX yet. [I have not
bothered with mod_jk2 with Apache 1.3 -- I just use mod_jk there on an
old with old sort of principle.]
I
Jess Holle wrote:
Henri Gomez wrote:
Jess Holle wrote:
Sorry, I should have said mod_alias, not mod_dir...
With Apache 1.3 or 2.0 ?
2.0.49 on Windows. I have not tried Solaris or AIX yet. [I have not
bothered with mod_jk2 with Apache 1.3 -- I just use mod_jk there on an
old with old sort
Henri Gomez wrote:
Jess Holle wrote:
Henri Gomez wrote:
Jess Holle wrote:
Sorry, I should have said mod_alias, not mod_dir...
With Apache 1.3 or 2.0 ?
2.0.49 on Windows. I have not tried Solaris or AIX yet. [I have not
bothered with mod_jk2 with Apache 1.3 -- I just use mod_jk there on an
jean-frederic clere wrote:
Settings and test case of course more than welcome :=}
I think I have reproduced it with the following:
+++
Alias /examples /opt/SMAWoIS/jakarta-tomcat-4.1.29/webapps/examples
Location /examples/servlet/*
JkUriSet group ajp13:pgtr0327:8009
/Location
+++
The
Jess Holle wrote:
jean-frederic clere wrote:
Settings and test case of course more than welcome :=}
I think I have reproduced it with the following:
+++
Alias /examples /opt/SMAWoIS/jakarta-tomcat-4.1.29/webapps/examples
Location /examples/servlet/*
JkUriSet group ajp13:pgtr0327:8009
jean-frederic clere wrote:
Henri Gomez wrote:
Jess Holle wrote:
Henri Gomez wrote:
Jess Holle wrote:
Sorry, I should have said mod_alias, not mod_dir...
With Apache 1.3 or 2.0 ?
2.0.49 on Windows. I have not tried Solaris or AIX yet. [I have not
bothered with mod_jk2 with Apache 1.3 --
Jess Holle wrote:
Jess Holle wrote:
jean-frederic clere wrote:
Settings and test case of course more than welcome :=}
I think I have reproduced it with the following:
+++
Alias /examples /opt/SMAWoIS/jakarta-tomcat-4.1.29/webapps/examples
Location /examples/servlet/*
JkUriSet group
jean-frederic clere wrote:
I think I have reproduced it with the following:
+++
Alias /examples /opt/SMAWoIS/jakarta-tomcat-4.1.29/webapps/examples
Location /examples/servlet/*
JkUriSet group ajp13:pgtr0327:8009
/Location
+++
The /examples/servlet/* uri has /examples/servlet/*-1 for
This account does not exist
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- Additional Comments From [EMAIL PROTECTED] 2004-01-14 13:03
There is a standard for encoding URIs
(http://www.w3.org/International/O-URL-
code.html) but this standard is not consistently followed by clients.
This causes a number of problems.
...
2. The Coyote HTTP/1.1 connector has a
look at these bugs
bug 23929
bug 25360
bug 25231
bug 25235
bug 22666
bug 24557
bug 24345
bug 25848
some keywords I could think of are:
setCharacterEncoding
international characters
not latin characters
special characters
GET method
It is difficult to find a good question in FAQ for this issue. As
Remy Maucherat wrote:
Jess Holle wrote:
Remy Maucherat wrote:
This is a good question -- but one which only applies to POST. My bug
case was explictly with GET.
If there is an entity body encoding specified in the request, then I
am not sure which should override. If there is not, then I
From a developers point of view however, applying the above two points
a) brakes expected behaviour (setCharacterEncoding() method does not
work the same as before)
b) does not give an acceptable alternative (if all parameter passing
could be solved with POST method, then the GET method would
Stefanos Karasavvidis wrote:
If not already done, port the useBodyEncodingForURI parameter to the
next 4.1.x release.
This new flag has been ported last month.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Jess Holle wrote:
Remmy, et al:
The API is *not* optional. It is a required part of the servlet spec.
Great. I didn't know that ;-)
How about:
- Not CCing me. I'm subscribed to tomcat-dev already. thanks.
- There's big threads, commit messages (incl recent ones), and bugs on
this issue. How
Remy Maucherat wrote:
Jess Holle wrote:
Remmy, et al:
The API is *not* optional. It is a required part of the servlet spec.
Great. I didn't know that ;-)
How about:
- Not CCing me. I'm subscribed to tomcat-dev already. thanks.
Sorry.
- There's big threads, commit messages (incl recent ones),
Jess Holle wrote:
- There's big threads, commit messages (incl recent ones), and bugs on
this issue. How about reading that before writing an email about how
bad things are.
I did search the archives for such threads before even filing my
duplicate bug, so apparently my searching is inept.
Remy Maucherat wrote:
Jess Holle wrote:
- There's big threads, commit messages (incl recent ones), and bugs
on this issue. How about reading that before writing an email about
how bad things are.
I did search the archives for such threads before even filing my
duplicate bug, so apparently
Jess Holle wrote:
Remy Maucherat wrote:
For example:
remm2003/12/10 14:26:28
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java
mbeans-descriptors.xml
Log:
- Add a flag to allow using the
Remy Maucherat wrote:
Jess Holle wrote:
Remy Maucherat wrote:
For example:
remm2003/12/10 14:26:28
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java
mbeans-descriptors.xml
Log:
- Add a
Jess Holle wrote:
Remy Maucherat wrote:
This is a good question -- but one which only applies to POST. My bug
case was explictly with GET.
If there is an entity body encoding specified in the request, then I am
not sure which should override. If there is not, then I would presume
Burns, Darrell wrote:
We are having this bug show up right now(No processor available,
rejecting this
connection). I noticed that this has been resoved, but not through QA.
Any more
information you could give me would be appreciated.
Well, I can't reproduce this.
People rarely post about such
Did you configure according to
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/doc/jk2/insta
llhowto.html
Including setting up APR?
-Martin
- Original Message -
From: Samuel Arnod-Prin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, August 27,
Howdy,
This is a user, not developer question, so if you want to continue this
discussion do so on the tomcat-user mailing list.
public class UseOfParameters extends GenericServlet
snip
End of Source Code --
According to what i have read, a log file by the
On Tuesday, August 12, 2003 12:39 AM, Bill Barker [SMTP:[EMAIL PROTECTED]
wrote:
- Original Message -
From: Mark Thomas [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, August 11, 2003 3:23 PM
Subject: RE: Bug 19867
I have been looking into
http://nagoya.apache.org
Having looked at this problem a little more (assuming this is the same
problem, i had done a little recoding, but the symptoms are the same), i
have some more info.
Unless there's a major unexpected flaw and I missed something, I do
believe that the shutdown is synchronous if you use the stop
Wesley Hall wrote:
Hello,
I have found a small bug during my work embedding the tomcat server into our
application.
When a secure connector is added to an instance of Embedded, and embedded is
startd and stopped several times in quick succession (which is part of our
test framework) a race
- Original Message -
From: Mark Thomas [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, August 11, 2003 3:23 PM
Subject: RE: Bug 19867
I have been looking into
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19867
and have a couple of questions.
The error seen
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21714
--- Davanum Srinivas [EMAIL PROTECTED] wrote:
Do you want me to create a bugzilla report? here's the diff. Need to check for the
whole class
(mx4j.adaptor.http.HttpAdaptor)
Thanks,
dims
Index: JkMX.java
Hi Costin and tomcat developers!
I found this bug in Tomcat Mailing List Archive from Date: Mon, 24 Jul 2000
10:25:13 -0700.
We are experiencing similar problem in our application.
We are using IIS and Tomcat3.2.3
After some days of load IIS-tomcat redirection stops response since IIS
Even added a jaas.conf in my user.dir with the
following entry...
Tomcat {
com.sun.security.auth.module.NTLoginModule
required;
};
--- Sam Ewing [EMAIL PROTECTED] wrote:
I am using JAASRealm with the NT Login module. My
Realm configuration from
server.xml (tomcat 4.1.18) is:
I tried debugging the JAASRealm. This is where things
go wrong-
public Principal authenticate(String username, String
credentials) {
...
loginContext = new LoginContext
(appName, new JAASCallbackHandler(this, username,
credentials))
...
Is this a bug? (i think so!)
sorry - i will use bugzilla next time.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Thnx, I will check this out!
-Andris
I'm having problems with JK2 connector and Microsoft IIS. I can't...
Sounds like you might have come across the same problem I did. If so,
this patch might solve your case too:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15278
--
To unsubscribe,
Hi,
I'm having problems with JK2 connector and Microsoft IIS. I can't
upload files, more precisely, the servlet does not get correct
mime stream. The data is sent all-right, but the last mime
boundary usually is not there. Needless to say that the same
servlet works fine with mod_jk2 and
Sorry for answering my own mail but I lost the thread and want to clarify
some aspects with respect to Matts message. He wrote:
---
This means that ALL roles can access this resource. When you specify *, you
don't need to specify security-role below, but if you DO specify a role or
roles, then it
On Friday, December 6, 2002, at 07:05 AM, Thomas Paradies wrote:
Hi,
I'm a little bit confused about the use of the security-role tag -
generally
and especially in Tomcat. The WebApp DTD refers for auth-constraint to
this
element commented as follows:
... The role-name used here must either
Adrian Sampaleanu wrote:
We are having a problem with Catalina 4.1.12 (I believe we also had
issues with previous versions, but can't say for sure) with respect to
how POSTed requests are handled if the transfer encoding is chunked.
It seems that request parameters in the content are not
Developers List
Subject: Re: Bug(?) and suggested solution for chunked
transfer-encoding
POST request
Adrian Sampaleanu wrote:
We are having a problem with Catalina 4.1.12 (I believe we also had
issues with previous versions, but can't say for sure) with
respect to
how POSTed
Remy Maucherat wrote:
Adrian Sampaleanu wrote:
We are having a problem with Catalina 4.1.12 (I believe we also had
issues with previous versions, but can't say for sure) with respect
to how POSTed requests are handled if the transfer encoding is
chunked. It seems that request parameters in
]
Sent: Friday, November 08, 2002 12:10 PM
To: Tomcat Developers List
Subject: Re: Bug(?) and suggested solution for chunked
transfer-encoding
POST request
Adrian Sampaleanu wrote:
We are having a problem with Catalina 4.1.12 (I believe we also had
issues with previous versions
This is not a bug, but a feature :)..
The release notes tells more about it.
Martin
-Original Message-
From: Frédérik Bilhaut [mailto:fbilhaut;wanadoo.fr]
Sent: 01 November 2002 16:38
To: [EMAIL PROTECTED]
Subject: Bug with symbolic links in WEB-INF/lib/
Hi !
I noticed a Tomcat bug
:48 AM
To: Tomcat Developers List
Subject: Re: Bug 13658
Costin Manolache wrote:
I think it is perfectly fine for Coyote to require Java2.
HashMap is available in GCJ/Kaffe and AFAIK in J2ME ( one of the
profiles).
I'll double check the last part.
I would also +1 removing
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Sunday, October 20, 2002 12:04 AM
Subject: Re: Bug 13658
Bill Barker wrote:
- Original Message -
From: Remy Maucherat
To: Tomcat Developers List
Sent
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Saturday, October 19, 2002 2:11 AM
Subject: Re: Bug 13658
Bill Barker wrote:
Before I start performing major surgery on the TC4/5 connector, I
wanted to
check on what
(ThreadPool.jav
a:516)
at java.lang.Thread.run(Thread.java:479)
Cheers,
Hans
-Ursprungliche Nachricht-
Von: Remy Maucherat [mailto:remm;apache.org]
Gesendet: Freitag, 18. Oktober 2002 20:15
An: Tomcat Developers List
Betreff: Re: Bug 13736
Bill Barker wrote:
+1. As I said above
)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:516)
at java.lang.Thread.run(Thread.java:479)
Cheers,
Hans
-Ursprungliche Nachricht-
Von: Remy Maucherat [mailto:remm;apache.org]
Gesendet: Freitag, 18. Oktober 2002 20:15
An: Tomcat Developers List
Betreff: Re: Bug
Bill Barker wrote:
- Original Message -
From: Remy Maucherat
To: Tomcat Developers List
Sent: Saturday, October 19, 2002 2:11 AM
Subject: Re: Bug 13658
Bill Barker wrote:
Before I start performing major surgery on the TC4/5 connector, I
wanted to
check on what is the reason
Remy Maucherat wrote:
Bill Barker wrote:
I don't remember anything like that for 3.3.x (and nothing even close is
open in BZ). But, then again, I don't imagine that very many people
try and
use the Http10Connector in production, and Coyote is only available in the
nightly for 3.3
Bill Barker wrote:
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Sunday, October 20, 2002 12:04 AM
Subject: Re: Bug 13658
Bill Barker wrote:
- Original Message -
From: Remy Maucherat
To: Tomcat
OTOH, I don't think this should be the case, and I think we should
stop/start the server socket in that particular case, as was done in the
old HTTP connector:
One thing to consider here - the CHUID case, where you bind on 80
and then change the user id.
You can stop the server socket, but
Bill Barker wrote:
Before I start performing major surgery on the TC4/5 connector, I
wanted to
check on what is the reason for having the attributes field in
CoyoteRequest
(instead of just delegating to the o.a.c.Request like the 3.3 Adapter
does).
At the moment, the SSL request attributes
Bill Barker wrote:
I don't remember anything like that for 3.3.x (and nothing even close is
open in BZ). But, then again, I don't imagine that very many people
try and
use the Http10Connector in production, and Coyote is only available in the
nightly for 3.3 until 3.3.2 comes out.
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Friday, October 18, 2002 1:17 AM
Subject: Re: Bug 13736
Bill Barker wrote:
I don't remember anything like that for 3.3.x (and nothing even close is
open in BZ
Bill Barker wrote:
+1. As I said above, it probably hasn't shown up in 3.3 mostly because
AJP13 has many fewer accepts.
I'll fix it then.
You have to be careful that no IOException should end up in that code,
otherwise, for each one the server socket will be restarted (not good).
With
Hi,
we have some configuration files that lies directly
under WEB-INF/classes
per ClassLoader.getResource.
Please try:
ClassLoader cl=Thread.currentThread().getContextClassLoader();
InputStream is=cl.getResourceAsStream(some.txt);
Happy Java programming!
---
Jun Inamori
OOP-Reserch
Just viewed DateTool in CVS. Yes, format also has
thread problem and need fix. But, has parse been
fixed? I didn't see any change about it in v1.7.
--- Bill Barker [EMAIL PROTECTED] wrote:
I just checked in a fix for the format side
(setting the Last-Modified
header). This one is much harder
-Original Message-
From: jean-frederic clere
OPT=-Djava.class.path=${TOMCAT_HOME}\bin\tomcat-jni.jar;${TOMCAT_HOME}
\s
erver\lib\commons-logging.jar
I do not like this work-around: we will have end with a huge
classpath.
Neither do I, but this is the only way for now
Mladen Turk wrote:
-Original Message-
From: jean-frederic clere
OPT=-Djava.class.path=${TOMCAT_HOME}\bin\tomcat-jni.jar;${TOMCAT_HOME}
\s
erver\lib\commons-logging.jar
I do not like this work-around: we will have end with a huge
classpath.
Neither do I, but this is the only
-Original Message-
From: Mladen Turk [mailto:[EMAIL PROTECTED]]
OK this is a release showstopper!
IMHO the reason is missing org.apache.commons.logging.LogFactory,
perhaps not loaded by the jni channel.
If someone more familiar with that can dig into and trace the
problem
This is the classloader problem.
Think that Bill Baker is solving this, but until then add the
commons-logging.jar to the loaded classes when started inprocess:
OPT=-Djava.class.path=${TOMCAT_HOME}\bin\tomcat-jni.jar;${TOMCAT_HOME}\s
erver\lib\commons-logging.jar
Adding commons-logging to the
I just checked in a fix for the format side (setting the Last-Modified
header). This one is much harder to hit, but that doesn't mean that you
can't. The parse side (getting the If-Modified-Since header) has been
fixed in the nightly for quite some time now.
- Original Message -
From:
Sean Reilly wrote:
Hi,
I posted bug #11091
(http://issues.apache.org/bugzilla/show_bug.cgi?id=11091) on July 23rd.
Since then, nobody besides myself has posted a comment to it, and it is
still assigned to [EMAIL PROTECTED]
The recent test milestone (4.1.10) released on August 30th does
1 - 100 of 291 matches
Mail list logo
