[EMAIL PROTECTED] schrieb:
Author: mturk
Date: Sat Jun 24 03:44:34 2006
New Revision: 416897
URL: http://svn.apache.org/viewvc?rev=416897view=rev
Log:
Instead calling time(NULL), use it as a function
parameter.
Modified: tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
@@ -283,32
Hi Mladen,
In jk/native/common/jk_ajp_common.c: Are you able to convince me, that
this condition is correct:
2210 if (n aw-ep_mincache_sz) {
2211 if (JK_IS_DEBUG_LEVEL(l)) {
2212 jk_log(l, JK_LOG_DEBUG,
2213
Thanks, I committed most of it (and some more). The only thing I left
unchanged is not escaping the Ampersand as a seperator between query
arguments.
Johan Bergström schrieb:
Hello dev-list.
I'm quite new to both tomcat and mod_jk.. really liking it so far!
Thought I could contribute back
[EMAIL PROTECTED] schrieb:
+if ((cnt - n) aw-ep_mincache_sz) {
= (lower or equals) instead of ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi,
I would like to start releasing mod_jk 1.2.16 this week.
Since our last release was done from CVS and there are several updates
to the tool chain (autoconf/automake/m4/libtool), there is some risk of
breaking the release (additionally to mod_jk code bugs).
For that reason I would propose
I think it's time to rename jakarta-tomcat-connectors to
tomcat-connectors. I'll try to handle the remaining jakarta-tomcat
artefacts inside the connectors module and concerning the download.
Does anyone know about external references we might break?
Rainer
That's part of what I'll be doing.
Jean-frederic Clere schrieb:
Rainer Jung wrote:
I think it's time to rename jakarta-tomcat-connectors to
tomcat-connectors. I'll try to handle the remaining jakarta-tomcat
artefacts inside the connectors module and concerning the download.
Does anyone
/28/06, Rainer Jung [EMAIL PROTECTED] wrote:
I think it's time to rename jakarta-tomcat-connectors to
tomcat-connectors. I'll try to handle the remaining jakarta-tomcat
artefacts inside the connectors module and concerning the download.
Does anyone know about external references we might break
the duplicated
java source trees don't confuse people. Given how much unused native
we have, it may be good to just move mod_jk and whatever else is still
used to tomcat6/ repo.
Costin
On 6/28/06, Rainer Jung [EMAIL PROTECTED] wrote:
I think it's time to rename jakarta-tomcat-connectors to
tomcat
Maybe this
http://www.apache.org/dev/svn-eol-style.txt
will help?
Filip Hanik - Dev Lists schrieb:
gee, this is the second time this happened to me.
my IDE is set to preserve line endings, do I need to setup some
subversion property?
Filip
Jean-frederic Clere wrote:
Hi,
Try to prevent
Hi,
version 1.2.16 of the Apache Tomcat mod_jk web server connector has been
tagged. This version contains numerous bug fixes and some new
improvements over our last release 1.2.15. Please test and share your
experience.
If no critical bugs will be found, we will have a formal release vote
Hi,
version 1.2.16 of the Apache Tomcat mod_jk web server connector has been
tagged. This version contains numerous bug fixes and some new
improvements over our last release 1.2.15. Please test and share your
experience.
If no critical bugs will be found, we will have a formal release vote
Hi,
as a reminder: I will summarize test feedback for mod_jk 1.2.16 late
friday, and provided positive test results the Apache Tomcat project
will proceed to vote on the final release. Until now only about 10
downloads happened, so we need more users to participate!
To ensure a quality release
I updated the README for 5.0.30 and 5.0.28 with a deprecation warning in
the style of 5.5. I also made the notice on the download page a little
more visible. It will take a couple of hours, before people.a.o
replicates it to the productive web server.
Thank's for the hint!
Rainer
Mladen Turk
Hi,
the tests for mod_jk 1.2.16 had a couple of results, unfortunately with
one bad regression bug:
1) The status worker (aka jkmanager) had a bug, which resulted in double
locking and hanging when a user tried to change the important attributed
disabled or stopped (and also for the new one
Hi,
thanks to everyone who tested 1.2.16. Unfortunately we had one
regression bug in the status worker (hanging update request because of
double locking). For full results please see:
http://marc.theaimsgroup.com/?l=tomcat-devm=115234851210076w=2
Today version 1.2.17 of the Apache Tomcat mod_jk
of unsigned int...
With this iSeries build without problems...
2006/7/12, Rainer Jung [EMAIL PROTECTED]:
Hi,
thanks to everyone who tested 1.2.16. Unfortunately we had one
regression bug in the status worker (hanging update request because of
double locking). For full results please see:
http
It's called once a minute (at least if a request comes in) to be able to
clean up things not directly related to the actual request, like closing
idle connections.
[EMAIL PROTECTED] schrieb:
Hi,
I'm currently working in mod_jk in order to add a particular mechanism, in
this
work I have to
I think Mladen and I both want people to move to mod_proxy_*. Mladen
already offered help and httpd-dev for porting mod_jk improvements to
mod_proxy_* and I definitely want to join him in that. But first I need
to manage the pending mod_jk release, something we are right now doing.
I don't know
Hi Remy and Filip,
overwhelmed is much more correct than uncomfortable. I think looking at
how much work Filip has put into it since it's beginnings, it was good
to not immediately change the default implementation for TC 5.5 when
Filip started.
As Filip thinks it's ready for TC 6, I will
Hi Mladen,
would you mind putting it on
http://tomcat.apache.org/dev/dist/
first?
Many thanks for the Win-Builds!
Regards,
Rainer
Mladen Turk wrote:
Henri Gomez wrote:
What the status of mod_jk 1.2.17 ?
It would be usefull to get some binaries to help users check against
their
Be careful:
I understand Henri problem report as getsockopt complaining about the
*last* argument. So it has been introduced between 1.2.15 and 1.2.16:
r386629 | pero | 2006-03-17 13:36:04 +0100 (Fri, 17 Mar 2006) | 1
Mladen Turk wrote:
Anyhow, I suppose it should be neither int nor unsigned int,
but rather size_t, at least that's the retval from sizeof, right?
Of course its used by getsockopt that OTOH requires socklen_t.
Since it's only use is putting it into getsockopt(), I would suggest the
use of
Then let Peter try it on Mac OS X, if he only gets a warning or a real
error.
Henri Gomez wrote:
Ok, build against the latest from SVN (thanks Mladen), and build
without any problem on iSeries.
A strong 1.2.18 candidate
2006/7/18, Mladen Turk [EMAIL PROTECTED]:
Henri Gomez wrote:
Well on
?
2006/7/18, Jim Jagielski [EMAIL PROTECTED]:
On Jul 18, 2006, at 8:46 AM, Mladen Turk wrote:
Rainer Jung wrote:
Then let Peter try it on Mac OS X, if he only gets a warning or a
real error.
Sure, but since
http://www.hmug.org/man/2/getsockopt.php
says that the OS/X uses socklen_t
I'll care about that, since it looks like I'll do 1.2.18 now.
But I will only update documentation on tomcat.apache.org/dev. I'm
really thinking about rolling back the premature publication of newer
doc on tomcat.apache.org. I think, doc there should not be more recent,
than the last release.
In
http://www.apache.org/dev/version-control.html
the ASF suggests:
Committers will need to properly configure their svn client. One
particular issue is OS-specific line-endings for text files. When you
add a new text file, especially when applying patches from Bugzilla,
first ensure that
No, I think it's not:
1) This is not a regression, it was always implemented like that.
2) The recover feature is used in the load balancer and the first way of
avoiding errors is meant to be retries, the second way is failover. Only
then comes recovery.
3) A worker that goes into error
. At least in most cases.
Mladen Turk wrote:
Rainer Jung wrote:
Mladen Turk wrote:
Anyhow, why would 60 second be optimal value?
It could as well be 90, 100, 180, etc...
Increasing is something totally different. I just want to avoid people
ending with a system that changes error/ok states
David Rees wrote:
While the change you made allows you to configure the worker to a
recover_time lower than 60 seconds, it doesn't let you change it to a
value lower than 60 using the status worker.
Still investigating, but it looks like there are a number of other
places it should be changed.
David Rees wrote:
Thanks that should work around my issue quite nicely. I'll check out
SVN and give a whirl (unless a new tag is to be rolled again shortly?)
Try 1.2.18.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Hi,
thanks to everyone who tested 1.2.17. We had one bug related to special
types used in the networking code. Furthermore there was one request for
enhancement we included in the next version 1.2.18.
Today this version 1.2.18 of the Apache Tomcat mod_jk web server
connector has been
To find out, why this is so: did you get the same VStudio complains for
1.2.16 or 17? I tought you built those?
I would suggest to just repack the zip, since there is no change in
repository and no official release yet.
Mladen Turk wrote:
Rainer Jung wrote:
Hi,
http://tomcat.apache.org/dev
/installer/License.rtf
- ./native/iis/installer/isapi-redirector-win32-msi.ism
So we would need to maintain a list, which files need to be excluded in
the -l. I think it ill be easier to rely on svn and keep the eol
information there.
Mladen Turk wrote:
Rainer Jung wrote:
Hi,
http
Mladen Turk wrote:
Rainer Jung wrote:
To find out, why this is so: did you get the same VStudio complains
for 1.2.16 or 17? I tought you built those?
I would suggest to just repack the zip, since there is no change in
repository and no official release yet.
OK.
I have used your zip file
Hi Mladen,
I wouldn't have known before, but
http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html
says:
Subversion's locking feature is currently limited to files only - it's
not yet possible to reserve access to a whole directory tree.
So I guess that's why you were able to
I found it easy to delete via filtering for svn lock and svn unlock.
It's different for the archives, but for them this traffic peak will not
be serious. The worst thing was, that mails got delayed by several hours.
I would prefer to keep svn commits on the dev list.
Yoav Shapira wrote:
Hi,
Hello to all Tomcat project members,
after 2 unsuccessful release attempts for mod_jk it looks like 1.2.18
doesn't get any bug reports. All known bugs related to 1.2.16 and 1.2.17
have been fixed in 1.2.18. About 20 users downloaded 1.2.16 and 1.2.17
each, and 11 downloads happened for 1.2.18
of release.
Thanks
On Mon, 2006-07-24 at 13:07 +0200, Peter Rossbach wrote:
Stable,
really cool community driven release. :-)
Peter
Am 24.07.2006 um 12:13 schrieb Mladen Turk:
Rainer Jung wrote:
Apache Tomcat Connectors 1.2.18 is:
[X] Stable - no major issues, no regressions
[ ] Beta
for your participation in the vote!
Rainer
Rainer Jung schrieb:
Hello to all Tomcat project members,
after 2 unsuccessful release attempts for mod_jk it looks like 1.2.18
doesn't get any bug reports. All known bugs related to 1.2.16 and 1.2.17
have been fixed in 1.2.18. About 20 users downloaded
Apache Tomcat Connectors 1.2.18 is:
[X] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what they are
Rainer
-
To
The results of the vote are:
Stable: 6 votes (Mladen, Henri, Peter, Yoav, Jean-Frederic, Rainer)
Beta, Alpha: None.
I'm now going to move everything to the download area, updating docs,
updating cgi, mailing announcement ...
-
The Apache Tomcat team is pleased to announce the immediate availability
of version 1.2.18 of the Apache Tomcat mod_jk web server connector.
mod_jk is a connector which allows a web server such as Apache HTTPD
to act as a front end to the Tomcat web application server.
This version contains
mod_jk already uses shared memory, but since it should work for apache
1.3 and 2.0/2.2 it does not use apr. If your extensions are only meant
for 2.0/2.2, then have a look at apr:
http://apr.apache.org/docs/apr/modules.html
I'm not sure, that I understand your use case. Isn't Enhydra able to
Klaus Wagner wrote:
On Mon, 2006-08-14 at 16:24 +0200, Rainer Jung wrote:
Klaus Wagner wrote:
...
If you really, really want to do this, for the watchdog you can enhance
the existing maintain methods. There is already a mechanism that calls
the maintain methods during a request only
programming)
Thanks a lot !!!
On 8/14/06, Rainer Jung [EMAIL PROTECTED] wrote:
Klaus Wagner wrote:
On Mon, 2006-08-14 at 16:24 +0200, Rainer Jung wrote:
Klaus Wagner wrote:
...
If you really, really want to do this, for the watchdog you can enhance
the existing maintain methods
not a problem, and the TC code and the Java API doc suggest
it's no problem on any platform.
Regards
Rainer
Filip Hanik - Dev Lists schrieb:
Rainer Jung wrote:
Jim Jagielski schrieb:
In a nutshell, there are many cases where Apache httpd and
Tomcat are separated by a firewall
Klaus Wagner schrieb:
Here my impressions of the situation from an serveradmin perspective.
On Wed, 2006-08-23 at 17:08 +0200, Rainer Jung wrote:
I still don't have a consistent idea what happened around the firewall:
- silently dropping is not expected apart from a deny rule, but deny
Hi Mladen,
Mladen Turk schrieb:
Rainer Jung wrote:
I still don't have a consistent idea what happened around the firewall:
It is a very simple:
I don't think so, because no one was able to give the details. From a
simple perspective everything is clear, but only the details will give
Mladen Turk schrieb:
The patch the Jim provided, gives us the functionality of turning off
the keep alive from the clients (httpd in this case) perspective.
I do not agree, although its a hack and easy fix for
the problem itself.
I would prefer the more useful 3 param connections/pool
Hi all,
I plan to commit four more changes during the weekend. 2 of them are
already coded and running, the other 2 ones I still need to implement.
Most of the commits I did this week were only preparations for these
functionally bigger ones.
Already done but not committed:
- Passing back child
OK, so
- what's the show stopper: the rewrite windows things?
If yes, I would suggest to release this one patch without *any* of the
changes I did last week, because I hope, that this release would need no
changes.
Rainer
Mladen Turk schrieb:
Rainer Jung wrote:
I would then make a snapshot
Hi all,
I applied some bigger changes to mod_jk. The result is available from
trunk, but also from
http://people.apache.org/~rjung/mod_jk-1.2.19-437488/
Under this URL you can also find the updated docs.
Since we need to decide, if we release Mladens Windows fixes from a
branch (not
This configure worked for previous version ;'(
2006/8/28, Henri Gomez [EMAIL PROTECTED]:
I'll make a build on our Linux PPC box and make some tests.
Stay tuned
BTW, a windows binary will be usefull also
2006/8/28, Rainer Jung [EMAIL PROTECTED]:
Hi all,
I applied some bigger changes to mod_jk
Mladen Turk wrote:
Rainer,
can you make some tomcat-connectors-1.2.19-dev.tar.gz?
Regards,
Mladen.
Hi Mladen,
isn't that what's under
http://people.apache.org/~rjung/mod_jk-1.2.19-437488/
The numver is the subversion revision. The contents are 1.2.19-dev with
everything like in the
Mladen Turk wrote:
You can put tarball inside your http://people.apache.org/~rjung/
It's much easier to handle tarball then doing svn co for each platform.
Somehow I don't get the problem: the tarball was already on
people.apache.org when I sent the original message. It's in the
directory
If no one stops me, I'll do so at in 30 minutes :)
Henri Gomez schrieb:
2006/8/29, Mladen Turk [EMAIL PROTECTED]:
Henri Gomez wrote:
BTW, a windows binary will be usefull also
http://people.apache.org/~mturk/jk1219/
Done some bug fixes to be able to compile,
so they are in sync with
Hi all,
Mladen and I applied some minor but partly important fixes. The result
is available from trunk, but also as a tarball from
http://people.apache.org/~rjung/mod_jk-1.2.19-438031/
Under this URL you can also find the docs (no changes form previous
quality check).
Feel free to send any
Hi Filip,
I can't give the correct recommendations, but explain the flag:
The flag tells the loader not to load the default thread library, but
instead another - usually older - one. Linux had incompatible changes in
it's thread implementation and since the distros bundle so much
software, they
+1 (thanks for the nice comments on the recent connectors work) and +1
to Mladens Comments on the connector stuff.
Maybe you might like to add myself to the diversifying release managers
part concerning tomcat-connectors.
Regards,
Rainer
Yoav Shapira schrieb:
Hey,
We need to submit a
I checked it, and tomcat-connectors-1.2.18-src.zip seems to have CRLF
line ends.
Alpha Huang schrieb:
It has been a long time that mod_jk.dsp has unix line endings (LF) instead of
win32's CRLF.
I have to fix it every time when I use msdev to build it.
Although many text editors could fix
, and Rainer Jung for the connectors.
Releases:
- mod_jk 1.2.17 and 1.2.18 were released. 1.2.18 is currently the
stable release (it was put out on July 20th). mod_jk 1.2.19 is in the
works, expected to release in the first half of September.
- Tomcat 4.1.34 was released in the first week of September
Yes, I'm willing and I've got time to cut a release during the weekend.
I'll put a HEAD tarball on people.apache.org during the next hour and
announce that on tomcat-dev, so that interesting parties have another
chance of giving it a quick try (since wwe've got again a lot of changes
since
before we cut the release.
The release is being planned for tagging during saturday.
Regards,
Rainer
Rainer Jung wrote:
Yes, I'm willing and I've got time to cut a release during the weekend.
I'll put a HEAD tarball on people.apache.org during the next hour and
announce that on tomcat-dev, so
Rainer Jung:
In preparation of release 1.2.19 of tomcat-connnectors (including
mod_jk) I made the actual HEAD of the code available for download and
testing under
http://people.apache.org/~rjung/mod_jk-1.2.19-442987/
This is not an official release, but another opportunity to give the
code
worker show state REC (cool)
I thing first report is a bootstrap problem, but I can find it :-)
regards
Peter
Am 13.09.2006 um 16:07 schrieb Rainer Jung:
In preparation of release 1.2.19 of tomcat-connnectors (including
mod_jk) I made the actual HEAD of the code available for download
This is not a known feature.
Anything in the mod_jk log?
You mean first hit after restart, or after a time of inactivity?
Platform? Server version?
The new svn HEAD code gives the ability to log useful state info of the
LB in the access logs, so you can more easily find out, how often and
Please open a Bugzilla for an enhancement request.
Thanks for pointing it out.
David Rees wrote:
On 9/14/06, Mladen Turk [EMAIL PROTECTED] wrote:
So what do you do when you have multiple virtualhosts mapped to
different workers?
Please don't split hair :)
In that case use the
Hi,
I'm going to tag tomcat-connectors 1.2.19 in around an hour. In case
anyone has a pending important commit, please let me know soon.
Regards,
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Hi,
version 1.2.19 of the Apache Tomcat mod_jk web server connector has been
tagged. This version contains numerous bug fixes and some new
improvements over our last release 1.2.18. Please test and share your
experience. Your feedback helped us a lot during the previous release,
so we hope there
Hi,
there is some information, that the JNI worker in mod_jk does not really
work (since a long time). So it looks like it is not being maintained
any more.
I would like to clarify things for future mod_jk releases:
- is there any information, that the JNI worker is still usable (for
which
Hi William,
which mod_jk version is this based on?
Where can I have a look at the code?
Regards,
Rainer
William L. Thomson Jr. wrote:
Your timing is perfect, not. I just added code to the mod_jk ebuild on
Gentoo to build and install the JNI stuff, yesterday. :( Although no one
requested it,
Getting a positive feedback from you (it works!) will help :)
We plan starting the vote on thursday, so if we do not run in a blocker
the release should be official at the end of the week.
Regards,
Rainer
Peter Huber schrieb:
Thanks for the quick response. Is there any release date fixed for
On 02.03.2010 20:54, Filip Hanik - Dev Lists wrote:
Time for another one folks? Should I tag end of this week?
There has been a lot of code changes in the 5.5.x branch, so I would
expect some regressions, (similar experience to 6.0.x). So after this
one, we can roll a bit more frequently until
On 03.03.2010 00:14, Bill Stoddard wrote:
On 3/2/10 1:33 PM, William A. Rowe Jr. wrote:
On 3/2/2010 7:18 AM, Mark Thomas wrote:
On 02/03/2010 00:20, Sandro Martini wrote:
For a Full Administration Console (I don't see this since a long time)
we have to see later, this is complex and requires
On 02.03.2010 10:14, mt...@apache.org wrote:
Author: mturk
Date: Tue Mar 2 09:14:44 2010
New Revision: 917928
URL: http://svn.apache.org/viewvc?rev=917928view=rev
Log:
Port SSLInsecureRenegotiation from mod_ssl
Modified:
tomcat/trunk/java/org/apache/tomcat/jni/SSL.java
On 05.03.2010 21:37, jean-frederic clere wrote:
On 03/05/2010 09:24 PM, Henri Gomez wrote:
Hi to all,
I sent some patches to Jean-Fred about the LocalString_fr.properties.
I have noticed it is in fact fix in trunk but not in tc6.0.x I have
submitted a new proposal. Please double check... It
I lost track w.r.t. UTF-8 conversion: is it still OK to use ISO-8859
encoded message strings in the tc 5.5.x LocalStrings_XX.properties
files? We removed all of them in trunk and TC 6.0.x but there are lots
of them in TC 5.5.x. Any need to change?
Regards,
Rainer
On 06.03.2010 13:09, Konstantin Kolinko wrote:
2010/3/6rj...@apache.org:
Author: rjung
Date: Sat Mar 6 11:44:50 2010
New Revision: 919747
URL: http://svn.apache.org/viewvc?rev=919747view=rev
Log:
Add proposal.
+
+* Remove ISO-8859 encoding from all properties files using native2ascii.
+
+1
On 07.03.2010 22:40, Tim Whittington wrote:
I've committed this change now.
I replaced USE_RAW_HEADERS with USE_CGI_HEADERS, and inverted all the
conditionals.
cheers
tim
On Mon, Feb 8, 2010 at 9:13 PM, Tim Whittingtont...@apache.org wrote:
OK, the most conservative change will be to
On 08.03.2010 20:00, Konstantin Kolinko wrote:
I propose to relax our RTC policy and use CTR for the types of changes
listed below:
2. I think that we can have C-T-R for any svn metadata (svn:
properties), as those are not the code. I am +1.
Allow C-T-R for changes to svn properties:
[ ]
On 14.03.2010 08:07, Mladen Turk wrote:
Hi,
I would suggest that we use JIRA instead maintaining STATUS.txt files.
Each branch can then be a separate component and each status vote
JIRA issue classified as either bug, feature, etc...
Voting is supported except that one cannot vote for the
Welcome! Have Fun :)
On 31.03.2010 21:29, Filip Hanik - Dev Lists wrote:
On behalf of the Tomcat committers I am pleased to announce that Keiichi
Fujino (kfujino) has been voted in as a new Tomcat committer.
Please join me in welcoming him.
Regards,
Filip
On 14.04.2010 16:13, Mladen Turk wrote:
Apr 14, 2010 4:12:16 PM org.apache.catalina.startup.Catalina startInternal
INFO: Server startup in 965 ms
^^
Impressive!
Cheers,
Rainer
-
To
On 14.04.2010 20:52, Mladen Turk wrote:
On 04/14/2010 08:35 PM, Rainer Jung wrote:
On 14.04.2010 16:13, Mladen Turk wrote:
Apr 14, 2010 4:12:16 PM org.apache.catalina.startup.Catalina
startInternal
INFO: Server startup in 965 ms
^^
Impressive!
8 core i7 does the remaining :)
Naaa
On 15.04.2010 17:37, Konstantin Kolinko wrote:
2010/4/12 Florian Kirchhoffflorian.kirchh...@qwest.com:
Hi,
first please forgive me for the apparent x-post (my previous post was
hi-jacked and thus is ignored by most relevant contributors, see
I updated OACC with all relevant patches from TC 5.5.x, TC 6.0.x and one
form trunk between September 2009 and now. Have fun.
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional
On 16.04.2010 18:34, Konstantin Kolinko wrote:
Hi!
I propose to drop the org.apache.tomcat.util.collections package in
our trunk (TC7).
+1
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional
Just a short note: I stumbled over the ForceGarbageCollection JVMTI
function today. It reliably triggers a full GC and the call only returns
after having run the GC. It will do so, even when System.gc() is
disabled. It looks like it doesn't respect ExplicitGCInvokesConcurrent,
so it will
On 22.04.2010 18:51, Mark Thomas wrote:
On 22/04/2010 17:40, Rainer Jung wrote:
Experimenting on the extreme side of things: when trying to use
aliases=/=/some/path I can't get any resource to load:
- there is /some/path/test.properties
- servletContext().getResourceAsStream(/test.properties
On 23.04.2010 12:04, Mark Thomas wrote:
On 23/04/2010 10:51, Rainer Jung wrote:
On 22.04.2010 18:51, Mark Thomas wrote:
On 22/04/2010 17:40, Rainer Jung wrote:
Experimenting on the extreme side of things: when trying to use
aliases=/=/some/path I can't get any resource to load
There is a previously undocumented VirtualWebappLoader, which extends
WebappLoader and allows to add search paths (repositories) to the webapp
class loader.
I added a bit of docs yesterday and the option to configure, whether the
additional repositories will be searched first or last (this is
On 25.04.2010 23:18, Sylvain Laurent wrote:
I don't understand what would be the purpose of this feature. Is it
in order to really force a GC when clicking on the Find leaks
button of the manager ?
Yes
If it's for that, I don't think it's worth
the trouble. People really interested in fixing
On 26.04.2010 06:46, Konstantin Kolinko wrote:
2010/4/23 Mark Thomasma...@apache.org:
On 23/04/2010 12:30, Rainer Jung wrote:
On 23.04.2010 12:04, Mark Thomas wrote:
On 23/04/2010 10:51, Rainer Jung wrote:
On 22.04.2010 18:51, Mark Thomas wrote:
On 22/04/2010 17:40, Rainer Jung wrote
by the leak prevention. Since we know
the code, it was because its context class loader was equal to the
WebappClassLoader of /manager. That's what I don't understand. See my
original post.
Regards,
Rainer
On 6 mai 2010, at 20:51, Rainer Jung wrote:
While doing some testing with 6.0.26 I
On 07.05.2010 11:00, Konstantin Kolinko wrote:
2010/5/7 Rainer Jungrainer.j...@kippdata.de:
I'm wondering why the PCKS Token
Poller thread was captured by the leak prevention. Since we know the code,
it was because its context class loader was equal to the WebappClassLoader
of /manager. That's
On 07.05.2010 14:23, Konstantin Kolinko wrote:
2010/5/7 Rainer Jungrainer.j...@kippdata.de:
On 07.05.2010 11:00, Konstantin Kolinko wrote:
2010/5/7 Rainer Jungrainer.j...@kippdata.de:
I'm wondering why the PCKS Token
Poller thread was captured by the leak prevention. Since we know the
code,
On 07.05.2010 20:08, Filip Hanik - Dev Lists wrote:
On 05/07/2010 08:03 AM, Rainer Jung wrote:
It's there after JDK start with some version of the JDK. It's not
there if I only start a plain Java test doing only a sleep using the
same JDK.
well, if the app uses java.net.URL to a https
Hi Konstantin,
On 09.05.2010 11:38, Konstantin Kolinko wrote:
2010/5/9 Rainer Jungrainer.j...@kippdata.de:
On 07.05.2010 20:08, Filip Hanik - Dev Lists wrote:
On 05/07/2010 08:03 AM, Rainer Jung wrote:
It's there after JDK start with some version of the JDK. It's not
there if I only start
On 06.05.2010 20:51, Rainer Jung wrote:
While doing some testing with 6.0.26 I noticed, that when shutting it
down it logs an error about thread Poller SunPKCS11-Solaris not being
stopped. When I add the more explicit logging from tc6 trunk, it says
the thread was started by /manager
501 - 600 of 2013 matches
Mail list logo
