[jira] [Created] (NET-417) org.apache.commons.net.ftpFTPClient, file will not be totally transferred.
org.apache.commons.net.ftpFTPClient, file will not be totally transferred. -- Key: NET-417 URL: https://issues.apache.org/jira/browse/NET-417 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.0.1 Environment: Windows XP FTPClient program sending file to Windows 2003 IIS FTP Server Reporter: tom yang If I use this ftp.storeFile(f.getName(), stream) to transfer file to the FTP Server. After the function returned the file will be partially sent. E.g. If the file has 1025 bytes, only 1024 bytes will be sent while if the file has 2050 bytes, only 2048 bytes will be sent. That's because the default buffer size is 1024, each time 1024 bytes of file content will be sent to the FTP server. But stream.flush() is not called at the end of each transfer. Finally, socket stream to FTP server will be closed before the last transmission and the last frame of data, which may be less than 1024, will be left unsent. My way of fixing this BUG: Change the content of method FtpClient.__storeFile(), change the last parameter for calling Util.copyStream() to 'true'. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-589) JavaDoc error in OneWayAnovaImpl
JavaDoc error in OneWayAnovaImpl Key: MATH-589 URL: https://issues.apache.org/jira/browse/MATH-589 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Lorenzo González Priority: Trivial JavaDoc por OneWayAnovaImpl say: Implements one-way ANOVA statistics defined in the OneWayAnovaImpl interface. And the Javadoc must say: Implements one-way ANOVA statistics defined in the OneWayAnova interface. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-485) Feature Request: Kalman Filter
[ https://issues.apache.org/jira/browse/MATH-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated MATH-485: - Attachment: MATH-485-cleanup.patch Thanks for already committing the patch ;-). I have worked on the comments from Luc and provided a cleanup patch that corrects the following: * added missing javadoc comments * fixed checkstyle errors (ignoring method extension warnings as I do not know exactly how or if to resolve them) * added package.html * processNoise and measurementNoise are now correctly retrieved from the respective models every predict/correct step @time-dependant noises: I think this makes perfect sense, but I was unsure how to solve this in an optimal way. By now, one could create a specific ProcessModel implementation that returns the "right" process noise at the correct time-step. For a more general case, one would also need the mentioned integer parameter in the predict/correct methods, or do you think about keeping track of the iteration internally in the Kalman filter? > Feature Request: Kalman Filter > -- > > Key: MATH-485 > URL: https://issues.apache.org/jira/browse/MATH-485 > Project: Commons Math > Issue Type: Wish >Reporter: Benjamin McCann > Fix For: 3.0 > > Attachments: KalmanFilterExample.java, MATH-485-cleanup.patch, > MATH-485-update1.patch, MATH-485.patch > > > I'd love it if Commons Math could add support for the Kalman filter. Here > are a few implementations that might be able to be used for reference or > included if they're using compatible licenses: > http://code.google.com/p/efficient-java-matrix-library/wiki/KalmanFilterExamples > http://mathstat.asu.edu/~eubank/ > http://www.fit.vutbr.cz/research/prod/index.php.en?id=53¬itle=1 > http://sourceforge.net/projects/jkalman/ > http://www.vni.com/products/imsl/jmsl/v30/api/com/imsl/stat/KalmanFilterEx1.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-121) Provide thread name for EvcitionTimer
[
https://issues.apache.org/jira/browse/POOL-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved POOL-121.
--
Resolution: Fixed
> Provide thread name for EvcitionTimer
> -
>
> Key: POOL-121
> URL: https://issues.apache.org/jira/browse/POOL-121
> Project: Commons Pool
> Issue Type: Improvement
>Affects Versions: 1.3, 1.4
>Reporter: Christoph Kutzinski
>Priority: Trivial
> Fix For: 2.0
>
>
> When taking thread dumps and while debugging, I always like when each thread
> has a speaking name. Therefore I suggest that Pool's EvictionTimer should
> have a name, too.
> E.g.:
> instead of
> _timer = new Timer(true);
> use
> _timer = new Timer("commons-pool-EvictionTimer", true);
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-134) Parameterize the maxWait time to be per borrow call
[ https://issues.apache.org/jira/browse/POOL-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-134. -- Resolution: Fixed Assignee: Mark Thomas > Parameterize the maxWait time to be per borrow call > --- > > Key: POOL-134 > URL: https://issues.apache.org/jira/browse/POOL-134 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 1.4 > Environment: JRE 1.4.x >Reporter: David Meibusch >Assignee: Mark Thomas >Priority: Minor > Fix For: 2.0 > > > Use case: > The pool is being used to pool connections in a mid-tier system to a backend > system. > Client requests to the system have a configured timeout specified as an > elapsed time with respect to the client application. > Requests may spend some elapsed time in internal work queues and/or may > borrow connections multiple times to service the single request. > When calling the borrowObject method the mid tier system requires the wait > time to be only a portion of request time remaining. > The maxWait time for the GenericObjectPool is currently a global value for > all borrowObject operations. > The current implementation requires only minor changes to support a per > borrowObject maxTime. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-150) GenericKeyedObjectPool.preparePool does not throw an exception if supplied factory is null
[
https://issues.apache.org/jira/browse/POOL-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved POOL-150.
--
Resolution: Fixed
This was fixed as a side-effect of the 2.0.x re-factoring although not in the
manner originally envisaged as factories may be null when GKOPs are created.
> GenericKeyedObjectPool.preparePool does not throw an exception if supplied
> factory is null
> --
>
> Key: POOL-150
> URL: https://issues.apache.org/jira/browse/POOL-150
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Java 5
>Reporter: VIJAY KUMAR
> Fix For: 2.0
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> GenericKeyedObjectPool.preparePool doesnot throw an exception if supplied
> factory is null.
> GenericKeyedObjectPool.preparePool invokes ensureMinIdle() if
> populateImmediately is true and GenericKeyedObjectPool.ensureMinIdle()
> invokes GenericKeyedObjectPool.addObject() which throws an
> IllegalStateException if factory is null but this exception does not throw
> further in GenericKeyedObjectPool.preparePool.
> Catch block of GenericKeyedObjectPool..preparePool is empty.
> public synchronized void preparePool(Object key, boolean populateImmediately)
> {
> ObjectQueue pool = (ObjectQueue)(_poolMap.get(key));
> System.out.println(this.getClass().getName()+".preparePool() pool
> ["+pool +"]");
> if (null == pool) {
> pool = new ObjectQueue();
> _poolMap.put(key,pool);
> _poolList.add(key);
> }
> if (populateImmediately) {
> try {
> // Create the pooled objects
> System.out.println(this.getClass().getName()+".preparePool()
> Create the pooled objects ");
> ensureMinIdle(key);
> }
> catch (Exception e) {
> //Do nothing
> }
> }
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (BEANUTILS-340) Property with getter from generic interface returns wrong readMethod/propertyType on Linux environment
[
https://issues.apache.org/jira/browse/BEANUTILS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048659#comment-13048659
]
Travis Schneeberger commented on BEANUTILS-340:
---
BTW. I see that this jira is marked "LATER THAN 1.8.4". Since there is a
working patch (which includes unit tests) could we get this included in the
1.8.4 release?
> Property with getter from generic interface returns wrong
> readMethod/propertyType on Linux environment
> --
>
> Key: BEANUTILS-340
> URL: https://issues.apache.org/jira/browse/BEANUTILS-340
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.8.0-BETA
> Environment: ==Works correctly in==
> Windows XP
> java version "1.5.0_12"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
> Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode)
> ==Fails in==
> Linux 2.6.27-gentoo-r8 #6 SMP Thu Feb 5 19:18:16 MST 2009 i686 06/17
> GenuineIntel GNU/Linux
> java version "1.5.0_17"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_17-b04)
> Java HotSpot(TM) Server VM (build 1.5.0_17-b04, mixed mode)
>Reporter: Dave Lindquist
>Priority: Minor
> Fix For: LATER THAN 1.8.4
>
> Attachments: jira_340.patch, jira_340_new.patch
>
>
> PropertyUtils.getPropertyDescriptors is returning the wrong readMethod (and
> thus the wrong property type) when a method is implemented from a genericized
> interface, but only on some environments. This seems to work on Windows, but
> fails on Linux. (Compile environment does not matter, runtime environment
> does seem to matter.)
> Take the following test class:
> {code}
> public class Testing
> {
> public static void main(String[] args) throws Exception
> {
> for(PropertyDescriptor desc :
> PropertyUtils.getPropertyDescriptors(Test2.class))
> {
> if(desc.getName().equals("something"))
> {
> System.out.println(desc.getName() + "\t" +
> desc.getPropertyType() + "\t" + desc.getReadMethod() + "\t" +
> desc.getReadMethod().isSynthetic() + "\t" + desc.getReadMethod().isBridge());
> }
> }
> }
>
> // An interface with generics, and with getter and setter defined
> 'generically'.
> public static interface Test
> {
> public T getSomething();
>
> public void setSomething(T something);
> }
>
> // A concrete class using a specific genericization of the interface
> (Long), with getter and setter implemented appropriately.
> public static class Test2 implements Test
> {
> public Long getSomething()
> {
> return(null);
> }
>
> public void setSomething(Long something)
> {
>
> }
> }
> }
> {code}
> When run on Windows XP, and working correctly, this prints:
> something class java.lang.Longpublic java.lang.Long
> Testing$Test2.getSomething() false false
> indicating that it got the 'long' version of the method, and that this method
> is NOT synthetic or a bridge method.
> However, when run on Linux, this prints:
> something class java.lang.Number public volatile java.lang.Number
> Testing$Test2.getSomething() truetrue
> which is the signature from the interface, and is marked with both synthetic
> and bridge, indicating that this is not the 'real' method, but the
> compiler-created method due to generics.
> I think that it should be ignoring the 'synthetic/bridge' method auto-created
> by the compiler, but I'm not sure why it is environment-dependent. Perhaps
> the environment somehow controls the method definition order? (At runtime,
> not compile time, obviously.)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (BEANUTILS-340) Property with getter from generic interface returns wrong readMethod/propertyType on Linux environment
[
https://issues.apache.org/jira/browse/BEANUTILS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046548#comment-13046548
]
Travis Schneeberger edited comment on BEANUTILS-340 at 6/13/11 5:07 PM:
I've included a patch file which works around the java.bean.Introspector bug.
Please consider incorporating this patch in your next release. Here are a few
details:
I searched for all the places commons-beanutils interfaces with the
Introspector api to retrieve PropertyDescriptors. Then I checked each read &
write method to see if it was synthetic or bridge and if it is I attempt to
replace it with the non synthetic/bridge version.
This patch is java 1.3 compatible since I'm using reflection to check if a
method is synthetic or bridge.
I've also included a unit test. I've had to comment out the test case since it
relies on java 1.5+ features.
This patch was generated against the 1.8.3 release. Please let me know if there
is anything else I can do to help this get included in the next release of
beanutils.
was (Author: leo.herbie):
I've included a patch file which works around the java.bean.Introspector
bug. Please consider incorporating this patch in your next release. Here are
a few details:
I searched for all the places commons-beanutils interfaces with the
Introspector api to retrieve PropertyDescriptors. Then I checked each read &
write method to see if it was synthetic or bridge and if it is I attempt to
replace it with the non synthetic/bridge version.
Note: doing it on the write method may not be necessary since covariant returns
doesn't affect it but I did it anyway b/c I'm not familiar with all the places
java uses synthetic/bridge methods
This patch is java 1.3 compatible since I'm using reflection to check if a
method is synthetic or bridge.
I've also included a unit test. I've had to comment out the test case since it
relies on java 1.5+ features.
This patch was generated against the 1.8.3 release. Please let me know if there
is anything else I can do to help this get included in the next release of
beanutils.
> Property with getter from generic interface returns wrong
> readMethod/propertyType on Linux environment
> --
>
> Key: BEANUTILS-340
> URL: https://issues.apache.org/jira/browse/BEANUTILS-340
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.8.0-BETA
> Environment: ==Works correctly in==
> Windows XP
> java version "1.5.0_12"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
> Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode)
> ==Fails in==
> Linux 2.6.27-gentoo-r8 #6 SMP Thu Feb 5 19:18:16 MST 2009 i686 06/17
> GenuineIntel GNU/Linux
> java version "1.5.0_17"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_17-b04)
> Java HotSpot(TM) Server VM (build 1.5.0_17-b04, mixed mode)
>Reporter: Dave Lindquist
>Priority: Minor
> Fix For: LATER THAN 1.8.4
>
> Attachments: jira_340.patch, jira_340_new.patch
>
>
> PropertyUtils.getPropertyDescriptors is returning the wrong readMethod (and
> thus the wrong property type) when a method is implemented from a genericized
> interface, but only on some environments. This seems to work on Windows, but
> fails on Linux. (Compile environment does not matter, runtime environment
> does seem to matter.)
> Take the following test class:
> {code}
> public class Testing
> {
> public static void main(String[] args) throws Exception
> {
> for(PropertyDescriptor desc :
> PropertyUtils.getPropertyDescriptors(Test2.class))
> {
> if(desc.getName().equals("something"))
> {
> System.out.println(desc.getName() + "\t" +
> desc.getPropertyType() + "\t" + desc.getReadMethod() + "\t" +
> desc.getReadMethod().isSynthetic() + "\t" + desc.getReadMethod().isBridge());
> }
> }
> }
>
> // An interface with generics, and with getter and setter defined
> 'generically'.
> public static interface Test
> {
> public T getSomething();
>
> public void setSomething(T something);
> }
>
> // A concrete class using a specific genericization of the interface
> (Long), with getter and setter implemented appropriately.
> public static class Test2 implements Test
> {
> public Long getSomething()
> {
> return(null);
> }
>
> public void setSomething(Long somethin
[jira] [Commented] (BEANUTILS-340) Property with getter from generic interface returns wrong readMethod/propertyType on Linux environment
[
https://issues.apache.org/jira/browse/BEANUTILS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048657#comment-13048657
]
Travis Schneeberger commented on BEANUTILS-340:
---
If anyone would like a patched version of commons-beanutils there is one
located @
http://nexus.kuali.org/content/groups/public/org/kuali/commons/commons-beanutils/1.8.3-kuali-SNAPSHOT/
This jar contains my patch that I've attached to this jira and is based off the
1.8.3 release. Note that the maven coordinates of this artifact are
"org.kuali.commons:commons-beanutils:1.8.3-kuali-SNAPSHOT" This is currently
a SNAPSHOT version but will be a final release in a few months if this jira
isn't addressed before then. Enjoy!
> Property with getter from generic interface returns wrong
> readMethod/propertyType on Linux environment
> --
>
> Key: BEANUTILS-340
> URL: https://issues.apache.org/jira/browse/BEANUTILS-340
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.8.0-BETA
> Environment: ==Works correctly in==
> Windows XP
> java version "1.5.0_12"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
> Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode)
> ==Fails in==
> Linux 2.6.27-gentoo-r8 #6 SMP Thu Feb 5 19:18:16 MST 2009 i686 06/17
> GenuineIntel GNU/Linux
> java version "1.5.0_17"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_17-b04)
> Java HotSpot(TM) Server VM (build 1.5.0_17-b04, mixed mode)
>Reporter: Dave Lindquist
>Priority: Minor
> Fix For: LATER THAN 1.8.4
>
> Attachments: jira_340.patch, jira_340_new.patch
>
>
> PropertyUtils.getPropertyDescriptors is returning the wrong readMethod (and
> thus the wrong property type) when a method is implemented from a genericized
> interface, but only on some environments. This seems to work on Windows, but
> fails on Linux. (Compile environment does not matter, runtime environment
> does seem to matter.)
> Take the following test class:
> {code}
> public class Testing
> {
> public static void main(String[] args) throws Exception
> {
> for(PropertyDescriptor desc :
> PropertyUtils.getPropertyDescriptors(Test2.class))
> {
> if(desc.getName().equals("something"))
> {
> System.out.println(desc.getName() + "\t" +
> desc.getPropertyType() + "\t" + desc.getReadMethod() + "\t" +
> desc.getReadMethod().isSynthetic() + "\t" + desc.getReadMethod().isBridge());
> }
> }
> }
>
> // An interface with generics, and with getter and setter defined
> 'generically'.
> public static interface Test
> {
> public T getSomething();
>
> public void setSomething(T something);
> }
>
> // A concrete class using a specific genericization of the interface
> (Long), with getter and setter implemented appropriately.
> public static class Test2 implements Test
> {
> public Long getSomething()
> {
> return(null);
> }
>
> public void setSomething(Long something)
> {
>
> }
> }
> }
> {code}
> When run on Windows XP, and working correctly, this prints:
> something class java.lang.Longpublic java.lang.Long
> Testing$Test2.getSomething() false false
> indicating that it got the 'long' version of the method, and that this method
> is NOT synthetic or a bridge method.
> However, when run on Linux, this prints:
> something class java.lang.Number public volatile java.lang.Number
> Testing$Test2.getSomething() truetrue
> which is the signature from the interface, and is marked with both synthetic
> and bridge, indicating that this is not the 'real' method, but the
> compiler-created method due to generics.
> I think that it should be ignoring the 'synthetic/bridge' method auto-created
> by the compiler, but I'm not sure why it is environment-dependent. Perhaps
> the environment somehow controls the method definition order? (At runtime,
> not compile time, obviously.)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-416) Increasing sub-negotiation message holder array size
[ https://issues.apache.org/jira/browse/NET-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhijeet Gaikwad updated NET-416: - Attachment: NTLM_Auth_Support.patch __suboption[] array size increased to 512. As NTLM packet size sent by server is more than 256 bytes. If increased, Telnet Client can be used to support NTLM Authnetication from Linux as well as Windows machine. > Increasing sub-negotiation message holder array size > > > Key: NET-416 > URL: https://issues.apache.org/jira/browse/NET-416 > Project: Commons Net > Issue Type: Improvement > Components: Telnet >Affects Versions: 3.0, 3.0.1 > Environment: Linux >Reporter: Abhijeet Gaikwad > Labels: authentication, linux, ntlm, telnet > Attachments: NTLM_Auth_Support.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > I am trying to achieve NTLM Authentication by extending the Telnet option > handler. The challenge sent by the telnet server is greater than 256 bytes, > but currently the __suboption[] array in TelnetInputStream supports only a > 256 bytes message. If I increase the size of the array to 512, I am able to > achieve NTLM Authentication. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
