memory usage (in top for example), this
is the memory usage of your process. You can confirm this output
with a call to Runtime.getRuntime().totalMemory().
--
Denis Benoit
--
To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands,
of changes is available in the
> release notes.
> It is proposed that it recieves a Stable rating. The existing 4.1.10
> release will be retired.
>
>
> +1 [X] Yes, I approve this release
> -1 [ ] No, because:
>
>
--
Denis Benoit
[EMAIL PROTECTED]
--
To unsubscribe,
of 4.1.X. At that point,
I would be willing to propose a patch if everybody agrees on this approach.
For now, I'm more eager to see a stable 4.1.X, than to have SSO work in all
scenarios :)
Agreed?
On Mon, 8 Jul 2002 [EMAIL PROTECTED] wrote:
> On Mon, 8 Jul 2002, Denis Benoit wrote:
n" and it would not find the session, or worse,
find another session. At that point, all hell break loose...
On Mon, 8 Jul 2002, Tim Funk wrote:
> Would this new solution be compatible with URL rewriting? (No cookies
> being used)
>
> [EMAIL PROTECTED] wrote:
> > On Mon,
utside'
> we would only use the standard JSESSIONID cookie / path param.
>
> Costin
>
> On Thu, 4 Jul 2002, Denis Benoit wrote:
>
> > Hi,
> >
> > With the current code (TC 4.1.6), the single signon does not work with the
> > loadbalancer connector.
support the proposal
> [ ] -0 I do not support the proposal
> [ ] -1 I am against the proposal being implemented, because:
>
>
>
>
> The vote will run for one full week until July 9th. Users and other
> contributors may vote, but only committers have binding votes.
&g
On Fri, 5 Jul 2002, Remy Maucherat wrote:
> Note: The 4.1.7 release is virtually equivalent to 4.1.6, with the
> addition of one major fix in Coyote JK 2 (fix for bug 10018). This is
> why I'm posting the stability vote so soon after the release, given
> 4.1.6 has been around for enough time,
found.
Comments?
--
Denis Benoit
[EMAIL PROTECTED]
Tél: (514)879-5168
**
Financière Banque Nationale et NBCN n'assument
aucune responsabilité quant à la confidentialité et l'intégrité du
présent courriel en raison d
;lose" the session. If a
> request
> for a session that is "retired" comes in (like a page fault), we can
> retrieve it from disk.
>
> Granted, this is more complex, and we face a possible new attack (requests
> for retired sessions that are actually very very old or
gt; especially those with tag invokations. His knowledge in JSTL would
> make him an invaluable addition to the tomcat development community.
+1 Welcome!
--
Denis Benoit
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
Denis Benoit
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
ajor issues, so it looks like
> a decent beta candidate.
--
Denis Benoit
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
s approach allows for optimizations in
> iterations. Instead of acquiring a tag handler from the appropriate
> stack and returning it to the stack in each iteration step, the tag
> handler could be acquired at the beginning of the iteration and held
> on to for the duration of th
a Jasper 3 / Tomcat 5
thing :) At that time, it could be further investigated the benefits and
penalties of this approach. But if we choose to delegate each tag to a method,
I think it would be important to leave the door open to tag reuse, that is if we
do not implement it at the same time.
Comments?
--
Denis Benoit
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
w hours and take a stance,
or maybe propose something :) I sure hope that I can help in some way work on
this class that I came to know more closely with my previous patch, and in other
parts of Tomcat... I have other ideas :) I really liked working with Kin-Man
(I hope it was mutual!), and I look
rintln(" throws javax.servlet.jsp.JspException {");
- }
-
- public void done() {
- finalOutput.println(" }");
- }
-
- public void beginPartMethod(int bit) {
- finalOutput.print("if (bitmask.get(");
- finalOutput.print(bit);
- finalOutput.println(")) {");
- }
-
- public void endPartMethod() {
- finalOutput.println("}");
- finalOutput.println();
- }
-
- public void println(String aLine) {
- if (null != aLine) {
- finalOutput.print(aLine);
- }
- finalOutput.println();
- }
-
- public void printin(String partLine) {
- finalOutput.print(" ");
- finalOutput.print(partLine);
- }
-
- public void print(String partLine) {
- finalOutput.print(partLine);
- }
-
- public String toString() {
- return rawOutput.toString();
- }
- }
-
}
--- 1529,1533
--
Denis Benoit
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
m(rawOutput, true);
-
- finalOutput.println();
- finalOutput.println(" private void finallies(java.util.BitSet bitmask,
JspWriter out, java.util.Vector tags, PageContext pageContext)");
- finalOutput.println(" throws javax.servlet.jsp.JspException {");
-
On Fri, 17 May 2002, Kin-Man Chung wrote:
> I'll implement maximum tag nesting (though PageInfo) and you can work on
> #1. Deal?
Deal!
Thanks!
--
Denis Benoit
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mai
method, this is the one that initiates the visit(XXX) calls, right?.
Would you like me to propose a patch for #1? For #2? And what about having
the maximum CustomTag nesting depth level available through PageInfo?
Thanks!
--
Denis Benoit
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
ber of tags in the page
from the PageInfo object. This would be cleaner, because we could then declare
the array at the top of the generated java file.
In a word I'm very much willing to produce such a patch. But, we have to think
if now is the appropriate time. Jasper2 is in the process of
"element of the row" would be the index in the Tag array to apply
the action to (only meaningful for "release()").
The state array is "final static", built at compile time and never modified
for a given JSP, so thread safe. The finallies method would only have to
l
essage cryptic (it is!), to determine what's exactly the
problem. The _jsp_service method can be really long, even without the
"finallies" being inlined. That's why I had created a new method.
Your idea of getting information from the PageInfo is certainly welcome. This
way we
ready
in the vector when we reach the pseudo "finally" block;
Thanks!
--
Denis Benoit
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
On Mon, 29 Apr 2002, Remy Maucherat wrote:
> This looks like a good idea to me (Kin-Man is not there this week, so it's
> not an expert opinion). I would see that kind of change going into Jasper 2,
> though. Do you think you can prepare a patch against that version ?
>
> Remy
>
>
> --
> To un
Index:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.6
diff
nd compare it the the "old" code.
Comments or suggestions are welcome.
Thanks!
--
Denis Benoit
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
26 matches
Mail list logo
