Costin Manolache wrote:
Bill Barker wrote:
I, personally, think that it's time for a branch in j-t-c. At this point,
even Tomcat 3.3 won't build against the HEAD.
My proposal is: Revert the JMX dependencies in j-t-c, Create a branch
(e.g.
coyote_10), and re-apply the JMX patches to the HEAD
Bill Barker wrote:
I saw just the opposite. Jasper2 with tag-pooling was a real dog (the time
spent in synchronized methods to maintain the pool completely swamped any
benefit from GC). After patching my copy to make don't-tag-pool the default
(since there isn't any way to do this in the config
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Saturday, January 18, 2003 12:36 AM
Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
Bill Barker wrote:
I saw just the opposite. Jasper2 with tag-pooling
Bill Barker wrote:
Yeah, well, almost all of my JSP pages are defined by:
servlet
servlet-namesomename/servlet-name
jsp-page/somepath/somepage.jsp/jsp-page
/servlet
And I can assure you that the params for JspServlet don't work at all
(unless I take the totally brain-dead path of including
Hi,
I feel providing Object Pooling ability to tomcat would be very useful.
Database connection pooling would be very useful for a lot of users.
I have been doing it as a separate component.I wrote for my purpose and bundled with
the tomcat my folks are using.I have used the Object pooling
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=10026.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Bill Barker wrote:
I, personally, think that it's time for a branch in j-t-c. At this point,
even Tomcat 3.3 won't build against the HEAD.
My proposal is: Revert the JMX dependencies in j-t-c, Create a branch (e.g.
coyote_10), and re-apply the JMX patches to the HEAD branch. Tomcat 3.3 and
--- Manveen Kaur [EMAIL PROTECTED] wrote:
Hi,
I have a web-app that looks up a properties file.
I'm getting a java.util.MissingResourceException on
ResourceBundle.getBundle(..);
The jar containg the properties file is in WEB-INF/lib.
Could you post the code snippet that tries to load
Glenn Nielsen wrote:
Bill Barker wrote:
ballot
[ ] +1 I Support the idea of a branch, and will help maintain it.
[ ] +0 I like the idea
[ ] -0 I don't like the idea
[X] -1 I'm against the idea of branching
/ballot
Before branching and having to maintain patches in two branches,
why not try
On Saturday 18 January 2003 06:41 am, White Knight wrote:
Hi,
I feel providing Object Pooling ability to tomcat would be very useful.
Database connection pooling would be very useful for a lot of users.
I have been doing it as a separate component.I wrote for my purpose and
bundled with 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=16234.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I patched jasper2 and tagpool to synchronize only at begin/end of the jsp site
= 2 syncs per request
Torsten Fohrer
On Saturday 18 January 2003 10:24, you wrote:
Bill Barker wrote:
Yeah, well, almost all of my JSP pages are defined by:
servlet
servlet-namesomename/servlet-name
Remy Maucherat wrote:
Glenn Nielsen wrote:
Bill Barker wrote:
ballot
[ ] +1 I Support the idea of a branch, and will help maintain it.
[ ] +0 I like the idea
[ ] -0 I don't like the idea
[X] -1 I'm against the idea of branching
/ballot
Before branching and having to maintain patches in two
Glenn Nielsen wrote:
Before branching and having to maintain patches in two branches,
why not try to fix the builds and/or change the implemenation of the
additional JMX support so that it can be built optionally.
Sorry, but this is not possible, and I will *not* include these changes
in
Glenn Nielsen wrote:
Why is it not possible to add (optional) JMX support to j-t-c components so
that we don't have to branch?
I did not say anything about 4.1, just that I feel it is preferable to not
have to maintain two j-t-c code bases.
You can't have everything JMX being optional, it
Bill Barker wrote:
If tag-pooling works for you, I'm happy for you. The current
implementation
doesn't work for me big time. However, I'm very interested in Costin's
claim that it can be done thread-local.
One quick question ( looking at generated code ) - why is the TP limited
to 5
Costin Manolache wrote:
Bill Barker wrote:
If tag-pooling works for you, I'm happy for you. The current
implementation
doesn't work for me big time. However, I'm very interested in Costin's
claim that it can be done thread-local.
One quick question ( looking at generated code ) - why is
one questions? can jasper not use a simply synchronized block on the jsp
instance, getting 1 tag instance/class/declaration and stores it somewhere,
as a example in the pageContext/local variable, and synchronize later in the
finally block and puts back the tag instances.
Torsten
On Saturday
I agree that the currnet Jasper tag pooling could be improved.
Per JSP Page (current)
--
The current tag pool manages one or more pools of tags on a per JSP
page basis. With a synchronized method call for each get/reuse pair
for a TagHandler used in the page. That page could
Glenn Nielsen wrote:
Bill Barker wrote:
I, personally, think that it's time for a branch in j-t-c. At this
point,
even Tomcat 3.3 won't build against the HEAD.
My proposal is: Revert the JMX dependencies in j-t-c, Create a branch
(e.g.
coyote_10), and re-apply the JMX patches to the HEAD
Remy Maucherat wrote:
If tag-pooling works for you, I'm happy for you. The current
implementation
doesn't work for me big time. However, I'm very interested in Costin's
claim that it can be done thread-local.
One quick question ( looking at generated code ) - why is the TP limited
to 5
please, correct my if i be wrong.
On Saturday 18 January 2003 22:56, you wrote:
I agree that the currnet Jasper tag pooling could be improved.
Per JSP Page (current)
--
The current tag pool manages one or more pools of tags on a per JSP
page basis. With a
Hans Bergsten wrote:
Costin Manolache wrote:
[...]
Wow. I would be _very_ curious to see those benchmarks and the modern
JVM that was used.
All my tests ( including JDK1.4, IBM vms, GCJ ) show that reusing is well
worth the trouble - at least if you have 100s of requests per second
( it is not
23 matches
Mail list logo
