DO NOT REPLY [Bug 30719] - [net] The FTPClient is unable to list files on Japanese servers

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30719





--- Additional Comments From [EMAIL PROTECTED]  2005-04-16 04:46 ---
Aargh.  My last post was garbled too.  Here is what I meant to say:

But the date formats are now handled a different way as I indicated in my
previous post.  So WONTFIX is NOT the appropriate designation here.  There is
now a solution to the date formatting problem in the new FTPClientConfig system
with its Date Format options.  Your committing of Mr. Mortenson's patch fixes
the encoding problem.  And the FTPClientConfig date parsing fixes the date
problem.  Since both pieces of this are now fixed, I have changed the status
accordingly, to FIXED.





-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 30719] - [net] The FTPClient is unable to list files on Japanese servers

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30719


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 30719] - [net] The FTPClient is unable to list files on Japanese servers

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30719


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |




--- Additional Comments From [EMAIL PROTECTED]  2005-04-16 04:40 ---
Oh, duh.  You DID say what parts of the patch you applied.  That part of my last
post should be ignored.  You've applied the encoding stuff.  That is great.  

But the date formats are now handled a different way as I indicated in my
previous post.  So WONTFIX is the appropriate designation here.  There is a
solution to the Date Format problem.  It is the new FTPClientConfig system. 
Therefore I am changing this to FIXED.  Your committing of Mr. Mortenson's patch
fixes the encoding problem.  And the FTPClientConfig date parsing fixes the date
problem.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 30719] - [net] The FTPClient is unable to list files on Japanese servers

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30719





--- Additional Comments From [EMAIL PROTECTED]  2005-04-16 04:35 ---
Which parts have already been applied and which parts have you decide not to
apply, Rory?  

The business about numeric date formats can handled by the new FTPClientConfig
system.  I don't think we should be entertaining any more patches dealing with
Regexes to handle date formats.  The new approach, using FTPClientConfigs uses
SimpleDateFormats to handle the dates.

The stuff with encodings is another matter.  There may be merit to it but I
haven't had time to look at it yet, either.  

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [net] FTP client date parsing: new format

[Steve Cohen]

No, that's not it at all.  Remember that the new system does not use 
Regexes for date parsing, it uses SimpleDateFormats.  From Mr. Praks' 
descriptions, I am assuming he's now running the 1.3 or earlier 
versions, which do use regexes.

This surprises me because I've had several conversations with him over 
the past month in which the new system was discussed.  Perhaps he forgot 
to specify the date format as "/MM/dd" in his FTPClientConfig this 
time?  Or perhaps his code is finding an older commons-net.jar than he 
was expecting?

Steve Cohen

Rory Winston wrote:
Right, the problem with this format is that the date is not composed of three 
discrete components (from a regex POV), but two. Basically what we will need to 
do is expand the regex to handle thuis - can you give me details of the FTP 
server operating system and FTP server software version if you have it please.
Cheers
Rory
"Jakarta Commons Developers List"  wrote:

--ms000205030904010307020307
Content-Type: text/plain; charset=windows-1257; format=flowed
Content-Transfer-Encoding: 7bit
Ok, now I've found out what is the issue: the regexp pattern used by 
UnixFTPEntryParser assumes too much about the format of the date. In 
particular, it assumes that there are spaces inside the date or 
something like that. As I'm not much of a regexp expert, I cannot really 
pinpoint the problem with the pattern. But I can demonstrate the results 
from applying this pattern below.

This is the usual case that is parsed OK.
*entry*: -rw-r--r--1 1000 1000   27 Jan 24 11:31 
messages.vsp
parsed into these variables:
   typeStr=-
   hardLinkCount=1
   usr=1000
   grp=1000
   filesize=27
   datestr=Jan 24 11:31
   name=messages.vsp
   endtoken=

This is the one that has issues. Lucky for me, the parser manages to 
"parse" the entries that represent symbolic links, as these entries seem 
to have enough spaces required by the regexp pattern. Although 
incorrectly, it nicely demonstrates the issue with the parser.
*entry*: lrwxrwxrwx   1 neeme neeme23 2005-03-02 18:06 macros -> 
../../../global/macros/
parsed into these variables:
   typeStr=l
   hardLinkCount=1
   usr=neeme
   grp=neeme
   filesize=23
   datestr=2005-03-02 18:06 macros
   name=->
   endtoken= ../../../global/macros/

Note that starting from datestr variable, the parsing is f**ked up...
How can we solve this issue?
Make regexp pattern also configurable? Better suggestions?
Rgds,
Neeme
Neeme Praks wrote:

I cannot give you access as it is inside our corporate firewall.
So I guess I'll try to debug it on my own. :-)
I'll let you know when I have made some progress with that.
--ms000205030904010307020307
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII5TCC
As0wggI2oAMCAQICAw2VSTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQxMjA4MjM0NjM5WhcNMDUxMjA4MjM0NjM5
WjBCMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBu
ZWVtZUBhcGFjaGUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyZu8bdSh
BOVFe3KQjdsj5+J9Ji5+1+1M3IF5JeC6LKOlcLqralU5mqO25xuqJMLcl6AY9K88RMtv9DyN
fUz6AWA8fPYUhV1zO5WPuK4k+/9VzwGMIMUt/U1iVkdE0reW+qRWa6saip3HlFCR0iZCf+4w
uMf7cO3yBMbFAvXjVNQoV/ghks39q6qS9aPPCehuqccpAds3UXS1JUPcfIuxrHtlEZacyW0O
Dxs59fzqIREXxZCR5YotiBXdOvhb9NC5l6pzoViGCLUy7H56FNfVyqWtB8nMa4zTkodxFN6l
mofpDpXhSyu3mwZWA5+qWaN0cOt8wviPNSU0KKzTK2GDewIDAQABoy0wKzAbBgNVHREEFDAS
gRBuZWVtZUBhcGFjaGUub3JnMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAAm0Q
+3NNp/N3X4hNDiBfjehE68roH96Rr/+N4uabBDQb1r5Cd00IRZ3DpzCdGrFq441hJT5faOZ2
RcqWk399YfTXecWEVpHfY7lcFwzCOiSyhTLjkZza8jxLsrzpleXbwWXfOlHGivPxMmSbcCpT
0oNCXMD5adUOcew7Wr1HMaYwggLNMIICNqADAgECAgMNlUkwDQYJKoZIhvcNAQEEBQAwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MTIwODIz
NDYzOVoXDTA1MTIwODIzNDYzOVowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJl
cjEfMB0GCSqGSIb3DQEJARYQbmVlbWVAYXBhY2hlLm9yZzCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMmbvG3UoQTlRXtykI3bI+fifSYuftftTNyBeSXguiyjpXC6q2pVOZqj
tucbqiTC3JegGPSvPETLb/Q8jX1M+gFgPHz2FIVdczuVj7iuJPv/Vc8BjCDFLf1NYlZHRNK3
lvqkVmurGoqdx5RQkdImQn/uMLjH+3Dt8gTGxQL141TUKFf4IZLN/auqkvWjzwnobqnHKQHb
N1F0tSVD3HyLsax7ZRGWnMltDg8bOfX86iERF8WQkeWKLYgV3Tr4W/TQuZeqc6FYhgi1Mux+
ehTX1cqlrQfJzGuM05KHcRTepZqH6Q6V4Usrt5sGVgOfqlmjdHDrfML4jzUlNCis0ythg3sC
AwEAAaMtMCswGwYDVR0RBBQwEoEQbmVlbWVAYXBhY2hlLm9yZzAMBgNVHRMBAf8EAjAAMA0G
CSqGSIb3DQEBBAUAA4GBAAJtEPtzTafzd1+ITQ4gX43oROvK6B/eka//jeLmmwQ0G9a+QndN
CEWdw6cwnRqxauONYSU+X2jmdkXKlpN/fWH013nFhFaR32O5XBcMwjoksoUy45Gc2vI8S7K8
6ZXl28Fl3zpRxorz8TJkm3AqU9KDQlzA+WnVDnHsO1q9RzGmMIIDPzCCAqigAwIBAgIBDTAN
BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgN

[sql] test patch, tag request

[jakarta . t . wuuza]

I submitted patches before and I guess I left out this piece for the test 
class.  It just tests that default values are read correctly from the xml.  
Also, it defaults the base dir, which made testing in Eclipse easier, I think 
(I did this a while back).

Also, could someone tag the SQL module with just a daily tag, like 
1.0-dev-20050415 or whatever?  Now that my patches are accepted, my codebase is 
the same as CVS and a tag would be nice.

Thanks
John

(I'm not subscribed to the list so please CC me.)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 30719] - [net] The FTPClient is unable to list files on Japanese servers

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30719


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r161507 - jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java

[rwinston]

Author: rwinston
Date: Fri Apr 15 09:54:27 2005
New Revision: 161507

URL: http://svn.apache.org/viewcvs?view=rev&rev=161507
Log:
Add @version tag

Modified:

jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java

Modified: 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java?view=diff&r1=161506&r2=161507
==
--- 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java
 (original)
+++ 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java
 Fri Apr 15 09:54:27 2005
@@ -16,7 +16,7 @@
  * 
  * The original system presenting this issue was an AIX system - see bug 
#27437 for details.
  * 
- *  $Id$
+ *  @version $Id$
  */
 public class FTPConfigEntryParserTest extends TestCase {




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [net] FTP client date parsing: new format

[Rory Winston]

Neeme,

There is a preliminary (subject to review) fix in SVN for this problem.

For an example of how to parse this, look at:

http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java?rev=161506&view=markup

Cheers
Rory

"Jakarta Commons Developers List"  wrote:

> 
> --ms000205030904010307020307
> Content-Type: text/plain; charset=windows-1257; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> 
> Ok, now I've found out what is the issue: the regexp pattern used by 
> UnixFTPEntryParser assumes too much about the format of the date. In 
> particular, it assumes that there are spaces inside the date or 
> something like that. As I'm not much of a regexp expert, I cannot really 
> pinpoint the problem with the pattern. But I can demonstrate the results 
> from applying this pattern below.
> 
> This is the usual case that is parsed OK.
> *entry*: -rw-r--r--1 1000 1000   27 Jan 24 11:31 
> messages.vsp
> parsed into these variables:
> typeStr=-
> hardLinkCount=1
> usr=1000
> grp=1000
> filesize=27
> datestr=Jan 24 11:31
> name=messages.vsp
> endtoken=
> 
> This is the one that has issues. Lucky for me, the parser manages to 
> "parse" the entries that represent symbolic links, as these entries seem 
> to have enough spaces required by the regexp pattern. Although 
> incorrectly, it nicely demonstrates the issue with the parser.
> *entry*: lrwxrwxrwx   1 neeme neeme23 2005-03-02 18:06 macros -> 
> ../../../global/macros/
> parsed into these variables:
> typeStr=l
> hardLinkCount=1
> usr=neeme
> grp=neeme
> filesize=23
> datestr=2005-03-02 18:06 macros
> name=->
> endtoken= ../../../global/macros/
> 
> Note that starting from datestr variable, the parsing is f**ked up...
> 
> How can we solve this issue?
> Make regexp pattern also configurable? Better suggestions?
> 
> Rgds,
> Neeme
> 
> Neeme Praks wrote:
> 
> > I cannot give you access as it is inside our corporate firewall.
> > So I guess I'll try to debug it on my own. :-)
> >
> > I'll let you know when I have made some progress with that.
> >
> 
> --ms000205030904010307020307
> Content-Type: application/x-pkcs7-signature; name="smime.p7s"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="smime.p7s"
> Content-Description: S/MIME Cryptographic Signature
> 
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII5TCC
> As0wggI2oAMCAQICAw2VSTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
> ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
> bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQxMjA4MjM0NjM5WhcNMDUxMjA4MjM0NjM5
> WjBCMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBu
> ZWVtZUBhcGFjaGUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyZu8bdSh
> BOVFe3KQjdsj5+J9Ji5+1+1M3IF5JeC6LKOlcLqralU5mqO25xuqJMLcl6AY9K88RMtv9DyN
> fUz6AWA8fPYUhV1zO5WPuK4k+/9VzwGMIMUt/U1iVkdE0reW+qRWa6saip3HlFCR0iZCf+4w
> uMf7cO3yBMbFAvXjVNQoV/ghks39q6qS9aPPCehuqccpAds3UXS1JUPcfIuxrHtlEZacyW0O
> Dxs59fzqIREXxZCR5YotiBXdOvhb9NC5l6pzoViGCLUy7H56FNfVyqWtB8nMa4zTkodxFN6l
> mofpDpXhSyu3mwZWA5+qWaN0cOt8wviPNSU0KKzTK2GDewIDAQABoy0wKzAbBgNVHREEFDAS
> gRBuZWVtZUBhcGFjaGUub3JnMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAAm0Q
> +3NNp/N3X4hNDiBfjehE68roH96Rr/+N4uabBDQb1r5Cd00IRZ3DpzCdGrFq441hJT5faOZ2
> RcqWk399YfTXecWEVpHfY7lcFwzCOiSyhTLjkZza8jxLsrzpleXbwWXfOlHGivPxMmSbcCpT
> 0oNCXMD5adUOcew7Wr1HMaYwggLNMIICNqADAgECAgMNlUkwDQYJKoZIhvcNAQEEBQAwYjEL
> MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
> BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MTIwODIz
> NDYzOVoXDTA1MTIwODIzNDYzOVowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJl
> cjEfMB0GCSqGSIb3DQEJARYQbmVlbWVAYXBhY2hlLm9yZzCCASIwDQYJKoZIhvcNAQEBBQAD
> ggEPADCCAQoCggEBAMmbvG3UoQTlRXtykI3bI+fifSYuftftTNyBeSXguiyjpXC6q2pVOZqj
> tucbqiTC3JegGPSvPETLb/Q8jX1M+gFgPHz2FIVdczuVj7iuJPv/Vc8BjCDFLf1NYlZHRNK3
> lvqkVmurGoqdx5RQkdImQn/uMLjH+3Dt8gTGxQL141TUKFf4IZLN/auqkvWjzwnobqnHKQHb
> N1F0tSVD3HyLsax7ZRGWnMltDg8bOfX86iERF8WQkeWKLYgV3Tr4W/TQuZeqc6FYhgi1Mux+
> ehTX1cqlrQfJzGuM05KHcRTepZqH6Q6V4Usrt5sGVgOfqlmjdHDrfML4jzUlNCis0ythg3sC
> AwEAAaMtMCswGwYDVR0RBBQwEoEQbmVlbWVAYXBhY2hlLm9yZzAMBgNVHRMBAf8EAjAAMA0G
> CSqGSIb3DQEBBAUAA4GBAAJtEPtzTafzd1+ITQ4gX43oROvK6B/eka//jeLmmwQ0G9a+QndN
> CEWdw6cwnRqxauONYSU+X2jmdkXKlpN/fWH013nFhFaR32O5XBcMwjoksoUy45Gc2vI8S7K8
> 6ZXl28Fl3zpRxorz8TJkm3AqU9KDQlzA+WnVDnHsO1q9RzGmMIIDPzCCAqigAwIBAgIBDTAN
> BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES
> MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE
> CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl
> cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0
> aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC
> WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0Z

Re: [net] FTP client date parsing: new format

[Rory Winston]

Neeme,

There is a preliminary (subject to review) fix in SVN for this problem.

For an example of how to parse this, look at:

http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java?rev=161506&view=markup

Cheers
Rory

"Jakarta Commons Developers List"  wrote:

> 
> --ms000205030904010307020307
> Content-Type: text/plain; charset=windows-1257; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> 
> Ok, now I've found out what is the issue: the regexp pattern used by 
> UnixFTPEntryParser assumes too much about the format of the date. In 
> particular, it assumes that there are spaces inside the date or 
> something like that. As I'm not much of a regexp expert, I cannot really 
> pinpoint the problem with the pattern. But I can demonstrate the results 
> from applying this pattern below.
> 
> This is the usual case that is parsed OK.
> *entry*: -rw-r--r--1 1000 1000   27 Jan 24 11:31 
> messages.vsp
> parsed into these variables:
> typeStr=-
> hardLinkCount=1
> usr=1000
> grp=1000
> filesize=27
> datestr=Jan 24 11:31
> name=messages.vsp
> endtoken=
> 
> This is the one that has issues. Lucky for me, the parser manages to 
> "parse" the entries that represent symbolic links, as these entries seem 
> to have enough spaces required by the regexp pattern. Although 
> incorrectly, it nicely demonstrates the issue with the parser.
> *entry*: lrwxrwxrwx   1 neeme neeme23 2005-03-02 18:06 macros -> 
> ../../../global/macros/
> parsed into these variables:
> typeStr=l
> hardLinkCount=1
> usr=neeme
> grp=neeme
> filesize=23
> datestr=2005-03-02 18:06 macros
> name=->
> endtoken= ../../../global/macros/
> 
> Note that starting from datestr variable, the parsing is f**ked up...
> 
> How can we solve this issue?
> Make regexp pattern also configurable? Better suggestions?
> 
> Rgds,
> Neeme
> 
> Neeme Praks wrote:
> 
> > I cannot give you access as it is inside our corporate firewall.
> > So I guess I'll try to debug it on my own. :-)
> >
> > I'll let you know when I have made some progress with that.
> >
> 
> --ms000205030904010307020307
> Content-Type: application/x-pkcs7-signature; name="smime.p7s"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="smime.p7s"
> Content-Description: S/MIME Cryptographic Signature
> 
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII5TCC
> As0wggI2oAMCAQICAw2VSTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
> ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
> bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQxMjA4MjM0NjM5WhcNMDUxMjA4MjM0NjM5
> WjBCMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBu
> ZWVtZUBhcGFjaGUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyZu8bdSh
> BOVFe3KQjdsj5+J9Ji5+1+1M3IF5JeC6LKOlcLqralU5mqO25xuqJMLcl6AY9K88RMtv9DyN
> fUz6AWA8fPYUhV1zO5WPuK4k+/9VzwGMIMUt/U1iVkdE0reW+qRWa6saip3HlFCR0iZCf+4w
> uMf7cO3yBMbFAvXjVNQoV/ghks39q6qS9aPPCehuqccpAds3UXS1JUPcfIuxrHtlEZacyW0O
> Dxs59fzqIREXxZCR5YotiBXdOvhb9NC5l6pzoViGCLUy7H56FNfVyqWtB8nMa4zTkodxFN6l
> mofpDpXhSyu3mwZWA5+qWaN0cOt8wviPNSU0KKzTK2GDewIDAQABoy0wKzAbBgNVHREEFDAS
> gRBuZWVtZUBhcGFjaGUub3JnMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAAm0Q
> +3NNp/N3X4hNDiBfjehE68roH96Rr/+N4uabBDQb1r5Cd00IRZ3DpzCdGrFq441hJT5faOZ2
> RcqWk399YfTXecWEVpHfY7lcFwzCOiSyhTLjkZza8jxLsrzpleXbwWXfOlHGivPxMmSbcCpT
> 0oNCXMD5adUOcew7Wr1HMaYwggLNMIICNqADAgECAgMNlUkwDQYJKoZIhvcNAQEEBQAwYjEL
> MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
> BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MTIwODIz
> NDYzOVoXDTA1MTIwODIzNDYzOVowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJl
> cjEfMB0GCSqGSIb3DQEJARYQbmVlbWVAYXBhY2hlLm9yZzCCASIwDQYJKoZIhvcNAQEBBQAD
> ggEPADCCAQoCggEBAMmbvG3UoQTlRXtykI3bI+fifSYuftftTNyBeSXguiyjpXC6q2pVOZqj
> tucbqiTC3JegGPSvPETLb/Q8jX1M+gFgPHz2FIVdczuVj7iuJPv/Vc8BjCDFLf1NYlZHRNK3
> lvqkVmurGoqdx5RQkdImQn/uMLjH+3Dt8gTGxQL141TUKFf4IZLN/auqkvWjzwnobqnHKQHb
> N1F0tSVD3HyLsax7ZRGWnMltDg8bOfX86iERF8WQkeWKLYgV3Tr4W/TQuZeqc6FYhgi1Mux+
> ehTX1cqlrQfJzGuM05KHcRTepZqH6Q6V4Usrt5sGVgOfqlmjdHDrfML4jzUlNCis0ythg3sC
> AwEAAaMtMCswGwYDVR0RBBQwEoEQbmVlbWVAYXBhY2hlLm9yZzAMBgNVHRMBAf8EAjAAMA0G
> CSqGSIb3DQEBBAUAA4GBAAJtEPtzTafzd1+ITQ4gX43oROvK6B/eka//jeLmmwQ0G9a+QndN
> CEWdw6cwnRqxauONYSU+X2jmdkXKlpN/fWH013nFhFaR32O5XBcMwjoksoUy45Gc2vI8S7K8
> 6ZXl28Fl3zpRxorz8TJkm3AqU9KDQlzA+WnVDnHsO1q9RzGmMIIDPzCCAqigAwIBAgIBDTAN
> BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES
> MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE
> CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl
> cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0
> aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC
> WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0Z

svn commit: r161506 - jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java

[rwinston]

Author: rwinston
Date: Fri Apr 15 09:50:48 2005
New Revision: 161506

URL: http://svn.apache.org/viewcvs?view=rev&rev=161506
Log:
Added to repository

Added:

jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java

Added: 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java?view=auto&rev=161506
==
--- 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java
 (added)
+++ 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java
 Fri Apr 15 09:50:48 2005
@@ -0,0 +1,148 @@
+package org.apache.commons.net.ftp.parser;
+
+import java.text.SimpleDateFormat;
+import java.util.Calendar;
+import java.util.Date;
+
+import junit.framework.TestCase;
+
+import org.apache.commons.net.ftp.FTPClientConfig;
+import org.apache.commons.net.ftp.FTPFile;
+
+/**
+ * This is a simple TestCase that tests entry parsing using the new 
FTPClientConfig
+ * mechanism. The normal FTPClient cannot handle the different date format in 
these 
+ * entries, however using a configurable format, we can handle it easily.
+ * 
+ * The original system presenting this issue was an AIX system - see bug 
#27437 for details.
+ * 
+ *  $Id$
+ */
+public class FTPConfigEntryParserTest extends TestCase {
+   
+   private SimpleDateFormat df = new SimpleDateFormat();
+
+   public void testParseFieldsOnAIX() {
+   
+   // Set a date format for this server type
+   FTPClientConfig config = new 
FTPClientConfig(FTPClientConfig.SYST_UNIX);
+   config.setDefaultDateFormatStr("dd MMM HH:mm");
+
+   UnixFTPEntryParser parser = new UnixFTPEntryParser();
+   parser.configure(config);
+
+   FTPFile f = parser.parseFTPEntry("-rw-r-   1 ravensm  sca   
   814 02 Mar 16:27 ZMIR2.m");
+
+   assertNotNull("Could not parse entry.", f);
+   assertFalse("Is not a directory.", f.isDirectory());
+
+   assertTrue("Should have user read permission.", f.hasPermission(
+   FTPFile.USER_ACCESS, FTPFile.READ_PERMISSION));
+   assertTrue("Should have user write permission.", 
f.hasPermission(
+   FTPFile.USER_ACCESS, FTPFile.WRITE_PERMISSION));
+   assertFalse("Should NOT have user execute permission.", f
+   .hasPermission(FTPFile.USER_ACCESS, 
FTPFile.EXECUTE_PERMISSION));
+   assertTrue("Should have group read permission.", 
f.hasPermission(
+   FTPFile.GROUP_ACCESS, FTPFile.READ_PERMISSION));
+   assertFalse("Should NOT have group write permission.", f
+   .hasPermission(FTPFile.GROUP_ACCESS, 
FTPFile.WRITE_PERMISSION));
+   assertFalse("Should NOT have group execute permission.",
+   f.hasPermission(FTPFile.GROUP_ACCESS,
+   FTPFile.EXECUTE_PERMISSION));
+   assertFalse("Should NOT have world read permission.", 
f.hasPermission(
+   FTPFile.WORLD_ACCESS, FTPFile.READ_PERMISSION));
+   assertFalse("Should NOT have world write permission.", f
+   .hasPermission(FTPFile.WORLD_ACCESS, 
FTPFile.WRITE_PERMISSION));
+   assertFalse("Should NOT have world execute permission.",
+   f.hasPermission(FTPFile.WORLD_ACCESS,
+   FTPFile.EXECUTE_PERMISSION));
+
+   assertEquals(1, f.getHardLinkCount());
+
+   assertEquals("ravensm", f.getUser());
+   assertEquals("sca", f.getGroup());
+
+   assertEquals("ZMIR2.m", f.getName());
+   assertEquals(814, f.getSize());
+
+   Calendar cal = Calendar.getInstance();
+   
+   Date refDate = new Date();
+   
+   cal.set(Calendar.MONTH, Calendar.MARCH);
+   cal.set(Calendar.DATE, 2);
+   cal.set(Calendar.HOUR_OF_DAY, 16);
+   cal.set(Calendar.MINUTE, 27);
+   cal.set(Calendar.SECOND, 0);
+   
+   // With no year specified, it defaults to 1970
+   // TODO this is a bug - it should default to the current year
+   cal.set(Calendar.YEAR, 1970);
+   
+   assertEquals(df.format(cal.getTime()), 
df.format(f.getTimestamp()
+   .getTime()));
+   }
+   
+   /**
+* This is a new format reported on t

svn commit: r161505 - jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/UnixFTPEntryParserTest.java

[rwinston]

Author: rwinston
Date: Fri Apr 15 09:48:34 2005
New Revision: 161505

URL: http://svn.apache.org/viewcvs?view=rev&rev=161505
Log:
Rename

Modified:

jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/UnixFTPEntryParserTest.java

Modified: 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/UnixFTPEntryParserTest.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/UnixFTPEntryParserTest.java?view=diff&r1=161504&r2=161505
==
--- 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/UnixFTPEntryParserTest.java
 (original)
+++ 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/UnixFTPEntryParserTest.java
 Fri Apr 15 09:48:34 2005
@@ -26,209 +26,176 @@
  * @author mailto:[EMAIL PROTECTED]">Steve Cohen
  * @version $Id$
  */
-public class UnixFTPEntryParserTest extends FTPParseTestFramework
-{
+public class UnixFTPEntryParserTest extends FTPParseTestFramework {
 
-private static final String[] badsamples =
-{
-"zrwxr-xr-x   2 root root 4096 Mar  2 15:13 zxbox",
-"dxrwr-xr-x   2 root root 4096 Aug 24  2001 zxjdbc",
-"drwxr-xr-x   2 root root 4096 Jam  4 00:03 zziplib",
-"drwxr-xr-x   2 root 99   4096 Feb 23 30:01 zzplayer",
-"drwxr-xr-x   2 root root 4096 Aug 36  2001 zztpp",
-"-rw-r--r--   1 14   staff   80284 Aug 22  
zxJDBC-1.2.3.tar.gz",
-"-rw-r--r--   1 14   staff  119:26 Aug 22  2000 
zxJDBC-1.2.3.zip",
-"-rw-r--r--   1 ftp  no group83853 Jan 22  2001 
zxJDBC-1.2.4.tar.gz",
-"-rw-r--r--   1ftp   nogroup126552 Jan 22  2001 
zxJDBC-1.2.4.zip",
-"-rw-r--r--   1 root root   111325 Apr -7 18:79 
zxJDBC-2.0.1b1.tar.gz"
-};
-
-private static final String[] goodsamples =
-{
-
-"-rw-r--r--   1 500  50021 Aug  8 14:14 JB3-TES1.gz",
-"-rwxr-xr-x   2 root root 4096 Mar  2 15:13 zxbox",
-"drwxr-xr-x   2 root root 4096 Aug 24  2001 zxjdbc",
-"drwxr-xr-x   2 root root 4096 Jan  4 00:03 zziplib",
-"drwxr-xr-x   2 root 99   4096 Feb 23  2001 zzplayer",
-"drwxr-xr-x   2 root root 4096 Aug  6  2001 zztpp",
-"drwxr-xr-x 1 usernameftp 512 Jan 29 23:32 prog",
-"lrw-r--r--   1 14   14  80284 Aug 22  2000 
zxJDBC-1.2.3.tar.gz",
-"frw-r--r--   1 14   staff  119926 Aug 22  2000 
zxJDBC-1.2.3.zip",
-"crw-r--r--   1 ftp  nogroup 83853 Jan 22  2001 
zxJDBC-1.2.4.tar.gz",
-"brw-r--r--   1 ftp  nogroup126552 Jan 22  2001 
zxJDBC-1.2.4.zip",
-"-rw-r--r--   1 root root   111325 Apr 27  2001 
zxJDBC-2.0.1b1.tar.gz",
-"-rw-r--r--   1 root root   190144 Apr 27  2001 
zxJDBC-2.0.1b1.zip",
-"-rwxr-xr-x   2 500  500   166 Nov  2  2001 
73131-testtes1.afp",
-"-rw-r--r--   1 500  500   166 Nov  9  2001 
73131-testtes1.AFP",
-"-rw-r--r--   1 500  500   166 Nov 12  2001 
73131-testtes2.afp",
-"-rw-r--r--   1 500  500   166 Nov 12  2001 
73131-testtes2.AFP",
-"-rw-r--r--   1 500  500   204 Aug  5 07:35 
testRemoteUPCopyNIX",
-"-rw-r--r--   1 500  500   204 Aug  5 07:31 
testRemoteUPDCopyNIX",
-"-rw-r--r--   1 500  500   204 Aug  5 07:31 
testRemoteUPVCopyNIX",
-"-rw-r--r-T   1 500  500 0 Mar 25 08:20 testSticky",
-"-rwxr-xr-t   1 500  500 0 Mar 25 08:21 
testStickyExec",
-"-rwSr-Sr--   1 500  500 0 Mar 25 08:22 testSuid",
-   "-rwsr-sr--   1 500  500 0 Mar 25 08:23 
testSuidExec",
-   "-rwsr-sr--   1 500  500 0 Mar 25 0:23 
testSuidExec2",
-"drwxrwx---+ 23 500 5000 Jan 10 13:09 testACL",
-
-   "-rw-r--r--   1 13518644 May 25 12:12 std"
-};
-
-/**
- * @see junit.framework.TestCase#TestCase(String)
- */
-public UnixFTPEntryParserTest(String name)
-{
-super(name);
-}
-
-/**
- * @see 
org.apache.commons.net.ftp.parser.FTPParseTestFramework#getBadListing()
- */
-protected String[] getBadListing()
-{
-return(badsamples);
-}
-
-/**
- * @see 
org.apache.commons.net.ftp.parser.FTPParseTestFramework#getGoodListing()
- */
-protected String[] getGoodListing()
-{
-return(goodsamples);
-}
-
-/**
- * @see org.apache.commons.net.ftp.parser.FTPParseTestFramework#getParser()
- */
-protected FTPFileEntryParser getParser()
-{
-return(new UnixFTPEntryParser());
-}
-
-/**
-

svn commit: r161502 - jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java

[rwinston]

Author: rwinston
Date: Fri Apr 15 09:46:29 2005
New Revision: 161502

URL: http://svn.apache.org/viewcvs?view=rev&rev=161502
Log:
Changed REGEX variable to accomodate date dtrings with only two components. 
There may be a better way to do this, however this seems to support both types. 
Existing unit tests pass.

Modified:

jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java

Modified: 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java?view=diff&r1=161501&r2=161502
==
--- 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java
 (original)
+++ 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java
 Fri Apr 15 09:46:29 2005
@@ -70,7 +70,7 @@
 + "(\\S+)\\s+"
 + "(?:(\\S+)\\s+)?"
 + "(\\d+)\\s+"
-   + "(\\S+)\\s+(\\S+)\\s+(\\S+)\\s+" /*the three parts of the 
date in any order*/
+   + "(\\S+)\\s+(\\S+)\\s+((\\S+)(?:\\s+))?" /*the three parts of 
the date in any order*/
 + "(\\S+)(\\s*.*)";
 
 
@@ -129,9 +129,10 @@
 String usr = group(16);
 String grp = group(17);
 String filesize = group(18);
-String datestr = group(19) + " " + group(20) + " " + group(21);
-String name = group(22);
-String endtoken = group(23);
+String datestr = group(19) + " " + group(20);
+if(group(22) != null && group(22) != "") datestr += " " +  
group(22);
+String name = group(23);
+String endtoken = group(24);
 
 try
 {



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Minor bug in FileUpload

[Peter Speck]

Hi,
Line 545 in org.apache.commons.fileupload.FileUploadBase
is
header = new String(buffer, 0, i - 2);
but should be
header = new String(buffer, 0, i - 2, "ISO-8859-1");
as http headers 'uses' latin-1, and the native java platform charset  
might be something else.


   - Peter Speck
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [net] FTP client date parsing: new format

[Rory Winston]

Right, the problem with this format is that the date is not composed of three 
discrete components (from a regex POV), but two. Basically what we will need to 
do is expand the regex to handle thuis - can you give me details of the FTP 
server operating system and FTP server software version if you have it please.

Cheers
Rory

"Jakarta Commons Developers List"  wrote:

> 
> --ms000205030904010307020307
> Content-Type: text/plain; charset=windows-1257; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> 
> Ok, now I've found out what is the issue: the regexp pattern used by 
> UnixFTPEntryParser assumes too much about the format of the date. In 
> particular, it assumes that there are spaces inside the date or 
> something like that. As I'm not much of a regexp expert, I cannot really 
> pinpoint the problem with the pattern. But I can demonstrate the results 
> from applying this pattern below.
> 
> This is the usual case that is parsed OK.
> *entry*: -rw-r--r--1 1000 1000   27 Jan 24 11:31 
> messages.vsp
> parsed into these variables:
> typeStr=-
> hardLinkCount=1
> usr=1000
> grp=1000
> filesize=27
> datestr=Jan 24 11:31
> name=messages.vsp
> endtoken=
> 
> This is the one that has issues. Lucky for me, the parser manages to 
> "parse" the entries that represent symbolic links, as these entries seem 
> to have enough spaces required by the regexp pattern. Although 
> incorrectly, it nicely demonstrates the issue with the parser.
> *entry*: lrwxrwxrwx   1 neeme neeme23 2005-03-02 18:06 macros -> 
> ../../../global/macros/
> parsed into these variables:
> typeStr=l
> hardLinkCount=1
> usr=neeme
> grp=neeme
> filesize=23
> datestr=2005-03-02 18:06 macros
> name=->
> endtoken= ../../../global/macros/
> 
> Note that starting from datestr variable, the parsing is f**ked up...
> 
> How can we solve this issue?
> Make regexp pattern also configurable? Better suggestions?
> 
> Rgds,
> Neeme
> 
> Neeme Praks wrote:
> 
> > I cannot give you access as it is inside our corporate firewall.
> > So I guess I'll try to debug it on my own. :-)
> >
> > I'll let you know when I have made some progress with that.
> >
> 
> --ms000205030904010307020307
> Content-Type: application/x-pkcs7-signature; name="smime.p7s"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="smime.p7s"
> Content-Description: S/MIME Cryptographic Signature
> 
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII5TCC
> As0wggI2oAMCAQICAw2VSTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
> ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
> bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQxMjA4MjM0NjM5WhcNMDUxMjA4MjM0NjM5
> WjBCMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBu
> ZWVtZUBhcGFjaGUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyZu8bdSh
> BOVFe3KQjdsj5+J9Ji5+1+1M3IF5JeC6LKOlcLqralU5mqO25xuqJMLcl6AY9K88RMtv9DyN
> fUz6AWA8fPYUhV1zO5WPuK4k+/9VzwGMIMUt/U1iVkdE0reW+qRWa6saip3HlFCR0iZCf+4w
> uMf7cO3yBMbFAvXjVNQoV/ghks39q6qS9aPPCehuqccpAds3UXS1JUPcfIuxrHtlEZacyW0O
> Dxs59fzqIREXxZCR5YotiBXdOvhb9NC5l6pzoViGCLUy7H56FNfVyqWtB8nMa4zTkodxFN6l
> mofpDpXhSyu3mwZWA5+qWaN0cOt8wviPNSU0KKzTK2GDewIDAQABoy0wKzAbBgNVHREEFDAS
> gRBuZWVtZUBhcGFjaGUub3JnMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAAm0Q
> +3NNp/N3X4hNDiBfjehE68roH96Rr/+N4uabBDQb1r5Cd00IRZ3DpzCdGrFq441hJT5faOZ2
> RcqWk399YfTXecWEVpHfY7lcFwzCOiSyhTLjkZza8jxLsrzpleXbwWXfOlHGivPxMmSbcCpT
> 0oNCXMD5adUOcew7Wr1HMaYwggLNMIICNqADAgECAgMNlUkwDQYJKoZIhvcNAQEEBQAwYjEL
> MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
> BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MTIwODIz
> NDYzOVoXDTA1MTIwODIzNDYzOVowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJl
> cjEfMB0GCSqGSIb3DQEJARYQbmVlbWVAYXBhY2hlLm9yZzCCASIwDQYJKoZIhvcNAQEBBQAD
> ggEPADCCAQoCggEBAMmbvG3UoQTlRXtykI3bI+fifSYuftftTNyBeSXguiyjpXC6q2pVOZqj
> tucbqiTC3JegGPSvPETLb/Q8jX1M+gFgPHz2FIVdczuVj7iuJPv/Vc8BjCDFLf1NYlZHRNK3
> lvqkVmurGoqdx5RQkdImQn/uMLjH+3Dt8gTGxQL141TUKFf4IZLN/auqkvWjzwnobqnHKQHb
> N1F0tSVD3HyLsax7ZRGWnMltDg8bOfX86iERF8WQkeWKLYgV3Tr4W/TQuZeqc6FYhgi1Mux+
> ehTX1cqlrQfJzGuM05KHcRTepZqH6Q6V4Usrt5sGVgOfqlmjdHDrfML4jzUlNCis0ythg3sC
> AwEAAaMtMCswGwYDVR0RBBQwEoEQbmVlbWVAYXBhY2hlLm9yZzAMBgNVHRMBAf8EAjAAMA0G
> CSqGSIb3DQEBBAUAA4GBAAJtEPtzTafzd1+ITQ4gX43oROvK6B/eka//jeLmmwQ0G9a+QndN
> CEWdw6cwnRqxauONYSU+X2jmdkXKlpN/fWH013nFhFaR32O5XBcMwjoksoUy45Gc2vI8S7K8
> 6ZXl28Fl3zpRxorz8TJkm3AqU9KDQlzA+WnVDnHsO1q9RzGmMIIDPzCCAqigAwIBAgIBDTAN
> BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES
> MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE
> CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl
> cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0
> aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC
> WkExJTAjBgNVBAoTHFRoYXd0ZSBD

Re: [net] FTP client date parsing: new format

[Rory Winston]

Right, the problem with this format is that the date is not composed of three 
discrete components (from a regex POV), but two. Basically what we will need to 
do is expand the regex to handle thuis - can you give me details of the FTP 
server operating system and FTP server software version if you have it please.

Cheers
Rory

"Jakarta Commons Developers List"  wrote:

> 
> --ms000205030904010307020307
> Content-Type: text/plain; charset=windows-1257; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> 
> Ok, now I've found out what is the issue: the regexp pattern used by 
> UnixFTPEntryParser assumes too much about the format of the date. In 
> particular, it assumes that there are spaces inside the date or 
> something like that. As I'm not much of a regexp expert, I cannot really 
> pinpoint the problem with the pattern. But I can demonstrate the results 
> from applying this pattern below.
> 
> This is the usual case that is parsed OK.
> *entry*: -rw-r--r--1 1000 1000   27 Jan 24 11:31 
> messages.vsp
> parsed into these variables:
> typeStr=-
> hardLinkCount=1
> usr=1000
> grp=1000
> filesize=27
> datestr=Jan 24 11:31
> name=messages.vsp
> endtoken=
> 
> This is the one that has issues. Lucky for me, the parser manages to 
> "parse" the entries that represent symbolic links, as these entries seem 
> to have enough spaces required by the regexp pattern. Although 
> incorrectly, it nicely demonstrates the issue with the parser.
> *entry*: lrwxrwxrwx   1 neeme neeme23 2005-03-02 18:06 macros -> 
> ../../../global/macros/
> parsed into these variables:
> typeStr=l
> hardLinkCount=1
> usr=neeme
> grp=neeme
> filesize=23
> datestr=2005-03-02 18:06 macros
> name=->
> endtoken= ../../../global/macros/
> 
> Note that starting from datestr variable, the parsing is f**ked up...
> 
> How can we solve this issue?
> Make regexp pattern also configurable? Better suggestions?
> 
> Rgds,
> Neeme
> 
> Neeme Praks wrote:
> 
> > I cannot give you access as it is inside our corporate firewall.
> > So I guess I'll try to debug it on my own. :-)
> >
> > I'll let you know when I have made some progress with that.
> >
> 
> --ms000205030904010307020307
> Content-Type: application/x-pkcs7-signature; name="smime.p7s"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="smime.p7s"
> Content-Description: S/MIME Cryptographic Signature
> 
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII5TCC
> As0wggI2oAMCAQICAw2VSTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
> ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
> bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQxMjA4MjM0NjM5WhcNMDUxMjA4MjM0NjM5
> WjBCMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBu
> ZWVtZUBhcGFjaGUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyZu8bdSh
> BOVFe3KQjdsj5+J9Ji5+1+1M3IF5JeC6LKOlcLqralU5mqO25xuqJMLcl6AY9K88RMtv9DyN
> fUz6AWA8fPYUhV1zO5WPuK4k+/9VzwGMIMUt/U1iVkdE0reW+qRWa6saip3HlFCR0iZCf+4w
> uMf7cO3yBMbFAvXjVNQoV/ghks39q6qS9aPPCehuqccpAds3UXS1JUPcfIuxrHtlEZacyW0O
> Dxs59fzqIREXxZCR5YotiBXdOvhb9NC5l6pzoViGCLUy7H56FNfVyqWtB8nMa4zTkodxFN6l
> mofpDpXhSyu3mwZWA5+qWaN0cOt8wviPNSU0KKzTK2GDewIDAQABoy0wKzAbBgNVHREEFDAS
> gRBuZWVtZUBhcGFjaGUub3JnMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAAm0Q
> +3NNp/N3X4hNDiBfjehE68roH96Rr/+N4uabBDQb1r5Cd00IRZ3DpzCdGrFq441hJT5faOZ2
> RcqWk399YfTXecWEVpHfY7lcFwzCOiSyhTLjkZza8jxLsrzpleXbwWXfOlHGivPxMmSbcCpT
> 0oNCXMD5adUOcew7Wr1HMaYwggLNMIICNqADAgECAgMNlUkwDQYJKoZIhvcNAQEEBQAwYjEL
> MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
> BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MTIwODIz
> NDYzOVoXDTA1MTIwODIzNDYzOVowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJl
> cjEfMB0GCSqGSIb3DQEJARYQbmVlbWVAYXBhY2hlLm9yZzCCASIwDQYJKoZIhvcNAQEBBQAD
> ggEPADCCAQoCggEBAMmbvG3UoQTlRXtykI3bI+fifSYuftftTNyBeSXguiyjpXC6q2pVOZqj
> tucbqiTC3JegGPSvPETLb/Q8jX1M+gFgPHz2FIVdczuVj7iuJPv/Vc8BjCDFLf1NYlZHRNK3
> lvqkVmurGoqdx5RQkdImQn/uMLjH+3Dt8gTGxQL141TUKFf4IZLN/auqkvWjzwnobqnHKQHb
> N1F0tSVD3HyLsax7ZRGWnMltDg8bOfX86iERF8WQkeWKLYgV3Tr4W/TQuZeqc6FYhgi1Mux+
> ehTX1cqlrQfJzGuM05KHcRTepZqH6Q6V4Usrt5sGVgOfqlmjdHDrfML4jzUlNCis0ythg3sC
> AwEAAaMtMCswGwYDVR0RBBQwEoEQbmVlbWVAYXBhY2hlLm9yZzAMBgNVHRMBAf8EAjAAMA0G
> CSqGSIb3DQEBBAUAA4GBAAJtEPtzTafzd1+ITQ4gX43oROvK6B/eka//jeLmmwQ0G9a+QndN
> CEWdw6cwnRqxauONYSU+X2jmdkXKlpN/fWH013nFhFaR32O5XBcMwjoksoUy45Gc2vI8S7K8
> 6ZXl28Fl3zpRxorz8TJkm3AqU9KDQlzA+WnVDnHsO1q9RzGmMIIDPzCCAqigAwIBAgIBDTAN
> BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES
> MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE
> CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl
> cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0
> aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC
> WkExJTAjBgNVBAoTHFRoYXd0ZSBD

DO NOT REPLY [Bug 17794] - [fileupload] FileItem.getName() returns filename plus path from Windows/IE

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=17794


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-04-15 18:00 ---
It is not a bug. FileUpload is returning to you exactly what the browser 
provided as content encoded per RFC 1867. As mentioned before in the comments 
for this bug report, it is not the role of FileUpload to interpret the values 
supplied by the browser.

As for FileUpload being "of little use" without this change, that makes no 
sense, since you can use the same couple of lines of code in your application, 
if this is the ehaviour that you need.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Jakarta Commons Discovery

[Fernando Nasser]

Hi,
I participate in some Open Source communities that distribute and use 
Discovery.

At JPackage we have an RPM with the 0.2  built from 
http://www.apache.org/dist/jakarta/commons/discovery/source/commons-discovery-0.2-src.tar.gz
(everything is built from source so we can provide the source with the 
binary as Open Source should).

It happens that in the ObjectWeb JOnAS community they needed to use 
instead an snapshot of 27-Mar-2004 due to some bugs in 0.2.

If I update the JPackage RPM to an untagged version of the sources 
people may complain and I am also afraid of some backward 
incompatibility with that would affect the projects that currently use 
the 0.2 Discovery.

Would you consider tagging a 0.2.1 and making the source tar ball 
available?   Would that be backwards compatible?

Thanks in advance for your attention.
Regards to all,
Fernando
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r161486 - jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java

[rwinston]

Author: rwinston
Date: Fri Apr 15 08:38:28 2005
New Revision: 161486

URL: http://svn.apache.org/viewcvs?view=rev&rev=161486
Log:
Added a TestCase that shows how the new FTPClientConfig mechanism can solve 
problems like that demonstrated in Bug #27437

Modified:

jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java

Modified: 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java?view=diff&r1=161485&r2=161486
==
--- 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java
 (original)
+++ 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/FTPClientConfigFunctionalTest.java
 Fri Apr 15 08:38:28 2005
@@ -1,3 +1,4 @@
+
 /*
  * Copyright 2005 The Apache Software Foundation
  *



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 27437] - [net] FTP "get" and "list" tasks fail

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=27437


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-04-15 17:39 ---
The mechanisms to fix this are in the trunk and will be released in 1.4. I have
added a TestCase to the repository that shows how you can solve this issue using
the FTPClientConfig class.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
You are on the CC list for the bug, or are watching someone who is.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

jakarta/commons-sandbox-sql is moved to db/ddlutils

[John McNally]

As voted on previously the code within commons-sandbox-sql is now being 
developed under oversite of the DB pmc and the code was copied to the

/db/ddlutils
svn repository.
I left the old files in place as I did not want to break any 
dependencies, but if you want me to I can remove the sql directory.  I 
modifed the README.txt file to indicate that development is no longer 
being done within Jakarta, but let me know if I should do more.

John McNally
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r161482 - jakarta/commons/sandbox/sql/trunk/README.txt

[jmcnally]

Author: jmcnally
Date: Fri Apr 15 08:15:58 2005
New Revision: 161482

URL: http://svn.apache.org/viewcvs?view=rev&rev=161482
Log:
Note the movement of this project in the README

Modified:
jakarta/commons/sandbox/sql/trunk/README.txt

Modified: jakarta/commons/sandbox/sql/trunk/README.txt
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/sql/trunk/README.txt?view=diff&r1=161481&r2=161482
==
--- jakarta/commons/sandbox/sql/trunk/README.txt (original)
+++ jakarta/commons/sandbox/sql/trunk/README.txt Fri Apr 15 08:15:58 2005
@@ -1,16 +1,9 @@
 Jakarta Commons SQL
 ===
 
-The primary build tool for this project is Maven. 
-So all you should need to do is install Maven and just type
+commons-sql has moved from Jakarta to the DB project and is now known as
+ddlutils.  The code can be checked out from:
 
-   maven
+ https://svn.apache.org/repos/asf/db/ddlutils/
 
-For more help using Maven please go to
-
-  http://jakarta.apache.org/turbine/maven/
-
-Maven also supports the auto-generation of Ant build files so
-you may also be able to use Ant to build the code.
-
-Enjoy!
+DO NOT modify files here



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r161467 - jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/telnet/TelnetClientTest.java

[rwinston]

Author: rwinston
Date: Fri Apr 15 07:25:50 2005
New Revision: 161467

URL: http://svn.apache.org/viewcvs?view=rev&rev=161467
Log:
Remove output messages during testing

Modified:

jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/telnet/TelnetClientTest.java

Modified: 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/telnet/TelnetClientTest.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/telnet/TelnetClientTest.java?view=diff&r1=161466&r2=161467
==
--- 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/telnet/TelnetClientTest.java
 (original)
+++ 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/telnet/TelnetClientTest.java
 Fri Apr 15 07:25:50 2005
@@ -135,7 +135,6 @@

// only increment socket number on success
socket++;
-   System.err.println("opened client-server connection on port " + 
port);
} catch (IOException e) {
closeConnection(server, client, port);
System.err.println("failed to open client-server connection on 
port " + port);
@@ -170,7 +169,6 @@
 try {
 if (client != null) {
 client.disconnect();
-System.err.println("closed client-server connection on port " 
+ port);
 }
 } catch (IOException e) {
 System.err.println("failed to close client-server connection on 
port " + port);



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20489] - [net] Time out waiting for response on Mac OS 8.6/9.2 (classic)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20489


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-04-15 16:23 ---
No updates on this issue since 2003 - seems to be an old JDK bug. Closing.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r161466 - jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/tftp/TFTPClient.java

[rwinston]

Author: rwinston
Date: Fri Apr 15 07:21:23 2005
New Revision: 161466

URL: http://svn.apache.org/viewcvs?view=rev&rev=161466
Log:
Wait for last ACK, from [Bug# 32859]

Modified:

jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/tftp/TFTPClient.java

Modified: 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/tftp/TFTPClient.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/tftp/TFTPClient.java?view=diff&r1=161465&r2=161466
==
--- 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/tftp/TFTPClient.java
 (original)
+++ 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/tftp/TFTPClient.java
 Fri Apr 15 07:21:23 2005
@@ -372,6 +372,7 @@
 
 dataLength = lastBlock = hostPort = bytesRead = 0;
 block = 0;
+boolean lastAckWait = false;
 
 if (mode == TFTP.ASCII_MODE)
 input = new ToNetASCIIInputStream(input);
@@ -455,7 +456,10 @@
 if (lastBlock == block)
 {
 ++block;
-break _receivePacket;
+if (lastAckWait)
+  break _sendPacket;
+else
+  break _receivePacket;
 }
 else
 {
@@ -501,9 +505,8 @@
 data.setData(_sendBuffer, 4, offset - 4);
 sent = data;
 }
-while (dataLength == 0);
+while (dataLength == 0 || lastAckWait);
 
-bufferedSend(sent);
 endBufferedOps();
 }
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32859] - [net] TFTPClient's send file discards last ack

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32859


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-04-15 16:21 ---
Thanks Perttu. 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r161465 - jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ntp/NTPUDPClient.java

[rwinston]

Author: rwinston
Date: Fri Apr 15 07:20:10 2005
New Revision: 161465

URL: http://svn.apache.org/viewcvs?view=rev&rev=161465
Log:
Set port on NTP message, as per [Bug# 34219]

Modified:

jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ntp/NTPUDPClient.java

Modified: 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ntp/NTPUDPClient.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ntp/NTPUDPClient.java?view=diff&r1=161464&r2=161465
==
--- 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ntp/NTPUDPClient.java
 (original)
+++ 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ntp/NTPUDPClient.java
 Fri Apr 15 07:20:10 2005
@@ -68,6 +68,7 @@
 message.setVersion(_version);
 DatagramPacket sendPacket = message.getDatagramPacket();
 sendPacket.setAddress(host);
+sendPacket.setPort(port);
 
 NtpV3Packet recMessage = new NtpV3Impl();
 DatagramPacket receivePacket = recMessage.getDatagramPacket();



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [net] FTP client date parsing: new format

[Neeme Praks]

Ok, now I've found out what is the issue: the regexp pattern used by 
UnixFTPEntryParser assumes too much about the format of the date. In 
particular, it assumes that there are spaces inside the date or 
something like that. As I'm not much of a regexp expert, I cannot really 
pinpoint the problem with the pattern. But I can demonstrate the results 
from applying this pattern below.

This is the usual case that is parsed OK.
*entry*: -rw-r--r--1 1000 1000   27 Jan 24 11:31 
messages.vsp
parsed into these variables:
   typeStr=-
   hardLinkCount=1
   usr=1000
   grp=1000
   filesize=27
   datestr=Jan 24 11:31
   name=messages.vsp
   endtoken=

This is the one that has issues. Lucky for me, the parser manages to 
"parse" the entries that represent symbolic links, as these entries seem 
to have enough spaces required by the regexp pattern. Although 
incorrectly, it nicely demonstrates the issue with the parser.
*entry*: lrwxrwxrwx   1 neeme neeme23 2005-03-02 18:06 macros -> 
../../../global/macros/
parsed into these variables:
   typeStr=l
   hardLinkCount=1
   usr=neeme
   grp=neeme
   filesize=23
   datestr=2005-03-02 18:06 macros
   name=->
   endtoken= ../../../global/macros/

Note that starting from datestr variable, the parsing is f**ked up...
How can we solve this issue?
Make regexp pattern also configurable? Better suggestions?
Rgds,
Neeme
Neeme Praks wrote:
I cannot give you access as it is inside our corporate firewall.
So I guess I'll try to debug it on my own. :-)
I'll let you know when I have made some progress with that.


smime.p7s
Description: S/MIME Cryptographic Signature

DO NOT REPLY [Bug 30970] - [net] PATCH] FTP and FTPClient changes

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30970


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||LATER




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 30970] - [net] PATCH] FTP and FTPClient changes

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30970


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |




--- Additional Comments From [EMAIL PROTECTED]  2005-04-15 16:14 ---
Sorry Joseph, what I actually meant to do was mark this as LATER. I think you
have some good ideas in here, and will be taking a better look when I get some 
time.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 30970] - [net] PATCH] FTP and FTPClient changes

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30970


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 30719] - [net] The FTPClient is unable to list files on Japanese servers

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30719





--- Additional Comments From [EMAIL PROTECTED]  2005-04-15 16:12 ---
Many thanks for the patch Leif. I applied parts of it for release 1.3, however I
have not applied the whole patch, so I felt it better to mark as WONTFIX rather
than FIXED.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34219] - [net] NTP port parameter ignored

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=34219


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-04-15 16:10 ---
Patch applied. Thanks.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33972] - [net] FTP Parsing off in Net Components for ACL

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33972


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-04-15 16:08 ---
Applied patch. Thanks.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r161464 - in jakarta/commons/proper/net/trunk/src: java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java test/org/apache/commons/net/ftp/parser/UnixFTPEntryParserTest.java

[rwinston]

Author: rwinston
Date: Fri Apr 15 07:08:07 2005
New Revision: 161464

URL: http://svn.apache.org/viewcvs?view=rev&rev=161464
Log:
Added support for trailing ACL characters [Bug# 33972]

Modified:

jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java

jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/UnixFTPEntryParserTest.java

Modified: 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java?view=diff&r1=161463&r2=161464
==
--- 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java
 (original)
+++ 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java
 Fri Apr 15 07:08:07 2005
@@ -65,7 +65,7 @@
  */
 private static final String REGEX =
 "([bcdlfmpSs-])"
-+ 
"(((r|-)(w|-)([xsStTL-]))((r|-)(w|-)([xsStTL-]))((r|-)(w|-)([xsStTL-])))\\s+"
+
+"(((r|-)(w|-)([xsStTL-]))((r|-)(w|-)([xsStTL-]))((r|-)(w|-)([xsStTL-])))\\+?\\s+"
 + "(\\d+)\\s+"
 + "(\\S+)\\s+"
 + "(?:(\\S+)\\s+)?"

Modified: 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/UnixFTPEntryParserTest.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/UnixFTPEntryParserTest.java?view=diff&r1=161463&r2=161464
==
--- 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/UnixFTPEntryParserTest.java
 (original)
+++ 
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/UnixFTPEntryParserTest.java
 Fri Apr 15 07:08:07 2005
@@ -45,6 +45,7 @@
 
 private static final String[] goodsamples =
 {
+
 "-rw-r--r--   1 500  50021 Aug  8 14:14 JB3-TES1.gz",
 "-rwxr-xr-x   2 root root 4096 Mar  2 15:13 zxbox",
 "drwxr-xr-x   2 root root 4096 Aug 24  2001 zxjdbc",
@@ -70,6 +71,8 @@
 "-rwSr-Sr--   1 500  500 0 Mar 25 08:22 testSuid",
"-rwsr-sr--   1 500  500 0 Mar 25 08:23 
testSuidExec",
"-rwsr-sr--   1 500  500 0 Mar 25 0:23 
testSuidExec2",
+"drwxrwx---+ 23 500 5000 Jan 10 13:09 testACL",
+
"-rw-r--r--   1 13518644 May 25 12:12 std"
 };
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33942] - [net] FTP: NoSuchMethodError thrown when sending command to disconnected FTP server

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33942


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-04-15 16:01 ---
Patch applied.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33942] - [net] FTP: NoSuchMethodError thrown when sending command to disconnected FTP server

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33942


Bug 33942 depends on bug 31793, which changed state.

Bug 31793 Summary: [net] handling ftp disconnection initiated by firewalls
http://issues.apache.org/bugzilla/show_bug.cgi?id=31793

   What|Old Value   |New Value

 Status|REOPENED|RESOLVED
 Resolution||FIXED



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31793] - [net] handling ftp disconnection initiated by firewalls

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=31793


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-04-15 16:00 ---
Patch applied.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r161462 - jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTP.java

[rwinston]

Author: rwinston
Date: Fri Apr 15 07:00:13 2005
New Revision: 161462

URL: http://svn.apache.org/viewcvs?view=rev&rev=161462
Log:
Commit fix for JDK 1.3. Fixes bugs 33942 and 31973

Modified:

jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTP.java

Modified: 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTP.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTP.java?view=diff&r1=161461&r2=161462
==
--- 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTP.java 
(original)
+++ 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTP.java 
Fri Apr 15 07:00:13 2005
@@ -21,8 +21,12 @@
 import java.io.OutputStreamWriter;
 import java.net.InetAddress;
 import java.net.SocketException;
+import java.net.Socket;
 import java.util.Enumeration;
 import java.util.Vector;
+import java.lang.reflect.Method;
+import java.lang.reflect.InvocationTargetException;
+
 import org.apache.commons.net.MalformedServerReplyException;
 import org.apache.commons.net.ProtocolCommandListener;
 import org.apache.commons.net.ProtocolCommandSupport;
@@ -439,7 +443,7 @@
 }
 catch (SocketException e)
 {
-if (!isConnected() || _socket_ == null || !_socket_.isConnected())
+if (!isConnected() || !socketIsConnected(_socket_))
 {
 throw new FTPConnectionClosedException("Connection 
unexpectedly closed.");
 }
@@ -457,6 +461,38 @@
 return _replyCode;
 }
 
+/**
+ * Checks if the socket is connected using reflection to be backward 
compatible.
+ * The return value of this method is only meaningful in an java 1.4 
environment.
+ *
+ * @param socket
+ * @return true if connected or pre java 1.4
+ */
+private boolean socketIsConnected(Socket socket)
+{
+if (socket == null)
+{
+return false;
+}
+
+try
+{
+Method isConnected = socket.getClass().getMethod("isConnected", 
null);
+return ((Boolean) isConnected.invoke(socket, null)).booleanValue();
+}
+catch (NoSuchMethodException e)
+{
+return true;
+}
+catch (IllegalAccessException e)
+{
+return true;
+}
+catch (InvocationTargetException e)
+{
+return true;
+}
+}
 
 /***
  * Sends an FTP command to the server, waits for a reply and returns the



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r161460 - jakarta/commons/sandbox/compress/trunk/src/java/org/apache/commons/compress/bzip2/CBZip2InputStream.java

[roxspring]

Author: roxspring
Date: Fri Apr 15 06:51:30 2005
New Revision: 161460

URL: http://svn.apache.org/viewcvs?view=rev&rev=161460
Log:
The underlying InputStream really should be closed

Modified:

jakarta/commons/sandbox/compress/trunk/src/java/org/apache/commons/compress/bzip2/CBZip2InputStream.java

Modified: 
jakarta/commons/sandbox/compress/trunk/src/java/org/apache/commons/compress/bzip2/CBZip2InputStream.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/compress/trunk/src/java/org/apache/commons/compress/bzip2/CBZip2InputStream.java?view=diff&r1=161459&r2=161460
==
--- 
jakarta/commons/sandbox/compress/trunk/src/java/org/apache/commons/compress/bzip2/CBZip2InputStream.java
 (original)
+++ 
jakarta/commons/sandbox/compress/trunk/src/java/org/apache/commons/compress/bzip2/CBZip2InputStream.java
 Fri Apr 15 06:51:30 2005
@@ -964,4 +964,9 @@
 }
 }
 }
+
+public void close() throws IOException 
+{
+m_input.close();
+}
 }



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34472] - [daemon] jsvc - can't run tomcat on 64-bit solaris

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=34472


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|jsvc - can't run tomcat on  |[daemon] jsvc - can't run
   |64-bit solaris  |tomcat on 64-bit solaris




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34472] - jsvc - can't run tomcat on 64-bit solaris

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=34472





--- Additional Comments From [EMAIL PROTECTED]  2005-04-15 14:46 ---
Created an attachment (id=14732)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14732&action=view)
Patch to apsupport.m4


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34472] New: - jsvc - can't run tomcat on 64-bit solaris

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=34472

   Summary: jsvc - can't run tomcat on 64-bit solaris
   Product: Commons
   Version: unspecified
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: normal
  Priority: P2
 Component: Daemon
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I can't run tomcat using the sparcv9 64-bit jre.

However, if apsupport.m4 is changed on line 27 from "sparc" to "sparc*", then I
can run
CFLAGS="-xtarget=generic64" LDFLAGS="-xtarget=generic64" ./configure
--build=sparcv9--solaris
and then I can build a 64-bit version of jsvc.
(Note: this requires location.c from svn revision 140763 or later to get the
correct jvm.cfg file).
Then I can run tomcat using:
jsvc -jvm server ...

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34470] New: - [beanutils] Need utility for collecting differences between objects

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=34470

   Summary: [beanutils] Need utility for collecting differences
between objects
   Product: Commons
   Version: unspecified
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Bean Utilities
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


It would be really convinient if there was a method on the BeanUtils object that
would return a list of all the attributes that have changed between two objects.
 This is useful for creating an audit trail of those attributes that have been
modified.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP@brutus]: Project commons-jelly-tags-xml (in module commons-jelly) failed

[commons-jelly-tags-xml development]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-xml has an issue affecting its community integration.
This issue affects 12 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-define :  Commons Jelly
- commons-jelly-tags-html :  Commons Jelly
- commons-jelly-tags-http :  Commons Jelly
- commons-jelly-tags-jaxme :  Commons Jelly
- commons-jelly-tags-jetty :  Commons Jelly
- commons-jelly-tags-jface :  Commons Jelly
- commons-jelly-tags-jsl :  Commons Jelly
- commons-jelly-tags-swing :  Commons Jelly
- commons-jelly-tags-xml :  Commons Jelly
- commons-jelly-tags-xmlunit :  Commons Jelly
- maven :  Project Management Tools
- maven-bootstrap :  Project Management Tools


Full details are available at:

http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-xml-15042005.jar] identifier set to 
project name
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/gump_work/build_commons-jelly_commons-jelly-tags-xml.html
Work Name: build_commons-jelly_commons-jelly-tags-xml (Type: Build)
Work ended in a state of : Failed
Elapsed: 13 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-15042005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-15042005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-15042005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-15042005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-15042005.jar
-
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes

java:compile:
[echo] Compiling to 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes
[echo] 
==

  NOTE: Targetting JVM 1.4, classes
  will not run on earlier JVMs

==
  
[javac] Compiling 16 source files to 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes

java:jar-resources:

test:prepare-filesystem:
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports

test:test-resources:
Copying 36 files to 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes

test:compile:
[javac] Compiling 4 source files to 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes

test:test:
[junit] Running org.apache.commons.jelly.tags.xml.TestImport
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.992 sec
[junit] Running org.apache.commons.jelly.tags.xml.TestJelly
[junit] some text
[junit] exists = true, readable = true, class=java.io.File
[junit] 
[junit]   Tests run: 15, Failures: 0, Errors: 13, Time elapsed: 0.512 sec
[junit] [ERROR] TEST org.apache.commons.jelly.tags.xml.TestJelly FAILED
[junit] Running org.apache.commons.jelly.tags.xml.TestParser
[junit] 

DO NOT REPLY [Bug 17794] - [fileupload] FileItem.getName() returns filename plus path from Windows/IE

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=17794


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2005-04-15 10:22 ---
(In reply to comment #2)
> *** Bug 34393 has been marked as a duplicate of this bug.
I think this is a real bug that should be solved as indicated in a patch
provided in another duplicate offering.  At least commons upload will be of
little use to me if that patch or one doing the same thing is not applied.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] update docs to specify that java 1.1 is supported

[Simon Kitching]

On Fri, 2005-04-15 at 00:02 -0700, Brian Stansberry wrote:
> Random thoughts
> 
> 1) Found a brief discussion on this list a month ago
> that touched on issues with JDK detection:
> 
> http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=111049144008136&w=2

Thanks for the link.

> 
> 2) My experience is that the JVM will not try to load
> a class until it is needed, so even though
> AccessController and PrivilegedAction are imported,
> LogFactory/LogFactoryImpl/SimpleLogcan be loaded.  In
> the test I ran the NoClassDefFoundError is thrown when
> an attempt is made to use PrivilegedAction, not when
> LogFactory is loaded.  So, *potentially* the error can
> be caught and handled or just avoided via JDK
> detection.

Yep, that's my understanding of the Sun JVM at least..

> 
> The concern I have is that this "lazy loading" of
> classes is not required in the spec (see
> http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#22574
> ).  Some JVMs (e.g. the M$ JVM used in Win9x browsers)
> *may* try to link all classes when LogFactory is
> loaded, in which case JDK detection won't work unless
> we use reflection for the AccessController stuff. 
> Reflection sounds pretty nasty. (Is it even possible
> for anonymous inner classes?  Don't know how it could
> be.)

Yep, I agree with this too. In particular, assuming that "lazy loading"
is in effect might get hairy with GCJ. I think we would have to go with
a reflection-based approach somehow.

I don't think the anonymous-inner-class bit is a show-stopper; can't we
just pull that out into a separate, ordinary, class?

However we need to invoke it moderately frequently (each time
LogFactory.getLog is called). So I'm not sure normal reflection will be
acceptable. 


> 
> 3) Did a little archeology and it looks like JCL 1.0.1
> was cut about a week before the AccessController stuff
> was added.  So that's the last release that ran on JDK
> 1.1.

Yep, that's how I read the CVS/SVN logs too. Version 1.0.2 was JDK1.2
only.

There's no information I can find on whether the change to drop JDK 1.1
was deliberate or not..

> 
> 4) Throwing in my own 2 cents, I think of JCL as being
> targetted to component/library/framework developers. 
> I don't expect there are many applets being written
> that target 1.1 and also incorporate the kinds of
> libraries that use JCL.

Well, as I said in my earlier email, Win9x (and possible WinNT) shipped
with the microsoft 1.1 JVM, and I believe a fair number of simple
applets still target that JVM in order to avoid requiring users of those
operating systems to install a JVM explicitly.


My current opinion, though, is that we should:
(a) simply document the current state in the commons-logging website
and/or wiki: JCL 1.0.2 and later require JVM1.2.
(b) when working on the revised JCL, regard support for 1.1 as
"desirable but not mandatory".

I think at this point the work we already have in progress for JCL is
enough without tackling this task too.

What do you think?

Cheers,

Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] update docs to specify that java 1.1 is supported

[Brian Stansberry]

--- Simon Kitching <[EMAIL PROTECTED]> wrote:

> Hmm..you're quite right. The problem is not
> "getContextClassLoader", but
> there *is* a problem with AccessController.
> 
> I've checked the svn/cvs history, and the
> AccessController stuff was
> added by Richard Sitze in r138923 on 2002-10-18.
> Presumably that was the
> date at which JCL no longer worked on java1.1.
> 
> Given that there have been no complaints about that,
> should we assume
> that JCL for java-1.1 is not in great demand, and
> explicitly support
> only 1.3 or later? I see no reason to support 1.2,
> as it is well
> out-of-date; 1.1 has *some* justification as many
> Win9x systems shipped
> with this jvm version and still are in use (see the
> user request which
> started this discussion).
> 
> ALternatively, we can simply test for 1.1 before
> attempting to use the
> AccessController stuff...
> 

Random thoughts

1) Found a brief discussion on this list a month ago
that touched on issues with JDK detection:

http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=111049144008136&w=2

2) My experience is that the JVM will not try to load
a class until it is needed, so even though
AccessController and PrivilegedAction are imported,
LogFactory/LogFactoryImpl/SimpleLogcan be loaded.  In
the test I ran the NoClassDefFoundError is thrown when
an attempt is made to use PrivilegedAction, not when
LogFactory is loaded.  So, *potentially* the error can
be caught and handled or just avoided via JDK
detection.

The concern I have is that this "lazy loading" of
classes is not required in the spec (see
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#22574
).  Some JVMs (e.g. the M$ JVM used in Win9x browsers)
*may* try to link all classes when LogFactory is
loaded, in which case JDK detection won't work unless
we use reflection for the AccessController stuff. 
Reflection sounds pretty nasty. (Is it even possible
for anonymous inner classes?  Don't know how it could
be.)

3) Did a little archeology and it looks like JCL 1.0.1
was cut about a week before the AccessController stuff
was added.  So that's the last release that ran on JDK
1.1.

4) Throwing in my own 2 cents, I think of JCL as being
targetted to component/library/framework developers. 
I don't expect there are many applets being written
that target 1.1 and also incorporate the kinds of
libraries that use JCL.

Brian

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]