[jira] [Commented] (MATH-811) Improve event detection by selecting g function slope
[ https://issues.apache.org/jira/browse/MATH-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468379#comment-13468379 ] Yannick TANGUY commented on MATH-811: - Your idea seems interesting, but I think it depends on how users already handle event detection. If most of them won't use the slope selection, maybe an extended interface is better, or an abstract class (like in OREKIT events package), so that these users don't have to implement this method. But if there are "enough" users who can be interested in the new features, I think it must be implemented in EventHandler interface, and users will have to adapt their code. In the second hypothesis, I understand it will have to wait for 4.0. Anyway, what's really important for us is to have this feature now (and it's ok, "our" version of Commons Math implement it), to identify precisely the differences between our version and the official version (snapshot or a released version) and then, to know approximatively when this feature could be integrated (Commons Math roadmap). By now, this discussion has enabled to improve the implementation, clarify the use of event detection : that's a good point ! And when you'll have time to look further into it, we can discuss again to find a more elegant solution (if any) and integrate it. > Improve event detection by selecting g function slope > - > > Key: MATH-811 > URL: https://issues.apache.org/jira/browse/MATH-811 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Yannick TANGUY > Attachments: JIRA-811_slope_selection.patch, > JIRA-811_slope_selection_V2.patch, JIRA-811_slope_selection_V3.patch, > JIRA-811_slope_selection_V3_with_spaces.patch, > JIRA-811_slope_selection_with_spaces.patch > > > We would like to select g function slope in CommonsMath event detection > feature. > This would improve event detection for the final user (the possibility to > ignore some events, and less computation time) and also correct a bug found > while using OREKIT (see https://www.orekit.org/forge/issues/104) in our > applications. > The modification consists in adding a method (getSlopeSelection() : int) in > EventHandler, and modifying one conditionnal in the method evaluateStep > (class EventState). > We can provide modified code and unitary tests for this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[ https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirko Raner updated CODEC-158: -- Attachment: CODEC-158.patch Attached are the modifications I had in mind to address this. Please let me know if you have any questions or improvements. There is already a class called BinaryCodec in package org.apache.commons.codec.binary. The new BinaryCodec interface in org.apache.commons.codec may be confused with this existing class. In the patch, the naming is consistent (i.e. StringEncoder+StringDecoder->StringCodec and BinaryEncoder+BinaryDecoder->BinaryCodec) and the two types are distinguishable by their package. If you feel this could be a problem, please make a suggestion as to how this can be resolved. Thanks! > Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder > and decoder > --- > > Key: CODEC-158 > URL: https://issues.apache.org/jira/browse/CODEC-158 > Project: Commons Codec > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Mirko Raner >Priority: Minor > Attachments: CODEC-158.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > Currently, there are no common interfaces that extend both the encoder and > the decoder interfaces. This makes it hard to deal with a codec as a single > entity and requires separate treatment of encoder and decoder parts. > For example, let's say you want to develop a storage abstraction that uses an > encoding. Right now, you would need to write > class Storage > { > @Inject Encoder encoder; > @Inject Decoder decoder; > //... > } > In practice, encoder and decoder need to match, and most likely both encoder > and decoder would be bound to the same implementation, like Base64 or > URLCodec. Because of the lack of a common superinterface they need to be > specified separately. There are some classes like BaseNCodec that can be used > to unify some of the encoders and decoders, but they are too specific and > restrictive. > Ideally, I would like to write: > class Storage > { > @Inject Codec codec; > //... > } > Assuming that combined encoder/decoder classes like Base64 would implement > that Codec interface, this could be directly bound to a combined > encoder/decoder implementation. > It would be nice if these interfaces were added and the existing codec > classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be > modified to implement these new interfaces. > I'm happy to contribute a patch if there is interest in this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[ https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468459#comment-13468459 ] Sebb commented on CODEC-158: Thanks! Does not seem to affect binary compatibility (according to Clirr). However, it is very awkward having an interface and implementation of the interface with the same class name, so I think the BinaryCodec interface needs to be renamed. Otherwise one has to do something like: BinaryCodec bc = new org.apache.commons.codec.binary.BinaryCodec(); or org.apache.commons.codec.BinaryCodec bc = new BinaryCodec(); or even org.apache.commons.codec.BinaryCodec bc = new org.apache.commons.codec.binary.BinaryCodec(); These are ugly and tricky to read. > Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder > and decoder > --- > > Key: CODEC-158 > URL: https://issues.apache.org/jira/browse/CODEC-158 > Project: Commons Codec > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Mirko Raner >Priority: Minor > Attachments: CODEC-158.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > Currently, there are no common interfaces that extend both the encoder and > the decoder interfaces. This makes it hard to deal with a codec as a single > entity and requires separate treatment of encoder and decoder parts. > For example, let's say you want to develop a storage abstraction that uses an > encoding. Right now, you would need to write > class Storage > { > @Inject Encoder encoder; > @Inject Decoder decoder; > //... > } > In practice, encoder and decoder need to match, and most likely both encoder > and decoder would be bound to the same implementation, like Base64 or > URLCodec. Because of the lack of a common superinterface they need to be > specified separately. There are some classes like BaseNCodec that can be used > to unify some of the encoders and decoders, but they are too specific and > restrictive. > Ideally, I would like to write: > class Storage > { > @Inject Codec codec; > //... > } > Assuming that combined encoder/decoder classes like Base64 would implement > that Codec interface, this could be directly bound to a combined > encoder/decoder implementation. > It would be nice if these interfaces were added and the existing codec > classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be > modified to implement these new interfaces. > I'm happy to contribute a patch if there is interest in this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBCP-393) DBCP to support database connection failover
Campbell created DBCP-393: - Summary: DBCP to support database connection failover Key: DBCP-393 URL: https://issues.apache.org/jira/browse/DBCP-393 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.4 Reporter: Campbell Priority: Critical Hello. Would it be possible for the DriverManagerConnectionFactory to accept a list or alternative database connection URL. With a possible maxRetry parameter, the suggestion is this improvement would allow for automatic fail over to a secondary database when a connection exception occurs. Let me know if this is a good candidate or if you have made thought of this already as it is standard behaviour in other managed datasources. Many thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EMAIL-120) attach(DataSource xx) doesn't close inputstream
mike bell created EMAIL-120: --- Summary: attach(DataSource xx) doesn't close inputstream Key: EMAIL-120 URL: https://issues.apache.org/jira/browse/EMAIL-120 Project: Commons Email Issue Type: Bug Affects Versions: 1.2 Environment: Windows 7, 64 bit Reporter: mike bell Basically I have code like shown below. message.attach(reports[1].getDatasource(), "Report" + new SimpleDateFormat("mmdd").format(new java.util.Date()) + "." + selectedAttachment, selectedAttachment.toUpperCase() + " version of report"); Where the DataSource in question is a simple JAF FileDataSource. What I found [when I found files were not being cleaned up by my cleaner) 1. I can delete the backing file before calling this method 2. I cannot delete the backing file after calling this method. 3. Workaround uses the URL version of attachment. DataSource ds=reports[1].getDatasource(); FileDataSource fds=(FileDataSource) ds; URL url=fds.getFile().toURI().toURL(); /** * MJB: We don't use the DataSource directly (as we should) because of a bug in Commons Email * where it usually doesn't close the inputstream */ message.attach(url,"Report" + new SimpleDateFormat("mmdd").format(new java.util.Date()) + "." + selectedAttachment, selectedAttachment.toUpperCase() + " version of report"); 4. I therefore assume the inputstream has been opened and never closed. 5. Same test after calling send() provides same results -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-437) [FTP] Program crashes when StackOverFlow Exception happens from pulling a softlinked directory that link to the directory that has the same name one level above
[ https://issues.apache.org/jira/browse/VFS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Zhu updated VFS-437: --- Attachment: (was: FtpFileObject_patch) > [FTP] Program crashes when StackOverFlow Exception happens from pulling a > softlinked directory that link to the directory that has the same name one > level above > - > > Key: VFS-437 > URL: https://issues.apache.org/jira/browse/VFS-437 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: java version "1.7.0_02" > Java(TM) SE Runtime Environment (build 1.7.0_02-b13) > Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode) > Linux version 2.6.18-238.el5 (mockbu...@builder10.centos.org) (gcc version > 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu Jan 13 15:51:15 EST 2011 >Reporter: Jason >Priority: Blocker > Fix For: 2.1 > > > With the setting below, StackOverFlow exceptions occur and server crashes > set the builder.setUserDirlsRoot (opt, true) > Attept to pull with: > ftp://root:password@ip:/Vol1 > Vol directory has the following info > lrwxrwxrwx 1 root root5 Oct 5 2007 Vol1 -> /Vol1 > When it tries to look for the parent of the Vol1, it goes back to the same > Vol1, which causes a infinite loop that eventually creates stackoverflow > exception. > The problem is inside the doGetType() method in FtpFileObject > @Override > protected FileType doGetType() > throws Exception > { > // VFS-210 > synchronized (getFileSystem()) > { > if (this.fileInfo == null) > { > getInfo(false); > } > if (this.fileInfo == UNKNOWN) > { > return FileType.IMAGINARY; > } > else if (this.fileInfo.isDirectory()) > { > return FileType.FOLDER; > } > else if (this.fileInfo.isFile()) > { > return FileType.FILE; > } > else if (this.fileInfo.isSymbolicLink()) > { > return getLinkDestination().getType(); > } > } > throw new FileSystemException("vfs.provider.ftp/get-type.error", > getName()); > } > It will keep hitting the "else if (this.fileinfo.isSymbolicLink())" condition > and the fileinfo displayed is always the Vol1 under root directory. > Exception is shown below > java.lang.StackOverflowError > at org.apache.commons.net.ftp.FTPFile.isDirectory(FTPFile.java:116) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:334) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.comm
[jira] [Updated] (VFS-437) [FTP] Program crashes when StackOverFlow Exception happens from pulling a softlinked directory that link to the directory that has the same name one level above
[ https://issues.apache.org/jira/browse/VFS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Zhu updated VFS-437: --- Attachment: (was: FtpFileObject_svndiff.htm) > [FTP] Program crashes when StackOverFlow Exception happens from pulling a > softlinked directory that link to the directory that has the same name one > level above > - > > Key: VFS-437 > URL: https://issues.apache.org/jira/browse/VFS-437 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: java version "1.7.0_02" > Java(TM) SE Runtime Environment (build 1.7.0_02-b13) > Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode) > Linux version 2.6.18-238.el5 (mockbu...@builder10.centos.org) (gcc version > 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu Jan 13 15:51:15 EST 2011 >Reporter: Jason >Priority: Blocker > Fix For: 2.1 > > > With the setting below, StackOverFlow exceptions occur and server crashes > set the builder.setUserDirlsRoot (opt, true) > Attept to pull with: > ftp://root:password@ip:/Vol1 > Vol directory has the following info > lrwxrwxrwx 1 root root5 Oct 5 2007 Vol1 -> /Vol1 > When it tries to look for the parent of the Vol1, it goes back to the same > Vol1, which causes a infinite loop that eventually creates stackoverflow > exception. > The problem is inside the doGetType() method in FtpFileObject > @Override > protected FileType doGetType() > throws Exception > { > // VFS-210 > synchronized (getFileSystem()) > { > if (this.fileInfo == null) > { > getInfo(false); > } > if (this.fileInfo == UNKNOWN) > { > return FileType.IMAGINARY; > } > else if (this.fileInfo.isDirectory()) > { > return FileType.FOLDER; > } > else if (this.fileInfo.isFile()) > { > return FileType.FILE; > } > else if (this.fileInfo.isSymbolicLink()) > { > return getLinkDestination().getType(); > } > } > throw new FileSystemException("vfs.provider.ftp/get-type.error", > getName()); > } > It will keep hitting the "else if (this.fileinfo.isSymbolicLink())" condition > and the fileinfo displayed is always the Vol1 under root directory. > Exception is shown below > java.lang.StackOverflowError > at org.apache.commons.net.ftp.FTPFile.isDirectory(FTPFile.java:116) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:334) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apach
[jira] [Updated] (VFS-437) [FTP] Program crashes when StackOverFlow Exception happens from pulling a softlinked directory that link to the directory that has the same name one level above
[ https://issues.apache.org/jira/browse/VFS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated VFS-437: - Attachment: VFS-437.diff Proposed solution ( from Dennis ) > [FTP] Program crashes when StackOverFlow Exception happens from pulling a > softlinked directory that link to the directory that has the same name one > level above > - > > Key: VFS-437 > URL: https://issues.apache.org/jira/browse/VFS-437 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: java version "1.7.0_02" > Java(TM) SE Runtime Environment (build 1.7.0_02-b13) > Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode) > Linux version 2.6.18-238.el5 (mockbu...@builder10.centos.org) (gcc version > 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu Jan 13 15:51:15 EST 2011 >Reporter: Jason >Priority: Blocker > Fix For: 2.1 > > Attachments: VFS-437.diff > > > With the setting below, StackOverFlow exceptions occur and server crashes > set the builder.setUserDirlsRoot (opt, true) > Attept to pull with: > ftp://root:password@ip:/Vol1 > Vol directory has the following info > lrwxrwxrwx 1 root root5 Oct 5 2007 Vol1 -> /Vol1 > When it tries to look for the parent of the Vol1, it goes back to the same > Vol1, which causes a infinite loop that eventually creates stackoverflow > exception. > The problem is inside the doGetType() method in FtpFileObject > @Override > protected FileType doGetType() > throws Exception > { > // VFS-210 > synchronized (getFileSystem()) > { > if (this.fileInfo == null) > { > getInfo(false); > } > if (this.fileInfo == UNKNOWN) > { > return FileType.IMAGINARY; > } > else if (this.fileInfo.isDirectory()) > { > return FileType.FOLDER; > } > else if (this.fileInfo.isFile()) > { > return FileType.FILE; > } > else if (this.fileInfo.isSymbolicLink()) > { > return getLinkDestination().getType(); > } > } > throw new FileSystemException("vfs.provider.ftp/get-type.error", > getName()); > } > It will keep hitting the "else if (this.fileinfo.isSymbolicLink())" condition > and the fileinfo displayed is always the Vol1 under root directory. > Exception is shown below > java.lang.StackOverflowError > at org.apache.commons.net.ftp.FTPFile.isDirectory(FTPFile.java:116) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:334) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.
[jira] [Updated] (LANG-778) Add methods uuidToByteArray and byteArrayToUuid
[ https://issues.apache.org/jira/browse/LANG-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible updated LANG-778: Fix Version/s: 3.2 Summary: Add methods uuidToByteArray and byteArrayToUuid (was: Add ByteArrayUtils) > Add methods uuidToByteArray and byteArrayToUuid > --- > > Key: LANG-778 > URL: https://issues.apache.org/jira/browse/LANG-778 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Reporter: Joerg Schaible >Assignee: Joerg Schaible >Priority: Minor > Fix For: 3.2 > > Attachments: LANG-778.diff > > Original Estimate: 8h > Remaining Estimate: 8h > > ByteArrayUtils will currently contain only conversion methods between several > types and an array of bytes. The functionality is similar to DataInput and > DataOutput, but without the indirection of IO streams. As special type the > utility class supports also conversion between UUID and byte array (memory > layout as described in RFC 4122). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468711#comment-13468711 ] Gilles commented on MATH-867: - Thanks. The improved Javadoc is in revision 1393641. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Fix For: 3.1 > > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-801) Util for conversion between primitive types
[ https://issues.apache.org/jira/browse/LANG-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible resolved LANG-801. - Resolution: Fixed Added with minor adjustment to naming conventions. > Util for conversion between primitive types > --- > > Key: LANG-801 > URL: https://issues.apache.org/jira/browse/LANG-801 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Reporter: Sebastien Riou >Assignee: Joerg Schaible >Priority: Minor > Attachments: patch_Conversion.txt > > > A utility class to convert data from one primitive type to another, in the > most commonly used fashions (big endian/little endian byte order, lsb first > or msb first). > It also deals with arrays of primitive types and String containing > hexadecimal numbers. > Such conversions are needed when dealing with embedded software or hardware > modeling/design. > I attach a initial version which deals with the "default" encoding, the one > which seems the most natural on the JVM: little endian byte ordering, and, > within a byte, lsb first. > I plan to implement the other encoding I need: > - big endian, lsb first > - big endian, msb first > So far I implemented about half of the methods needed to cover the default > encoding: > - methods to convert a large data type into an array of a smaller data type > (longToBytes for example) > - methods to convert an array of a small data type into a larger data type > (bytesToLong for example) > The remaining half consist of the methods to convert from an array of a data > type into an array of another data type (bytesToLongs, LongsToBytes) > Once this is available for different encodings, the most useful part can be > done: the "bridge" methods to convert from one encoding to another -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-778) Add methods uuidToByteArray and byteArrayToUuid
[ https://issues.apache.org/jira/browse/LANG-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible resolved LANG-778. - Resolution: Fixed Added as methods to class Conversion that contains already all the conversions between bytes and longs. > Add methods uuidToByteArray and byteArrayToUuid > --- > > Key: LANG-778 > URL: https://issues.apache.org/jira/browse/LANG-778 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Reporter: Joerg Schaible >Assignee: Joerg Schaible >Priority: Minor > Fix For: 3.2 > > Attachments: LANG-778.diff > > Original Estimate: 8h > Remaining Estimate: 8h > > ByteArrayUtils will currently contain only conversion methods between several > types and an array of bytes. The functionality is similar to DataInput and > DataOutput, but without the indirection of IO streams. As special type the > utility class supports also conversion between UUID and byte array (memory > layout as described in RFC 4122). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira