[jira] [Updated] (SANDBOX-400) Switch the Base graph implementation underlaying data structures to the thread safe version
[ https://issues.apache.org/jira/browse/SANDBOX-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi updated SANDBOX-400: --- Summary: Switch the Base graph implementation underlaying data structures to the thread safe version (was: Switch the Base graph implementation underlaying data structures thread safegr) Switch the Base graph implementation underlaying data structures to the thread safe version --- Key: SANDBOX-400 URL: https://issues.apache.org/jira/browse/SANDBOX-400 Project: Commons Sandbox Issue Type: Improvement Components: Graph Reporter: Simone Tripodi Assignee: Simone Tripodi Even if it won't help on shielding from race conditions, switching to Concurrent* version of adapted data structures would make current Graph implementations more consistent when working in a multi-thread environment -- 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] [Created] (SANDBOX-400) Switch the Base graph implementation underlaying data structures thread safegr
Switch the Base graph implementation underlaying data structures thread safegr -- Key: SANDBOX-400 URL: https://issues.apache.org/jira/browse/SANDBOX-400 Project: Commons Sandbox Issue Type: Improvement Components: Graph Reporter: Simone Tripodi Assignee: Simone Tripodi Even if it won't help on shielding from race conditions, switching to Concurrent* version of adapted data structures would make current Graph implementations more consistent when working in a multi-thread environment -- 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] (SANDBOX-400) Switch the Base graph implementation underlying data structures to the thread safe version
[ https://issues.apache.org/jira/browse/SANDBOX-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi updated SANDBOX-400: --- Summary: Switch the Base graph implementation underlying data structures to the thread safe version (was: Switch the Base graph implementation underlaying data structures to the thread safe version) Switch the Base graph implementation underlying data structures to the thread safe version -- Key: SANDBOX-400 URL: https://issues.apache.org/jira/browse/SANDBOX-400 Project: Commons Sandbox Issue Type: Improvement Components: Graph Reporter: Simone Tripodi Assignee: Simone Tripodi Even if it won't help on shielding from race conditions, switching to Concurrent* version of adapted data structures would make current Graph implementations more consistent when working in a multi-thread environment -- 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] (SANDBOX-400) Switch the Base graph implementation underlying data structures to the thread safe version
[ https://issues.apache.org/jira/browse/SANDBOX-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-400. Resolution: Fixed fixed on [r1296087|http://svn.apache.org/viewvc?rev=1296087view=rev] Switch the Base graph implementation underlying data structures to the thread safe version -- Key: SANDBOX-400 URL: https://issues.apache.org/jira/browse/SANDBOX-400 Project: Commons Sandbox Issue Type: Improvement Components: Graph Reporter: Simone Tripodi Assignee: Simone Tripodi Even if it won't help on shielding from race conditions, switching to Concurrent* version of adapted data structures would make current Graph implementations more consistent when working in a multi-thread environment -- 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] [Created] (SANDBOX-401) [BeanUtils2] Performance improvement: store hash code of AccessibleObjectDescriptor as member variable
[BeanUtils2] Performance improvement: store hash code of AccessibleObjectDescriptor as member variable -- Key: SANDBOX-401 URL: https://issues.apache.org/jira/browse/SANDBOX-401 Project: Commons Sandbox Issue Type: Improvement Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter As discussed on the ML, we should store the hash code of AccessibleObjectDescriptor in a private member variable after it has been computed the first time. The computed value can be returned on subsequent invocations. Since AccessibleObjectDescriptor is immutable (all of its fields are final) the hash code can never change, once an AccessibleObjectDescriptor has been initialized. -- 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] (SANDBOX-401) [BeanUtils2] Performance improvement: store hash code of AccessibleObjectDescriptor as member variable
[ https://issues.apache.org/jira/browse/SANDBOX-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated SANDBOX-401: Attachment: SANDBOX-401.txt I've attached a patch. TIA for reviewing ;) Benedikt [BeanUtils2] Performance improvement: store hash code of AccessibleObjectDescriptor as member variable -- Key: SANDBOX-401 URL: https://issues.apache.org/jira/browse/SANDBOX-401 Project: Commons Sandbox Issue Type: Improvement Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Attachments: SANDBOX-401.txt As discussed on the ML, we should store the hash code of AccessibleObjectDescriptor in a private member variable after it has been computed the first time. The computed value can be returned on subsequent invocations. Since AccessibleObjectDescriptor is immutable (all of its fields are final) the hash code can never change, once an AccessibleObjectDescriptor has been initialized. -- 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] [Created] (DAEMON-244) prunsrv does not propagate exit code
prunsrv does not propagate exit code Key: DAEMON-244 URL: https://issues.apache.org/jira/browse/DAEMON-244 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.10 Environment: MS Windows Reporter: Peter Ehrbar In order to perform recovery actions (e.g. restart service) the Windows Service Controller needs to detect abnormal program terminations (failures). The Service controller detects a failure if either the service process crashes or the process terminates with a non-zero exit code. For my Java server application I want to define recovery actions for the following conditions: 1) VM crash 2) Error was thrown (e.g. OutOfMemoryError) 3) System.exit() with non-zero exit code When using prunsrv as a wrapper, I observe the following behaviour: 1) VM crash is detected only when StartMode=jvm, otherwise the Service Controller ignores the failure situation 2) When an Error is thrown and StartMode=jvm, prunsrv does not terminate but seems to hang. Therefore, the Service Controller is not aware of the failure. For other StartModes, prunsrv terminates, but the Service Controller does not detect the failure. 3) When System.exit(42) is called, prunsrv terminates but the Service Controller does not detect the non-zero exit code. This applies for all StartModes. It seems to me as if prunsrv always terminates with exit code zero. But I expect the following behaviour: 1) VM crash with StartMode=jvm - OK as it is now, but with other StartModes, prunsrv should terminate with a non-zero exit code in order to indicate the abnormal termination. 2) When an Error is thrown, prunsrv should terminate with a non-zero exit code in order to indicate the abnormal termination. 3) When System.exit() is called, prunsrv should terminate with the exit code passed to System.exit() (transparent behaviour), in order to let the application indicate a failure situation. With the current behaviour, it is not possible to let the Windows Service Controller perform recovery actions. -- 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] (FILEUPLOAD-195) Error reading the file size larger than 2 gb
[ https://issues.apache.org/jira/browse/FILEUPLOAD-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220848#comment-13220848 ] Philip Helger commented on FILEUPLOAD-195: -- Duplicate of FILEUPLOAD-188 Error reading the file size larger than 2 gb Key: FILEUPLOAD-195 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-195 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2.1, 1.2.2 Reporter: Juliano Alves Priority: Minor Error reading bytes from the file sent via servlet when it has a size larger than 2GB, it puts the total file size is negative. -- 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] [Created] (FILEUPLOAD-205) FileCleaningTracker Repeaer thread not ended
FileCleaningTracker Repeaer thread not ended Key: FILEUPLOAD-205 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-205 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2.2 Environment: Tomcat 6, JDK 1.6.0_21 Reporter: Philip Helger When using a new FileCleaningTracker and calling exitWhenFinished upon WebApp context deinitialization the thread is not shutdown. This can be easily reproduced by using Tomcat's Find leaks funcitonality. -- 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] (FILEUPLOAD-205) FileCleaningTracker Reaper thread not ended
[ https://issues.apache.org/jira/browse/FILEUPLOAD-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Helger updated FILEUPLOAD-205: - Summary: FileCleaningTracker Reaper thread not ended (was: FileCleaningTracker Repeaer thread not ended) FileCleaningTracker Reaper thread not ended --- Key: FILEUPLOAD-205 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-205 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2.2 Environment: Tomcat 6, JDK 1.6.0_21 Reporter: Philip Helger When using a new FileCleaningTracker and calling exitWhenFinished upon WebApp context deinitialization the thread is not shutdown. This can be easily reproduced by using Tomcat's Find leaks funcitonality. -- 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] (JXPATH-152) Concurrent access on hashmap of JXPathIntrospector
[
https://issues.apache.org/jira/browse/JXPATH-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220937#comment-13220937
]
Naozumi Taromaru commented on JXPATH-152:
-
Collections.synchronizedMap is thread safe method.
However, since these HashMap are referred to frequently,
it becomes a bottleneck by the method of synchronizedMap's lock
in a multi-core CPU (or multi CPU) environment.
I recommend correcting by one of the following methods.
These methods can perform Map#get concurrently.
* Since byInterface resembles byClass, byInterface omits.
Before correction: (Before #1293412 modification.)
private static HashMap byClass = new HashMap();
...
byClass.put(...);
...
beanInfo = (JXPathBeanInfo) byClass.get(...);
correction method 1: (Easy)
private static Map byClass = ConcurrentHashMap();
...
byClass.put(...);
...
beanInfo = (JXPathBeanInfo) byClass.get(...);
* ConcurrentHashMap : java.util.concurrent.ConcurrentHashMap (JDK5 or later)
The feature of the method 1:
* Unlike JXPath-1.3, required JDK5 or later.
* Unlike JXPath-1.3, if key or value is null, NullPointerException occur.
(If you maintain the compatibility when key or value is null value, please see
method 2.)
correction method 2: (Specification is full compatible)
private static HashMap byClass = new HashMap();
private static final ReentrantReadWriteLock byClassReadWriteLock = new
ReentrantReadWriteLock();
private static final Lock byClassReadLock = byClassReadWriteLock.readLock();
private static final Lock byClassWriteLock = byClassReadWriteLock.writeLock();
...
byClassWriteLock.lock();
try {
byClass.put(...);
} finally {
byClassWriteLock.unlock();
}
...
byClassReadLock.lock();
try {
beanInfo = (JXPathBeanInfo) byClass.get(...);
} finally {
byClassReadLock.unlock();
}
* ReentrantReadWriteLock : java.util.concurrent.locks.ReentrantReadWriteLock
(JDK5 or later)
* Lock : java.util.concurrent.locks.Lock (JDK5 or later)
please see
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html
RWDictionary example.
The feature of the method 2:
* Unlike JXPath-1.3, required JDK5 or later.
* Like JXPath-1.3, null can be used for key or value.
correction method 3: (JDK1.3 compatible. but contrary to usage.)
private static HashMap byClass = new HashMap();
...
synchronized (byClass) {
byClass.put(...);
}
...
beanInfo = (JXPathBeanInfo) byClass.get(...);
if (beanInfo == null) { // not mapping, null mapping, or when byClass is being
expanded.
synchronized (byClass) {
beanInfo = (JXPathBeanInfo) byClass.get(...);
}
}
* Although it is contrary to usage,
this method can be used if it is java.util.HashMap,
using method are put get only.
(At least in the case of Sun(Oracle) JDK.)
The feature of the method 3:
* Like JXPath-1.3, JDK1.3 compatible.
* Like JXPath-1.3, null can be used for key or value.
* It is contrary to the following description of HashMap's API document.
If multiple threads access this map concurrently,
and at least one of the threads modifies the map structurally,
it must be synchronized externally.
(http://docs.oracle.com/javase/1.5.0/docs/api/java/util/HashMap.html)
Concurrent access on hashmap of JXPathIntrospector
--
Key: JXPATH-152
URL: https://issues.apache.org/jira/browse/JXPATH-152
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.3
Environment: Java5, Windows/AIX
Reporter: pleutre
Assignee: Matt Benson
Priority: Minor
Fix For: 1.4
Original Estimate: 24h
Remaining Estimate: 24h
JXPathIntrospector.registerDynamicClass method can be called in static part
of classes.
If two classes A B try to registerDynamicClass in the same time a
concurrent access exception can append on hashmap of JXPathIntrospector.
Replace hashmap by concurrent hashmap or synchronized access to these
hashmaps.
--
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] [Created] (NET-448) Self signed cert or ca not installed on client but FTPS still works
Self signed cert or ca not installed on client but FTPS still works --- Key: NET-448 URL: https://issues.apache.org/jira/browse/NET-448 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.1, 2.0 Environment: client: Windows SP sp4, jdk 1.6.0_24 server: Linux 2.6.32-220.4.2.el6.i686 running vsFTPd 2.2.2 apache lib: commons-net-2.0.jar or commons-net-3.1.jar or commons-net-2.0-jdk14.jar (from zehon) Reporter: Deepak Pant Priority: Trivial I am using vsftpd ftp server on centos with our own self signed root ca certificate. I have not installed the self signed root certificate on the client machine. Neither am I setting the Trust Manager on the FTPSClient object, using X509TrustManager instance pointing to my physical cert file. But I am still able to use the FTPSClient bundled in any of the following jar file and send/receive the files. commons-net-2.0.jar commons-net-3.1.jar commons-net-2.0-jdk14.jar (from zehon) I was expecting that I will have to either install the self signed root ca on the client machine Or set Trust Manager etc. Can you please explain the behavior? -- 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-447) Commons-net version 2.0 jar unable to download files of time stamp 29th February.
[ https://issues.apache.org/jira/browse/NET-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221064#comment-13221064 ] Sebb commented on NET-447: -- Have you tried with the current release, which is 3.1? Should be a drop-in replacement for 2.0. 2.0 is very out of date. Commons-net version 2.0 jar unable to download files of time stamp 29th February. -- Key: NET-447 URL: https://issues.apache.org/jira/browse/NET-447 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 2.0 Environment: Windows Server 2003. Reporter: Jeevesh Mishra Labels: patch Fix For: 2.0 Original Estimate: 1,304h Remaining Estimate: 1,304h When FTP Client of commons-net.jar (version 2.0) tries to get the list of files on FTP server then for the files of time stamp date 29th Feb 2012 it returns null value and in turn throws Null pointer Exception. Because the files are read in date viz sequence, thus it reads the file names correctly till 28th Feb but as soon as it gets a file of time-stamp date 29th it throws Null Pointer Exception and all the files after that are not read. Also its been mentioned in the case mentioned at following url that this issue has been resolved in version 1.5 : https://issues.apache.org/jira/browse/NET-188 Thus ideally such solution would have been included in all later versions. We would require a patch to resolve this. Also for your information we are using Wicket frame work. Do you forsee any Jar conflict with commons-net version 2.0 in such scenario. We are also attaching the Exceptions trace as follows: ERROR [01 Mar 2012 13:37:33] com.nordea.npdb.datafeed.sp.timertasks.DataFeedSpUsStockReportFtpImpl.execute(DataFeedSpUsStockReportFtpImpl.java:48) : Timer_DataFeedSpUsStockReportFtp [FAILED] java.lang.NullPointerException at com.nordea.npdb.bl.facade.DataFeedServiceImpl.saveFtpFetcherFiles(DataFeedServiceImpl.java:108)[NPDB-core-0-SNAPSHOT.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.6.0_24] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)[:1.6.0_24] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)[:1.6.0_24] at java.lang.reflect.Method.invoke(Method.java:597)[:1.6.0_24] at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)[spring-aop-3.0.3.RELEASE.jar:3.0.3.RELEASE] at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)[spring-aop-3.0.3.RELEASE.jar:3.0.3.RELEASE] at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)[spring-aop-3.0.3.RELEASE.jar:3.0.3.RELEASE] at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)[spring-tx-3.0.3.RELEASE.jar:3.0.3.RELEASE] at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)[spring-aop-3.0.3.RELEASE.jar:3.0.3.RELEASE] at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)[spring-aop-3.0.3.RELEASE.jar:3.0.3.RELEASE] at $Proxy105.saveFtpFetcherFiles(Unknown Source)[:] at com.nordea.npdb.datafeed.sp.timertasks.DataFeedSpUsStockReportFtpImpl.execute(DataFeedSpUsStockReportFtpImpl.java:32)[NPDB-core-0-SNAPSHOT.jar:] at com.nordea.npdb.infrastructure.batch.OldBatchJob.execute(OldBatchJob.java:12)[NPDB-core-0-SNAPSHOT.jar:] at org.springframework.batch.core.step.tasklet.TaskletStep$ChunkTransactionCallback.doInTransaction(TaskletStep.java:386)[spring-batch-core-2.1.7.RELEASE.jar:] at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130)[spring-tx-3.0.3.RELEASE.jar:3.0.3.RELEASE] at org.springframework.batch.core.step.tasklet.TaskletStep$2.doInChunkContext(TaskletStep.java:264)[spring-batch-core-2.1.7.RELEASE.jar:] at org.springframework.batch.core.scope.context.StepContextRepeatCallback.doInIteration(StepContextRepeatCallback.java:76)[spring-batch-core-2.1.7.RELEASE.jar:] at org.springframework.batch.repeat.support.RepeatTemplate.getNextResult(RepeatTemplate.java:367)[spring-batch-infrastructure-2.1.7.RELEASE.jar:] at org.springframework.batch.repeat.support.RepeatTemplate.executeInternal(RepeatTemplate.java:214)[spring-batch-infrastructure-2.1.7.RELEASE.jar:] at org.springframework.batch.repeat.support.RepeatTemplate.iterate(RepeatTemplate.java:143)[spring-batch-infrastructure-2.1.7.RELEASE.jar:] at
[jira] [Resolved] (NET-442) StringIndexOutOfBoundsException: String index out of range: -1 if server respond with root is current directory
[
https://issues.apache.org/jira/browse/NET-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-442.
--
Resolution: Fixed
Fix Version/s: 3.2
StringIndexOutOfBoundsException: String index out of range: -1 if server
respond with root is current directory
---
Key: NET-442
URL: https://issues.apache.org/jira/browse/NET-442
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.0.1
Environment: Ubuntu linux 11.04
Reporter: Andrea Selva
Fix For: 3.2
I've an ftp server that at the pwd request responds with |257 root is
current directory.| without any double quotes present and the lib gives up
with this exception:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1949)
at
org.apache.commons.net.ftp.FTPClient.__parsePathname(FTPClient.java:469)
at
org.apache.commons.net.ftp.FTPClient.printWorkingDirectory(FTPClient.java:2374)
Probably it's only needed a check in __parsePathname
private String __parsePathname(String reply)
{
int begin, end;
begin = reply.indexOf('') + 1;
end = reply.indexOf('', begin);
if (begin == -1 end == -1)
{
return reply;
}
return reply.substring(begin, end);
}
--
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] (COMPRESS-181) Tar files created by AIX native tar, and which contain symlinks, cannot be read by TarArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-181:
Affects Version/s: (was: 1.4)
Tar files created by AIX native tar, and which contain symlinks, cannot be
read by TarArchiveInputStream
Key: COMPRESS-181
URL: https://issues.apache.org/jira/browse/COMPRESS-181
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.2, 1.3
Environment: AIX 5.3
Reporter: Robert Clark
Fix For: 1.4
Attachments: simple-aix-native-tar.tar
A simple tar file created on AIX using the native ({{/usr/bin/tar}} tar
utility) *and* which contains a symbolic link, cannot be loaded by
TarArchiveInputStream:
{noformat}
java.io.IOException: Error detected parsing the header
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:201)
at Extractor.extract(Extractor.java:13)
at Extractor.main(Extractor.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.Main.runBuild(Main.java:809)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
Caused by: java.lang.IllegalArgumentException: Invalid byte 0 at offset 0 in
'{NUL}1722000726 ' len=12
at
org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:99)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:819)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.init(TarArchiveEntry.java:314)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:199)
... 29 more
{noformat}
Tested with 1.2 and the 1.4 nightly build from Feb 23
({{Implementation-Build: trunk@r1292625; 2012-02-23 03:20:30+}})
--
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] (COMPRESS-181) Tar files created by AIX native tar, and which contain symlinks, cannot be read by TarArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-181.
-
Resolution: Fixed
Fix Version/s: 1.4
fixed with svn revision 1296420
Thanks for the testcase
Tar files created by AIX native tar, and which contain symlinks, cannot be
read by TarArchiveInputStream
Key: COMPRESS-181
URL: https://issues.apache.org/jira/browse/COMPRESS-181
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.2, 1.3
Environment: AIX 5.3
Reporter: Robert Clark
Fix For: 1.4
Attachments: simple-aix-native-tar.tar
A simple tar file created on AIX using the native ({{/usr/bin/tar}} tar
utility) *and* which contains a symbolic link, cannot be loaded by
TarArchiveInputStream:
{noformat}
java.io.IOException: Error detected parsing the header
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:201)
at Extractor.extract(Extractor.java:13)
at Extractor.main(Extractor.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.Main.runBuild(Main.java:809)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
Caused by: java.lang.IllegalArgumentException: Invalid byte 0 at offset 0 in
'{NUL}1722000726 ' len=12
at
org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:99)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:819)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.init(TarArchiveEntry.java:314)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:199)
... 29 more
{noformat}
Tested with 1.2 and the 1.4 nightly build from Feb 23
({{Implementation-Build: trunk@r1292625; 2012-02-23 03:20:30+}})
--
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] [Created] (COLLECTIONS-395) Request for UnBoundedLRUMap implementation with extra get method
Request for UnBoundedLRUMap implementation with extra get method Key: COLLECTIONS-395 URL: https://issues.apache.org/jira/browse/COLLECTIONS-395 Project: Commons Collections Issue Type: Wish Components: Map Affects Versions: Nightly Builds Reporter: David Hawthorne Priority: Minor I've created an UnBoundedLRUMap implementation (based off of BoundedLRUMap) using the svn tree at version 3.3, and this has come in so handy that it makes sense to suggest it to the masters in charge of the collections framework. One tweak I made to the copy we're using is an extra get method that takes two arguments: key and boolean. The boolean determines whether or not the MRU item is updated, so we can make requests into the map that do *not* affect order. This is sometimes necessary in real world environments where you do not want a data structure with LRU-only accesses. This implementation would solve the main problem we have with using the jdk's LinkedHashMap LRU implementation. -- 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] [Reopened] (SANDBOX-400) Switch the Base graph implementation underlying data structures to the thread safe version
[ https://issues.apache.org/jira/browse/SANDBOX-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi reopened SANDBOX-400: looks like the Concurrent data structures downgraded the implementations, rolling back the modifications and creating the concurrent separated version Switch the Base graph implementation underlying data structures to the thread safe version -- Key: SANDBOX-400 URL: https://issues.apache.org/jira/browse/SANDBOX-400 Project: Commons Sandbox Issue Type: Improvement Components: Graph Reporter: Simone Tripodi Assignee: Simone Tripodi Even if it won't help on shielding from race conditions, switching to Concurrent* version of adapted data structures would make current Graph implementations more consistent when working in a multi-thread environment -- 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] [Created] (COLLECTIONS-396) New DynamicIterator class.
New DynamicIterator class.
--
Key: COLLECTIONS-396
URL: https://issues.apache.org/jira/browse/COLLECTIONS-396
Project: Commons Collections
Issue Type: New Feature
Components: Iterator
Environment: Java 1.5 or greater
Reporter: Jeff Rodriguez
Priority: Minor
Attachments: DynamicIterator.java, DynamicIteratorTest.java
I would like to submit my DynamicIterator class for inclusion in Commons
Collections.
Description from JavaDoc:
Iterates over the elements of an inner iterator provided by {@link
#nextIterator()} Once the inner iterator's {@link Iterator#hasNext()} method
returns false, {@link #nextIterator()} will be called to obtain another
iterator, and so on until {@link #nextIterator()} returns null.
The use case I had in mind for this class was the paged web service. A web
service returns a list of results, which are paginated. Once a page's results
are exhausted, {@link #nextIterator()} can go fetch the next page for iteration.
This class, and accompanying test class are my original works. I have released
them into the public domain, feel free to use the appropriate ASF license.
--
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] (COLLECTIONS-396) New DynamicIterator class.
[
https://issues.apache.org/jira/browse/COLLECTIONS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Rodriguez updated COLLECTIONS-396:
---
Attachment: DynamicIteratorTest.java
DynamicIterator.java
Class and test case.
New DynamicIterator class.
--
Key: COLLECTIONS-396
URL: https://issues.apache.org/jira/browse/COLLECTIONS-396
Project: Commons Collections
Issue Type: New Feature
Components: Iterator
Environment: Java 1.5 or greater
Reporter: Jeff Rodriguez
Priority: Minor
Labels: dynamic, iterator, new
Attachments: DynamicIterator.java, DynamicIteratorTest.java
Original Estimate: 1h
Remaining Estimate: 1h
I would like to submit my DynamicIterator class for inclusion in Commons
Collections.
Description from JavaDoc:
Iterates over the elements of an inner iterator provided by {@link
#nextIterator()} Once the inner iterator's {@link Iterator#hasNext()} method
returns false, {@link #nextIterator()} will be called to obtain another
iterator, and so on until {@link #nextIterator()} returns null.
The use case I had in mind for this class was the paged web service. A web
service returns a list of results, which are paginated. Once a page's results
are exhausted, {@link #nextIterator()} can go fetch the next page for
iteration.
This class, and accompanying test class are my original works. I have
released them into the public domain, feel free to use the appropriate ASF
license.
--
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] (COLLECTIONS-396) New DynamicIterator class.
[
https://issues.apache.org/jira/browse/COLLECTIONS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Rodriguez updated COLLECTIONS-396:
---
Description:
I would like to submit my DynamicIterator class for inclusion in Commons
Collections.
Description from JavaDoc:
Iterates over the elements of an inner iterator provided by nextIterator() Once
the inner iterator's hasNext() method returns false, nextIterator() will be
called to obtain another iterator, and so on until nextIterator() returns null.
The use case I had in mind for this class was the paged web service. A web
service returns a list of results, which are paginated. Once a page's results
are exhausted, {@link #nextIterator()} can go fetch the next page for iteration.
This class, and accompanying test class are my original works. I have released
them into the public domain, feel free to use the appropriate ASF license.
was:
I would like to submit my DynamicIterator class for inclusion in Commons
Collections.
Description from JavaDoc:
Iterates over the elements of an inner iterator provided by {@link
#nextIterator()} Once the inner iterator's {@link Iterator#hasNext()} method
returns false, {@link #nextIterator()} will be called to obtain another
iterator, and so on until {@link #nextIterator()} returns null.
The use case I had in mind for this class was the paged web service. A web
service returns a list of results, which are paginated. Once a page's results
are exhausted, {@link #nextIterator()} can go fetch the next page for iteration.
This class, and accompanying test class are my original works. I have released
them into the public domain, feel free to use the appropriate ASF license.
New DynamicIterator class.
--
Key: COLLECTIONS-396
URL: https://issues.apache.org/jira/browse/COLLECTIONS-396
Project: Commons Collections
Issue Type: New Feature
Components: Iterator
Environment: Java 1.5 or greater
Reporter: Jeff Rodriguez
Priority: Minor
Labels: dynamic, iterator, new
Attachments: DynamicIterator.java, DynamicIteratorTest.java
Original Estimate: 1h
Remaining Estimate: 1h
I would like to submit my DynamicIterator class for inclusion in Commons
Collections.
Description from JavaDoc:
Iterates over the elements of an inner iterator provided by nextIterator()
Once the inner iterator's hasNext() method returns false, nextIterator() will
be called to obtain another iterator, and so on until nextIterator() returns
null.
The use case I had in mind for this class was the paged web service. A web
service returns a list of results, which are paginated. Once a page's results
are exhausted, {@link #nextIterator()} can go fetch the next page for
iteration.
This class, and accompanying test class are my original works. I have
released them into the public domain, feel free to use the appropriate ASF
license.
--
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] (SANDBOX-400) Switch the Base graph implementation underlying data structures to the thread safe version
[ https://issues.apache.org/jira/browse/SANDBOX-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221257#comment-13221257 ] Simone Tripodi commented on SANDBOX-400: tests restored on r1296445 Switch the Base graph implementation underlying data structures to the thread safe version -- Key: SANDBOX-400 URL: https://issues.apache.org/jira/browse/SANDBOX-400 Project: Commons Sandbox Issue Type: Improvement Components: Graph Reporter: Simone Tripodi Assignee: Simone Tripodi Even if it won't help on shielding from race conditions, switching to Concurrent* version of adapted data structures would make current Graph implementations more consistent when working in a multi-thread environment -- 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] [Created] (COMMONSSITE-66) Add support for a commons.release.3 set of properties to offer a 3rd download option
Add support for a commons.release.3 set of properties to offer a 3rd download option -- Key: COMMONSSITE-66 URL: https://issues.apache.org/jira/browse/COMMONSSITE-66 Project: Commons All Issue Type: New Feature Components: Commons Build Plugin Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) Maven home: C:\Java\apache-maven-3.0.4\bin\.. Java version: 1.6.0_31, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_31\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Assignee: Gary D. Gregory Add support for a commons.release.3 set of properties to offer a 3rd download option: commons.release.3.* will be just like commons.release.2.* -- 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] (MATH-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221287#comment-13221287
]
Sebb commented on MATH-746:
---
FastMath still needs a bit of tidying up; for example FastMathCalc is no longer
needed at run-time.
==
Also the final qualifier below needs to be enabled; potentially remove the
disabled code and the boolean.
Or comment out.
private static /* final */ boolean RECOMPUTE_TABLES_AT_RUNTIME = false;
Things to do before releasing 3.0
-
Key: MATH-746
URL: https://issues.apache.org/jira/browse/MATH-746
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Priority: Blocker
Fix For: 3.0
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
(r1291896)
** List of new features (/) (r1292318)
* Create a release branch
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out print statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out print statement in {{SymmLQTest}} (/) (r1244992, removed in
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
** org.apache.commons.math3.distribution.TriangularDistribution (/) (r1292572)
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251
and r1292270)
* Check the user guide
--
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] (MATH-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221292#comment-13221292
]
Sebb commented on MATH-746:
---
Also, vitally important:
We need to make sure that any non-final protected and public variables really
need to be exposed.
They form part of the API that is particularly difficult to change without
breaking binary compatibility.
[They also make thorough testing much harder.]
If the variables are not currently used by subclasses, then consider making
them private; they can always be exposed later if found necessary by adding a
getter/setter.
There are currently rather a lot of these.
Things to do before releasing 3.0
-
Key: MATH-746
URL: https://issues.apache.org/jira/browse/MATH-746
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Priority: Blocker
Fix For: 3.0
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
(r1291896)
** List of new features (/) (r1292318)
* Create a release branch
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out print statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out print statement in {{SymmLQTest}} (/) (r1244992, removed in
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
** org.apache.commons.math3.distribution.TriangularDistribution (/) (r1292572)
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251
and r1292270)
* Check the user guide
--
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] [Created] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods
ResizableDoubleArray is not thread-safe yet has some synch. methods --- Key: MATH-757 URL: https://issues.apache.org/jira/browse/MATH-757 Project: Commons Math Issue Type: Bug Reporter: Sebb ResizableDoubleArray has several synchronised methods, but is not thread-safe, because class variables are not always accessed using the lock. Is the class supposed to be thread-safe? If so, all accesses (read and write) need to be synch. If not, the synch. qualifiers could be dropped. In any case, the protected fields need to be made private. -- 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] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods
[ https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221306#comment-13221306 ] Thomas Neidhart commented on MATH-757: -- As far as I have seen, all methods that change an internal state use a lock in some way: * using synchronized modifier * synchronized(this) block The only methods that are not synchronized just return some (immutable) parameters of the class wrt array expansion strategy. So imo the class should be thread-safe. ResizableDoubleArray is not thread-safe yet has some synch. methods --- Key: MATH-757 URL: https://issues.apache.org/jira/browse/MATH-757 Project: Commons Math Issue Type: Bug Reporter: Sebb ResizableDoubleArray has several synchronised methods, but is not thread-safe, because class variables are not always accessed using the lock. Is the class supposed to be thread-safe? If so, all accesses (read and write) need to be synch. If not, the synch. qualifiers could be dropped. In any case, the protected fields need to be made private. -- 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] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods
[ https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221350#comment-13221350 ] Sebb commented on MATH-757: --- I'm referring to safe publication: because of the Java memory model, changes to variables are not necessarily made visible (published) to other threads unless both the writer and reader use the same lock. [Or the variable is volatile] Furthermore, because the variables are not private, subclasses can change any of the variables without using synch. There seems to be no particular reason for the variables to be anything but private; that would at least prevent external code from changing them arbitrarily. It also looks to me as though there is no need to make some of the variables mutable, as there is a ctor which provides them all. Why not just make them final? This does not seem to be the sort of class that needs runtime config, e.g. via JavaBeans. ResizableDoubleArray is not thread-safe yet has some synch. methods --- Key: MATH-757 URL: https://issues.apache.org/jira/browse/MATH-757 Project: Commons Math Issue Type: Bug Reporter: Sebb ResizableDoubleArray has several synchronised methods, but is not thread-safe, because class variables are not always accessed using the lock. Is the class supposed to be thread-safe? If so, all accesses (read and write) need to be synch. If not, the synch. qualifiers could be dropped. In any case, the protected fields need to be made private. -- 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] (MATH-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221359#comment-13221359
]
Gilles commented on MATH-746:
-
bq. FastMath still needs a bit of tidying up [...]
I've reinstated the final qualifier for RECOMPUTE_TABLES_AT_RUNTIME. But I
don't understand the remark on FastMathCalc. Strictly speaking, it is not
needed, but it is the link to the meaning of the tables contents. It's not
necessary to use FastMath, but it is in order to understand how the tables
are built.
What could have been done was to have FastMathCalc be a class similar to
FastMathLiteralArrays, in the sense that it would contain all the methods
loadExpIntA, ... but each method would, instead of returning a precomputed
array, trigger the necessary computations and populate the array just before
returning it.
What could have been moved away (to the test part of the source tree) are the
support methods that print the arrays.
Both can still be done after releasing 3.0.
Things to do before releasing 3.0
-
Key: MATH-746
URL: https://issues.apache.org/jira/browse/MATH-746
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Priority: Blocker
Fix For: 3.0
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
(r1291896)
** List of new features (/) (r1292318)
* Create a release branch
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out print statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out print statement in {{SymmLQTest}} (/) (r1244992, removed in
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
** org.apache.commons.math3.distribution.TriangularDistribution (/) (r1292572)
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251
and r1292270)
* Check the user guide
--
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] (MATH-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221362#comment-13221362
]
Gilles commented on MATH-746:
-
bq. We need to make sure that any non-final protected and public variables
really need to be exposed.
Do you have a list of those?
Things to do before releasing 3.0
-
Key: MATH-746
URL: https://issues.apache.org/jira/browse/MATH-746
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Priority: Blocker
Fix For: 3.0
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
(r1291896)
** List of new features (/) (r1292318)
* Create a release branch
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out print statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out print statement in {{SymmLQTest}} (/) (r1244992, removed in
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
** org.apache.commons.math3.distribution.TriangularDistribution (/) (r1292572)
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251
and r1292270)
* Check the user guide
--
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] (MATH-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221376#comment-13221376
]
Sebb commented on MATH-746:
---
I've started making a list, see MATH-758.
It's likely to be quite long...
Things to do before releasing 3.0
-
Key: MATH-746
URL: https://issues.apache.org/jira/browse/MATH-746
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Priority: Blocker
Fix For: 3.0
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
(r1291896)
** List of new features (/) (r1292318)
* Create a release branch
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out print statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out print statement in {{SymmLQTest}} (/) (r1244992, removed in
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
** org.apache.commons.math3.distribution.TriangularDistribution (/) (r1292572)
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251
and r1292270)
* Check the user guide
--
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] [Created] (MATH-759) ListUnivariateImpl does not always access windowSize using synch.
ListUnivariateImpl does not always access windowSize using synch. - Key: MATH-759 URL: https://issues.apache.org/jira/browse/MATH-759 Project: Commons Math Issue Type: Bug Reporter: Sebb ListUnivariateImpl has two synch. methods: getWindowSize setWindowSize However, windowSize is frequently referenced elsewhere without synch. It's not clear why the methods need synch., but if there is a need, then windowSize should always be read using synch. The code should use the super-class getter and setter. -- 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] [Created] (MATH-760) DescriptiveStatistics.windowSize has a getter and setter, but is protected, so subclasses can bypass the validation check in the setter
DescriptiveStatistics.windowSize has a getter and setter, but is protected, so subclasses can bypass the validation check in the setter --- Key: MATH-760 URL: https://issues.apache.org/jira/browse/MATH-760 Project: Commons Math Issue Type: Bug Reporter: Sebb DescriptiveStatistics.windowSize has a setter which does validation and maintains the list if necessary. However the field is protected, so classes can ignore the setter. As it happens, this is exactly what the subclass ListUnivariateImpl.setWindowSize does. The field should be made private. -- 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] (MATH-758) Fields which could be private and/or final
[ https://issues.apache.org/jira/browse/MATH-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221445#comment-13221445 ] Sebb commented on MATH-758: --- LaguerreSolver.complexSolver - could this be private and final? Dfp fields exp/mant/nans/sign - looks like these could be private with getters, apart from nans which is written by subclasses. AbstractFormat.setDenominatorFormat() AbstractFormat.setNumeratorFormat() - are these needed (only used in test code)? If not, the underlying fields could be made final NordsieckStepInterpolator.stateVariation is only used internally AFAICT, so could be private FirstMoment.n has a getter, and is not updated externally, so could be private FourthMoment.m4 is only read externally by Kurtosis, so could be private (there is a getter) The fields m1, m2, m3 are only ever written by the xxxMoment classes, which set them to zero. Each class could have a protected zero() method, which could be chained in the same way as the clear() method. Other classes could then use the getters and m1-m4 could be private. [To be continued] Fields which could be private and/or final -- Key: MATH-758 URL: https://issues.apache.org/jira/browse/MATH-758 Project: Commons Math Issue Type: Bug Reporter: Sebb BaseAbstractUnivariateIntegrator has several fields that are not currently changed after construction and could be final: protected double absoluteAccuracy; protected double relativeAccuracy; protected int minimalIterationCount; protected Incrementor iterations; protected Incrementor evaluations; These all have getters as well, so could also be made private. -- 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] (MATH-758) Fields which could be private and/or final
[ https://issues.apache.org/jira/browse/MATH-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221466#comment-13221466 ] Gilles commented on MATH-758: - Class AbstractLeastSquaresOptimizer in package optimization.general uses many protected instance variables which are modified in subclasses. This cannot be changed at this point (too many things to touch and a quite likely performance loss due to array copying). Fields which could be private and/or final -- Key: MATH-758 URL: https://issues.apache.org/jira/browse/MATH-758 Project: Commons Math Issue Type: Bug Reporter: Sebb BaseAbstractUnivariateIntegrator has several fields that are not currently changed after construction and could be final: protected double absoluteAccuracy; protected double relativeAccuracy; protected int minimalIterationCount; protected Incrementor iterations; protected Incrementor evaluations; These all have getters as well, so could also be made private. -- 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] (MATH-758) Fields which could be private and/or final
[ https://issues.apache.org/jira/browse/MATH-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221470#comment-13221470 ] Gilles commented on MATH-758: - bq. LaguerreSolver.complexSolver - could this be private and final? Done. Fields which could be private and/or final -- Key: MATH-758 URL: https://issues.apache.org/jira/browse/MATH-758 Project: Commons Math Issue Type: Bug Reporter: Sebb BaseAbstractUnivariateIntegrator has several fields that are not currently changed after construction and could be final: protected double absoluteAccuracy; protected double relativeAccuracy; protected int minimalIterationCount; protected Incrementor iterations; protected Incrementor evaluations; These all have getters as well, so could also be made private. -- 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] [Closed] (COMMONSSITE-66) Add support for a commons.release.3 set of properties to offer a 3rd download option
[ https://issues.apache.org/jira/browse/COMMONSSITE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed COMMONSSITE-66. -- Closing. About to cut RC. As closed this will show up in the site JIRA report. Add support for a commons.release.3 set of properties to offer a 3rd download option -- Key: COMMONSSITE-66 URL: https://issues.apache.org/jira/browse/COMMONSSITE-66 Project: Commons All Issue Type: New Feature Components: Commons Build Plugin Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) Maven home: C:\Java\apache-maven-3.0.4\bin\.. Java version: 1.6.0_31, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_31\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Assignee: Gary D. Gregory Add support for a commons.release.3 set of properties to offer a 3rd download option: commons.release.3.* will be just like commons.release.2.* -- 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] (MATH-758) Fields which could be private and/or final
[ https://issues.apache.org/jira/browse/MATH-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221471#comment-13221471 ] Gilles commented on MATH-758: - The logic of AbstractWell (package random) relies on the variables being protected - no change at this point. Fields which could be private and/or final -- Key: MATH-758 URL: https://issues.apache.org/jira/browse/MATH-758 Project: Commons Math Issue Type: Bug Reporter: Sebb BaseAbstractUnivariateIntegrator has several fields that are not currently changed after construction and could be final: protected double absoluteAccuracy; protected double relativeAccuracy; protected int minimalIterationCount; protected Incrementor iterations; protected Incrementor evaluations; These all have getters as well, so could also be made private. -- 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] (MATH-754) Additional Fraction Constructor
[ https://issues.apache.org/jira/browse/MATH-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-754. - Resolution: Won't Fix This issue was based on a wrong assumption. If you wish, please propose the enhancements (create Fraction objects based on various user criteria) on the dev ML. Additional Fraction Constructor --- Key: MATH-754 URL: https://issues.apache.org/jira/browse/MATH-754 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Environment: All Reporter: Travis Hanna Priority: Minor Labels: features, newbie, patch Fix For: 3.0 Attachments: math.patch I'm writing some code which outputs fractional measurements meant for human consumption. I need a constructor for Fraction which allows you to restrict the denominators to a finite set. This is necessary due to the fact that real-world tools are only available with certain fractions. For example, it's next to impossible to find a ruler with 1/7 inch marked :). I'm attaching a patch which implements the functionality. I've attempted to mimic the style of the existing code as much as possible. One caveat: I don't speak French so the french error message is a computer-generated translation and probably very poor. -- 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] (MATH-758) Fields which could be private and/or final
[ https://issues.apache.org/jira/browse/MATH-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221477#comment-13221477 ] Gilles commented on MATH-758: - There is a heavy use of protected variables in the classes of the ode package. Maybe that Luc can give his opinion as to whether it has to be so. Anyways, my impression is that it cannot be changed without a lot of work - no change at this point. Fields which could be private and/or final -- Key: MATH-758 URL: https://issues.apache.org/jira/browse/MATH-758 Project: Commons Math Issue Type: Bug Reporter: Sebb BaseAbstractUnivariateIntegrator has several fields that are not currently changed after construction and could be final: protected double absoluteAccuracy; protected double relativeAccuracy; protected int minimalIterationCount; protected Incrementor iterations; protected Incrementor evaluations; These all have getters as well, so could also be made private. -- 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] (MATH-758) Fields which could be private and/or final
[ https://issues.apache.org/jira/browse/MATH-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221479#comment-13221479 ] Sebb commented on MATH-758: --- Note that getters can return the array without copying (though returning the array itself is best avoided if indexed getters can be used instead). Using a getter instead of direct access means that it would be possible at a later date to change the code to clone the array; this is not possible when direct access is allowed. For sub-classes that access array elements, then a getter(int idx) that gets the element would be preferable, as it makes the element read-only. This should be applicable in the AbstractWell case. It's never *necessary* to expose mutable data fields directly, so the default should be for all such fields to be private, with access via getters (and setters if necessary). Fields which could be private and/or final -- Key: MATH-758 URL: https://issues.apache.org/jira/browse/MATH-758 Project: Commons Math Issue Type: Bug Reporter: Sebb BaseAbstractUnivariateIntegrator has several fields that are not currently changed after construction and could be final: protected double absoluteAccuracy; protected double relativeAccuracy; protected int minimalIterationCount; protected Incrementor iterations; protected Incrementor evaluations; These all have getters as well, so could also be made private. -- 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] (MATH-758) Fields which could be private and/or final
[ https://issues.apache.org/jira/browse/MATH-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221480#comment-13221480 ] Sebb commented on MATH-758: --- bq. Anyways, my impression is that it cannot be changed without a lot of work - no change at this point. If it's not changed now, then even more work will likely be needed if it is done later. Fields which could be private and/or final -- Key: MATH-758 URL: https://issues.apache.org/jira/browse/MATH-758 Project: Commons Math Issue Type: Bug Reporter: Sebb BaseAbstractUnivariateIntegrator has several fields that are not currently changed after construction and could be final: protected double absoluteAccuracy; protected double relativeAccuracy; protected int minimalIterationCount; protected Incrementor iterations; protected Incrementor evaluations; These all have getters as well, so could also be made private. -- 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] (MATH-758) Fields which could be private and/or final
[ https://issues.apache.org/jira/browse/MATH-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221490#comment-13221490 ] Gilles commented on MATH-758: - I totally agree on the data encapsulation issue. The problem is the timing: It is not the appropriate time to make large modifications to the code because almost 2 years of work must released. Most of these issues are going to stay at the level of potential problems (the field are not intended to be directly accessed by users) as they have been until now. I must point again that those issues stem from not having a consistent coding policy, e.g. a rule such as It's never necessary to expose mutable data fields directly. This rule should be integrated when thinking about the implementation, not as an after-thought. Redesigning some of the affected implementations will need more time than I have now. Fields which could be private and/or final -- Key: MATH-758 URL: https://issues.apache.org/jira/browse/MATH-758 Project: Commons Math Issue Type: Bug Reporter: Sebb BaseAbstractUnivariateIntegrator has several fields that are not currently changed after construction and could be final: protected double absoluteAccuracy; protected double relativeAccuracy; protected int minimalIterationCount; protected Incrementor iterations; protected Incrementor evaluations; These all have getters as well, so could also be made private. -- 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] (EMAIL-114) Methods to add multiple To, cc, Bcc is desired
[ https://issues.apache.org/jira/browse/EMAIL-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokul Nanthakumar C updated EMAIL-114: -- Attachment: arrayOfStringForAddresses.patch Patch for new Methods addTo(String[]), addCc(String[]), addBcc(String[]) Methods to add multiple To, cc, Bcc is desired -- Key: EMAIL-114 URL: https://issues.apache.org/jira/browse/EMAIL-114 Project: Commons Email Issue Type: Improvement Reporter: Gokul Nanthakumar C Attachments: arrayOfStringForAddresses.patch Currently if we have list of email address as string adding them to mail is possible only by looping or converting them as list of java.mail.internet.InternetAddress. Method like addTo(String[] emails) is desired. -- 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] (MATH-758) Fields which could be private and/or final
[ https://issues.apache.org/jira/browse/MATH-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221511#comment-13221511 ] Gilles commented on MATH-758: - I think that most of the easy stuff has been done. Fields which could be private and/or final -- Key: MATH-758 URL: https://issues.apache.org/jira/browse/MATH-758 Project: Commons Math Issue Type: Bug Reporter: Sebb BaseAbstractUnivariateIntegrator has several fields that are not currently changed after construction and could be final: protected double absoluteAccuracy; protected double relativeAccuracy; protected int minimalIterationCount; protected Incrementor iterations; protected Incrementor evaluations; These all have getters as well, so could also be made private. -- 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] (MATH-759) ListUnivariateImpl does not always access windowSize using synch.
[ https://issues.apache.org/jira/browse/MATH-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-759: Priority: Minor (was: Major) This is class is defined in the test part of the source tree. ListUnivariateImpl does not always access windowSize using synch. - Key: MATH-759 URL: https://issues.apache.org/jira/browse/MATH-759 Project: Commons Math Issue Type: Bug Reporter: Sebb Priority: Minor ListUnivariateImpl has two synch. methods: getWindowSize setWindowSize However, windowSize is frequently referenced elsewhere without synch. It's not clear why the methods need synch., but if there is a need, then windowSize should always be read using synch. The code should use the super-class getter and setter. -- 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] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods
[ https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221520#comment-13221520 ] Gilles commented on MATH-757: - Instance variables are private as of r1296563. ResizableDoubleArray is not thread-safe yet has some synch. methods --- Key: MATH-757 URL: https://issues.apache.org/jira/browse/MATH-757 Project: Commons Math Issue Type: Bug Reporter: Sebb ResizableDoubleArray has several synchronised methods, but is not thread-safe, because class variables are not always accessed using the lock. Is the class supposed to be thread-safe? If so, all accesses (read and write) need to be synch. If not, the synch. qualifiers could be dropped. In any case, the protected fields need to be made private. -- 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
