Re: [VOTE][betwixt] Release Betwixt 0.6
hey dion! have you had a chance to test the release candidate yet? - robert On 22 Sep 2004, at 05:37, Dion Gillard wrote: Is there a test build or SNAPSHOT we can test with? On Tue, 21 Sep 2004 20:18:35 +0100, robert burrell donkin [EMAIL PROTECTED] wrote: the release candidate has been around for a few days and no ill effects have been reported. so, i'd like to propose that the code on the RELEASE_0_6_BRANCH is released as Betwixt 0.6. i'll tally the votes no earlier than 2200 GMT on Thursday 21st September. here's my +1 - robert 8-- [ ] +1 Unreservedly support Betwixt 0.6 Release [ ] +0 Support (with reservations) [ ] -0 Cannot support this release [ ] -1 Betwixt 0.6 should not be released - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - 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: HTTP Client File Upload Question
Hello again, I found the problem, elsewhere, so I formally apologise for wasting time and impugning the reputation the httpclient code. :-) N - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP Client File Upload Question
Oleg Kalnichevski wrote: Nigel, Try setting Parts' transfer-encoding and charset to null and see if that makes any difference. http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/methods/multipart/PartBase.html#setTransferEncoding(java.lang.String) Thanks for the suggestion Oleg. It doesn't seem to help, I can see that it isn't adding those headers to the form data now (looking at the logs in lumbermill as it runs) but it still comes over garbled. Currently my next step will be to try and encode it somehow before sending, but if it is indeed stripping the two high bits then even a 7bit encoding is going to get mangled. I am really at a loss, I really need to get this working in the next couple of days so any suggestions, wild whacky or otherwise all equally appreciated guys. Cheers, Nige - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[NET] Designing a Date Format-aware FTP Entry Parser
Designing a Date Format-aware FTP Entry Parser After having percolated on the back burner for several years as an unresolved issue, there is finally some momentum toward solving the problem of parsing FTP entries from servers which format the file timestamps in the directory listings in a format other than the NetComponents standard. In order to understand what must be done, it would be helpful to understand what we now do. In brief, we are using a regular expression to achieve basically the same results as attempting to parse the date portion of the listing with one of two alternate java.text.SimpleDateFormats in the en_US locale: 1.MMM dd HH:mm for dates within one year of the current time 2.MMM dd for dates older than one year. Additionally, these formats presume some timezone, which is either the local timezone of the server or GMT, I presume. The alternative mechanism that I am proposing would remove the parsing of the timestamp from the responsibilities of the regular expression and unload this onto some other object. But what object? The obvious candidate would be java.text.DateFormat. This abstract class allows a formatter object to be created on the basis of some formatting codes defined in DateFormat (LONG, MEDIUM, SHORT) and a Locale. But this is problematic because what is meant by MEDIUM in en_US is a string like Sep 25, 2004 while in de_DE, you get a string like 25.09.2004. This just won't do. So we have to fall back on java.text.SimpleDateFormat, passing in both a specific formatting string and a Locale, which provides the month names, etc. (By the way, has anyone ever noticed that SimpleDateFormat is actually less simple than DateFormat?) :-) The regular expression would merely extract from the listing the entire timestamp portion and delegate the task of parsing it to a pair of SimpleDateFormat objects (one for less than 1 year old and the other for one year old or older), each constructed on the basis of a format string and a locale. Since the Locale should be the same for both formats, we would require the user to provide the two format Strings, and the Locale (or possibly the constituent elements of the locale, the country code and language code). We want an object that encapsulates all of that, say, org.apache.commons.net.ftp.parser.FTPDateFormat. So each parser would have a settable member of this class FTPDateFormat would be constructed from two format strings and a Locale. Possibly a timezone as well. We probably would have to provide some default FTPDateFormat objects for some of the common locales. One consequence of this is that we would start making heavier use of the FTPFileEntryParserFactory objects. We might want to start thinking about deemphasizing but not deprecating the use of FTPClient.listFiles() which is simple but makes too many assumptions. There are already four or five different overrides of this method name and adding several more parameters into the mix will make this completely unworkable. Instead, going through the factory would become the more common, more documented and recommended approach. This would be the preferred method of accessing commons-net ftp for clients such as Ant and VFS. Users who are happily using listFiles() in its current form in their custom apps built directly from commons-net could continue to do so. Well, these are some preliminary thoughts. Let's hear from the other developers of this project. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31419] New: - incorrect code sample
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31419 incorrect code sample Summary: incorrect code sample Product: Commons Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Digester AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] At the Usage Examples section in the javadoc of org.apache.commons.digester, The package declaration for class Bar should be package mypackage; instead of public mypackage; . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 31272] - TelnetInputStream zombie thread memory leak, FTPClient TelnetClient
In message [EMAIL PROTECTED], Rory Winston w rites: Actually, just having a quick perusal, I think this may be the culprit ... I've fixed, tested, + committed. Thanks. That's the second straight sloppy patch I've made. I always tell myself I shouldn't touch code after midnight :) I must have somehow compiled it with the unit tests disabled or just not noticed they failed. Shame on me. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] SNTP support?
In message [EMAIL PROTECTED], Rory Winston w rites: Has there been any code contributed re: (S)NTP? I feel I may have a use for this in my day-to-day, and I am just wondering if there has been any movs toward including this. I see there is a TODO on the list that says review (S)NTP code, which implies some code to review. There should be a code submission somewhere in bugzilla, but I can't find it right now. I kept meaning to go over the code, but never got around to it. If you can review it and decide whether/how to incorporate it, that would be great! If really not in bugzilla and I'm not making another late night gaffe, then it may have been submitted to the mailing list and I don't know if the mailing list archives save binary attachments (it may have been a zip file). If you can't find it with a quick search, let me know and I'll dig through my email and see if I can find it and forward it to you. If it went to the mailing list I've still got it somewhere. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31130] - [configuration] Add save() method and comment handling to HierarchicalXMLConfiguration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31130. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31130 [configuration] Add save() method and comment handling to HierarchicalXMLConfiguration --- Additional Comments From [EMAIL PROTECTED] 2004-09-25 15:44 --- Created an attachment (id=12865) The new patch (valid after refactoring of load() and save() methods) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CVS access configuration problems
Hi, I'm having trouble setting up CVS access to the Jakarta modules. I'm trying to configure WinCVS as my CVS client, and I've followed the instructions shown at http://jakarta.apache.org/site/cvsindex.html. All appears to go well - the client successfully connects to the CVS repository using the suggested connection command cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login but when I try to search for modules to check out, I can only see the following: apache-1.3 apache-1.3-sourceonly apachetest-alias htdocs-1.3 httpd-docs-1.3 httpd-docs-2.0 modperl-2.0 modperl-docs-alias world I was hoping to see a lot of Jakarta modules in there, but there's nothing related to Jakarta in the list. Am I doing something stupid here? Is the Jakarta stuff actually hosted on cvs.apache.org or do I need to connect to a different host (e.g. cvs.jakarta.apache.org)? A little help in this matter would be greatly appreciated as I'm relatively new to the world of CVS. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Do we need to support Ant based builds?
On Sat, 25 Sep 2004 10:10:15 +1000, Brett Porter [EMAIL PROTECTED] wrote:
Yep, and under gump there is a build.properties set up to hijack all the
versions :)
Remove build.properties under gump and you go back to having this behaviour.
We don't necessarily need gump to do nightly builds however - it really
is just a matter of maven jar:deploy-snapshot run regularly. The trick
is keeping it consistent with the ant-based nightlies, having somewhere
to run it, and when to run it - do you really need nightlies on commons
components, or should it be triggered by commits?
A few quick comments:
1) Not all Commons components are set up for Maven builds, so the
just a matter of doesn't apply in all cases.
2) The Commons nightly builds are just one part of the wider Jakarta
nightly build, and certainly not all Jakarta projects use Maven, or
are likely to do so any time soon.
3) To answer the last question above - yes, we want nightly builds. I
don't think we want to load up the Apache infrastructure with
continuous commit-triggered builds for all of the Jakarta projects, or
even just for Commons components. Having a nightly build gives us a
predictable load at a known time.
--
Martin Cooper
Cheers,
Brett
Mark R. Diggory wrote:
At least in Maven, the version of the dependency is captured in the
metadata of the project.xml file. When the ant build file is generated
off the project.xml file, these dependencies are translated into the
get url's to point at the ibiblio maven repository.
get dest=${libdir}/commons-logging-1.0.3.jar
usetimestamp=true ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.3.jar;
/get
get dest=${libdir}/commons-discovery-0.2.jar
usetimestamp=true ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-discovery/jars/commons-discovery-0.2.jar;
/get
So, in a sense, maven is already handling the correct dependencies
both in the project.xml and the generated ant build.xml.
-Mark Diggory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS access configuration problems
By and large, we don't use the CVS modules feature, which is why you see so few. You just need to use the repository name instead. So, for Commons, you would check out jakarta-commons and / or jakarta-commons-sandbox. -- Martin Cooper On Sat, 25 Sep 2004 09:17:53 +0100, Chris Lambrou [EMAIL PROTECTED] wrote: Hi, I'm having trouble setting up CVS access to the Jakarta modules. I'm trying to configure WinCVS as my CVS client, and I've followed the instructions shown at http://jakarta.apache.org/site/cvsindex.html. All appears to go well - the client successfully connects to the CVS repository using the suggested connection command cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login but when I try to search for modules to check out, I can only see the following: apache-1.3 apache-1.3-sourceonly apachetest-alias htdocs-1.3 httpd-docs-1.3 httpd-docs-2.0 modperl-2.0 modperl-docs-alias world I was hoping to see a lot of Jakarta modules in there, but there's nothing related to Jakarta in the list. Am I doing something stupid here? Is the Jakarta stuff actually hosted on cvs.apache.org or do I need to connect to a different host (e.g. cvs.jakarta.apache.org)? A little help in this matter would be greatly appreciated as I'm relatively new to the world of CVS. Chris - 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]
DO NOT REPLY [Bug 31396] - undocumented dependency on commons-logging
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31396. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31396 undocumented dependency on commons-logging [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-09-25 20:12 --- BeanUtils has depended on commons logging for a very long time - since release 1.3, I think. If you take a look at the website, you'll see that this is documented (and has been for some time): http:/ /jakarta.apache.org/commons/beanutils/dependencies.html. The change in dependencies is that BeanUtils no longer requires commons-collections. This change was well documented in the release notes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Do we need to support Ant based builds?
Martin Cooper wrote:
A few quick comments:
1) Not all Commons components are set up for Maven builds, so the
just a matter of doesn't apply in all cases.
This is true, but all Commons projects are required to use Maven to
build the Project's Website. It benefits a Commons project to use Maven
to build and test the distributions and a majority of them do. Do we
have a clear list of the projects that do not at this time?
My earlier point was strictly to bridge this gap. All projects (Maven
Based) can easily produce an Ant build.xml file using maven's Ant task,
the build.xml file works correctly with Craig's current nightly build
process, so Ant is the common denominator here and this solution is
already inadvertently in production. Clearly it works.
2) The Commons nightly builds are just one part of the wider Jakarta
nightly build, and certainly not all Jakarta projects use Maven, or
are likely to do so any time soon.
True.
3) To answer the last question above - yes, we want nightly builds. I
don't think we want to load up the Apache infrastructure with
continuous commit-triggered builds for all of the Jakarta projects, or
even just for Commons components. Having a nightly build gives us a
predictable load at a known time.
--
Martin Cooper
Cheers,
Brett
Mark R. Diggory wrote:
At least in Maven, the version of the dependency is captured in the
metadata of the project.xml file. When the ant build file is generated
off the project.xml file, these dependencies are translated into the
get url's to point at the ibiblio maven repository.
get dest=${libdir}/commons-logging-1.0.3.jar
usetimestamp=true ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.3.jar;
/get
get dest=${libdir}/commons-discovery-0.2.jar
usetimestamp=true ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-discovery/jars/commons-discovery-0.2.jar;
/get
So, in a sense, maven is already handling the correct dependencies
both in the project.xml and the generated ant build.xml.
-Mark Diggory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Please make a RC2 release of Commons Configuration soon
Its has been a long while since the RC1 release of commons configuration and there have been some pretty significant bug fixes that Ive reported made since then. Furthermore, the site is displaying docs saying they're based on the Sept 24 RC2 release, but the same site says that the current release is RC1. Ive got application code distributed over several machines that depends on fixes made since RC1. Currently Im having to build from CVS and manually distribute a JAR version. Please get another release out and into Ibiblio ASAP. Cheers Ben Hutchison PS One of my previous issue reports was a ClassCastException caused by casting an object to String, which should have been String.valueOf(). I noticed the fix was made in 3 places, but is still missing on line 412 of XMLConfiguration. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Do we need to support Ant based builds?
1) Not all Commons components are set up for Maven builds, so the just a matter of doesn't apply in all cases. 2) The Commons nightly builds are just one part of the wider Jakarta nightly build, and certainly not all Jakarta projects use Maven, or are likely to do so any time soon. Yes, I understand that. Sorry, I thought this discussion was in the context of Maven builds in commons at the moment. 3) To answer the last question above - yes, we want nightly builds. I don't think we want to load up the Apache infrastructure with continuous commit-triggered builds for all of the Jakarta projects, or even just for Commons components. Having a nightly build gives us a predictable load at a known time. Absolutely. I actually meant that it might be better to run nightly builds that only build if the project has changed. This avoids unnecessary load, disk usage and mirror syncing (if indeed the nightlies are mirrored) for projects that are inactive or less active (there are a lot of commons projects and very few if any get daily changes). Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS access configuration problems
Martin, As I said, I haven't used CVS much and wasn't aware of the distinction between modules and repositories. It also didn't seem obvious to me that the WinCVS gui allows one to type in any repository name, rather than having to select one of the modules. Anyhow, it's all worked a treat, so many thanks. Chris Martin Cooper wrote: By and large, we don't use the CVS modules feature, which is why you see so few. You just need to use the repository name instead. So, for Commons, you would check out jakarta-commons and / or jakarta-commons-sandbox. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] API changes for RC2
The following changes have been suggested recently. Before cutting 1.0 final, we should make sure we are all OK postponing or forgoing these: 1) Eliminate the univariate/multivariate distinction in the stat package, because this seems confusing to some. Change .univariate to .descriptive and .multivariate to .regression 2) Add methods to create row or column matrices from double arrays and to extract submatrices (to the interface itself, rather than adding these to a utils class later) 3) Make the PRNG fully pluggable in the random package. 4) Modify Variance and StandardDeviation to compute multiple statistics (with the variants being population, rather than sample statistics). 5) Drop the interface / implementation separation throughout the package. I am personally -1 on 4) and 5); -0 on 1) and 2); and +0 on 3). I voted +1 on the release; however, which means that 3) is a wart that I am willing to live with for 1.0. It can be worked around now and to fix it correctly will require that we define a PRNG interface and introduce factories, etc. Mark, since you voted to reopen API discussion, can you weigh in on these issues and add any others that you see as show-stoppers? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] API changes for RC2
1) +1 (although I can see that some statistics (like PCA, factorial, cluster analysis and so) might end up in a multivariate package). 2) +1 3) +0 (I can see that it might be more logical to implement it after 1.0, but them I would be in favour of dropping PNRG all together in this release.) 4) +1 5) neutral, I can see the rational behind it, but I also see that it is not the general way many packages like the java(x) core classes itself are made. I can see that there might be good solid reasons (which I do not entierly get) to do it that way despite that I personally do not like it. But I can live with that. Kim The following changes have been suggested recently. Before cutting 1.0 final, we should make sure we are all OK postponing or forgoing these: 1) Eliminate the univariate/multivariate distinction in the stat package, because this seems confusing to some. Change .univariate to .descriptive and .multivariate to .regression 2) Add methods to create row or column matrices from double arrays and to extract submatrices (to the interface itself, rather than adding these to a utils class later) 3) Make the PRNG fully pluggable in the random package. 4) Modify Variance and StandardDeviation to compute multiple statistics (with the variants being population, rather than sample statistics). 5) Drop the interface / implementation separation throughout the package. I am personally -1 on 4) and 5); -0 on 1) and 2); and +0 on 3). I voted +1 on the release; however, which means that 3) is a wart that I am willing to live with for 1.0. It can be worked around now and to fix it correctly will require that we define a PRNG interface and introduce factories, etc. Mark, since you voted to reopen API discussion, can you weigh in on these issues and add any others that you see as show-stoppers? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.kimvdlinde.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/math/xdocs changes.xml
psteitz 2004/09/25 19:08:47 Modified:math/xdocs changes.xml Log: Added ComplexFormat fix. Revision ChangesPath 1.2 +3 -0 jakarta-commons/math/xdocs/changes.xml Index: changes.xml === RCS file: /home/cvs/jakarta-commons/math/xdocs/changes.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- changes.xml 19 Sep 2004 22:48:03 - 1.1 +++ changes.xml 26 Sep 2004 02:08:47 - 1.2 @@ -44,6 +44,9 @@ to the commons-dev list by Jon Langlois on 9/14. Integer arguments to getCumXxx were always returning 0 due to type conversion problems. /action + action dev=brentworden type=fix +Fixed locale-dependency in ComplexFormat. (pr #31325). + /action /release release version=1.0-RC1 date=2004-09-07 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] API changes for RC2
Some thoughts from a general Commons perspective: 1) +0, This is worth getting right early on as package renaming does tend to confuse users and takes a long time to work through deprecation etc. 2) -0. This is a new feature. If it's easy, add it. If it involves effort, don't bother until 1.1. 3) -0. Two options leap to mind, release PRNG as it is, or don't release the PRNG code. Yes it's a pain for users when you change the functionality in a new version, but when the option is not having a feature, users opt for the functionality and pain later. Most likely the change would be a simple perl regexp anyway. 4) -0. I was never a statistician, but this sounds like new functionality. Either release the code as is, or drop it. While 3) is an API change, this sounds like a functional change and those are much more painful for a user. 5) -0. Keep it as is. Again, it might mean an API change in the future, but I doubt anyone knows the perfect solution so let's see how this one goes. So the only one I'd advise as really being worth the effort is 1. Hen On Sat, 25 Sep 2004 21:41:31 -0400, Kim van der Linde [EMAIL PROTECTED] wrote: 1) +1 (although I can see that some statistics (like PCA, factorial, cluster analysis and so) might end up in a multivariate package). 2) +1 3) +0 (I can see that it might be more logical to implement it after 1.0, but them I would be in favour of dropping PNRG all together in this release.) 4) +1 5) neutral, I can see the rational behind it, but I also see that it is not the general way many packages like the java(x) core classes itself are made. I can see that there might be good solid reasons (which I do not entierly get) to do it that way despite that I personally do not like it. But I can live with that. Kim The following changes have been suggested recently. Before cutting 1.0 final, we should make sure we are all OK postponing or forgoing these: 1) Eliminate the univariate/multivariate distinction in the stat package, because this seems confusing to some. Change .univariate to .descriptive and .multivariate to .regression 2) Add methods to create row or column matrices from double arrays and to extract submatrices (to the interface itself, rather than adding these to a utils class later) 3) Make the PRNG fully pluggable in the random package. 4) Modify Variance and StandardDeviation to compute multiple statistics (with the variants being population, rather than sample statistics). 5) Drop the interface / implementation separation throughout the package. I am personally -1 on 4) and 5); -0 on 1) and 2); and +0 on 3). I voted +1 on the release; however, which means that 3) is a wart that I am willing to live with for 1.0. It can be worked around now and to fix it correctly will require that we define a PRNG interface and introduce factories, etc. Mark, since you voted to reopen API discussion, can you weigh in on these issues and add any others that you see as show-stoppers? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.kimvdlinde.com - 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: [math] API changes for RC2
Just to enhance my 4) bit, I'd advise dropping in this case and not releasing this code if you plan to change the internal functionality. If it's going to involve an API change with the new code though, go ahead and release. Hen On Sat, 25 Sep 2004 23:02:57 -0400, Henri Yandell [EMAIL PROTECTED] wrote: Some thoughts from a general Commons perspective: 1) +0, This is worth getting right early on as package renaming does tend to confuse users and takes a long time to work through deprecation etc. 2) -0. This is a new feature. If it's easy, add it. If it involves effort, don't bother until 1.1. 3) -0. Two options leap to mind, release PRNG as it is, or don't release the PRNG code. Yes it's a pain for users when you change the functionality in a new version, but when the option is not having a feature, users opt for the functionality and pain later. Most likely the change would be a simple perl regexp anyway. 4) -0. I was never a statistician, but this sounds like new functionality. Either release the code as is, or drop it. While 3) is an API change, this sounds like a functional change and those are much more painful for a user. 5) -0. Keep it as is. Again, it might mean an API change in the future, but I doubt anyone knows the perfect solution so let's see how this one goes. So the only one I'd advise as really being worth the effort is 1. Hen On Sat, 25 Sep 2004 21:41:31 -0400, Kim van der Linde [EMAIL PROTECTED] wrote: 1) +1 (although I can see that some statistics (like PCA, factorial, cluster analysis and so) might end up in a multivariate package). 2) +1 3) +0 (I can see that it might be more logical to implement it after 1.0, but them I would be in favour of dropping PNRG all together in this release.) 4) +1 5) neutral, I can see the rational behind it, but I also see that it is not the general way many packages like the java(x) core classes itself are made. I can see that there might be good solid reasons (which I do not entierly get) to do it that way despite that I personally do not like it. But I can live with that. Kim The following changes have been suggested recently. Before cutting 1.0 final, we should make sure we are all OK postponing or forgoing these: 1) Eliminate the univariate/multivariate distinction in the stat package, because this seems confusing to some. Change .univariate to .descriptive and .multivariate to .regression 2) Add methods to create row or column matrices from double arrays and to extract submatrices (to the interface itself, rather than adding these to a utils class later) 3) Make the PRNG fully pluggable in the random package. 4) Modify Variance and StandardDeviation to compute multiple statistics (with the variants being population, rather than sample statistics). 5) Drop the interface / implementation separation throughout the package. I am personally -1 on 4) and 5); -0 on 1) and 2); and +0 on 3). I voted +1 on the release; however, which means that 3) is a wart that I am willing to live with for 1.0. It can be worked around now and to fix it correctly will require that we define a PRNG interface and introduce factories, etc. Mark, since you voted to reopen API discussion, can you weigh in on these issues and add any others that you see as show-stoppers? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.kimvdlinde.com - 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: [math] API changes for RC2
Population variance and sample variances do only differ in the number
the summed difference (second moment) is divided through. The way I have
implemented it in my Variances class is by keeping the methods as they
are (I do believe setting the default to sample variances is right) and
supplement with the general versions, in which you can add a constant like:
final static int Variance.POPULATION = 0;
final static int Variance.SAMPLE= 1;
the internal formulas becomes then:
public double getResult(final int varianceType) {
if ((moment.n-varianceType) = 0) {
return Double.NaN;
} else if (moment.n == 1) {
return 0d;
} else {
return moment.m2 /
((double) moment.n - varianceType);
}
}
public double getResult() {
return getResult(VarianceTypes.SAMPLE);
}
Kim
Henri Yandell wrote:
Just to enhance my 4) bit, I'd advise dropping in this case and not
releasing this code if you plan to change the internal functionality.
If it's going to involve an API change with the new code though, go
ahead and release.
Hen
On Sat, 25 Sep 2004 23:02:57 -0400, Henri Yandell [EMAIL PROTECTED] wrote:
Some thoughts from a general Commons perspective:
1) +0, This is worth getting right early on as package renaming does
tend to confuse users and takes a long time to work through
deprecation etc.
2) -0. This is a new feature. If it's easy, add it. If it involves
effort, don't bother until 1.1.
3) -0. Two options leap to mind, release PRNG as it is, or don't
release the PRNG code. Yes it's a pain for users when you change the
functionality in a new version, but when the option is not having a
feature, users opt for the functionality and pain later. Most likely
the change would be a simple perl regexp anyway.
4) -0. I was never a statistician, but this sounds like new
functionality. Either release the code as is, or drop it. While 3) is
an API change, this sounds like a functional change and those are much
more painful for a user.
5) -0. Keep it as is. Again, it might mean an API change in the
future, but I doubt anyone knows the perfect solution so let's see how
this one goes.
So the only one I'd advise as really being worth the effort is 1.
Hen
On Sat, 25 Sep 2004 21:41:31 -0400, Kim van der Linde
[EMAIL PROTECTED] wrote:
1) +1 (although I can see that some statistics (like PCA, factorial,
cluster analysis and so) might end up in a multivariate package).
2) +1
3) +0 (I can see that it might be more logical to implement it after
1.0, but them I would be in favour of dropping PNRG all together in this
release.)
4) +1
5) neutral, I can see the rational behind it, but I also see that it is
not the general way many packages like the java(x) core classes itself
are made. I can see that there might be good solid reasons (which I do
not entierly get) to do it that way despite that I personally do not
like it. But I can live with that.
Kim
The following changes have been suggested recently. Before cutting 1.0
final, we should make sure we are all OK postponing or forgoing these:
1) Eliminate the univariate/multivariate distinction in the stat
package, because this seems confusing to some. Change .univariate to
.descriptive and .multivariate to .regression
2) Add methods to create row or column matrices from double arrays and
to extract submatrices (to the interface itself, rather than adding
these to a utils class later)
3) Make the PRNG fully pluggable in the random package.
4) Modify Variance and StandardDeviation to compute multiple statistics
(with the variants being population, rather than sample statistics).
5) Drop the interface / implementation separation throughout the package.
I am personally -1 on 4) and 5); -0 on 1) and 2); and +0 on 3). I voted
+1 on the release; however, which means that 3) is a wart that I am
willing to live with for 1.0. It can be worked around now and to fix it
correctly will require that we define a PRNG interface and introduce
factories, etc.
Mark, since you voted to reopen API discussion, can you weigh in on
these issues and add any others that you see as show-stoppers?
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
http://www.kimvdlinde.com
-
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]
--
http://www.kimvdlinde.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Lang 2.0 - 2.1 diff
Stephen asked for this a bit back, sorry it's taken me so long. http://www.apache.org/~bayard/commons-lang-2.1/Commons-Lang-2.0-to-2.1/changes.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] API changes for RC2
Henri Yandell wrote: Some thoughts from a general Commons perspective: Thanks! 1) +0, This is worth getting right early on as package renaming does tend to confuse users and takes a long time to work through deprecation etc. Ugh.. Lots of change incompatible with RC1 here...but if others agree... What I dont understand is why the concept of univariate vs. multivariate is hard to understand. Univariate - sample consists of a single array of data (one random variable / distribution); multivariate - sample has more than on column (random vector / joint distribution). 2) -0. This is a new feature. If it's easy, add it. If it involves effort, don't bother until 1.1. 3) -0. Two options leap to mind, release PRNG as it is, or don't release the PRNG code. Yes it's a pain for users when you change the functionality in a new version, but when the option is not having a feature, users opt for the functionality and pain later. Most likely the change would be a simple perl regexp anyway. A point of clarification here. There is no PRNG code in [math]. The random package includes random data generation methods that *use* the JDK PRNG to generate random data, permutations or samples. I strongly disagree with the assertion that the JDK Random (and SecureRandom) implementations are worthless to the point where this package (which fully documents what PRNG is used) is not worth releasing. The valid issue here is that the PRNG should be pluggable (currently you have to subclass RandomDataImpl to do this). There also appears to be interest -- independently -- in adding other PRNG implementations, which could be among those plugged in to the random package. 4) -0. I was never a statistician, but this sounds like new functionality. Either release the code as is, or drop it. While 3) is an API change, this sounds like a functional change and those are much more painful for a user. I disagree strongly with this change, for two reasons: first, we spent a long time dabating whether or not statistics should be implemented as separate classes and decided in favor of this. To have a single class compute multiple statistics would be inconsistent with the design of the package. Secondly, even though the population version is computationally close to the sample version, there is an important and fundamental difference between them conceptually. I tried to explain this in earlier posts. Moreover, it is trivial to add additional classes implementing the population versions -- which actually supports the current one statistic per class design. I have not added them because I did not see this as essential for 1.0 and frankly I am not sure they belong in .statistics, since statistics are usually associated with sample data (i.e., some people would not call the population versions statistics but rather population parameters). 5) -0. Keep it as is. Again, it might mean an API change in the future, but I doubt anyone knows the perfect solution so let's see how this one goes. So the only one I'd advise as really being worth the effort is 1. Hen Phil The following changes have been suggested recently. Before cutting 1.0 final, we should make sure we are all OK postponing or forgoing these: 1) Eliminate the univariate/multivariate distinction in the stat package, because this seems confusing to some. Change .univariate to .descriptive and .multivariate to .regression 2) Add methods to create row or column matrices from double arrays and to extract submatrices (to the interface itself, rather than adding these to a utils class later) 3) Make the PRNG fully pluggable in the random package. 4) Modify Variance and StandardDeviation to compute multiple statistics (with the variants being population, rather than sample statistics). 5) Drop the interface / implementation separation throughout the package. I am personally -1 on 4) and 5); -0 on 1) and 2); and +0 on 3). I voted +1 on the release; however, which means that 3) is a wart that I am willing to live with for 1.0. It can be worked around now and to fix it correctly will require that we define a PRNG interface and introduce factories, etc. Mark, since you voted to reopen API discussion, can you weigh in on these issues and add any others that you see as show-stoppers? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time bugs Was: [lang] FastDateFormat year bug
Someone was smart and wrote a test to stop us doing this :)
It breaks the compatiblity with SimpleDateFormat.
I still think the real problem here is that we're trying to use a
DateFormat to represent a Duration, and DateFormat's lack the concept
of ignore leading 0's.
Instead I've added a boolean padWithZeroes parameter to the format
method. So the broken test code changes from:
//text = DurationFormatUtils.ISO_EXTENDED_FORMAT.format(cal);
to
text = DurationFormatUtils.format(cal.getTime().getTime(),
DurationFormatUtils.ISO_EXTENDED_FORMAT_PATTERN, false);
Ugly, but at least it's now using a duration.
It also changes the date you pass in. The former didn't work on
milliseconds but had a time of 1 AD. The latter switches to use
milliseconds.
There are still a few problems in here. What used to, with FastDateFormat, be:
P1Y2M3DT10H30M0.0S
is now:
P1Y1M3DT3H30M0.0S
Now, the 10H to 3H difference is probably due to my weakly defined
YEAR/MONTH values.
The 2M to 1M is interesting. One month is the correct answer to my
mind, but it used to think it was 2 months. Looks like this is
actually a bug that's been fixed, so that's a plus.
Lastly, I'd like to go ahead and remove the
DurationFormatUtils.ISO_EXTENDED_FORMAT variable. The PATTERN would
probably be renamed to use this more concise name. It has a plus-point
that it handles years/months better, though still fails to work leaps
out correctly. It's weird to use as you have to use dates in the
mid-roman era.
Hen
On Mon, 13 Sep 2004 11:15:14 -0400, Chua, Jerson (Exchange)
[EMAIL PROTECTED] wrote:
Hen,
Try this one out.
Update the code in case 'y' into this
if (tokenLen == 2) {
rule = TwoDigitYearField.INSTANCE;
} else {
rule = selectNumberRule(Calendar.YEAR, tokenLen);
}
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 12, 2004 12:48 AM
To: Jakarta Commons Developers List
Subject: Re: Time bugs Was: [lang] FastDateFormat year bug
Actually, I retract this. If it switches to P'y'Y, then it won't print
out 2002 but 02 when it does large durations. I think the 'hack' of
using a DateFormat to format durations is stretched here.
So 2 problems now. Years are broke in ISO_EXTENDED and dates are broke
in FastDateFormat.
Hen
On Sun, 12 Sep 2004 00:40:51 -0400, Henri Yandell [EMAIL PROTECTED]
wrote:
testISODurationFormat:
// test fixture from example in
http://www.w3.org/TR/xmlschema-2/#duration
cal.set(1, 1, 3, 10, 30, 0);
cal.set(Calendar.MILLISECOND, 0);
text = DurationFormatUtils.ISO_EXTENDED_FORMAT.format(cal);
assertEquals(P1Y2M3DT10H30M0.0S, text);
This is, I believe, a bug in our pattern:
ISO_EXTENDED_FORMAT_PATTERN = 'P''Y'M'M'd'DT'H'H'm'M's.S'S'
should be:
ISO_EXTENDED_FORMAT_PATTERN = 'P'y'Y'M'M'd'DT'H'H'm'M's.S'S'
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
***
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang/time DurationFormatUtilsTest.java
bayard 2004/09/25 22:45:33
Modified:lang/src/java/org/apache/commons/lang/time DateUtils.java
DurationFormatUtils.java
lang/src/test/org/apache/commons/lang/time
DurationFormatUtilsTest.java
Log:
switched tests away from using the extended format to using just the pattern and the
duration format code. Switched a year to being 365.25 days, though months are still
quite off when doing durations on milliseconds.
Revision ChangesPath
1.29 +2 -2
jakarta-commons/lang/src/java/org/apache/commons/lang/time/DateUtils.java
Index: DateUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/time/DateUtils.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- DateUtils.java21 Sep 2004 02:11:06 - 1.28
+++ DateUtils.java26 Sep 2004 05:45:33 - 1.29
@@ -57,7 +57,7 @@
public static final long MILLIS_PER_DAY = 24 * MILLIS_PER_HOUR;
// hmm. not very accurate. used by DurationFormatUtils
-static final long MILLIS_PER_YEAR = 365 * MILLIS_PER_DAY;
+static final long MILLIS_PER_YEAR = 365 * MILLIS_PER_DAY + 6 * MILLIS_PER_HOUR;
static final long MILLIS_PER_MONTH = MILLIS_PER_YEAR / 12;
/**
1.14 +15 -11
jakarta-commons/lang/src/java/org/apache/commons/lang/time/DurationFormatUtils.java
Index: DurationFormatUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/time/DurationFormatUtils.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- DurationFormatUtils.java 1 Sep 2004 17:40:55 - 1.13
+++ DurationFormatUtils.java 26 Sep 2004 05:45:33 - 1.14
@@ -25,7 +25,8 @@
* @author a href=mailto:[EMAIL PROTECTED]Stefan Bodewig/a
* @author Stephen Colebourne
* @author a href=mailto:[EMAIL PROTECTED]Gary Gregory/a
- * @since 2.0
+ * @author Henri Yandell
+ * @since 2.1
* @version $Id$
*/
public class DurationFormatUtils {
@@ -64,8 +65,8 @@
* @see #ISO_EXTENDED_FORMAT_PATTERN
* @see a
href=http://www.w3.org/TR/xmlschema-2/#duration;http://www.w3.org/TR/xmlschema-2/#duration/a
*/
-public static final FastDateFormat ISO_EXTENDED_FORMAT =
-FastDateFormat.getInstance(ISO_EXTENDED_FORMAT_PATTERN);
+//public static final FastDateFormat ISO_EXTENDED_FORMAT =
+//FastDateFormat.getInstance(ISO_EXTENDED_FORMAT_PATTERN);
/**
* pGet the time gap as a string./p
@@ -97,6 +98,9 @@
* @return the time as a String
*/
public static String format(long millis, String format) {
+return format(millis, format, true);
+}
+public static String format(long millis, String format, boolean padWithZeros) {
StringBuffer buffer = new StringBuffer();
Token[] tokens = lexx(format);
int sz = tokens.length;
@@ -151,25 +155,25 @@
buffer.append(value.toString());
} else {
if(value == y) {
-buffer.append( StringUtils.leftPad(+years, count, 0) );
+buffer.append( padWithZeros ? StringUtils.leftPad(+years,
count, 0) : +years );
} else
if(value == M) {
-buffer.append( StringUtils.leftPad(+months, count, 0) );
+buffer.append( padWithZeros ? StringUtils.leftPad(+months,
count, 0) : +months );
} else
if(value == d) {
-buffer.append( StringUtils.leftPad(+days, count, 0) );
+buffer.append( padWithZeros ? StringUtils.leftPad(+days,
count, 0) : +days );
} else
if(value == H) {
-buffer.append( StringUtils.leftPad(+hours, count, 0) );
+buffer.append( padWithZeros ? StringUtils.leftPad(+hours,
count, 0) : +hours );
} else
if(value == m) {
-buffer.append( StringUtils.leftPad(+minutes, count, 0) );
+buffer.append( padWithZeros ? StringUtils.leftPad(+minutes,
count, 0) : +minutes );
} else
if(value == s) {
-buffer.append( StringUtils.leftPad(+seconds, count, 0) );
+buffer.append( padWithZeros ? StringUtils.leftPad(+seconds,
count, 0) : +seconds );
} else
if(value == S) {
-buffer.append( StringUtils.leftPad(+milliseconds, count, 0)
);
+buffer.append( padWithZeros ?
StringUtils.leftPad(+milliseconds, count, 0)
Problems using AuthSSLProtocolSocketFactory to send Client Certificate in HTTPS session handshake
I have been trying for quite a wile to get the AuthSSLProtocolSocketFactory
to send a client certificate and it doesn't seem to be working. I am
wondering if the server (Oracle single sign-on server) is requesting the
client cert. When the request is made from a browser, the browser does send
the client cert. I have attached, my application, it is relatively simple
and a debug log. The debug options I used were -
javax.net.debug=ssl,handshake,keymanager.
I have looked at the debug log and I do not see a certificate request.
However, when IE is used, IE sends a client certificate.
Any help would be appreciated.
Thanks,
Dale McIntosh
/*
* Created on Aug 26, 2004
*
* TODO To change the template for this generated file go to
* Window - Preferences - Java - Code Style - Code Templates
*/
package testpackage
import java.io.*;
import java.net.*;
import org.apache.commons.httpclient.protocol.*;
import org.apache.commons.httpclient.*;
//import org.apache.commons.httpclient.auth.HttpAuthRealm;
import org.apache.commons.httpclient.methods.*;
import org.apache.commons.httpclient.contrib.ssl.*;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
* @author dmcintosh
*
* TODO To change the template for this generated type comment go to
* Window - Preferences - Java - Code Style - Code Templates
*/
public class LoadEventData {
private static final Log LOG = LogFactory.getLog(LoadEventData.class);
private String keyStorePath = ;
private String trustStorePath = ;
private String keyStorePassword = ;
public LoadEventData(String targetURL, String path, int pauseInterval, String userName, String keyStorePath, String keyStorePassword)
{
this(targetURL, path, pauseInterval, userName, keyStorePath, keyStorePath, keyStorePassword);
}
public LoadEventData(String targetURL, String path, int pauseInterval, String userName, String trustStorePath, String keyStorePath, String keyStorePassword)
{
this.keyStorePath = keyStorePath;
this.trustStorePath = trustStorePath != null ? trustStorePath : keyStorePath;
this.keyStorePassword = keyStorePassword;
initSocket(targetURL, path, pauseInterval, userName);
}
public void initSocket(String targetURL, String path, int pauseInterval, String userName)
{
File dir = new File(path);
if (dir.isDirectory())
{
do
{
File[] fileList = dir.listFiles();
for (int i = 0; i fileList.length; i++)
{
File evtFile = fileList[i];
String evtFileName = evtFile.getName();
if (evtFileName.toLowerCase().equals(quit.txt))
{
evtFile.delete();
System.exit(0);
}
if (evtFileName.lastIndexOf(.xml) == evtFileName.length() - 4)
{
if (loadEventDataFile(targetURL, userName, evtFile) = 0) System.out.println(File + evtFileName + sent to server);
else System.out.println(File + evtFileName + not processed - processing error);
evtFile.delete();
}
else System.out.println(File + evtFileName + not processed - bad type);
}
try
{
if (pauseInterval 0) Thread.sleep(pauseInterval * 1000);
}
catch (InterruptedException e) {};
} while (pauseInterval = 0);
}
}
public int loadEventDataFile(String targetURL, String userName, File evtFile)
{
HttpConnection connection = null;
HttpConnectionManager connectionManager = new SimpleHttpConnectionManager();
int status = 0;
try
{
LOG.debug(Here is a logging test);
String finalURL = targetURL + ?user= + userName;
MultipartPostMethod filePost = new MultipartPostMethod(finalURL);
filePost.addParameter(event, evtFile);
HttpClient client = new HttpClient();
URL url = new URL(targetURL);
HttpState state = new HttpState();
String host = url.getHost();
int port = url.getPort();
System.out.println(Host = + host + , + , Port = + port );
if (targetURL.trim().indexOf(https://;) == 0)
{
port = 443;
Protocol authhttps = new Protocol(https,
(ProtocolSocketFactory) new AuthSSLProtocolSocketFactory(
new URL(file: + keyStorePath), keyStorePassword,
new URL(file: + trustStorePath), keyStorePassword), 443);
Protocol.registerProtocol(https, authhttps);
client.getHostConfiguration().setHost(host, port, authhttps);
GetMethod fileGet = new GetMethod(finalURL);
status = client.executeMethod(fileGet);
String responseString = fileGet.getResponseBodyAsString();
if (responseString != null responseString.length() 0) System.out.println(Response String : +
Re: Problems using AuthSSLProtocolSocketFactory to send Client Certificate in HTTPS session handshake
Sorry the log didn't get attached Dale - Original Message - From: Dale McIntosh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, September 25, 2004 1:26 PM Subject: Problems using AuthSSLProtocolSocketFactory to send Client Certificate in HTTPS session handshake I have been trying for quite a wile to get the AuthSSLProtocolSocketFactory to send a client certificate and it doesn't seem to be working. I am wondering if the server (Oracle single sign-on server) is requesting the client cert. When the request is made from a browser, the browser does send the client cert. I have attached, my application, it is relatively simple and a debug log. The debug options I used were - javax.net.debug=ssl,handshake,keymanager. I have looked at the debug log and I do not see a certificate request. However, when IE is used, IE sends a client certificate. Any help would be appreciated. Thanks, Dale McIntosh - 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: Problems using AuthSSLProtocolSocketFactory to send Client Certificate in HTTPS session handshake
Dale, Do you know if the client authentication has been configured as required or optional? Does the server reject the connection when attempt is made to authenticate with an invalid certificate? The fact that IE pops up the certificate dialog does not not actually mean that the server validates the certificate or requests a client certificate at all. I tend to trust more the SSL log showing that the server did not request a client certificate. I retested the AuthSSLProtocolSocketFactory against Apache 2.0.51 with mod_ssl one more time and everything appeared to be OK. Oleg On Sat, 2004-09-25 at 22:26, Dale McIntosh wrote: I have been trying for quite a wile to get the AuthSSLProtocolSocketFactory to send a client certificate and it doesn't seem to be working. I am wondering if the server (Oracle single sign-on server) is requesting the client cert. When the request is made from a browser, the browser does send the client cert. I have attached, my application, it is relatively simple and a debug log. The debug options I used were - javax.net.debug=ssl,handshake,keymanager. I have looked at the debug log and I do not see a certificate request. However, when IE is used, IE sends a client certificate. Any help would be appreciated. Thanks, Dale McIntosh __ - 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: Problems using AuthSSLProtocolSocketFactory to send ClientCertificate in HTTPS session handshake
Oleg, The client certificate authentication is configured to be optional. The clients can either authenticate via a user certificate or via a user name / password. I am writing an automated interface that requires client authentification. The way that I determine that the client certificate wasn't sent, is by the page returned in the HTTP response. If I request a particular page and get the login page instead, I know the certificate was not sent. If I get the requested page, I know the certificate was sent and accepted by the server. I can validate this with IE by requesting a page without logging in. If I have a vaid client cert, I get the desired page. If not, I get the login page. My Java program, however, always gives me the login page. I am assuming that this is because the server is not requesting the client certificate. My belief at this point is that Oracle is only sending the client certificate to browser (IE) based clients. That would explain the problem. I have created an Oracle TAR, to see if this is an Oracle problem. I want to make sure that no client certificate request was made. I didn't see one looking at the log and I assume you didn't either. I expect to hear from Oracle soon, I'll let you know what they have to say about this. Thanks, Dale - Original Message - From: Oleg Kalnichevski [EMAIL PROTECTED] To: Commons HttpClient Project [EMAIL PROTECTED] Sent: Saturday, September 25, 2004 2:19 PM Subject: Re: Problems using AuthSSLProtocolSocketFactory to send ClientCertificate in HTTPS session handshake Dale, Do you know if the client authentication has been configured as required or optional? Does the server reject the connection when attempt is made to authenticate with an invalid certificate? The fact that IE pops up the certificate dialog does not not actually mean that the server validates the certificate or requests a client certificate at all. I tend to trust more the SSL log showing that the server did not request a client certificate. I retested the AuthSSLProtocolSocketFactory against Apache 2.0.51 with mod_ssl one more time and everything appeared to be OK. Oleg On Sat, 2004-09-25 at 22:26, Dale McIntosh wrote: I have been trying for quite a wile to get the AuthSSLProtocolSocketFactory to send a client certificate and it doesn't seem to be working. I am wondering if the server (Oracle single sign-on server) is requesting the client cert. When the request is made from a browser, the browser does send the client cert. I have attached, my application, it is relatively simple and a debug log. The debug options I used were - javax.net.debug=ssl,handshake,keymanager. I have looked at the debug log and I do not see a certificate request. However, when IE is used, IE sends a client certificate. Any help would be appreciated. Thanks, Dale McIntosh __ - 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]
