skunkdav-dev Mailing List for SkunkDAV WebDAV Client (Page 2)
Status: Beta
Brought to you by:
smulloni
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(10) |
Aug
(9) |
Sep
(19) |
Oct
(9) |
Nov
(14) |
Dec
(2) |
2002 |
Jan
(32) |
Feb
(13) |
Mar
(1) |
Apr
|
May
(3) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2003 |
Jan
(5) |
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Ge G. Z. <geg...@16...> - 2002-02-26 22:17:53
|
Hi, Jacob We want to add more columns into the available Table columns to name some pdf papers, such as author, paper title, publisher etc. From the API, these existing columns are defined in DAVTableHeader class, can we directly add to this class? Thanks. guozheng and harrywang |
From: GARTRELL,MIKE (HP-Corvallis,ex1) <mik...@hp...> - 2002-02-21 00:53:00
|
Are there any plans to provide support for the ACL method as defined by the WebDAV Access Control Protocol (http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.htm#_Toc5296181 23) in SkunkDAV? ---> Mike Gartrell <--- ---> mik...@hp... <--- ---> phone: (541) 715-0008 <--- |
From: Jacob S. <smu...@sm...> - 2002-02-12 17:07:11
|
As the folks on this list have no doubt noticed, I have not had a lot of time to spend on skunkdav maintenance of late, which is unfair to those of you who want to use it. I wish to remain involved and keep the codebase up to date; indeed, I'd like it to enter a new stage of growth, remedy its defects, support DeltaV, etc. However, I can't do it by myself at the moment. I hereby invite any programmer(s) interested in developing and helping to maintain skunkdav to contact me. I'd like to share the responsibility, and I'd also be more stimulated to work on it in collaboration than by myself. Robin Thomas has joined up to work on specific issues that interest him; anyone else with a pet peeve should raise his/her hand. js -- Jacob Smullyan | smu...@sm... http://www.smullyan.org/smulloni/ |
From: Jacob S. <smu...@sm...> - 2002-02-12 16:59:19
|
On Tue, Feb 12, 2002 at 11:27:42AM -0500, gr...@ch... wrote: > I am using the SkunkDav library in my Java application to access webdav > server resources. I have two issues: > 1) Why is authenticator being reset? > I set up the authenticator in DAVConnection with username and password > information because I don't want the authentication panel to pop up. The > method getAuthorization(AuthorizationInfo , RoRequest , RoResponse ) in > HTTPAuthHandler, resets the authenticator, causing the authentication > window to pop up. > If I comment out the line; authenticator.reset() everything works fine. > Why is authenticator being reset? I don't know anymore, and it will soon be moot, because I will be removing the authenticator in the next release, which upgrades to a newer version of HTTPClient. There will be a slight break in backwards compatibility, in this area alone, but it won't be too significant. For the time being, then, if you are hardcoding authentication information, I'd suggest you not use an auth handler at all, and call setAuthorization() instead. That method will still be supported (although it will probably be deprecated). > 2) Output stream? > The HTTPClient allows data to be sent to the server using byte[] or output > stream. Has anyone used SkunkDav to send data using output stream. A patch was submitted to add precisely this, and it will also be in the next release. I am behind in checking this stuff in. Feel free to pester me. js -- Jacob Smullyan | smu...@sm... http://www.smullyan.org/smulloni/ |
From: <gr...@ch...> - 2002-02-12 16:35:58
|
I am using the SkunkDav library in my Java application to access webdav server resources. I have two issues: 1) Why is authenticator being reset? I set up the authenticator in DAVConnection with username and password information because I don't want the authentication panel to pop up. The method getAuthorization(AuthorizationInfo , RoRequest , RoResponse ) in HTTPAuthHandler, resets the authenticator, causing the authentication window to pop up. If I comment out the line; authenticator.reset() everything works fine. Why is authenticator being reset? 2) Output stream? The HTTPClient allows data to be sent to the server using byte[] or output stream. Has anyone used SkunkDav to send data using output stream. Thanks Geeta Raju |
From: Brendan R. <bre...@te...> - 2002-02-11 20:20:08
|
hi all, I'm not sure if this mailing list supports attachments, but attached is my version of DAVConnection. Do a search for "Brendan" in the code and you'll find the bits I added for digest authentication. My archived message below explains the simple concept. I think that's all it took, and it did work on at least one Digest authenticating server in the field. Let me know if I've missed out on anything. - Brendan P.S. While attaching things, I've also attached DAVFile. On that same server, the order of child nodes was important. The original TreeMap didn't seem to preserve order, so I changed it to a Vector. Again, search for "brendan" to find the changes. > -----Original Message----- > From: sku...@li... > [mailto:sku...@li...]On Behalf Of David > Scheck > Sent: Tuesday, January 15, 2002 2:42 PM > To: sku...@li... > Subject: Re: [Skunkdav-dev] Is Digest Authentication doable? > > > I just found the following archived email message on the Digest > topic. Does anyone have this simple fix working? I am not exactly > sure where to look for those 'original functions' so that I can copy the > Digest parts back into the new handler. > > Has this been submitted to CVS already? > > -dave > > > Message: 6920971 > > FROM: Brendan Reville > DATE: 10/26/2001 11:44:25 > SUBJECT: RE: [Skunkdav-dev] Qs; digest authentication > > correct, but it's fairly simple to add. > > You'll see that the authorization handler at the bottom of > DAVConnection.java just overrides HTTPClient's default > AuthorizationHandler. > For the functions it overrides it pretty much duplicates the code from > the > original, doing a bit of extra skunkdav work. You can go back to the > original functions and copy the Digest parts into the new handler, and it > seems to work fine. > > - Brendan > On Tuesday, January 15, 2002, at 05:05 PM, David Scheck wrote: > > > I wanted to use SkunkDAV to create a Java app that front ends a webdav > > server using Digest authentication. It looks to me that only the > > Basic authentication scheme is supported by SkunkDAV. Is this true? > > Does anyone have any idea how hard it would be to add Digest support? > > Was it left as an exercise because it was hard? > > > > Thanks > > dave > > > > > > > > _______________________________________________ > > Skunkdav-dev mailing list > > Sku...@li... > > https://lists.sourceforge.net/lists/listinfo/skunkdav-dev > > > _______________________________________________ > Skunkdav-dev mailing list > Sku...@li... > https://lists.sourceforge.net/lists/listinfo/skunkdav-dev |
From: Jacob S. <smu...@sm...> - 2002-02-08 22:59:55
|
I will change the license in the source files to indicate that the license that applies to the library components is LGPL. js On Fri, Feb 08, 2002 at 11:49:53AM -0800, GARTRELL,MIKE (HP-Corvallis,ex1) wrote: > This problem was due to the cacerts file being in the wrong > location. HTTPClient was was unable to find the proper certificate for the > server, which caused the NullPointerException described below. > > Will the next release of SkunkDAV formally license the DAV client > library portion under the LGPL? > > -----Original Message----- > From: Jacob Smullyan [mailto:smu...@sm...] > Sent: Friday, February 01, 2002 6:19 PM > To: GARTRELL,MIKE (HP-Corvallis,ex1) > Cc: 'sku...@li...' > Subject: Re: [Skunkdav-dev] SSL connection problem > > > On Fri, Feb 01, 2002 at 05:39:45PM -0800, GARTRELL,MIKE (HP-Corvallis,ex1) > wrote: > > The NullPointerException is occuring inside the test > > (checkCertificate()), so yes, the test is failing. Do you know what would > > cause this? It appears there is a certificate problem on the client, but > I > > am unable to identify the root cause. The appropriate certificate for the > > server that I'm connecting to is located in the keystore and the cacerts > > keystore. > > But all the code in checkCertificate is enclosed in a try/block; why > would it cause the test to fail? It is simply printing the stack > trace of the exception. If the test is failing, it is for another > reason (probably the same reason that SSLSocket.getSession() is > returning null). If the certificate is located in the keystore, then > I don't currently know why. > > I am currently upgrading the library to use the newer version of > HTTPClient. I just looked at the SSL patches used by Joachim Feise's > DAVExplorer, which also uses HTTPClient. You might try a simple > connection test to your server with my HTTPClient patch and with > Feise's; my patch is taken from Tschalar's, and is rather crude. I'd > be delighted if Feise's worked for you; his code and mine are > license-compatible, and I could incorporate his patch or some portion > thereof. > > > > > -----Original Message----- > > From: Jacob Smullyan [mailto:smu...@sm...] > > Sent: Friday, February 01, 2002 4:52 PM > > To: GARTRELL,MIKE (HP-Corvallis,ex1) > > Cc: 'sku...@li...' > > Subject: Re: [Skunkdav-dev] SSL connection problem > > > > > > On Fri, Feb 01, 2002 at 04:10:44PM -0800, GARTRELL,MIKE (HP-Corvallis,ex1) > > wrote: > > > I'm receiving the following exception when attempting to establish > > > an HTTPS connection to a DAV server using SkunkDAV 1.0.2.4: > > > > > > .java.lang.NullPointerException > > > at > > > HTTPClient.jsse.JsseSSLSupport.checkCertificate(JsseSSLSupport.java:91) > > > at > > > HTTPClient.jsse.JsseSSLSupport.createSocket(JsseSSLSupport.java:73) > > > at > HTTPClient.HTTPConnection.sendRequest(HTTPConnection.java:2846) > > > at > > HTTPClient.HTTPConnection.handleRequest(HTTPConnection.java:2662) > > > at > > HTTPClient.HTTPConnection.setupRequest(HTTPConnection.java:2455) > > > at > > > HTTPClient.HTTPConnection.ExtensionMethod(HTTPConnection.java:1315) > > > at > > > org.skunk.dav.client.DAVConnection.execute(DAVConnection.java:221) > > > at com.hp.vdpcore.webdav.DAVWriter.writeFile(Unknown Source) > > > at > > > > > > com.hp.vdpcore.webdav.test.DAVWriterTest.testWriteFile(DAVWriterTest.java:11 > > > 7) > > > at java.lang.reflect.Method.invoke(Native Method) > > > at junit.framework.TestCase.runTest(TestCase.java:156) > > > at junit.framework.TestCase.runBare(TestCase.java:130) > > > at junit.framework.TestResult$1.protect(TestResult.java:106) > > > at junit.framework.TestResult.runProtected(TestResult.java:124) > > > at junit.framework.TestResult.run(TestResult.java:109) > > > at junit.framework.TestCase.run(TestCase.java:121) > > > at junit.framework.TestSuite.runTest(TestSuite.java:157) > > > at junit.framework.TestSuite.run(TestSuite.java:152) > > > at junit.textui.TestRunner.doRun(TestRunner.java:74) > > > at junit.textui.TestRunner.run(TestRunner.java:201) > > > at > > > com.hp.vdpcore.webdav.test.DAVWriterTest.main(DAVWriterTest.java:97) > > > > > > The above occurs when executing a PUT using the PutMethod. > Any > > > ideas about what might cause this? > > > > The stack trace is getting printed, but not passed up to the caller, > > right? I don't see any other possibility in that method. > > > > The method in question is rather pointless to begin with at the > > moment. It doesn't do anything, actually, except possibly print an > > error message of one kind or another. Does the test fail? > > > > j > > > > \> > > > > > > ---> Mike Gartrell <--- ---> mik...@hp... <--- > > > ---> phone: (541) 715-0008 <--- > > > > > > > > > _______________________________________________ > > > Skunkdav-dev mailing list > > > Sku...@li... > > > https://lists.sourceforge.net/lists/listinfo/skunkdav-dev > > > > -- > > Jacob Smullyan | smu...@sm... > > http://www.smullyan.org/smulloni/ > > > > _______________________________________________ > > Skunkdav-dev mailing list > > Sku...@li... > > https://lists.sourceforge.net/lists/listinfo/skunkdav-dev > > -- > Jacob Smullyan | smu...@sm... > http://www.smullyan.org/smulloni/ > > _______________________________________________ > Skunkdav-dev mailing list > Sku...@li... > https://lists.sourceforge.net/lists/listinfo/skunkdav-dev -- Jacob Smullyan | smu...@sm... http://www.smullyan.org/smulloni/ |
From: GARTRELL,MIKE (HP-Corvallis,ex1) <mik...@hp...> - 2002-02-08 19:50:11
|
This problem was due to the cacerts file being in the wrong location. HTTPClient was was unable to find the proper certificate for the server, which caused the NullPointerException described below. Will the next release of SkunkDAV formally license the DAV client library portion under the LGPL? -----Original Message----- From: Jacob Smullyan [mailto:smu...@sm...] Sent: Friday, February 01, 2002 6:19 PM To: GARTRELL,MIKE (HP-Corvallis,ex1) Cc: 'sku...@li...' Subject: Re: [Skunkdav-dev] SSL connection problem On Fri, Feb 01, 2002 at 05:39:45PM -0800, GARTRELL,MIKE (HP-Corvallis,ex1) wrote: > The NullPointerException is occuring inside the test > (checkCertificate()), so yes, the test is failing. Do you know what would > cause this? It appears there is a certificate problem on the client, but I > am unable to identify the root cause. The appropriate certificate for the > server that I'm connecting to is located in the keystore and the cacerts > keystore. But all the code in checkCertificate is enclosed in a try/block; why would it cause the test to fail? It is simply printing the stack trace of the exception. If the test is failing, it is for another reason (probably the same reason that SSLSocket.getSession() is returning null). If the certificate is located in the keystore, then I don't currently know why. I am currently upgrading the library to use the newer version of HTTPClient. I just looked at the SSL patches used by Joachim Feise's DAVExplorer, which also uses HTTPClient. You might try a simple connection test to your server with my HTTPClient patch and with Feise's; my patch is taken from Tschalar's, and is rather crude. I'd be delighted if Feise's worked for you; his code and mine are license-compatible, and I could incorporate his patch or some portion thereof. > > -----Original Message----- > From: Jacob Smullyan [mailto:smu...@sm...] > Sent: Friday, February 01, 2002 4:52 PM > To: GARTRELL,MIKE (HP-Corvallis,ex1) > Cc: 'sku...@li...' > Subject: Re: [Skunkdav-dev] SSL connection problem > > > On Fri, Feb 01, 2002 at 04:10:44PM -0800, GARTRELL,MIKE (HP-Corvallis,ex1) > wrote: > > I'm receiving the following exception when attempting to establish > > an HTTPS connection to a DAV server using SkunkDAV 1.0.2.4: > > > > .java.lang.NullPointerException > > at > > HTTPClient.jsse.JsseSSLSupport.checkCertificate(JsseSSLSupport.java:91) > > at > > HTTPClient.jsse.JsseSSLSupport.createSocket(JsseSSLSupport.java:73) > > at HTTPClient.HTTPConnection.sendRequest(HTTPConnection.java:2846) > > at > HTTPClient.HTTPConnection.handleRequest(HTTPConnection.java:2662) > > at > HTTPClient.HTTPConnection.setupRequest(HTTPConnection.java:2455) > > at > > HTTPClient.HTTPConnection.ExtensionMethod(HTTPConnection.java:1315) > > at > > org.skunk.dav.client.DAVConnection.execute(DAVConnection.java:221) > > at com.hp.vdpcore.webdav.DAVWriter.writeFile(Unknown Source) > > at > > > com.hp.vdpcore.webdav.test.DAVWriterTest.testWriteFile(DAVWriterTest.java:11 > > 7) > > at java.lang.reflect.Method.invoke(Native Method) > > at junit.framework.TestCase.runTest(TestCase.java:156) > > at junit.framework.TestCase.runBare(TestCase.java:130) > > at junit.framework.TestResult$1.protect(TestResult.java:106) > > at junit.framework.TestResult.runProtected(TestResult.java:124) > > at junit.framework.TestResult.run(TestResult.java:109) > > at junit.framework.TestCase.run(TestCase.java:121) > > at junit.framework.TestSuite.runTest(TestSuite.java:157) > > at junit.framework.TestSuite.run(TestSuite.java:152) > > at junit.textui.TestRunner.doRun(TestRunner.java:74) > > at junit.textui.TestRunner.run(TestRunner.java:201) > > at > > com.hp.vdpcore.webdav.test.DAVWriterTest.main(DAVWriterTest.java:97) > > > > The above occurs when executing a PUT using the PutMethod. Any > > ideas about what might cause this? > > The stack trace is getting printed, but not passed up to the caller, > right? I don't see any other possibility in that method. > > The method in question is rather pointless to begin with at the > moment. It doesn't do anything, actually, except possibly print an > error message of one kind or another. Does the test fail? > > j > > \> > > > > ---> Mike Gartrell <--- ---> mik...@hp... <--- > > ---> phone: (541) 715-0008 <--- > > > > > > _______________________________________________ > > Skunkdav-dev mailing list > > Sku...@li... > > https://lists.sourceforge.net/lists/listinfo/skunkdav-dev > > -- > Jacob Smullyan | smu...@sm... > http://www.smullyan.org/smulloni/ > > _______________________________________________ > Skunkdav-dev mailing list > Sku...@li... > https://lists.sourceforge.net/lists/listinfo/skunkdav-dev -- Jacob Smullyan | smu...@sm... http://www.smullyan.org/smulloni/ |
From: Jacob S. <smu...@sm...> - 2002-02-02 02:19:05
|
On Fri, Feb 01, 2002 at 05:39:45PM -0800, GARTRELL,MIKE (HP-Corvallis,ex1) wrote: > The NullPointerException is occuring inside the test > (checkCertificate()), so yes, the test is failing. Do you know what would > cause this? It appears there is a certificate problem on the client, but I > am unable to identify the root cause. The appropriate certificate for the > server that I'm connecting to is located in the keystore and the cacerts > keystore. But all the code in checkCertificate is enclosed in a try/block; why would it cause the test to fail? It is simply printing the stack trace of the exception. If the test is failing, it is for another reason (probably the same reason that SSLSocket.getSession() is returning null). If the certificate is located in the keystore, then I don't currently know why. I am currently upgrading the library to use the newer version of HTTPClient. I just looked at the SSL patches used by Joachim Feise's DAVExplorer, which also uses HTTPClient. You might try a simple connection test to your server with my HTTPClient patch and with Feise's; my patch is taken from Tschalar's, and is rather crude. I'd be delighted if Feise's worked for you; his code and mine are license-compatible, and I could incorporate his patch or some portion thereof. > > -----Original Message----- > From: Jacob Smullyan [mailto:smu...@sm...] > Sent: Friday, February 01, 2002 4:52 PM > To: GARTRELL,MIKE (HP-Corvallis,ex1) > Cc: 'sku...@li...' > Subject: Re: [Skunkdav-dev] SSL connection problem > > > On Fri, Feb 01, 2002 at 04:10:44PM -0800, GARTRELL,MIKE (HP-Corvallis,ex1) > wrote: > > I'm receiving the following exception when attempting to establish > > an HTTPS connection to a DAV server using SkunkDAV 1.0.2.4: > > > > .java.lang.NullPointerException > > at > > HTTPClient.jsse.JsseSSLSupport.checkCertificate(JsseSSLSupport.java:91) > > at > > HTTPClient.jsse.JsseSSLSupport.createSocket(JsseSSLSupport.java:73) > > at HTTPClient.HTTPConnection.sendRequest(HTTPConnection.java:2846) > > at > HTTPClient.HTTPConnection.handleRequest(HTTPConnection.java:2662) > > at > HTTPClient.HTTPConnection.setupRequest(HTTPConnection.java:2455) > > at > > HTTPClient.HTTPConnection.ExtensionMethod(HTTPConnection.java:1315) > > at > > org.skunk.dav.client.DAVConnection.execute(DAVConnection.java:221) > > at com.hp.vdpcore.webdav.DAVWriter.writeFile(Unknown Source) > > at > > > com.hp.vdpcore.webdav.test.DAVWriterTest.testWriteFile(DAVWriterTest.java:11 > > 7) > > at java.lang.reflect.Method.invoke(Native Method) > > at junit.framework.TestCase.runTest(TestCase.java:156) > > at junit.framework.TestCase.runBare(TestCase.java:130) > > at junit.framework.TestResult$1.protect(TestResult.java:106) > > at junit.framework.TestResult.runProtected(TestResult.java:124) > > at junit.framework.TestResult.run(TestResult.java:109) > > at junit.framework.TestCase.run(TestCase.java:121) > > at junit.framework.TestSuite.runTest(TestSuite.java:157) > > at junit.framework.TestSuite.run(TestSuite.java:152) > > at junit.textui.TestRunner.doRun(TestRunner.java:74) > > at junit.textui.TestRunner.run(TestRunner.java:201) > > at > > com.hp.vdpcore.webdav.test.DAVWriterTest.main(DAVWriterTest.java:97) > > > > The above occurs when executing a PUT using the PutMethod. Any > > ideas about what might cause this? > > The stack trace is getting printed, but not passed up to the caller, > right? I don't see any other possibility in that method. > > The method in question is rather pointless to begin with at the > moment. It doesn't do anything, actually, except possibly print an > error message of one kind or another. Does the test fail? > > j > > \> > > > > ---> Mike Gartrell <--- ---> mik...@hp... <--- > > ---> phone: (541) 715-0008 <--- > > > > > > _______________________________________________ > > Skunkdav-dev mailing list > > Sku...@li... > > https://lists.sourceforge.net/lists/listinfo/skunkdav-dev > > -- > Jacob Smullyan | smu...@sm... > http://www.smullyan.org/smulloni/ > > _______________________________________________ > Skunkdav-dev mailing list > Sku...@li... > https://lists.sourceforge.net/lists/listinfo/skunkdav-dev -- Jacob Smullyan | smu...@sm... http://www.smullyan.org/smulloni/ |
From: GARTRELL,MIKE (HP-Corvallis,ex1) <mik...@hp...> - 2002-02-02 01:39:56
|
The NullPointerException is occuring inside the test (checkCertificate()), so yes, the test is failing. Do you know what would cause this? It appears there is a certificate problem on the client, but I am unable to identify the root cause. The appropriate certificate for the server that I'm connecting to is located in the keystore and the cacerts keystore. -----Original Message----- From: Jacob Smullyan [mailto:smu...@sm...] Sent: Friday, February 01, 2002 4:52 PM To: GARTRELL,MIKE (HP-Corvallis,ex1) Cc: 'sku...@li...' Subject: Re: [Skunkdav-dev] SSL connection problem On Fri, Feb 01, 2002 at 04:10:44PM -0800, GARTRELL,MIKE (HP-Corvallis,ex1) wrote: > I'm receiving the following exception when attempting to establish > an HTTPS connection to a DAV server using SkunkDAV 1.0.2.4: > > .java.lang.NullPointerException > at > HTTPClient.jsse.JsseSSLSupport.checkCertificate(JsseSSLSupport.java:91) > at > HTTPClient.jsse.JsseSSLSupport.createSocket(JsseSSLSupport.java:73) > at HTTPClient.HTTPConnection.sendRequest(HTTPConnection.java:2846) > at HTTPClient.HTTPConnection.handleRequest(HTTPConnection.java:2662) > at HTTPClient.HTTPConnection.setupRequest(HTTPConnection.java:2455) > at > HTTPClient.HTTPConnection.ExtensionMethod(HTTPConnection.java:1315) > at > org.skunk.dav.client.DAVConnection.execute(DAVConnection.java:221) > at com.hp.vdpcore.webdav.DAVWriter.writeFile(Unknown Source) > at > com.hp.vdpcore.webdav.test.DAVWriterTest.testWriteFile(DAVWriterTest.java:11 > 7) > at java.lang.reflect.Method.invoke(Native Method) > at junit.framework.TestCase.runTest(TestCase.java:156) > at junit.framework.TestCase.runBare(TestCase.java:130) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:121) > at junit.framework.TestSuite.runTest(TestSuite.java:157) > at junit.framework.TestSuite.run(TestSuite.java:152) > at junit.textui.TestRunner.doRun(TestRunner.java:74) > at junit.textui.TestRunner.run(TestRunner.java:201) > at > com.hp.vdpcore.webdav.test.DAVWriterTest.main(DAVWriterTest.java:97) > > The above occurs when executing a PUT using the PutMethod. Any > ideas about what might cause this? The stack trace is getting printed, but not passed up to the caller, right? I don't see any other possibility in that method. The method in question is rather pointless to begin with at the moment. It doesn't do anything, actually, except possibly print an error message of one kind or another. Does the test fail? j \> > > ---> Mike Gartrell <--- ---> mik...@hp... <--- > ---> phone: (541) 715-0008 <--- > > > _______________________________________________ > Skunkdav-dev mailing list > Sku...@li... > https://lists.sourceforge.net/lists/listinfo/skunkdav-dev -- Jacob Smullyan | smu...@sm... http://www.smullyan.org/smulloni/ |
From: Jacob S. <smu...@sm...> - 2002-02-02 00:52:27
|
On Fri, Feb 01, 2002 at 04:10:44PM -0800, GARTRELL,MIKE (HP-Corvallis,ex1) wrote: > I'm receiving the following exception when attempting to establish > an HTTPS connection to a DAV server using SkunkDAV 1.0.2.4: > > .java.lang.NullPointerException > at > HTTPClient.jsse.JsseSSLSupport.checkCertificate(JsseSSLSupport.java:91) > at > HTTPClient.jsse.JsseSSLSupport.createSocket(JsseSSLSupport.java:73) > at HTTPClient.HTTPConnection.sendRequest(HTTPConnection.java:2846) > at HTTPClient.HTTPConnection.handleRequest(HTTPConnection.java:2662) > at HTTPClient.HTTPConnection.setupRequest(HTTPConnection.java:2455) > at > HTTPClient.HTTPConnection.ExtensionMethod(HTTPConnection.java:1315) > at > org.skunk.dav.client.DAVConnection.execute(DAVConnection.java:221) > at com.hp.vdpcore.webdav.DAVWriter.writeFile(Unknown Source) > at > com.hp.vdpcore.webdav.test.DAVWriterTest.testWriteFile(DAVWriterTest.java:11 > 7) > at java.lang.reflect.Method.invoke(Native Method) > at junit.framework.TestCase.runTest(TestCase.java:156) > at junit.framework.TestCase.runBare(TestCase.java:130) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:121) > at junit.framework.TestSuite.runTest(TestSuite.java:157) > at junit.framework.TestSuite.run(TestSuite.java:152) > at junit.textui.TestRunner.doRun(TestRunner.java:74) > at junit.textui.TestRunner.run(TestRunner.java:201) > at > com.hp.vdpcore.webdav.test.DAVWriterTest.main(DAVWriterTest.java:97) > > The above occurs when executing a PUT using the PutMethod. Any > ideas about what might cause this? The stack trace is getting printed, but not passed up to the caller, right? I don't see any other possibility in that method. The method in question is rather pointless to begin with at the moment. It doesn't do anything, actually, except possibly print an error message of one kind or another. Does the test fail? j \> > > ---> Mike Gartrell <--- ---> mik...@hp... <--- > ---> phone: (541) 715-0008 <--- > > > _______________________________________________ > Skunkdav-dev mailing list > Sku...@li... > https://lists.sourceforge.net/lists/listinfo/skunkdav-dev -- Jacob Smullyan | smu...@sm... http://www.smullyan.org/smulloni/ |
From: GARTRELL,MIKE (HP-Corvallis,ex1) <mik...@hp...> - 2002-02-02 00:10:52
|
I'm receiving the following exception when attempting to establish an HTTPS connection to a DAV server using SkunkDAV 1.0.2.4: .java.lang.NullPointerException at HTTPClient.jsse.JsseSSLSupport.checkCertificate(JsseSSLSupport.java:91) at HTTPClient.jsse.JsseSSLSupport.createSocket(JsseSSLSupport.java:73) at HTTPClient.HTTPConnection.sendRequest(HTTPConnection.java:2846) at HTTPClient.HTTPConnection.handleRequest(HTTPConnection.java:2662) at HTTPClient.HTTPConnection.setupRequest(HTTPConnection.java:2455) at HTTPClient.HTTPConnection.ExtensionMethod(HTTPConnection.java:1315) at org.skunk.dav.client.DAVConnection.execute(DAVConnection.java:221) at com.hp.vdpcore.webdav.DAVWriter.writeFile(Unknown Source) at com.hp.vdpcore.webdav.test.DAVWriterTest.testWriteFile(DAVWriterTest.java:11 7) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:156) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:121) at junit.framework.TestSuite.runTest(TestSuite.java:157) at junit.framework.TestSuite.run(TestSuite.java:152) at junit.textui.TestRunner.doRun(TestRunner.java:74) at junit.textui.TestRunner.run(TestRunner.java:201) at com.hp.vdpcore.webdav.test.DAVWriterTest.main(DAVWriterTest.java:97) The above occurs when executing a PUT using the PutMethod. Any ideas about what might cause this? ---> Mike Gartrell <--- ---> mik...@hp... <--- ---> phone: (541) 715-0008 <--- |
From: Alexander D. <ale...@di...> - 2002-01-29 21:42:37
|
Hello, how is the patch for digest authentication coming along ? One thing: there might be a problem with HTTPClient, namely PUTs with output streams fail when using digest authentication. At least they do for me when using Apache + mod_dav. I currently have no other server to test it with. I already sent a notice to HTTPClient's author, but haven't received a reply yet. Regards, Alexander Dietrich -- ( Alexander Dietrich <ale...@di...> ) |
From: Jacob S. <smu...@sm...> - 2002-01-25 14:26:09
|
On Fri, Jan 25, 2002 at 12:51:59PM +0100, Alexander Dietrich wrote: > Jacob Smullyan wrote: > > > If you or Alexander D. submits a patch, I will :). If not, I'll do > > it, but probably not before tonight. However, it shouldn't be hard. > > No patch, but the three HTTP date formats from RFC 2616 translate > to these time pattern strings for SimpleDateFormat: > > RFC 1123: "EEE, dd MMM yyyy HH:mm:ss z" > RFC 850: "EEEE, dd-MMM-yy HH:mm:ss z" > asctime(): "EEE MMM d HH:mm:ss yyyy" > > Notes: > - clients should accept all three formats, but generate only the first > - the 'z' should actually be a literal "GMT", but this way it will > hopefully catch broken implementations that don't use GMT > - there's a problem with #3: asctime() prefixes single-digit days with a > space, setting the parser to lenient might be necessary > - I have only tested the first format Thanks, this will be very helpful. > Are you already attacking the ISO date monster ? I haven't had time, although I know what to do. I will have time for it this weekend, however, to code this, check in your patches, and possibly upgrade HTTPClient. > _______________________________________________ > Skunkdav-dev mailing list > Sku...@li... > https://lists.sourceforge.net/lists/listinfo/skunkdav-dev -- Jacob Smullyan | smu...@sm... http://www.smullyan.org/smulloni/ |
From: Alexander D. <ale...@di...> - 2002-01-25 11:49:59
|
Jacob Smullyan wrote: > If you or Alexander D. submits a patch, I will :). If not, I'll do > it, but probably not before tonight. However, it shouldn't be hard. No patch, but the three HTTP date formats from RFC 2616 translate to these time pattern strings for SimpleDateFormat: RFC 1123: "EEE, dd MMM yyyy HH:mm:ss z" RFC 850: "EEEE, dd-MMM-yy HH:mm:ss z" asctime(): "EEE MMM d HH:mm:ss yyyy" Notes: - clients should accept all three formats, but generate only the first - the 'z' should actually be a literal "GMT", but this way it will hopefully catch broken implementations that don't use GMT - there's a problem with #3: asctime() prefixes single-digit days with a space, setting the parser to lenient might be necessary - I have only tested the first format Are you already attacking the ISO date monster ? Regards, Alexander Dietrich -- ( Alexander Dietrich <ale...@di...> ) |
From: Jacob S. <smu...@sm...> - 2002-01-23 16:32:12
|
On Wed, Jan 23, 2002 at 09:54:04AM -0500, David Scheck wrote: > > On Wednesday, January 23, 2002, at 09:40 AM, Jacob Smullyan wrote: > > > > > If I were to add an additional method or methods which performed the > > Date conversions, would there be dancing in the streets? > > I would be dancing in the streets if DAVConnection & DAVFile had a > setTimeZone method and DAVFile had convenience methods that would return > the lastModified and creationDate using the timeZone. DAVFile should > inherit the timeZone of the DAVConnection but allow you to change it on > an individual basis if you desire. A more typically Java-oid sort of thing would be to default to the time zone of the current locale and permit that to be overridden as desired. However, the creation date tells the time zone where the creation occurred, so it also contains geographical information; do you want to throw that away? It would still be available in the raw data, which would minimize our crime. > In the meantime, does anyone have a code snippet on how to use > java.text.SimpleDateFormat to do the conversion? If you or Alexander D. submits a patch, I will :). If not, I'll do it, but probably not before tonight. However, it shouldn't be hard. Parsing the ISO date might be best done not all in one shot; I'm guessing I'd do the date, time and time offset (number of hours from GMT) separately, and then munge the Date object accordingly. So, to parse 2002-01-15T18:50:03-04:00, you'd split the string three ways. Maybe there is a way of splitting it just two ways and having it accept the "T", but I'd have to look into it. js -- Jacob Smullyan | smu...@sm... http://www.smullyan.org/smulloni/ |
From: Alexander D. <ale...@di...> - 2002-01-23 15:42:50
|
Jacob Smullyan wrote: > If I were to add an additional method or methods which performed the > Date conversions, would there be dancing in the streets? Or is anyone > motivated to contribute a patch to do this? Well, I could caper a bit if that helps. :) BTW, in what form do you want patches for SkunkDAV ? I'm currently working on something (else), but it's based on the latest release version. So if it needs to be against CVS, I'd have to take a look at that. > I should point out that creation date and last modified are two > different beasts with regard to formatting. The last modified date is > an http time-stamp, but creation date is an ISO 8601 date format, and > includes a time zone designator. RFC 2518 mandates precisely which > format to use. With regard to other dates, servers can send back very > different sorts of date formats; Xythos, as I recall (apologies if I > am mistaken) can be configured on a per-user basis to send back many > different date formats. Right, all properties are just strings IIRC. But since last modified and creation date do have defined formats, it would be nice to have them converted to Date objects right away. Date is independent of time zone and locale settings after all, giving the best basis for whatever processing. (Comparing to other dates, converting to another time zone, etc.) All other date values (not defined in the WebDAV RFC) will remain string properties I guess. Regards, Alexander -- ( Alexander Dietrich <ale...@di...> ) |
From: David S. <ds...@ap...> - 2002-01-23 14:54:07
|
On Wednesday, January 23, 2002, at 09:40 AM, Jacob Smullyan wrote: > > If I were to add an additional method or methods which performed the > Date conversions, would there be dancing in the streets? I would be dancing in the streets if DAVConnection & DAVFile had a setTimeZone method and DAVFile had convenience methods that would return the lastModified and creationDate using the timeZone. DAVFile should inherit the timeZone of the DAVConnection but allow you to change it on an individual basis if you desire. In the meantime, does anyone have a code snippet on how to use java.text.SimpleDateFormat to do the conversion? -dave |
From: Jacob S. <smu...@sm...> - 2002-01-23 14:40:21
|
On Wed, Jan 23, 2002 at 12:25:53PM +0100, Alexander Dietrich wrote: > David Scheck wrote: > > > Does anyone have the proper way to change DAVFile's getLastModified, > > getCreationDate from GMT to EST or PST? > > I think the time zone those methods use will not change, because "All > HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), > without exception." > But you could try java.text.SimpleDateFormat for parsing and formatting > the date strings. Receiving Date objects from DAVFile would be a bit more > solid, IMHO. That's right, the conversion is left up to the user of the API. This is a bit annoying, but it does separate sidestep locale, timezone and format issues from webdav response parsing issues, which is why I originally made that choice. If I were to add an additional method or methods which performed the Date conversions, would there be dancing in the streets? Or is anyone motivated to contribute a patch to do this? I should point out that creation date and last modified are two different beasts with regard to formatting. The last modified date is an http time-stamp, but creation date is an ISO 8601 date format, and includes a time zone designator. RFC 2518 mandates precisely which format to use. With regard to other dates, servers can send back very different sorts of date formats; Xythos, as I recall (apologies if I am mistaken) can be configured on a per-user basis to send back many different date formats. I believe, therefore, that leaving the information the server actually sent available to the user of the API is in that user's best interest. But having convenience methods that attempt to parse that information (and work in a significant number of known cases) sounds very worthwhile to me, too. js -- Jacob Smullyan | smu...@sm... http://www.smullyan.org/smulloni/ |
From: Alexander D. <ale...@di...> - 2002-01-23 11:24:03
|
David Scheck wrote: > Does anyone have the proper way to change DAVFile's getLastModified, > getCreationDate from GMT to EST or PST? I think the time zone those methods use will not change, because "All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception." But you could try java.text.SimpleDateFormat for parsing and formatting the date strings. Receiving Date objects from DAVFile would be a bit more solid, IMHO. Regards, Alexander Dietrich -- ( Alexander Dietrich <ale...@di...> ) |
From: David S. <ds...@ap...> - 2002-01-23 01:20:49
|
Does anyone have the proper way to change DAVFile's getLastModified, getCreationDate from GMT to EST or PST? Is there a global somewhere that will just know my desired timezone? thanks, -dave |
From: Jacob S. <smu...@sm...> - 2002-01-18 19:41:16
|
The font warnings will happen on Linux with the Sun VMs; to fix it you have to install fonts or fiddle with the font.properties file; I'm sure you can get the details by searching google with something like "font.properties Java Linux" if you are interested, but personally I just tolerate the irritating message. Your problem is unrelated to the font issue, I believe, and since I can't reproduce the problem I'm not sure how to help you. Trying another VM is a possibility; I like IBM's better than Sun's. What I can do is send you a test program which just displays a textarea for you to type into. If you experience the same problem with the test program, we can be sure that either SkunkDAV is not at fault and Java is, or that I don't know how to write a test program. I'll send it to you in a minute. js On Fri, Jan 18, 2002 at 09:03:35PM -0100, Marc-Olivier Bernard wrote: > > I did : java -version > java version "1.3.0_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_02) > Java HotSpot(TM) Client VM (build 1.3.0_02, mixed mode) > > By launching java -jar skunkdav-1.0.2.4.jar , i also have > > Font specified in font.properties not found > [--symbol-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific] > Font specified in font.properties not found > [--symbol-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific] > ... > > Sorry but i'm not java savvy ! > > MO > > On Fri, 18 Jan 2002, Jacob Smullyan wrote: > > > I use RedHat 7.1, and have tried several JVMs: Sun 1.3.1, Sun 1.4 > > beta, IBM 1.3. I have not run into this problem. I have also tried > > switching keyboard settings, which has not given rise to any > > difficulty. > > > > I wonder what might be the issue. What JVM are you using? > > > > js > > > > > > On Fri, Jan 18, 2002 at 12:55:12PM -0100, Marc-Olivier Bernard wrote: > > > > > > Hi, > > > > > > I tried out skunkdav on linux redhat 7.2, with apache+mod_dav. It works > > > pretty well. The only problem within your entire application, is that I > > > can't use some keys of my keyboard (for ex. <,>,@,digits). > > > > > > Maybe some java incompatibity ? > > > > > > Best Regards, > > > > > > -- > > > Marc-Olivier BERNARD > > > Mel mo...@pm... > > > > > > -- > Marc-Olivier BERNARD > Mel mo...@pm... > > > _______________________________________________ > Skunkdav-dev mailing list > Sku...@li... > https://lists.sourceforge.net/lists/listinfo/skunkdav-dev -- Jacob Smullyan | smu...@sm... http://www.smullyan.org/smulloni/ |
From: Marc-Olivier B. <Mar...@po...> - 2002-01-18 19:30:50
|
I did : java -version java version "1.3.0_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_02) Java HotSpot(TM) Client VM (build 1.3.0_02, mixed mode) By launching java -jar skunkdav-1.0.2.4.jar , i also have Font specified in font.properties not found [--symbol-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific] Font specified in font.properties not found [--symbol-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific] ... Sorry but i'm not java savvy ! MO On Fri, 18 Jan 2002, Jacob Smullyan wrote: > I use RedHat 7.1, and have tried several JVMs: Sun 1.3.1, Sun 1.4 > beta, IBM 1.3. I have not run into this problem. I have also tried > switching keyboard settings, which has not given rise to any > difficulty. > > I wonder what might be the issue. What JVM are you using? > > js > > > On Fri, Jan 18, 2002 at 12:55:12PM -0100, Marc-Olivier Bernard wrote: > > > > Hi, > > > > I tried out skunkdav on linux redhat 7.2, with apache+mod_dav. It works > > pretty well. The only problem within your entire application, is that I > > can't use some keys of my keyboard (for ex. <,>,@,digits). > > > > Maybe some java incompatibity ? > > > > Best Regards, > > > > -- > > Marc-Olivier BERNARD > > Mel mo...@pm... > > -- Marc-Olivier BERNARD Mel mo...@pm... |
From: Jacob S. <smu...@sm...> - 2002-01-18 14:48:21
|
I use RedHat 7.1, and have tried several JVMs: Sun 1.3.1, Sun 1.4 beta, IBM 1.3. I have not run into this problem. I have also tried switching keyboard settings, which has not given rise to any difficulty. I wonder what might be the issue. What JVM are you using? js On Fri, Jan 18, 2002 at 12:55:12PM -0100, Marc-Olivier Bernard wrote: > > Hi, > > I tried out skunkdav on linux redhat 7.2, with apache+mod_dav. It works > pretty well. The only problem within your entire application, is that I > can't use some keys of my keyboard (for ex. <,>,@,digits). > > Maybe some java incompatibity ? > > Best Regards, > > -- > Marc-Olivier BERNARD > Mel mo...@pm... -- Jacob Smullyan | smu...@sm... http://www.smullyan.org/smulloni/ |
From: Jacob S. <smu...@sm...> - 2002-01-17 20:34:18
|
If you know for a fact that you won't be needing any other DAV functionality, you can do what you need in standard Java pretty easily, I believe. You'll need an SSL implementation (unless you are using 1.4, which ships with JSSE), but don't need a DAV library. If I were you, I'd go that route simply because you'd eliminate a significant dependency, replacing 20,000 lines of code with 20. I haven't test this, but something along these lines should work too, if JSSE is present: URL u = new URL("https://www.what-have-you.com/"); HttpURLConnection conn=(HttpURLConnection) u.openConnection(); conn.setRequestMethod("PUT"); conn.setDoOutput(true); OutputStream out=conn.getOutputStream(); // write to the stream, fiush, check the response, etc. You'd need to add request headers for authentication manually, as you are doing anyway, and set the content length. Not that you aren't very welcome to use SkunkDAV, Slide and generally get into the wonderful world of WebDAV! But if you use standard Java you'd have one less thing to worry about. Just a thought. js On Thu, Jan 17, 2002 at 09:14:08PM +0100, Julien Dubois wrote: > Yes, I'm just using PUTs. I'm not using any of your GUI, in fact. > Well, once again Slide is ok for a couple of days, but my clients want > SSL support, so I don't have much of a choice. > > Have a nice evening , and thanks again. > > Julien. > > Jacob Smullyan wrote: > > >On Thu, Jan 17, 2002 at 08:57:20PM +0100, Julien Dubois wrote: > > > >>Thanks everybody for the support. > >> > >>Just to keep you informed : I've got my code running with jakarta-slide > >>now - it's basically the same code as the one I use for skunk, so I'm > >>sure I've got a trouble with skunk somewhere. Server-side, I have the > >>same results (slide working and skunk not woriking), whether I use Slide > >>or Zope. > >>Don't misunderstood me : I still want to use skunk, because you have SSL > >>support. I know quite well the SSL support in Slide, and I know they > >>have still some work to do. And your support is superior :-) > >>I can send you my code if you're interested.. > >> > > > >Thanks. Slide is a good API, but they've been very ambitious and as a > >result the last time I looked there were many holes. Small tools have > >a lot to recommend them. > > > >Are you just doing PUTs? If so, you probably don't need any DAV library at all.... > > > >js > > > >>Julien Dubois. > >> > >>Jacob Smullyan wrote: > >> > >>>Thanks to Dave for pitching in with help here! > >>> > >>>TO disable the cookie dialog, set the cookie handler to null. I > >>>believe that DAVConnection has code to do this, commented out, but > >>>left in as an example. Not that this is an HTTPClient issue, and > >>>reading the HTTPClient docs (www.innovation.ch) may be helpful. > >>> > >>>As you figured out, "cd"-ing is not part of WebDAV; there is no such > >>>thing as a "current working directory" in WebDAV, although client > >>>programs may create the illusion that there is. > >>> > >>>I'll get back to you about the third issue; I have some business to > >>>do, and then I'll return to the thread. > >>> > >>>js > >>> > >>>On Thu, Jan 17, 2002 at 07:18:13PM +0100, Julien Dubois wrote: > >>> > >>>>Hi everybody, > >>>> > >>>>Many thanks for the quick answers I got yesterday. I did some > >>>>improvements, but I'm still stuck on some parts and my time is running > >>>>scarce.... > >>>>So basically : > >>>>- I've got a working (tested with the Windows network neighbourooh and > >>>>the jakarta-slide client) Tomcat server, with a jakarta-slide web > >>>>application. > >>>>- I want to upload a file to http://127.0.0.1:8081/users/julien, with > >>>>user=julien and password=julien. Basic authentication is ok. > >>>>- I created my own DAVAuthenticator as an inner class of my code, so > >>>>that I am not bothered with authentication. This seems to work fine. > >>>> > >>>>I have now the following problems : > >>>>- I have no idea how to cd to "/users/julien". I can't find a method to > >>>>do it, and I feel stupid about it. > >>>>- I have a pop windows which ask me if i want to accept a cookie from > >>>>the server. I don't want this - my code is supposed to run server-side. > >>>>How can I disable this window? > >>>>- The servers answers me with a 409 (conflict) error. I don't have much > >>>>clue why this happens. I should have a 403 (unauthaurized) error, as I > >>>>try to upload my file in a read-only directory (see question 1 :-)) > >>>> > >>>>Here is my code : > >>>> > >>>>--------------------- Begin -------------------- > >>>> > >>>> private void skunk() throws Exception { > >>>> org.skunk.dav.client.DAVConnection davConnection = new > >>>>org.skunk.dav.client.DAVConnection("127.0.0.1", 8081, https); > >>>> org.skunk.dav.client.DAVAuthenticator auth = new > >>>>Dav.InnerDAVAuthenticator(user, password); > >>>> davConnection.setAuthenticator(auth); > >>>> > >>>> File file = new File(filename); > >>>> byte[] filebody = null; > >>>> try { > >>>> java.io.FileInputStream fizz=new java.io.FileInputStream(file); > >>>> int initialSize=(int) Math.min((long) file.length(), > >>>>Integer.MAX_VALUE); > >>>> java.io.ByteArrayOutputStream baos=new > >>>>java.io.ByteArrayOutputStream(initialSize); > >>>> byte[] buffer = new byte[2048]; > >>>> int bytesRead; > >>>> while ((bytesRead=fizz.read(buffer))!=-1) { > >>>> baos.write(buffer, 0, bytesRead); > >>>> } > >>>> filebody=baos.toByteArray(); > >>>> } > >>>> catch (java.io.IOException ioe) { > >>>> System.out.println("IOException : " + ioe.getMessage()); > >>>> throw new Exception(); > >>>> } > >>>> > >>>> org.skunk.dav.client.method.PutMethod method = new > >>>>org.skunk.dav.client.method.PutMethod(filename, filebody); > >>>> davConnection.execute(method); > >>>> > >>>> davConnection.closeConnection(); > >>>> } > >>>> > >>>> class InnerDAVAuthenticator extends > >>>>org.skunk.dav.client.DAVAuthenticator { > >>>> > >>>> private String davuser = ""; > >>>> private String davpassword = ""; > >>>> > >>>> InnerDAVAuthenticator(String davuser, String davpassword) { > >>>> this.davuser = davuser; > >>>> this.davpassword = davpassword; > >>>> } > >>>> > >>>> public void reset() { > >>>> } > >>>> > >>>> protected java.net.PasswordAuthentication > >>>>getPasswordAuthentication() { > >>>> if (davuser == null) { > >>>> davuser = ""; > >>>> } > >>>> if (davpassword == null) { > >>>> davpassword = ""; > >>>> } > >>>> return new java.net.PasswordAuthentication(davuser, > >>>>davpassword.toCharArray()); > >>>> } > >>>> } > >>>>--------------------- End ----------------------- > >>>> > >>>>Thanx for the help, > >>>> > >>>>Julien Dubois. > >>>> > >>>>_______________________________________________ > >>>>Skunkdav-dev mailing list > >>>>Sku...@li... > >>>>https://lists.sourceforge.net/lists/listinfo/skunkdav-dev > >>>> > >> > >>_______________________________________________ > >>Skunkdav-dev mailing list > >>Sku...@li... > >>https://lists.sourceforge.net/lists/listinfo/skunkdav-dev > >> > > -- Jacob Smullyan | smu...@sm... http://www.smullyan.org/smulloni/ |