Jean-Francois Arcand a écrit :
Henri Gomez wrote:
I traced TC 5.0 and Digester and suspect what could be the problem
with external entities when only SYTEM is defined ie :
!ENTITY appset1 SYSTEM appset1.xml
!ENTITY appset2 SYSTEM appset2.xml
In Digester.java, at least in the 1.5 release,
Kin-Man Chung wrote:
I don't know much about the test; it is one of stress test we have, but it
should not affect CharChunk this way, right, even if it has something
weird? Like I said, this happens only in this test, and not always
reproducible, so I am not surprised that nobody noticed it in
As described above, you're trying to use an illegal URL, which goes
above the top of the webapp's namespace. You'll need to use absolute
file: or http: type URLs, or provide your own EntityResolver that
does whatever you want it to do.
The only way to developpers and admins to have it works
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=23805.
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=23805.
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=21763.
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=23805.
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=23805.
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=23805.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
Should we set JAVA_ENDORSED_DIRS to a default value of
$CATALINA_HOME/common/endorsed in the startup scripts?
Cheers
Jean-Frederic
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
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=23831.
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=23805.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi to all,
Now that jk seems stabilized a bit, should we focalize on jk2 ?
For instance I added some features to jk (ping/pong) which should be
ported to jk2.
Also I wonder if APR is mandatory for jk2.
I'd like to use APR as a facade to all Operating System calls.
The goal is to hide all the
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=23805.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
+1 to have a version of mod_jk rewritten to use APR for all OS stuff
It would be best to use the version of APR which is distributed with
the current Apache 2 release so that there are no conflicts when using
mod_jk with Apache 2.
Requiring APR would allow using a global connection pool for the
Bill,
thank you so much (so far :-)
4.1.28 starts up nicely and answers me - even if I only get half of the start page
(index.jsp),
and even if I cannot execute the XML example ... and so on.
But at least this damned ebcdic-line-separator-problem is done away with
Anna
PS: I submitted a mail
+1 to use the APR as mandatory for the mod_jk.
You can rename it to the mod_jk2 after that easily :-)
MT.
-Original Message-
From: Henri Gomez
Hi to all,
Now that jk seems stabilized a bit, should we focalize on jk2 ?
For instance I added some features to jk (ping/pong) which
Hi,
I think it would be possible, using a new rule, to allow system
properties inside server.xml (and possibly elsewhere) for attribute
values. This is the same as what is being done by Ant in its build
scripts. This would add an additional degree of configurability to Tomcat.
Actually, I
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=23805.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
+0 (I'd be +1 if I could actually be of help - but love the idea)
-Tim
Remy Maucherat wrote:
Hi,
I think it would be possible, using a new rule, to allow system
properties inside server.xml (and possibly elsewhere) for attribute
values. This is the same as what is being done by Ant in its
Howdy,
If it's easy, +1 ;)
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 10:24 AM
To: Tomcat Developers List
Subject: [5.0] System properties in server.xml (and elsewhere)
Hi,
I think it
Mladen Turk a écrit :
+1 to use the APR as mandatory for the mod_jk.
You can rename it to the mod_jk2 after that easily :-)
Heu, the idea is to make jk2 (native2) apr mandatory.
We'll keep jk as it is today.
* the plan
- update jk2 (native2) to use APR only
- port jk add-ons like ping/pong to
Remy Maucherat a écrit :
Hi,
I think it would be possible, using a new rule, to allow system
properties inside server.xml (and possibly elsewhere) for attribute
values. This is the same as what is being done by Ant in its build
scripts. This would add an additional degree of configurability
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 5:21 AM
Subject: cvs commit:
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluste
r/tcp AsyncSocketSender.java IDataSender.java ReplicationTransmitter.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=23805.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Henri Gomez wrote:
Remy Maucherat a écrit :
Hi,
I think it would be possible, using a new rule, to allow system
properties inside server.xml (and possibly elsewhere) for attribute
values. This is the same as what is being done by Ant in its build
scripts. This would add an additional degree
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=23805.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
Possibly. Basically, if you have a foo.bar sys property, you can put
${foo.bar} in server.xml, and it will be replaced with the property
value (like in Ant). I didn't know this was present in 3.3.
Yes it was in TC 3.3.1 and
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=23841.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Henri Gomez wrote:
Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
Possibly. Basically, if you have a foo.bar sys property, you can put
${foo.bar} in server.xml, and it will be replaced with the property
value (like in Ant). I didn't know this was present in 3.3.
Yes
Remy Maucherat a écrit :
Henri Gomez wrote:
Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
Possibly. Basically, if you have a foo.bar sys property, you can
put ${foo.bar} in server.xml, and it will be replaced with the
property value (like in Ant). I didn't know this
Henri Gomez wrote:
Mladen Turk a écrit :
+1 to use the APR as mandatory for the mod_jk.
You can rename it to the mod_jk2 after that easily :-)
Heu, the idea is to make jk2 (native2) apr mandatory.
We'll keep jk as it is today.
* the plan
- update jk2 (native2) to use APR only
- port jk
jean-frederic clere a écrit :
Henri Gomez wrote:
Mladen Turk a écrit :
+1 to use the APR as mandatory for the mod_jk.
You can rename it to the mod_jk2 after that easily :-)
Heu, the idea is to make jk2 (native2) apr mandatory.
We'll keep jk as it is today.
* the plan
- update jk2 (native2)
I'm +1 on moving jk2 (native2) to APR. I haven't had a lot of time to play with jk2,
but I have seen that there are some issues with it on NetWare (something about it
allocating stuff when Apache 2 initializes it's 1st load and then expecting that stuff
to still be around when it comes up for
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=23831.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I am using mod_jk 1.2.5 w/Apache 1.3.28, talking to JBoss w/integrated
Tomcat 4.1.24. I am attempting to use the lb worker to load balance
across two instances of Tomcat. I will eventually do this against as
many as 5 Tomcat instances.
I am having limited success getting an equal
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=23831.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I may be totally wrong here, but it seems that if the
backgroundProcessorDelay property on a StandardContext is set to
something greater than zero (default is -1, inherited from
ContainerBase), the context's sessions are never purged.
This is because in ContainerBase$ContainerBackgroundProcessor,
Jan Luehe wrote:
I may be totally wrong here, but it seems that if the
backgroundProcessorDelay property on a StandardContext is set to
something greater than zero (default is -1, inherited from
ContainerBase), the context's sessions are never purged.
This is because in
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=19852.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Thanks for confirming, Remy!
I'll make these changes.
Jan
Remy Maucherat wrote:
Jan Luehe wrote:
I may be totally wrong here, but it seems that if the
backgroundProcessorDelay property on a StandardContext is set to
something greater than zero (default is -1, inherited from
ContainerBase), the
luehe 2003/10/15 10:24:16
Modified:catalina/src/share/org/apache/catalina/core
ContainerBase.java StandardContext.java
Log:
Start/stop ContainerBackgroundProcessor thread as part of
StandardContext.start()/stop(), respectively.
Revision Changes
fhanik 2003/10/15 11:11:49
Modified:modules/cluster/src/share/org/apache/catalina/cluster/session
SimpleTcpReplicationManager.java
Log:
removed the session replication upon session creation, this happens at the end of
the request anyway
Revision
I believe 23805 is unrelated to my problem, and may even be invalid.
Mine comes from CharChunk. To refresh the memory, the stack trace is
Servlet.service() for servlet jsp threw exception
java.lang.IndexOutOfBoundsException
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:132)
jfarcand2003/10/15 11:47:49
Modified:catalina/src/share/org/apache/catalina Wrapper.java
catalina/src/share/org/apache/catalina/core
StandardWrapper.java StandardWrapperValve.java
catalina/src/share/org/apache/coyote/tomcat5
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 8:31 AM
Subject: Re: [5.0] System properties in server.xml (and elsewhere)
Henri Gomez wrote:
Do you speak about the ${xxx} properties as
-Original Message-
From: Henri Gomez
Mladen Turk a écrit :
+1 to use the APR as mandatory for the mod_jk.
You can rename it to the mod_jk2 after that easily :-)
Heu, the idea is to make jk2 (native2) apr mandatory.
We'll keep jk as it is today.
And I was thinking you
Remy Maucherat wrote:
Hi,
I think it would be possible, using a new rule, to allow system
properties inside server.xml (and possibly elsewhere) for attribute
values. This is the same as what is being done by Ant in its build
scripts. This would add an additional degree of configurability to
I had an issue with 4.1.27 with having a DefaultContext define a JDBC
Resource. If the resource is defined in a specific Context everything is
fine, but move it into DefaultContext or GobalResources and you get
NullPointer Exceptions and so on.
Consider the following scenario:
1. Client sends POST request (with content type other than
application/x-www-form-urlencoded) to SSL-enabled server (with
client auth turned off).
2. Server parses request header, and determines that the resource
identified by the request-URI 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=18967.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
funkman 2003/10/15 18:42:04
Modified:docs/faq connectors.html misc.html security.html
docs/faq/printer connectors.html misc.html security.html
xdocs-faq connectors.xml misc.xml security.xml
Log:
Clarify error handling, system.out, new links for
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=23759.
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=18967.
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=23852.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
All,
I have an announcement to make since myself and some colleagues found during
some serious debugging on why session replication failed miserably on their
systems.
When running session replication for Tomcat 4.1.24
(http://cvs.apache.org/~fhanik/) on Redhat 9 using Sun JDK 1.4.2 nothing
works
Henri Gomez wrote:
Hi to all,
Now that jk seems stabilized a bit, should we focalize on jk2 ?
For instance I added some features to jk (ping/pong) which should be
ported to jk2.
Also I wonder if APR is mandatory for jk2.
I'd like to use APR as a facade to all Operating System calls.
Remy Maucherat wrote:
Hi,
I think it would be possible, using a new rule, to allow system
properties inside server.xml (and possibly elsewhere) for attribute
values. This is the same as what is being done by Ant in its build
scripts. This would add an additional degree of configurability
Gary Benson wrote:
Hi all,
I've been working on building Tomcat and its dependencies to native
code with gcj, and I'm interested to see how it compares against
Tomcat running under a 'normal' JVM. Now, I'm well aware that
benchmarks are not a real-world indicator of performance, but I
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=23853.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
60 matches
Mail list logo
