Re: Initial impressions.
Hi, Henri Yandell schrieb: On 2/6/07, Nelson Carpentier [EMAIL PROTECTED] wrote: Hello Everybody! Hopefully, this is more constructive than whiney. I thought I'd share my initial impressions with you about trying to contribute... Even whining can be good once we've got over the natural defensiveness :) I recently got an inkling to add a cool bit of functionality to the EqualsBuilder in the Commons-Lang project. I went through the documentation and stuff, figured out some of the style guidelines and other bits, then went ahead and did a svn co of the code I wanted to help with... Main style guideline for any source is to adhere to the apparent style of the source you're changing. And not to let the IDE reformat things in your patches/commits (just spent a while dealing with a 1200 line patch that was really only 200 lines... grrr). I started up a project in Eclipse and though there were errors showing up everywhere, I was able to get to the code I wanted to change. I started modifying a bit of the code, and only tried to tackle all the errors popping up when I wanted to compile my code and write some tests against it... Odd that there were errors. Lang's a very simple project in that the only dependency it has is JUnit and the only source trees you'll need to hook up are src/java and src/test. There will be lots of style warnings in Eclipse though. That's when I figured out I was having a JDK versioning problem. I Ah, and a bunch of warnings about 'enum'. And probably some deprecated bits. was on a Mac (to which I am fairly new), and everything was running I'm on a Mac too. the default of JDK 1.5. I looked at some more of the documentation and found that the JAR should be built with JDK 1.2. I figured out how to jump back to JDK 1.4.2 on the Mac, and maybe even to the JDK 1.3.X... But no JDK 1.2. There is no 1.2 on the Mac, and getting it on Linux is a pain in the arse (apparantly it was poorly coded and used illegal APIs), so your choices are to use Windows, use an old Linux install or use a glibc patch on Linux. Oh - or use Solaris I presume. Macs went from 1.1.x on OS 9 to 1.3.x on OS X. For the last Lang release I pointed this out and we've moved the JVM on which we build from 1.2 to 1.3. While on JDK 1.4.2, a lot of things seem to resolve themselves, but there are some packages I cannot fix, because they use enum which is a reserved word in later JDK's. I haven't yet checked this in JDK 1.3.X, but I figured Hey, why not go back to the recommended JDK 1.2? The enum stuff is just a warning. Or should be. Are you sure these are errors and not just lots of warnings? I usually use the command line for developing Lang, but I go to Eclipse quite often to do the more in depth debugging. So, I went straight to http://java.sun.com. There in my initial research, I found out that they really aren't keen on even giving out the 1.2 JDK, and there was even a big ol' warning that 1.3.X was soon to be EOL'd (End-of-life'd.). (Nevermind the fact that I am not sure I even COULD get 1.2 installed on my Mac even if I found it...) Once Lang 2.3 is out, I want to start thinking about 3.0 and suggesting the shocking idea of moving the support up to 1.5+. Although moving forward is good most of the times. Such central components like lang should stay behind the current JVM release as long as possible IMHO because other project who are depended on it might not always upgrade to the latest and greatest JVM-Release immediately. I think it is better for these projects to stay at same JVM for a long time and than make a bigger step as proposed by you here. One more thing people might take into consideration (I don't know if applies here) is that java programs are not always running desktop JVMs but also ones for embedded devices, ... and not all classes are available everywhere! Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validator/Digester offline validation
If you use the ValidatorResources(InputStream is) instead of
ValidatorResourcesInitializer(),
to read in the validator files, your Validator.xml will be validated for you.
-Rob
-Original Message-
From: Daniela Pistelli Gomes [mailto:[EMAIL PROTECTED]
Sent: Friday, April 2, 2004 08:41 PM
To: [EMAIL PROTECTED]
Subject: Validator/Digester offline validation
Hi,
I'm using commons-validator and commons-digester and I need to validate the
validation.xml file
without internet access and I don't want to remove the doctye tag.
I knew that I can implement any EntityResolver and set this at Digester, but I
don't have any Digester
instance, my question is, how can I get any Digester instance (or if is possible set
the EntityResolver
by a Digest static method) and them set this Digest for Validator.
At my Validator class I have
private ValidatorResources initResources() throws IOException, SAXException {
final InputStream rules = Thread.currentThread().getContextClassLoader()
.getResourceAsStream(validator-rules.xml);
final InputStream is = Thread.currentThread().getContextClassLoader()
.getResourceAsStream(validation.xml);
try {
return new ValidatorResources(new InputStream[] {rules, is});
} finally {
if (rules != null) {
rules.close();
}
if (is != null) {
is.close();
}
}
}
Thanks for your support
Best Regards
Daniela
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Unit tests failing
-Original Message- --- Martin Cooper [EMAIL PROTECTED] wrote: On Mon, 29 Mar 2004, Niall Pemberton wrote: I think its the ExceptionTest which is failing and it looks like it should from the code. There are three tests in ExceptionTest - only one has code to pass the test if it gets the Exception its expecting - the other two are set to fail. The two test which have failures have code to pass the test if the expected Exception is received but its been commented out and replaced with fail code. Theres a note saying This will be true in Validator 2.0 above the commented out code in one of the tests but that doesn't really explain why the tests have been set up to throw an exception and then fail. I think the bugs are in the test! No, the problems I'm seeing are definitely in the e-mail tests. I've attached the Maven rest reports for the e-mail and exception tests, in which you can see that the former failed, while the latter succeeded. The email tests are known to fail because there is a known bug in EmailValidator. I setup the exception tests and they should pass even though exceptions may get thrown. The stack traces you're seeing is commons-logging at work :-). I believe Rob knows more about the email situation but I think it's fine to release with the bug that's been known for a while now. Correct, these tests are supposed to fail. Basically, the way we do email validation is inadequate. I have a (java not javascript)version based on a Perl version that firsts iteratively strips off any comments before further validation. I wouldn't want to check those changes in since they are far from complete, though I could check in the accompaning perl scripts as DOCUMENTATION if someone else wants to jive it a shot. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Unit tests failing
-Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] I have a bit of trouble with supposed to fail. Perhaps currently expected to fail? ;-) In any case, I'm not comfortable with rolling a release where 'maven clean dist' fails right out of the box. Can we disable the failing tests for now, with a comment explaining why? A Maven(rc1) clean dist works for me, and the site generates cleanly. So I can disable the failing tests which target are you using besides maven clean dist, which works for me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateUtilities.js validateByte.js validateCreditCard.js validateDate.js validateEmail.js validateFloat.js validateFloatRange.js validateIntRange.js validateInteger.js validateMask.js validateMaxLength.js validateMinLength.js validateRequired.js validateShort.js
I realized that after making this patch that there is a DOM
javascript call called getAttribute() that will probably
work better than what I created. What I have will be succeptable
to attribute hiding by an html element named 'attributes' which
I am sure exists in somebody's ActionForm.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 04:56 AM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript
validateUtilities.js validateByte.js validateCreditCard.js validateDate.js
validateEmail.js validateFloat.js validateFloatRange.js validateIntRange.js
validateInteger.js validateMask.js validateMaxLength.js validateMinLength.js
validateRequired.js validateShort.js
rleland 2004/03/24 20:56:12
Modified:validator/src/javascript/org/apache/commons/validator/javascript
validateByte.js validateCreditCard.js
validateDate.js validateEmail.js validateFloat.js
validateFloatRange.js validateIntRange.js
validateInteger.js validateMask.js
validateMaxLength.js validateMinLength.js
validateRequired.js validateShort.js
Added: validator/src/javascript/org/apache/commons/validator/javascript
validateUtilities.js
Log:
Bug#: 27899
Add function to get an objects attribute if hidden by
an html element, in this case the forms name attrubute.
Have validator bring in Utility functions.
Revision ChangesPath
1.8 +4 -2
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateByte.js
Index: validateByte.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateByte.js,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- validateByte.js 8 Mar 2004 23:24:25 - 1.7
+++ validateByte.js 25 Mar 2004 04:56:11 - 1.8
@@ -11,7 +11,9 @@
var focusField = null;
var i = 0;
var fields = new Array();
-oByte = eval('new ' + form.name + '_ByteValidations()');
+var formName = getAttribute(form,name);
+
+oByte = eval('new ' + formName.value + '_ByteValidations()');
for (x in oByte) {
var field = form[oByte[x][0]];
1.7 +4 -2
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js
Index: validateCreditCard.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- validateCreditCard.js 8 Mar 2004 23:24:25 - 1.6
+++ validateCreditCard.js 25 Mar 2004 04:56:11 - 1.7
@@ -11,7 +11,9 @@
var focusField = null;
var i = 0;
var fields = new Array();
-oCreditCard = eval('new ' + form.name + '_creditCard()');
+var formName = getAttribute(form,name);
+
+oCreditCard = eval('new ' + formName.value + '_creditCard()');
for (x in oCreditCard) {
if ((form[oCreditCard[x][0]].type == 'text' ||
1.9 +4 -2
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateDate.js
Index: validateDate.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateDate.js,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- validateDate.js 8 Mar 2004 23:24:25 - 1.8
+++ validateDate.js 25 Mar 2004 04:56:11 - 1.9
@@ -11,7 +11,9 @@
var focusField = null;
var i = 0;
var fields = new Array();
- oDate = eval('new ' + form.name + '_DateValidations()');
+ var formName = getAttribute(form,name);
+
+ oDate = eval('new ' + formName.value + '_DateValidations()');
for (x in oDate) {
var field = form[oDate[x][0]];
1.8 +4 -2
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateEmail.js
Index: validateEmail.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateEmail.js,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- validateEmail.js8 Mar 2004
Re: validator inheritance
This functionality would be very useful, especially for internationalized forms. I would be willing to apply any patches, given that it maintains compatability. JUnit tests would also be needed. -Rob -Original Message- From: Nacho Gonzalez [mailto:[EMAIL PROTECTED] Here is the aproach I was thinking of. I beleive there should only be changes in no more than 2 classes and 1 file: validator.dtd:!ATTLIST formname CDATA #REQUIRED extends CDATA #IMPLIED org.apache.commons.validator.Form (or Bean if it gets changed) should reflect the change in the dtd and a pointer to the Form it extends (this could probably be set int the formSet.process(Map) while iterating the forms of the formSet) The methods getFields() and getFieldMap() should include super.getFields() and super.getFieldMap() making them Unmodifiable after merging. The only restriction would be that the extended form should belong to the formSet but this definetely makes sense! If this makes sense to you, then I am willing to do it (as well as any other necessary changes). If it doesn't make any sense, then I am willing to contribute as I beleive this could be a great improvement. Nacho G. Mac Dowell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validator inheritance
The methods getFields() and getFieldMap() should include super.getFields() and super.getFieldMap() making them Unmodifiable after merging. There would not be true inheritance though, this would be a reference to the extended map. Take a look the Tiles implementation, this would be a good starting point. I believe this implementation makes a copy of the map attributes as you suggest. This can result in increased memory usage. One approaches you might consider is to use a new Map but reference the same underlying objects, ie don't copy them. This would reduce memory consumption. Does anyone dynamically change the validation parameters ? I have always considered the field validations as fixed at load time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH][On Contributing Patches]
http://jakarta.apache.org/commons/patches.html Every time I apply patches I have to go read the manual again, and there isn't a wealth of examples. A meager but helpful reference is: http://www.network-theory.co.uk/articles/patchintro.html Probably the best advice is to first try: the '--dry-run' option to experiment with the options until a combination is found that works. For example using just patch --dry-run -i japanese.diff doesn't work, ie patch couldn't figure out that the patch was created with the '-u' option. So this combination works most of the time: patch --dry-run -u -p0 -i japanese.diff Then when the patch applies cleanly the '--dry-run' can be safely removed and the patch applied for real. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [resources] status was (Re: [lang] i18n package proposal)
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, January 29, 2004 07:28 AM To: 'Jakarta Commons Developers List' Subject: Re: [resources] status was (Re: [lang] i18n package proposal) Quoting Martin Cooper [EMAIL PROTECTED]: On Wed, 28 Jan 2004, Mark R. Diggory wrote: Ask those developing it for a status. Resources developers, what is the status of resources, how close are you to releasing? It's partly my fault, I suspect, that it isn't further down the pike. That's because the last time the promote/release discussion came up, I griped that some refactoring was needed. Unfortunately, it turns out that I was mistaken, since some refactoring had happened without my noticing, but the discussion faded out at that point anyway. So, I think we're actually pretty close to pushing this forward. If the other Resources committers agree, I'd be happy to shoot for promotion to Commons Proper, at which point people could at least start working against nightly builds, while we tie up the loose ends and get a 1.0 release out the door. How does that sound, to committers and non-committers alike? +1. Before a real 1.0 release I would really like to see a JDBC based implementation added, but that doesn't need to be a gating factor for promotion to commons proper (especially if I don't have time to work on it, although it's becoming possible that I might :-). James Mitchell mentioned it was hard to initialize values required to setup the JDBC connection, so the interfaces may have to change inorder to support JDBc access cleanly. If that is then that could be in a 2.0 release. -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allow anonymous issue creation in JIRA? (Re: [PROPOSAL] Jakarta Commons moving to JIRA)
-Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 03:10 AM To: 'Jakarta Commons Developers List' Cc: [EMAIL PROTECTED] Subject: RE: Allow anonymous issue creation in JIRA? (Re: [PROPOSAL] Jakarta Commons moving to JIRA) Would having anonymous issues increase the number of reports that don't have a contact email addresses or invalid email addresses. If so then if we had more questions on how to replicate the bug, and no email contact address then there isn't much that could be done. So you would prefer the option to show the Create Issue option, but require them to create an account? I prefer a account be required, but wouldn't insist on it. At the very minimum to make the contact email address manditory, if they don't have an account. Since Bugzilla verifies the email address when an account is created, we know it isn't bogus. If JIRA required an email address reporters could still put in a fake email address, or make a mistake in typing it in. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allow anonymous issue creation in JIRA? (Re: [PROPOSAL] Jakarta Commons moving to JIRA)
is there any reason we shouldn't enable anonymous issue posting/commenting, if projects want it? Would having anonymous issues increase the number of reports that don't have a contact email addresses or invalid email addresses. If so then if we had more questions on how to replicate the bug, and no email contact address then there isn 't much that could be done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Commons moving to JIRA
I am -1 for moving Jakarta Commons as a --whole-- to JIRA, If each sub-project of commons wants to move then thats ok. Why: There has been a Buzilla 2.16.4 available for some time that fixes several serious security issues. However, we haven't upgraded to that version, or any of the other improved versions, that have come around over the last 2 years. Does infrastructure really want to support 2 bug tracking systems ? I believe that the question of a BugTracking system to use is really an Apache wide decision, since if all projects don't move to JIRA, then there is 2 systems to maintain and learn. Are the JIRA people willing to provide admin type maintance for free ? The biggest improvement would be to treat each commons sub-project, as a project in bugzilla. strongI also think that each committer should automatically be made a buzilla admin./strong As echoed by others I believe we should use OSS software where there is a viable alternative, with similar functionality. -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Monday, January 12, 2004 10:48 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [PROPOSAL] Jakarta Commons moving to JIRA Guys, There are separate requests on the table to move BETWIXT, CLI, CODEC, JEXL and CONFIGURATION from Bugzilla to JIRA. JELLY is already there. Are there any other Jakarta Commons projects that want to migrate? Are there any that do NOT want to leave bugzilla? Right now, each project is a component of Commons. If we move to JIRA, I would propose that we create a Project Category for Jakarta Commons, and make each component a project, so that each one can be released separately with its own versioning, etc. We could use a common scheme for permissions, notifications, etc.. Jelly has a dedicate scheme, but I think we could use a single scheme for all of Jakarta Commons. A bugzilla import will create a single Commons project, but we can then move the issues from the imported project into a new project for each of our real projects. For each TLP, we should probably have a single permission scheme, but I'm not going to get into that argument today. We can create jakarta-administrator and jakarta-commons-developer groups. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Commons-Validator 1.1.1 released
Sorry. Then for now we should withdraw this release, do the vote(s) then rerelease ? I'll remove the release for now until there is some guidance. This is also an issue for Struts 1.2.1 which also intends to use this same set of rules ? -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Monday, December 15, 2003 06:27 PM To: 'Jakarta Commons Developers List' Cc: [EMAIL PROTECTED] Subject: Re: [ANNOUNCE] Commons-Validator 1.1.1 released This release raises some questions, since it follows (?) two sets of conflicting guidelines on how releases should be done. * The Commons guidelines call for a Release Plan to be voted on first, and a Release Candidate to be voted upon subsequent to that, and prior to the release itself. Jakarta also requires a vote prior to a release being made available. * The HTTPD guidelines appear to require no votes prior to the release being made available as an alpha version. Unless I am mistaken, there were no votes on release manager, release plan or release prior to this announcement, all of which are currently required by Jakarta and/or Jakarta Commons. While I understand that using the HTTPD release process might have its advantages, this would require a change to Jakarta and/or Commons rules, which is something that would have to be taken up by the PMC. In the meantime, I believe we need to use the rules that are currently in place. -- Martin Cooper On Mon, 15 Dec 2003, Robert Leland wrote: Commons Validator 1.1.1 is now available for testing. Please refer to http://jakarta.apache.org/commons/validator/tasks.html that details the changes that have taken place since the 1.1.0 release. Downloads: http://jakarta.apache.org/~rleland/ValidatorAlpha/1.1.1 Just a reminder : The release process is following the same general procedures established for the Apache HTTPD project http://httpd.apache.org/dev/release.html and Jakarta Commons products http://jakarta.apache.org/commons/releases/, and utilize the HTTPD numbering scheme. The release will initially be given an Alpha status and made available through the Release Manager's home directory. Pursuant to a Majority Vote on the /commons-dev/ Mailing List, the release may be moved to the public release directory. The vote may also serve to reclassify the release to be of *Beta* or *General Availability* (GA) quality, as defined by the Apache HTTPD project. Subsequent votes may reclassify the release, either to promote it or to demote it, as need be. Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpRecoverableException
] persistence.CheckPerformer - Read Timeout occurred while c ontacting proxy.. java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.net.SocketInputStream.read(SocketInputStream.java:182) at java.io.FilterInputStream.read(FilterInputStream.java:66) at java.io.PushbackInputStream.read(PushbackInputStream.java:120) at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:109) at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:135) at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1049) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.r eadLine(MultiThreadedHttpConnectionManager.java:1055) at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1828) at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1604) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:997) at org.apache.commons.httpclient.HttpMethodDirector.executeMethodForHost(HttpMethodDirector .java:308) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:1 38) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:469) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:355) at org.medra.persistence.CheckPerformer.checkDoi(CheckPerformer.java:316) at org.medra.persistence.Checker.run(Checker.java:96) ... 20031031 11:59:44,522 ERROR [Checker34] persistence.CheckPerformer - IOException occurred while con tacting proxy.. org.apache.commons.httpclient.HttpConnection$ConnectionTimeoutException at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:734) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.o pen(MultiThreadedHttpConnectionManager.java:1020) at org.apache.commons.httpclient.HttpMethodDirector.establishValidOpenConnection(HttpMethod Director.java:247) at org.apache.commons.httpclient.HttpMethodDirector.executeMethodForHost(HttpMethodDirector .java:300) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:1 38) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:469) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:355) at org.medra.persistence.CheckPerformer.checkDoi(CheckPerformer.java:316) at org.medra.persistence.Checker.run(Checker.java:96) I have one question more: in my application each thread sends a POST request to the same server, which, depending on the frequency of these requests, can become unavailable. When this occurs I start getting a lot of these timeout exceptions. I have noticed that at this point the system max open files limit is reached, as this exception starts to be thrown: 20031031 12:00:09,529 ERROR [Checker143] persistence.CheckPerformer - IOException occurred while contacting proxy.. java.net.SocketException: Too many open files at java.net.Socket.createImpl(Socket.java:313) at java.net.Socket.init(Socket.java:286) at java.net.Socket.init(Socket.java:119) at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(Default ProtocolSocketFactory.java:105) at org.apache.commons.httpclient.HttpConnection$1.doit(HttpConnection.java:675) at org.apache.commons.httpclient.HttpConnection$SocketTask.run(HttpConnection.java:1282) at java.lang.Thread.run(Thread.java:536) It's strange that this happens just when a lot of timeouts occurr. Is it possible that HttpConnectionManager is not able to close the timed-out sockets when a timeout occurs? thanks a lot, Fabio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpRecoverableException
Oleg Kalnichevski wrote: IOTimeoutException usually is a wrapper for java.io.InterruptedIOException. I guess the name does not adequately reflect the nature of this exception. I forgot to tell you my opinion about this: the name itself was clear to me, I expected it to be thrown instead of an InterruptedIOException. I just became suspectful after I realized that an InterruptedIOException (java.net.SocketTimeoutException) was actually thrown. Cheers Fabio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HttpRecoverableException
Hi, I'm using the nightly builds version of HttpClient and I have noticed that, when a timeout occurs, neither ConnectTimeoutException nor IOTimeoutException are ever thrown. Instead, HttpConnection.ConnectionTimeoutException and java.net.SocketTimeoutException are thrown in their place. Is this the expected behaviour? If yes, when is HttpRecoverableException thrown? thanks, Fabio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SoTimeout setting
Kalnichevski, Oleg wrote: I have (what appears to me at) a fairly straight-forward approach: allow HttpConnectionParams to be created and customized before physical HttpConnection instance is allocated, when connection manager allocates a connection it can look corresponding parameter object up from a hash map, and, if found, assign it to the connection. End of the story. With the intent to clarify my previous suggestions: this could be the right approach, for setting a timeout on a per-method base is actually a workaround as Oleg pointed out. A control on the HttpConnecction level would be more suitable. But, if I understand well your intent here and the global httpclient architecture, tieing the customization of HttpConnectionParams to a specific HostConfiguration would prevent different method execution attempts on a host from having different (increasing) timeouts.. Am I missing something? Cheers Fabio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SoTimeout setting
Hi, how am I supposed to set the socket timeout for an HttpClient and for different HttpMethods with the new preferences architecture? I don't understand the inheritance scheme: how can HttpMethodParams inherit SO_TIMEOUT from HttpConnectionParams? What is the default value of SO_TIMEOUT for a client and for a method? thanks a lot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SoTimeout setting
Does it mean that I can't set different timeouts for different methods sharing the same client? If not, how can I arrange this? thanks again Kalnichevski, Oleg wrote: Here's the current hierarchy of preference objects Global params ! +--- HttpClient params ! +--- HttpConnectionManager params ! ! ! +--- HttpConnection params ! +--- HttpMethod params Logically SO_TIMEOUT parameter applies to HttpConnection objects. It has nothing to do with HttpMethod objects (at least in my opinion). This way SO_TIMEOUT parameter can be defined at the HttpConnection level or any level above HttpConnection, that is HttpConnectionManager, HttpClient, or Global. HttpConnection will retrieve the value of SO_TIMEOUT from the lowest level at which it is defined. Per default SO_TIMEOUT is undefined, that is, the JVM default value will apply HTH Oleg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 15:08 To: Commons HttpClient Project Subject: SoTimeout setting Hi, how am I supposed to set the socket timeout for an HttpClient and for different HttpMethods with the new preferences architecture? I don't understand the inheritance scheme: how can HttpMethodParams inherit SO_TIMEOUT from HttpConnectionParams? What is the default value of SO_TIMEOUT for a client and for a method? thanks a lot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SoTimeout setting
My scenario is the following: I am trying to share the same client between different threads, each of them should execute an http method to an url, possibly the same url. If a timeout occurs for any one of the executeMethod() calls asynchronously executed by the different threads, I would like to let the thread retry the method with a longer timeout. If I can't modify the timeout for any connections in the pool, how can I get a connection with a different timeout just for that thread and not for all of them? thanks Kalnichevski, Oleg wrote: Are you sure you want to be able to set different SO_TIMEOUT per method, not per connection? Oleg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 16:54 To: Commons HttpClient Project Subject: Re: SoTimeout setting Does it mean that I can't set different timeouts for different methods sharing the same client? If not, how can I arrange this? thanks again Kalnichevski, Oleg wrote: Here's the current hierarchy of preference objects Global params ! +--- HttpClient params ! +--- HttpConnectionManager params ! ! ! +--- HttpConnection params ! +--- HttpMethod params Logically SO_TIMEOUT parameter applies to HttpConnection objects. It has nothing to do with HttpMethod objects (at least in my opinion). This way SO_TIMEOUT parameter can be defined at the HttpConnection level or any level above HttpConnection, that is HttpConnectionManager, HttpClient, or Global. HttpConnection will retrieve the value of SO_TIMEOUT from the lowest level at which it is defined. Per default SO_TIMEOUT is undefined, that is, the JVM default value will apply HTH Oleg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 15:08 To: Commons HttpClient Project Subject: SoTimeout setting Hi, how am I supposed to set the socket timeout for an HttpClient and for different HttpMethods with the new preferences architecture? I don't understand the inheritance scheme: how can HttpMethodParams inherit SO_TIMEOUT from HttpConnectionParams? What is the default value of SO_TIMEOUT for a client and for a method? thanks a lot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SoTimeout setting
Hi, sorry for not having introduced myself..My name is Fabio Capannini,it's not the first time I'm writing to this list:I have filed the bug report 23137 and already asked about the possibilty to set different timeouts for different methods on September the 9th. thanks again your work proves really useful I'm going to file a bug report for this issue. Kalnichevski, Oleg wrote: If I can't modify the timeout for any connections in the pool, how can I get a connection with a different timeout just for that thread and not for all of them? All right. That's the real issue here. If my memory does not fail me, we have already discussed it, agreed that it was a limitation, and I have committed to provide a fix for it. If you want to make sure that the issue does not go forgotten, just file a bug report with the bugzilla. Oleg Kalnichevski, Oleg wrote: Are you sure you want to be able to set different SO_TIMEOUT per method, not per connection? Oleg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 16:54 To: Commons HttpClient Project Subject: Re: SoTimeout setting Does it mean that I can't set different timeouts for different methods sharing the same client? If not, how can I arrange this? thanks again Kalnichevski, Oleg wrote: Here's the current hierarchy of preference objects Global params ! +--- HttpClient params ! +--- HttpConnectionManager params ! ! ! +--- HttpConnection params ! +--- HttpMethod params Logically SO_TIMEOUT parameter applies to HttpConnection objects. It has nothing to do with HttpMethod objects (at least in my opinion). This way SO_TIMEOUT parameter can be defined at the HttpConnection level or any level above HttpConnection, that is HttpConnectionManager, HttpClient, or Global. HttpConnection will retrieve the value of SO_TIMEOUT from the lowest level at which it is defined. Per default SO_TIMEOUT is undefined, that is, the JVM default value will apply HTH Oleg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 15:08 To: Commons HttpClient Project Subject: SoTimeout setting Hi, how am I supposed to set the socket timeout for an HttpClient and for different HttpMethods with the new preferences architecture? I don't understand the inheritance scheme: how can HttpMethodParams inherit SO_TIMEOUT from HttpConnectionParams? What is the default value of SO_TIMEOUT for a client and for a method? thanks a lot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
java exception
/usr/lib/locale/locale-archive 4c681000-4c68c000 r-xp 03:02 3817506/lib/libnss_files-2.3.2.so 4c68c000-4c68d000 rw-p a000 03:02 3817506/lib/libnss_files-2.3.2.so 4c891000-4c93 r--s 03:02 4407519 /usr/java/j2sdk1.4.1_02/jre/lib/ext/localedata.jar 4c93-4c9d2000 r--s 03:02 4407463 /usr/java/j2sdk1.4.1_02/jre/lib/ext/handle.jar 4c9d2000-4c9ef000 r--s 03:02 4407520 /usr/java/j2sdk1.4.1_02/jre/lib/ext/sunjce_provider.jar 4c9ef000-4caca000 r--s 03:02 115139 /usr/java/j2sdk1.4.1_02/jre/lib/ext/xercesImpl.jar 4caca000-4cb1a000 r--s 03:02 4407538 /usr/java/j2sdk1.4.1_02/jre/lib/ext/mail.jar 4cb1a000-4cb5 r--s 03:02 1720799 /usr/java/j2sdk1.4.1_02/jre/lib/ext/commons-httpclient.jar 4cb5-4cba7000 r--s 03:02 4407759 /usr/java/j2sdk1.4.1_02/jre/lib/ext/log4j-1.2.8.jar 4cba7000-4cbce000 r--s 03:02 4260263 /usr/java/j2sdk1.4.1_02/jre/lib/ext/medra.jar 4cbce000-4cbd5000 r--s 03:02 4407543 /usr/java/j2sdk1.4.1_02/jre/lib/ext/sax.jar 4cbd5000-4ce5b000 r--s 03:02 4407545 /usr/java/j2sdk1.4.1_02/jre/lib/ext/xalan.jar 4ce5b000-4ce69000 r--s 03:02 4407544 /usr/java/j2sdk1.4.1_02/jre/lib/ext/activation.jar 4ce69000-4cf34000 r--s 03:02 3866953/home/fabio/ed2k/ed2k_1.1.2.jar 4cf34000-4d4b1000 r--s 03:02 3866958 /home/fabio/java_scratch/WKNDZ3HJ.ZIP 4d4b1000-4d4b9000 r--s 03:02 213241 /usr/java/servlet-2_3-fcs-classfiles.zip 4d53a000-4d54a000 r-xp 03:02 737523 /usr/java/j2sdk1.4.1_02/jre/lib/i386/libnet.so 4d54a000-4d54c000 rw-p f000 03:02 737523 /usr/java/j2sdk1.4.1_02/jre/lib/i386/libnet.so 4dbd9000-4dbdf000 r--s 03:02 4915387/usr/lib/gconv/gconv-modules.cache 4e805000-4e81 r-xp 03:02 3817514/lib/libnss_nisplus-2.3.2.so 4e81-4e811000 rw-p a000 03:02 3817514/lib/libnss_nisplus-2.3.2.so 4e811000-4e814000 r-xp 03:02 3817503/lib/libnss_dns-2.3.2.so 4e814000-4e815000 rw-p 3000 03:02 3817503/lib/libnss_dns-2.3.2.so 4e815000-4e824000 r-xp 03:02 3817518/lib/libresolv-2.3.2.so 4e824000-4e825000 rw-p f000 03:02 3817518/lib/libresolv-2.3.2.so Local Time = Fri Oct 24 17:48:22 2003 Elapsed Time = 459 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_02-b06 mixed mode) # - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re:[VOTE][NET] Release Commons/Net v1.1.0
This is a call for a vote to release version 1.1.0 of Commons/Net. Links to the release canidate and changes may be found on the Commons/Net web site. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setBodyCheckTimeout causes problems in closing the connection
]);
}
}
/*if ((certificates != null) (certificates.length == 1)) {
X509Certificate certificate = certificates[0];
try {
certificate.checkValidity();
}
catch (CertificateException e) {
LOG.error(e.toString());
return false;
}
return true;
} else {
return this.standardTrustManager.isServerTrusted(certificates);
}*/
return true;
}
/**
* @see com.sun.net.ssl.X509TrustManager#getAcceptedIssuers()
*/
public X509Certificate[] getAcceptedIssuers() {
return this.standardTrustManager.getAcceptedIssuers();
}
}
Many thanks again..
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net][patch] jdk 1.4 specific call in VMSFTPEntryParser.java
How about and RC1 relase _and_ a freeze on new items for a month? Fine by me. Wasn't there a fix coming in by 8/10 or something? I think I remember reading that last week or something. Yes, there is a small enhancement to TelnetClient pending (notification of changes in state of telnet options, requested by Marco Isella). I'm going to commit this enhancement by 8/10, so we could freeze the RC1 just after I submit this new patch. Bye, Bruno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
unable to find line starting with HTTP error
Hi, In relation to the bug 20703, I have noticed that the workaround propose by Adrian Sutton works for the url http://www.msnbc.com/news/default.asp?newguid=2594c0a6623f464fb0ff25446bfa6cf3 mentioned in the bug report, but, at least as long as my experience is concerned, it doesn't seem to work for this url: http://www.computerhistory.org/ I get the same error unable to find line starting with HTTP as in the bug report.. Thanks for any suggestions.. Here is my error log: org.apache.commons.httpclient.HttpRecoverableException: Error in parsing the status line from the response: unable to find line starting with HTTP at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1892) at org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBase.java:2536) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1047) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:638) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:500) at CheckClient.performHttpRequest(CheckClient.java:356) at CheckClient.run(CheckClient.java:175) 0 INFO [Thread-1] CheckClient - Checking URL(1): http://www.computerhistory.org/ 209DEBUG [Thread-1] httpclient.HttpConnection - HttpConnection.setSoTimeout(1) 209DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.open() 445DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.execute(HttpState, HttpConnection) 445DEBUG [Thread-1] httpclient.HttpMethodBase - Execute loop try 1 445DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.processRequest(HttpState, HttpConnection) 446DEBUG [Thread-1] httpclient.HttpMethodBase - Attempt number 1 to process request 446DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.writeRequest(HttpState, HttpConnection) 446DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.writeRequestLine(HttpState, HttpConnection) 446DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.generateRequestLine(HttpConnection, String, String, String, String) 452DEBUG [Thread-1] httpclient.wire - HEAD / HTTP/1.1[\r][\n] 452DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.print(String) 457DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.write(byte[]) 457DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.write(byte[], int, int) 458DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.writeRequestHeaders(HttpState,HttpConnection) 458DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.addRequestHeaders(HttpState, HttpConnection) 458DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.addUserAgentRequestHeaders(HttpState, HttpConnection) 458DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.addHostRequestHeader(HttpState, HttpConnection) 460DEBUG [Thread-1] httpclient.HttpMethodBase - Request to add Host header ignored: header already added 460DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.addCookieRequestHeader(HttpState, HttpConnection) 477DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.addAuthorizationRequestHeader(HttpState, HttpConnection) 477DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.addProxyAuthorizationRequestHeader(HttpState, HttpConnection) 477DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.addProxyConnectionHeader(HttpState, HttpConnection) 477DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.addContentLengthRequestHeader(HttpState, HttpConnection) 479DEBUG [Thread-1] httpclient.wire - Host: www.computerhistory.org[\r][\n] 480DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.print(String) 480DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.write(byte[]) 480DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.write(byte[], int, int) 483DEBUG [Thread-1] httpclient.wire - User-Agent: Mozilla/5.0 (X11; U; Linux i686; it-IT; rv:1.3) Gecko/20030312[\r][\n] 483DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.print(String) 483DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.write(byte[]) 483DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.write(byte[], int, int) 485DEBUG [Thread-1] httpclient.wire - Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1[\r][\n] 485DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.print(String) 485DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.write(byte[]) 485DEBUG [Thread-1]
Re: Fw: unable to find line starting with HTTP error
I tried sending a GET request but I catch always the same error unable to find line starting with HTTP. thanks again.. 3620 DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.open() 3803 DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.execute(HttpState, HttpConnection) 3803 DEBUG [Thread-1] httpclient.HttpMethodBase - Execute loop try 1 3803 DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.processRequest(HttpState, HttpConnection) 3803 DEBUG [Thread-1] httpclient.HttpMethodBase - Attempt number 1 to process request 3803 DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.writeRequest(HttpState, HttpConnection) 3803 DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.writeRequestLine(HttpState, HttpConnection) 3803 DEBUG [Thread-1] httpclient.HttpMethodBase - enter HttpMethodBase.generateRequestLine(HttpConnection, String, String, String, String) 3803 DEBUG [Thread-1] httpclient.wire - GET / HTTP/1.1[\r][\n] ... 6962 DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.readLine() 6962 DEBUG [Thread-1] httpclient.wire - /html[\r][\n] 6962 DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.readLine() 6963 DEBUG [Thread-1] httpclient.HttpMethodBase - Closing the connection. 6963 DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.close() 6963 DEBUG [Thread-1] httpclient.HttpConnection - enter HttpConnection.closeSockedAndStreams() 6963 INFO [Thread-1] httpclient.HttpMethodBase - Recoverable exception caught when processing request 6964 WARN [Thread-1] httpclient.HttpMethodBase - Recoverable exception caught but MethodRetryHandler.retryMethod() returned false, rethrowing exception - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fw: unable to find line starting with HTTP error
Hi, thank you very much for the help.. Actually I always try sending a HEAD request first, and then skip to GET in case of failure. I have already dealt with the problem of servers sending Body even in response to a HEAD request: Oleg adviced me to add the statement httphead.setBodyCheckTimeout(500); // Activate optional body check which actually fixed the problem.. ..until http://www.computerhistory.org broke into my life..! Anyway, as the problem lies in the bad behaviour of the server, I'll let it down, and happily leave on holiday.. Thanks again.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: performance issue
Well ... there must be something different about my environment. The results with JBoss3.2.1-tomcat4.1.24 were much worse! (I decreased threads to 5 and messages per thread to 10 since tomcat defaults max threads per servlet somewhere and I didn't want to dig for the setting.) alpha3 .034 minutes beta2 .167 minutes Could it be the jdk? I'm running 1.4.0 on XP Pro service pack 1. I could try downloading and installing the most recent version of the jdk, running the test on a different machine ... hm. Also, I'm using the binaries off of the site rather than compiling from source against the jdk on my machine. Unfortunately, I won't have time to work on this any further until later this evening :-( Todd mail2web - Check your email from the web at http://mail2web.com/ . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Put method
Hi, I use PutMethod to upload files. Everything goes ok until I try to send a big file (~ 150 Mo): I get an OutOfMemoryError. I use a BufferedInputStream for my RequestBody. Has anyone already had this kind of error ? Thanks, Cedric. Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34/mn) ; tél : 08 92 68 13 50 (0,34/mn) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
Hi Jeffrey, I made a bit of rework on the telnet client patch in order to (partially) solve the problems you saw. - The Apache license has been added to all sources - I tried to improve compliance with the coding style standards (I'm still not able to run maven, so I can't see the reports...) - A new abstract class for test of option handlers has been added all the test cases for option handlers derive from that class - No System.out/err usage in the test cases - Some restructuring of the test cases not to do so much in setUp/tearDown - TelnetClientExample3 now sends the spy on a file (spy.log) No changes have been made to the implementation/functionality. I'm looking forward to more info from you, Bruno commons-net-openoption-patch5.ZIP Description: Zip compressed data commons-net-openoption-patch5-test.ZIP Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
Hi, I added yet another functionality to TelnetClient, which is very handy to debug: You can spy what's going on in the TelnetClient session by registering to it an OutputStream. TelnetClient will copy all the session activity on the registered outputstream. - TelnetClient: added two new methods (registerSpyStream(), stopSpyStream()) - Telnet: Added new methods to manage the spy stream - TelneInputStream: calls a Telnet's method to copy the received chars on the output stream - TelnetClientExample3: It is a new example showing the use of registerSpyStream() an stopSpyStream(). It opens a telnet connection to a server, then listen to port . Just connect to port with an external telnet, then type SPY on the TelnetClientExample3 terminal and you will see all the TelnetClient traffic copied on the telnet connection to port . UNSPY will stop spying the connection. I enclose another patch which includes all the preceeding + the new spy stream functionality (sources + JUnit tests). Again, sorry for sending so many versions of this patch, I'm just adding the functions I need one at a time when I have got some free time to do that. If you ave some comments or need some explanation, please contact me. Bruno commons-net-openoption-patch4.ZIP Description: Zip compressed data commons-net-openoption-patch4-test.ZIP Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
Jeffrey, I had some problem while running the JUnit tests for the TelnetClient patch on an HP-UX platform (trying to stress test the test cases). Th problem was due to a lack of syncronization between TelnetClient and the mini-server scaffold thread. So I had to change something to solve the problem (new Reader class that allows the scaffold server reading and sending responses in a separate thread. I enclose the new version of the test suite. Please, let me know if you have any problems while running the tests. Bye, Bruno commons-net-openoption-patch3-test.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
Jeffrey, In the enclosed file you will find some JUnit test cases for the TelnetClient patch. The test cases support the last version of the patch (the one I sent on march 17th). I won't write test cases for the previous alternative version unless we decide that we want to apply that version of the patch. You'll find three groups of test cases: - Unit tests. These are for the new classes, without hitting the network (InvalidTelnetOptionExceptionTest, SimpleOptionHandlerTest, SuppressGAOptionHandlerTest, TerminalTypeOptionHandlerTest, EchoOptionHandlerTest. - Protocol compliance tests. Finally, I implemented a simple test server (TelnetTestSimpleServer) that is used to do the testing at the protocol level. It is a very simple server that listens for connections in an independent thread and can be controlled by the outside for sending/receiving bytes. By the time, this test hasn't got 100% coverage of telnet protocol compliance. It covers to some extent option negotiation and AYT processing. (TelnetClientTest) - Functional test. It is a small functional test in which TelnetClient is used to look for Los Angeles weather forecast at rainmaker.wunderground.com (TelnetClientFuntionalTest). All the tests are JUnit, so you should be able to automatically execute them, but they have some requirements: - For the protocol compliance test, the simple server listens on ports , 3334, 3335. Make sure that these ports are free. - For the functional test, make sure that you can reach the weather service rainmaker.wunderground.com. A major issue for this last test is that it expects the serve sends some fixed strings. If in the future rainmaker.wunderground.com is changed (for example, more menus are added or prompts are changed) the functional test won't be working anymore. Any idea for a more robust funtional test will be greatly appreciated!! Law of testing: No matter how many tests you have done before, any execution of a test suite comes out with some bug. This case is no exception: Executing the test cases I found two bugs: - A bug in the option negotiation logic which was already there in the original telnet client (In case TC sends a DO, remote party refuses it sending a WONT, TC didn't acknowledge with a DONT. Simmetrically when TC sends a WILL, remote sends DONT TC didn't acknoledge with a WONT). - A bug in the new getLocalOptionState() and getRemoteOptionState() API methods. The bugs have been fixed by modifying Telnet.java and TelnetClient.java I enclose source code for the patch (all the sources are included, patch + the two bug fixes) Bye, Bruno commons-net-openoption-patch3.zip Description: Zip compressed data commons-net-openoption-patch3-test.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
Hi, last thursaday 3 13th I submitted a patch for an extended version of commons net's TelnetClient containing new functionalities. The support for an external option handler was through the TelnetOptionHAndler interface. The same object was used to handle all the options, with the result of a somehow reduced reusability of the option handlers. To improve reusability and cleanness of the interface I worked out a second patch in which the support for external option handlers is implemented in a different way: - An abstract base class for option handlers has been defined. - The user builds the actual option handler class for each option by extending the base class. the option hadler class takes care of whether to activate the option or not (local and remote side) and manages the subnegotiation - for each option the user registers a different option handler to TelnetClient This new patch is an alternative to the patch I sent on 3 13th, in that it doesn't provide new functionality, rather the same functionality is offered through a different API. I suggest that you take a look at both alternatives, even if I think that this new alternative goes a bit beyond in providing a reusable way of dealing with option handling. This new patch also includes a correction to the option handling mechanism (a flush() of the output stream has been added after sending option negotiation sequences, to ensure that negotiation occurs ASAP). A brief description of the new patch: - TelnetOptionHandler is an abstract base class for option handling. User extends this class specifying how to do subnegotiation for each of the options he wants to support. - EchoOptionHandler, TerminalTypeOptionHandler, SuppressGAOptionHandler, SimpleOptionHandler are a library of already provided option handlers. SimpleOptionHandler allows managing all options that don't require subnegotiation. - TelnetInputStream has been modifies to handle option subnegotiation and AYT response checking. - Telnet has been modified by adding new constructors, for handling TERMINAL-TYPE and for driving the control of option negotiation through the user provided TelnetOptionHandler instances. Also, methods for adding/removing the TelnetOptionHandler instances have been added. - TelnetClient has been modified by adding new constructors and interface methods. - TelnetClientExample1 is an example terminal that uses external TelnetOptionHandler instances and demonstrates use of sendAYT(), getLocalOptionState(), getRemoteOptionState(), SimpleOptionHandler, addOptionHAndler(), removeOptionHandler(). - TelnetClientExample2 is the same example terminal without use of the external option handler but using the built in TERMINAL-TYPE support. I know that I'm providing too much patches for the same functionality and this can be confusing. Sorry for that! Again, I think that the best is evaluating the last two patches (I prefer the second one). Any comment or suggestion will be welcome. Bruno commons-net-openoption-patch2.ZIP Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
I have looked at your one of your last submission, and just haven't had time to look in detail, sorry. I'll try to look today/tomorrow though. One other minor point, maybe in this latest patch you have, but could you try providing some test cases or are you using the Telnet example as a sort of smoke test for the changes? Hi Jeffrey, I think that the simplest way is to use the Telnet examples as a test for the new funtionality. I'll review the examples to see if they cover all the new stuff. I have been thinking about providing test cases: the problem is we should have a telnet server with a controlled behaviour (one for which we can set option managing properties) to define true test cases for the new functionalities. As we are going to test how TelnetClient implements the protocol (option negotiation and subnegotiation) we should have the possibility to set up the test cases (and look at the result) at the protocol level. I tried to find the original test suites for commons net (because the original test for TelnetClient should have the same problem) but couldn't find it. Can you please send me a link to it? The idea could be modifying it for the new stuff... Bruno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
I agree that testing at the protocol level would be needed and also a functional test against some existing servers. Both types of tests are going to be useful. Currently there are no tests, only some examples. This is an area where commons-net really needs some polish. It may be difficult to write *unit tests* for the existing code, but functional tests might have to do instead. But for new code ( especially new classes ) we could start with unit tests that do not require external systems. It is a difficult task to start out with, but one I think we need to start talking about at least. So any idea on getting a test harness for functional tests ( fit.c2.com / fitnesse.org are what I'm currently using at work and seems to work well ) and/or staring with some small unit tests would be beneficial. Maven is setup to fire junit based tests nicely and we have some unit tests for the line parsers for the ftp code already. Jeffrey, Thanks for the info. If you agree we could go on this way: - I'll try to have ready a simple server that is configurable enough for setting up different test cases at the protocol level. It could be reused for testing all the TelnetClient protocol compliance when someone has the time to accomplish the task of analyizing the part of telnet protocol implemented by it and defining test cases for it. But... how do we ensure that the tester server we use doesn't have some problem affecting the test results?. I'll try to keep it as simple at possible, and it should be strongly reviewed to ensure that it is (almost) bug free. - For the unit testing, I think that it's possible only for classes whose behaviour does not depend drammatically on the presence and behaviour of another party on a network (unless we are able to use the same tester protocol server of the above point for unit-test the network classes). So I think that we could do, by the moment, the unit test of the new classes (which by themselves don't require a network partner to test, as they aren't accessing the network). I'll look at Maven for these tests. - We can use TelnetExample1 and TelnetExample2 with some existing server on the net (rainmaker.wunderground.com ?) to do the functional testing. If you agree, I'll try to come out with the tester server in a couple of day... still busy at work.. :-( Also, I'll try to see how to do unit testing on TelnetOptionHandler, its derived classes and InvalidTelnetOptionException by using Maven (which I haven't seen yet). Regarding the functional test, I had a look at the examples, it should be enough. The examples are simple terminals that allows you to connect to a server and, besides providing access to the server, accept some commands that axercise the new APIs. Have a look at them and tell me what do you think about, if you have the time for it. Another point: how should we document the test procedure? For example, it is likely that the functional tests should be run by a person which will follow a test procedure looking for some desired test results. How do we document this? Bye, Bruno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
Hi to all, In the last days I already submitted a patch for an extended version of TelnetClient supporting TERMINAL-TYPE and a second patch containing the same + a bug fix for a previous problem of TelnetClient. This new patch contains all the preceeding changes + some new functionality that has been added to TelnetClient. Please, if you didn't already look at the preceeding patches, ignore them and take a look at this new version. Functionalities: - built-in support for TERMINAL-TYPE - Support for an external, user provided, option handler (the option handler is defined by implementing in a user class the new TelnetOptionHandler interface. A SimpleTelnetOptionHandler class is already provided. - Synchronous sendAYT() method checking for status of a telnet session - getLocalOptionState() getRemoteOptionState() methods for checking the state of the negotiated options on both ends of the telnet session. A brief description of the patch: - TelnetOptionHandler is a new interface that defines the interface that must be implemented to plug into TelnetClient a user provided option handling logic. - SimpleTelnetOptionHandler is a simple class implementing TelnetOptionHandler which can be used for typical telnet communication requirements. - TelnetInputStream has been modifies to handle option subnegotiation and AYT response checking. - Telnet has been modified by adding new constructors, for handling TERMINAL-TYPE and for driving the control of option negotiation through the user provided TelnetOptionHandler instance. - TelnetClient has been modified by adding new constructors and interface methods. - TelnetClientExample1 is an example terminal that uses an external TelnetOptionHandler and demonstrates use of sendAYT(), getLocalOptionState(), getRemoteOptionState(). - TelnetClientExample2 is the same example terminal without use of the external option handler but using the built in TERMINAL-TYPE support. Please, for any comments or doubts on this patch contact me without hesitation. Also, if this is not the right procedure to submit a patch, please give me a hint on how to do that. Best regards, Bruno D'Avanzo commons-net-openoption-patch.ZIP Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
You forgot to include a patch :) I include a zip file with the sources for the TERMINAL-TYPE patch. I am really a newbie in contributing to jakarta, so i'm sorry if this is not the right procedure for submitting patches. Also, I think that the support for subnegotiating options can be reused for implementing support for other telnet options. I think that the best way to do this could be defining a java interface for managing options and letting users of the library define their own class for managing options. Sounds good. Submit a patch. The included patch only deals with TERMINAL-TYPE. I'll try to send a patch for an open-option version of the TelnetClient by March 17th: I have a clear idea of how to do that, but I'm facing a hard schedule on my job right now :-( Best regards, Bruno D'Avanzo terminal-type-patch.ZIP Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
BUGFIX: The old TelnetClient did not clean the arrays used for option processing for each connection (as in the original class no option was accepted, the bug was there but it did not have the chance to come out) In the case that the same TelnetClient instance is used for more than one time, this results in a problem in the negotiation the second time you try to accept an option. The enclose classes fix this bug (modified Telnet.java, _connectAction_ to fix the bug) Please ignore the patch I sent before, this new patch includes all the preceeding + the BUGFIX. Best regards, Bruno D'Avanzo You forgot to include a patch :) I include a zip file with the sources for the TERMINAL-TYPE patch. I am really a newbie in contributing to jakarta, so i'm sorry if this is not the right procedure for submitting patches. Also, I think that the support for subnegotiating options can be reused for implementing support for other telnet options. I think that the best way to do this could be defining a java interface for managing options and letting users of the library define their own class for managing options. Sounds good. Submit a patch. The included patch only deals with TERMINAL-TYPE. I'll try to send a patch for an open-option version of the TelnetClient by March 17th: I have a clear idea of how to do that, but I'm facing a hard schedule on my job right now :-( terminal-type-patch.ZIP Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Adding TERMINAL-TYPE option to TelnetClient
Hi: In order to fix a problem while connecting to an OpenVMS server (delay of the OpenVMS login process when the terminal type is unknown) I added support of the TERMINAL-TYPE telnet option, RFC 1091 to the TelnetClient class of the Commons Net library (org.apache.commons.net.telnet.TelnetClient). A brief description of the modification I had to make for the added capability follows: - The state machine implemented in TelnetInputStream has been extended to support option subnegotiation (can be reused for implementing support for more option requiring subnegotiation) - The Telnet base class has been extended to drive the subnegotiation sending the terminal type to the other telnet party when requested - A new constructor has been added to the TelnetClient class, which accepts a String specifying the terminal type (the default terminal type is VT100, which is took when using the empty construvtor). I think this functionality could potentially be interesting for other users of the library, so I would like to propose that the updated sources be included in the Jakarta code base. Also, I think that the support for subnegotiating options can be reused for implementing support for other telnet options. I think that the best way to do this could be defining a java interface for managing options and letting users of the library define their own class for managing options. Any comment will be greatly appreciated. Bruno D'Avanzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DBCP connection problems with credentials
Hi,
I'am starting with DBCP and Tomcat because of some pooling
problems with Tyrex and Poolman.
First of all, It seems like DBCP works very well.
Now, I've got just a little problem with getConnection method
and credentials : PoolingDataSource object doesn't support
getConnection(user, password) method and throw
an UnsupportedOperationException.
I understand it as a pooled connections can't be shared among
multiple database users. My problem is that some application
still use getConnection(user, password) method even with
DataSource, so using DBCP with those applications is impossible
without modifing app. code.
So, here is my proposal : Why not modifing getConection(user,
password) in BasicDataSource so that :
- if username/password are good ones, this method forward
toward getConnection()
- if not, this method throw a SQLExeption, saying something
like Invalid username/password
I've tried to modify source code and I ask you if it would be
correct to transform getConnection(username, password) in
BasicDataSource like this :
---
public Connection getConnection(String username, String
password)
throws SQLException {
if(username.equalsIgnoreCase(this.username)
password.equalsIgnoreCase(this.password)) {
return (createDataSource().getConnection());
} else {
throw new SQLException(DBCP : Invalid username/password);
}
}
---
Thanks in advance for your responses
Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,13
/mn) ; tél : 08 92 68 13 50 (0,34/mn)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HttpClient: Basic Authentication acting more like a browser
I don't think he was asking about the spec's facilities for request requirement discovery, I think he was suggesting that the httpclient's state mechanism should behave more like a conventional browsers'. There's no reason not to do it; even if you could count on all of your servers to implement the response code 100 heuristics, there's nothing wrong with the standard browser behavior. On Tue, 29 Jan 2002, David Bullock wrote: I was reading in the HTTP 1.1 spec just today, and found that there is a way for the client to see if the server is willing to respond to the HTTP request headers before sending the message body. If the server is, then it gives the response right away. If not, then it asks the client to continue ( HTTP response code 100 ) with the message body. This allows for things like security credential exchanges, redirects, etc, to be performed without incurring unnecessary network overhead. This is probably exactly what you're after to limit transmitting a large body twice. Details are at: ftp://ftp.isi.edu/in-notes/rfc2616.txt Section 8.2.3 cheers, David. On Thu, 17 Jan 2002, Matthew Albright wrote: I've run into a interesting little shortcoming with HttpClient, and would like to know if someone is working on a solution. When a browser goes to a site that requires Basic Authentication, it will make a request (GET /), get a 401 response with a realm attached, and prompt the user for a username and password for that realm. After getting the username/password, it fills in the appropriate header with that information, and makes the request again, gets the 200 response, and presumably all the data for the page. Now, on subsequent visits to the same site, it appears (from server logs) that the browser fills in the Authentication header for each request, in a kind of pre-emptive strike. That way, the browser and server don't have to do the request-401-auth-200 dance every single time. It appears that HttpClient doesn't do this process exactly like a browser. Every single Method that is execute()'d will send out the initial request without Authentication, get the 401, and then send the request again with authentication information attached. This is not normally a problem, or even noticable. My problem is that I'm doing an HTTP POST with a good amount of data. This data is being sent down the wire twice for every Method.execute() that I'm calling. I'm on DSL, so it's not too bad, but for large payloads or slow connections, it's IMHO unacceptable. I'm considering modifying HttpState and HttpMethodBase to act more like a browser... make HttpState store not only the realm, but also the url of the site that requires authentication, and then make HttpMethodBase fill in that information if it matches for every request after the first successful one. Is anyone else working on this, or have any input on a specific approach to this problem? Any things I should look out for? Does anyone have any idea what I'm talking about? ;) And, once I've finished this, and gotten it working, what should I do with it? Just send a patch to this list? Thanks for reading this far. matt __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] cheers, -Ian -- Ian Kallen [EMAIL PROTECTED] | AIM/yahoo: iankallen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
