[jira] [Created] (DBUTILS-85) In BeanProcessor#isCompatibleType, can Integer.class.isInstance(value) be replaced by value instanceof Integer (etc)?

2012-01-07 Thread Sebb (Created) (JIRA)
In BeanProcessor#isCompatibleType, can Integer.class.isInstance(value) be 
replaced by value instanceof Integer (etc)?
-

 Key: DBUTILS-85
 URL: https://issues.apache.org/jira/browse/DBUTILS-85
 Project: Commons DbUtils
  Issue Type: Improvement
Reporter: Sebb
Priority: Minor


In BeanProcessor#isCompatibleType, there is one valid use of the dynamic 
Class#isInstance() method, followed by several that could surely use the static 
instanceof keyword:

{noformat}
if (value == null || type.isInstance(value)) { // == this needs to be dynamic
return true;

} else if (type.equals(Integer.TYPE)  Integer.class.isInstance(value)) { // 
== this doesn't
return true;

} else if (type.equals(Long.TYPE)  Long.class.isInstance(value)) { // == 
nore here
return true;
...
{noformat}

Seems unnecessary (and more verbose) to use the dynamic method where the target 
class is known at compile time.

Or am I missing something here? 
If so, let's document why the dynamic method is needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (NET-433) NET site should link to the examples

2012-01-07 Thread Sebb (Resolved) (JIRA)

 [ 
https://issues.apache.org/jira/browse/NET-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved NET-433.
--

   Resolution: Fixed
Fix Version/s: 3.1

 NET site should link to the examples
 

 Key: NET-433
 URL: https://issues.apache.org/jira/browse/NET-433
 Project: Commons Net
  Issue Type: Improvement
Reporter: Sebb
Priority: Minor
 Fix For: 3.1


 The NET site should have a page which covers the examples

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (CONFIGURATION-474) Lists don't seem to work whean loading INI files

2012-01-07 Thread Oliver Heger (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13182020#comment-13182020
 ] 

Oliver Heger commented on CONFIGURATION-474:


Indeed, in contrast to the deprecated INIConfiguration, 
HierarchicalINIConfiguration does not split comma-separated values. This should 
be added to be consistend with other configuration implementations. However, I 
would suggest to disable this feature by default to stay compatible with older 
versions. So in order to enable it, you would have to call 
{{setDelimiterParsingDisabled(false)}} before calling {{load()}}.

Thanks for the report.

 Lists don't seem to work whean loading INI files
 

 Key: CONFIGURATION-474
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-474
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Charles Leclerc
Priority: Minor

 After loading an INI file with HierarchicalINIConfiguration, getList() and 
 getStringArray() alaways return 1-size sets even if the parameter is in the 
 right form in the file. To reproduce one only need to create a small INI file 
 with the following content :
 key=val1,val2,val3
 The following code returns a 1-sized list :
 HierarchicalINIConfiguration c = new HierarchicalINIConfiguration();
 c.load(test.ini);
 List? l = c.getList(val);
 = l = [val1,val2,val3] instead of [val1,val2,val3]
 I tried to change the list delimiter, but it didn't work. Maybe it's 
 expected, but I haven't found anything in the doc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (CONFIGURATION-474) Lists don't seem to work whean loading INI files

2012-01-07 Thread Charles Leclerc (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13182033#comment-13182033
 ] 

Charles Leclerc commented on CONFIGURATION-474:
---

I tried to add {{setDelimiterParsingDisabled(false)}} before calling 
{{load()}}, but it doesn't work either, the List is is still 1-sized.

 Lists don't seem to work whean loading INI files
 

 Key: CONFIGURATION-474
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-474
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Charles Leclerc
Priority: Minor

 After loading an INI file with HierarchicalINIConfiguration, getList() and 
 getStringArray() alaways return 1-size sets even if the parameter is in the 
 right form in the file. To reproduce one only need to create a small INI file 
 with the following content :
 key=val1,val2,val3
 The following code returns a 1-sized list :
 HierarchicalINIConfiguration c = new HierarchicalINIConfiguration();
 c.load(test.ini);
 List? l = c.getList(val);
 = l = [val1,val2,val3] instead of [val1,val2,val3]
 I tried to change the list delimiter, but it didn't work. Maybe it's 
 expected, but I haven't found anything in the doc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (CONFIGURATION-474) Lists don't seem to work whean loading INI files

2012-01-07 Thread Charles Leclerc (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Charles Leclerc updated CONFIGURATION-474:
--

Description: 
After loading an INI file with HierarchicalINIConfiguration, getList() and 
getStringArray() alaways return 1-size sets even if the parameter is in the 
right form in the file. To reproduce one only need to create a small INI file 
with the following content :

{{key=val1,val2,val3}}

The following code returns a 1-sized list :

{code}
HierarchicalINIConfiguration c = new HierarchicalINIConfiguration();
c.load(test.ini);
List? l = c.getList(val);
{code}

= l = {{[val1,val2,val3]}} instead of {{[val1,val2,val3]}}

I tried to change the list delimiter, but it didn't work. Maybe it's expected, 
but I haven't found anything in the doc.

  was:
After loading an INI file with HierarchicalINIConfiguration, getList() and 
getStringArray() alaways return 1-size sets even if the parameter is in the 
right form in the file. To reproduce one only need to create a small INI file 
with the following content :

key=val1,val2,val3

The following code returns a 1-sized list :

HierarchicalINIConfiguration c = new HierarchicalINIConfiguration();
c.load(test.ini);
List? l = c.getList(val);

= l = [val1,val2,val3] instead of [val1,val2,val3]

I tried to change the list delimiter, but it didn't work. Maybe it's expected, 
but I haven't found anything in the doc.


 Lists don't seem to work whean loading INI files
 

 Key: CONFIGURATION-474
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-474
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Charles Leclerc
Priority: Minor

 After loading an INI file with HierarchicalINIConfiguration, getList() and 
 getStringArray() alaways return 1-size sets even if the parameter is in the 
 right form in the file. To reproduce one only need to create a small INI file 
 with the following content :
 {{key=val1,val2,val3}}
 The following code returns a 1-sized list :
 {code}
 HierarchicalINIConfiguration c = new HierarchicalINIConfiguration();
 c.load(test.ini);
 List? l = c.getList(val);
 {code}
 = l = {{[val1,val2,val3]}} instead of {{[val1,val2,val3]}}
 I tried to change the list delimiter, but it didn't work. Maybe it's 
 expected, but I haven't found anything in the doc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (NET-346) FTP should support reporting NATed external IP address

2012-01-07 Thread Sebb (Resolved) (JIRA)

 [ 
https://issues.apache.org/jira/browse/NET-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved NET-346.
--

   Resolution: Fixed
Fix Version/s: 3.1

Applied, with a minor change: getReportHostAddress now defers to getHostAddress 
if __reportActiveExternalHost is null.

 FTP should support reporting NATed external IP address
 --

 Key: NET-346
 URL: https://issues.apache.org/jira/browse/NET-346
 Project: Commons Net
  Issue Type: Improvement
  Components: FTP
Affects Versions: 2.2
Reporter: Kevin Samuel
 Fix For: 3.1

 Attachments: FTPClient.java, ftpclient.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 When trying to do an active FTP transfer as client from behind a firewall 
 with NAT, setActiveExternalIPAddress is not sufficient, as you can only 
 report the internal IP of the client (e.g. 192.168.1.2 vs 72.14.X.X)
 FTPClient should support an additional function to set the REPORTABLE 
 external active IP Address
 I created and successfully tested a fix for this:
 ADD PRIVATE MEMBER:
 private InetAddress __reportActiveExternalHost;
 IN __initDefaults():
 __reportActiveExternalHost = null;
 ADD PUBLIC FUNCTIONS:
 private InetAddress getReportHostAddress()
 {
   if (__reportActiveExternalHost != null)
   {
   return __reportActiveExternalHost ;
   }
   else if (__activeExternalHost != null)
 {
 return __activeExternalHost;
 }
 else
 {
 // default local address
 return getLocalAddress();
 }
 }
 public void setReportActiveExternalIPAddress(String ipAddress) throws 
 UnknownHostException
 {
 this.__reportActiveExternalHost = InetAddress.getByName(ipAddress);
 }
 IN _openDataConnection_:
 if (isInet6Address)
 {
 if 
 (!FTPReply.isPositiveCompletion(eprt(getReportHostAddress(), 
 server.getLocalPort(
 {
 server.close();
 return null;
 }
 }
 else
 {
 if 
 (!FTPReply.isPositiveCompletion(port(getReportHostAddress(), 
 server.getLocalPort(
 {
 server.close();
 return null;
 }
 }
 will also attach changed file
 sorry I am not familiar with the correct way to submit patches, although I 
 tried to model this on #NET-285 as much as possible

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (NET-427) In certain error/failure circumstances ftpClient.listFiles(param) returns an empty list instead of null or an exception

2012-01-07 Thread Sebb (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/NET-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13182062#comment-13182062
 ] 

Sebb commented on NET-427:
--

Just noticed that the listNames methods (which use NLST rather than LIST) 
return null if completePendingCommand() returns false; i.e. any names retrieved 
so far will be lost.

So perhaps listFiles needs to behave the same way.

 In certain error/failure circumstances ftpClient.listFiles(param) returns an 
 empty list instead of null or an exception
 ---

 Key: NET-427
 URL: https://issues.apache.org/jira/browse/NET-427
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 3.0.1
 Environment: SunOS 5.10 Generic_144489-06
Reporter: Mario Zannone
 Attachments: FtpTest.java, log_excerpt.txt


 According to the API docs ftpClient.listFiles(String) should return
 null or an exception on error conditions or failure:
  The convention for all the FTP command methods in FTPClient is
  such that they either return a boolean value or some other value.
  The boolean methods return true on a successful completion reply
  from the FTP server and false on a reply resulting in an error
  condition or failure. The methods returning a value other than
  boolean return a value containing the higher level data produced
  by the FTP command, or null if a reply resulted in an error
  condition or failure.
 ( 
 http://commons.apache.org/net/apidocs/org/apache/commons/net/ftp/FTPClient.html
  )
 However in certain error/failure circumstances listFiles(param)
 returns an empty list instead of null.
 Note that an empty list is a correct response when param does not
 match any file.
 We were able to bypass the problem checking the ftp reply with
 getReplyCode().  However, this listFiles behaviour is unexpected 
 and should at least be documented.
 The error is not systematic and not easy to diagnose or replicate.
 We were able to reproduce it using cron to run the attached
 program every minute on a slow and unreliable connection;
 in 24h the error did show only a couple of times.
 Attachments: test program and excerpt from the test log.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (NET-320) Allow TFTPServer.java to bind to a specific network adapter

2012-01-07 Thread Sebb (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/NET-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13182154#comment-13182154
 ] 

Sebb commented on NET-320:
--

Note that the TFTPServer is only currently intended for use by test code.

 Allow TFTPServer.java to bind to a specific network adapter
 ---

 Key: NET-320
 URL: https://issues.apache.org/jira/browse/NET-320
 Project: Commons Net
  Issue Type: Improvement
  Components: TFTP
Affects Versions: 2.0
Reporter: Kevin
  Labels: NetworkInterface, TFTP, TFTPServer
 Attachments: tftp-bind.diff

   Original Estimate: 24h
  Remaining Estimate: 24h

 It would be very nice to specify exactly which network interface you would 
 like to bind the TFTP server listening port to.  In some cases it's only 
 necessary to open up loopback, in other cases you may only want to bind to a 
 management network.  I would like to see one of two things happen to satisfy 
 this requirement.
  
 1) You could allow me to get a handle to the socket such that I can make 
 modifications to it on my own.
 or
 2) Add a constructor and/or method that allows me to pass a NetworkInterface 
 instance to specify which nic to bind the server to.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (NET-405) Support for IPv6 in SubnetUtils

2012-01-07 Thread Sebb (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/NET-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13182156#comment-13182156
 ] 

Sebb commented on NET-405:
--

Which of the methods are actually needed for use with IPv6?

 Support for IPv6 in SubnetUtils
 ---

 Key: NET-405
 URL: https://issues.apache.org/jira/browse/NET-405
 Project: Commons Net
  Issue Type: Improvement
Reporter: Marc Lefrancois

 Currently, we cannot use org.apache.commons.net.util.SubnetUtils with IPv6 
 addresses. This class will become less and less useful as more internet 
 device are only assigned IPv6 addresses since all available IPv4 address 
 blocks have now been attributed. 
 http://en.wikipedia.org/wiki/IPv4_address_exhaustion

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira