Al,
It sounds like the pattern you're proposing is the Strategy design
pattern (see Design Patterns by the four authors). Basically, an object
has multiple possible delegate objects, each of which implement a common
interface. Then, as the state changes, the strategy can switch from one
Hi all,
we have recently migrated a web application from using poolman to dbcp. The
db driver used for this application is jconnect.
During some long-term tests, we observed a memory-leak like behaviour,
caused by a growing number of objects on the heap which could not be garbage
collected.
+1
Kevin Ross - Xindice committer (Jelly user)
-Original Message-
From: bob mcwhirter [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 19, 2003 1:21 AM
To: Jakarta Commons Developers List
Subject: [VOTE] [committer] Peter Royal commons committer (specifically
jelly)
I'd like to
--- [EMAIL PROTECTED] wrote:
Al,
It sounds like the pattern you're proposing is the Strategy design
pattern (see Design Patterns by the four authors). Basically, an object
has multiple possible delegate objects, each of which implement a common
interface. Then, as the state changes,
On Thursday, June 19, 2003, at 11:10 AM, Jason van Zyl wrote:
If you are compiling a bit of Jelly to a Script what resources must be
present to simply compile. This bit of Jelly may have various
references
to classes that must be loaded and my question is must these resources
be present for the
--- Al Chou [EMAIL PROTECTED] wrote:
--- Phil Steitz [EMAIL PROTECTED] wrote:
--- Tim O'Brien [EMAIL PROTECTED] wrote:
On Tue, 17 Jun 2003, Mark R. Diggory wrote:
We all agree that the optimized double[]|- double computations should be
reused. The problem with the above is that you
Maybe I'm unique, but
sometimes I find that Java (as well as other languages) gets in my way
rather
than letting me solve the problem at hand in a natural way.
You're not alone in that belief. I've heard several people comment about
how easy it is to code Smalltalk when exploring new
I'm not an active committer to commons-jelly, but I trust Bob's
recommendation, and it is true that Jelly needs a champion.
+1
Tim
On Thu, 19 Jun 2003, bob mcwhirter wrote:
I'd like to recommend Peter Royal (proayl) as a commons committer.
He's a core developer in Avalon land, and I've
On Thu, 2003-06-19 at 11:28, Tim O'Brien wrote:
I'm not an active committer to commons-jelly, but I trust Bob's
recommendation, and it is true that Jelly needs a champion.
+1
+1
Tim
On Thu, 19 Jun 2003, bob mcwhirter wrote:
I'd like to recommend Peter Royal (proayl) as a commons
On Thu, 2003-06-19 at 11:43, Jason van Zyl wrote:
On Thu, 2003-06-19 at 11:17, Peter Royal wrote:
On Thursday, June 19, 2003, at 11:10 AM, Jason van Zyl wrote:
If you are compiling a bit of Jelly to a Script what resources must be
present to simply compile. This bit of Jelly may have
Phil Steitz wrote:
--- Brent Worden [EMAIL PROTECTED] wrote:
I am also a little confused by J's analysis. Do we know
definitively that using
J2SE, there is precision loss in Math.pow(x,n) vs x*x*...*x (n
terms) for small
integer n? If the answer is yes, we should establish the
guideline that
--- David Graham [EMAIL PROTECTED] wrote:
Maybe I'm unique, but
sometimes I find that Java (as well as other languages) gets in my way
rather
than letting me solve the problem at hand in a natural way.
You're not alone in that belief. I've heard several people comment about
how
Mark R. Diggory wrote:
J.Pietschmann wrote:
No. If you cast the base into a double there is not much risk of
overflow: double x = n; y=x*x; or y=((double)n)*((double)n);
or even y=n*(double)n; (but avoid y=(double)n*n).
Double mantissa has IIRC 52 bits, this should be good for integers
up to
David Graham wrote:
--- David Graham [EMAIL PROTECTED] wrote:
Maybe I'm unique, but
sometimes I find that Java (as well as other languages) gets in
my way
rather
than letting me solve the problem at hand in a natural way.
You're not alone in that belief. I've heard several people
Mark R. Diggory wrote:
(1) It is very important to also use ((double)x)*x instead of
(double)(x*x), as the loss of precision starts to occur at far greater
values than overflow occurs if one were doing integer arithmetic
IIRC Java shares also the C behaviour in that n*n becomes
negative instead
J.Pietschmann wrote:
Mark R. Diggory wrote:
J.Pietschmann wrote:
No. If you cast the base into a double there is not much risk of
overflow: double x = n; y=x*x; or y=((double)n)*((double)n);
or even y=n*(double)n; (but avoid y=(double)n*n).
Double mantissa has IIRC 52 bits, this should be good
--- Phil Steitz [EMAIL PROTECTED] wrote:
--- Al Chou [EMAIL PROTECTED] wrote:
I would prefer that
commons-math be easy for users to use than for it to stick closely to
typical
Java designs just for the sake of staying Java-ish.
I agree; but actually sticking to Java-ish design
J.Pietschmann wrote:
Mark R. Diggory wrote:
(1) It is very important to also use ((double)x)*x instead of
(double)(x*x), as the loss of precision starts to occur at far
greater values than overflow occurs if one were doing integer arithmetic
IIRC Java shares also the C behaviour in that n*n
I agreed with you upto that last sentence, My viewpoint: The whole point of
the java.util.Math class is that the functions are so standardized and so
final (on top of that mostly native) that they shouldn't really ever be
overridable, they are utility functions that one can rely to be of a
Static methods are a necessary evil in OO languages and should be
avoided when possible.
I disagree. Static functions are similar to Aspect Oriented Programming,
such as AspectJ which centrializes
code across many classes that is similar in functionality. This
eliminates duplicate code, and
Static methods are a necessary evil in OO languages and should be avoided
when possible.
I disagree. Static functions are similar to Aspect Oriented Programming,
such as AspectJ which centrializes
code across many classes that is similar in functionality. This eliminates
duplicate code, and
David Graham wrote:
Static methods are a necessary evil in OO languages and should be
avoided when possible.
I disagree. Static functions are similar to Aspect Oriented
Programming, such as AspectJ which centrializes
code across many classes that is similar in functionality. This
eliminates
olegk 2003/06/19 13:52:08
Modified:httpclient/src/java/org/apache/commons/httpclient/methods
PostMethod.java
httpclient/src/test/org/apache/commons/httpclient
TestMethodCharEncoding.java TestMethodsNoHost.java
David Graham wrote:
Static methods are a necessary evil in OO languages and should be
avoided when possible.
I disagree. Static functions are similar to Aspect Oriented
Programming, such as AspectJ which centrializes
code across many classes that is similar in functionality. This
eliminates
olegk 2003/06/19 14:09:19
Modified:httpclient release_notes.txt
Log:
Changelog updated
Revision ChangesPath
1.5 +3 -0 jakarta-commons/httpclient/release_notes.txt
Index: release_notes.txt
luehe 2003/06/19 14:12:07
Modified:xdocscomponents.xml
Log:
Added commons-el release
Revision ChangesPath
1.91 +15 -0 jakarta-commons/xdocs/components.xml
Index: components.xml
===
+1, and I'm willing to help prepare RCs for the core
Jelly library.
- Morgan
--- bob mcwhirter [EMAIL PROTECTED] wrote:
I'd like to recommend Peter Royal (proayl) as a
commons committer.
He's a core developer in Avalon land, and I've
worked with on
the jaxen (non-jakarta) project.
luehe 2003/06/19 14:38:58
Modified:xdocsel.xml
Log:
Updated commons-el page with release info
Revision ChangesPath
1.2 +22 -7 jakarta-commons/xdocs/el.xml
Index: el.xml
===
RCS file:
luehe 2003/06/19 14:40:47
Modified:el build.xml
Log:
Updated build version number
Revision ChangesPath
1.7 +2 -2 jakarta-commons/el/build.xml
Index: build.xml
===
RCS file:
Here's the tally I have:
+1 for:
bob mcwhirter
kevin ross
jason van zyl
morgan delagrange
paul hammant (non-binding?)
tim o'brien (non-binding?)
-1 (against):
none
0 (active abstain):
none
So, at least 4 binding +1s and no
Well, I have never used that class, so I can definitly NOT venture an
opinion! Having said that, if you provide patches to fix the code, and good
unit tests to prove the old code works and the new code works, then I would
be happy to apply your fixes.
What would be great is to first submit a
mbecke 2003/06/19 16:28:20
Modified:httpclient/src/java/org/apache/commons/httpclient URI.java
httpclient/src/test/org/apache/commons/httpclient
TestURI.java
httpclient release_notes.txt
Log:
Updated URI path resolution to
mbecke 2003/06/19 16:37:16
Modified:httpclient release_notes.txt
Log:
Removed spurious control characters.
Revision ChangesPath
1.7 +15 -15jakarta-commons/httpclient/release_notes.txt
Index: release_notes.txt
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=20931.
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=20931.
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=20844.
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=20933.
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=20933.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
mbecke 2003/06/19 18:11:23
Modified:httpclient release_notes.txt
Log:
Removed spurious control characters(again). Thanks to Tetsuya Kitahata for catching
this.
Revision ChangesPath
1.8 +15 -15jakarta-commons/httpclient/release_notes.txt
Index:
Hi,
Just for fun I set up a little test app. It demonstrates that the bug
is definitely in Common Beanutils. Normal Java relfection can call a
method derived from a protected nested class without problems. The
problem seems to be in o/a/c/b/MethodUtils.java : line 442ish where
Beanutils
Eric Johnson wrote:
Ortwin,
It is an odd problem. Not quite a dead-lock in the traditional sense.
One thread is waiting on the other, and the other is waiting for the
garbage collector. It just so happens that the garbage collector will
never kick in, because the first thread happens to be
Odi,
HttpClient doesn't depend on the GC, it depends on the user telling us
when the connection is no longer in use (which Eric discovered he
hadn't done). There is however a fallback whereby when a
HttpConnection is garbage collected (ie: when we discover that it is no
longer in use), it
Adrian Sutton wrote:
Odi,
HttpClient doesn't depend on the GC, it depends on the user telling us
when the connection is no longer in use (which Eric discovered he hadn't
done). There is however a fallback whereby when a HttpConnection is
garbage collected (ie: when we discover that it is no
Also, connections release themselves when there is no more data to be
read from the stream.
The solution in this case is to always call releaseConnection() when
you're finished with the connection (as is mentioned lots and lots
through our docs :) and I really can't see any better way to deal
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=20481.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
[EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2003-06-19 14:54 ---
Are there any objections, comments to this patch?
Oleg
Okay with me. Maybe UPPERCASE the BitSet identifier?
-
To unsubscribe,
Yep. Static variables should be in upper case. Will be done.
Oleg
-Original Message-
From: Ortwin Glck [mailto:[EMAIL PROTECTED]
Sent: Thu 6/19/2003 17:03
To: Commons HttpClient Project
Cc:
Subject:Re: DO NOT REPLY [Bug 20481] - HttpClient does not properly
Hey Adrian,
Thanks for responding. Contrib class would fine and I
would be willing to do it. Do you have a suggestion on a
name? I agree with your assessment about configurating
the whole can of worms, but some solution was better than
none. The only other thing I could think of would be
Eric,
I would rather keep web.xml file parsing out. We have to maintain compatibility with
Java 1.2.2 for which JAXP is an optional component. I do not think we should introduce
JAXP as a dependency for HttpClient.
Oleg
-Original Message-
From: [EMAIL PROTECTED] [mailto:[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=20481.
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=20481.
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=20665.
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=20665.
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=20665.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Thanks a lot for that Eric. I've got it in a virtual sticky for the
moment and hopefully will do up a proper page for the site over the
weekend. Rest assured though that it hasn't been ignored (those damn
virtual stickys just never seem to go away...).
Regards,
Adrian Sutton.
On Tuesday,
Mike,
There still exists x0A0 characters. (LF?)
Here I made a patch for it.
Sincerely,
-- Tetsuya ([EMAIL PROTECTED])
P.S. I sent the same mail to commons-dev.
-
On 19 Jun 2003 23:37:16 -
(Subject: cvs commit:
Howdy all,
I'm having some trouble pinpointing the exact cause of an exception I'm
getting from HttpClient, it seems to be related to connection
management with MultiThreadedConnectionManager so I thought I'd draw on
the expertise here. :)
Essentially, we have an invalid HTTP server
Quite right.
Thanks,
Mike
On Thursday, June 19, 2003, at 08:10 PM, Tetsuya Kitahata wrote:
Mike,
There still exists x0A0 characters. (LF?)
Here I made a patch for it.
Sincerely,
-- Tetsuya ([EMAIL PROTECTED])
P.S. I sent the same mail to commons-dev.
Hello,
I have been putting together a (relatively) comprehensive documentation
of NTLM and its use in various protocols; this is now up and available at:
http://davenport.sourceforge.net/ntlm.html
I figured there might be interest on this list; it only touches briefly
on NTLM HTTP
Eric,
Thanks for pointing this out. I will add a link to it to the
HttpClient NTLM authentication for those who are curious about the more
technical details.
Regards,
Adrian Sutton.
On Friday, June 20, 2003, at 11:12 AM, Eric wrote:
Hello,
I have been putting together a (relatively)
Adrian,
I'm looking into to this and I agree it is quite strange. The part I
don't understand is why the second attempt to write to the socket
fails. The socket is not being closed on the HttpClient side until
after the failure occurs. Any thoughts on how the connection is being
closed?
On Friday, June 20, 2003, at 11:41 AM, Michael Becke wrote:
Adrian,
I'm looking into to this and I agree it is quite strange. The part I
don't understand is why the second attempt to write to the socket
fails. The socket is not being closed on the HttpClient side until
after the failure
Hey Adrian,
Ok, but what about what something below?
MultipartPostMethod mpm = new MultipartPostMethod( http://localhost:8080; +
/something );
mpm.addParameter( A, new File( /usr/dev/images/add.gif ) );
How do I set the content type for the file? It seems either the
addParameter needs to
Eric,
You want to create the FilePart manually and then add it to the
MultipartPostMethod. Something like:
MultipartPostMethod mpm = new MultipartPostMethod(
http://localhost:8080/something; );
FilePart part = new FilePart(name, file, contentType, charset);
mpm.addPart(part);
Mike
On
Yup, I'm trying it on OS X and linux. I think the problem is in
HttpMethodBase.execute() in particular the following line:
if (responseStream != null) {
responseStream.close();
}
Since there is no content length or chunking the response stream is
not being wrapped and is
I have another problem with proxies in that even if
shouldCloseConnection() returns true, the connection to the proxy
isn't actually closed and I'm not sure why. Any hints about where
proxy connections are closed?
Ah, ignore this bit. I'd screwed up the test case so it added a
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=20938.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
67 matches
Mail list logo
