[jira] [Commented] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808938#comment-13808938 ] Gilles commented on MATH-1045: -- bq. [...] this may fail [...] For this issue, I could add a loop in order to find the one with largest absolute value. WDYT? But I have no idea how to construct a matrix for a unit test that would exhibit the problem. EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity --- Key: MATH-1045 URL: https://issues.apache.org/jira/browse/MATH-1045 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: eigenvalue, singular Fix For: 3.3 Attachments: MATH-1045.patch, MATH-1045.patch EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 for exact equality. Elsewhere in the class and in the code, of course, very small values are considered 0. This causes the solver to consider some singular matrices as non-singular. The patch here includes a test as well showing the behavior -- the matrix is clearly singular but isn't considered as such since one eigenvalue are ~1e-14 rather than exactly 0. (What I am not sure of is whether we should really be evaluating the *norm* of the imaginary eigenvalues rather than real/imag components separately. But the javadoc says the solver only supports real eigenvalues anyhow, so it's kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (COMPRESS-124) Unable to extract a sparse entries from tar archives
[ https://issues.apache.org/jira/browse/COMPRESS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-124: Summary: Unable to extract a sparse entries from tar archives (was: Unable to extract a TAR file that contains sparse entries) Unable to extract a sparse entries from tar archives Key: COMPRESS-124 URL: https://issues.apache.org/jira/browse/COMPRESS-124 Project: Commons Compress Issue Type: New Feature Components: Archivers Affects Versions: 1.1, 1.2 Environment: Platform independent. However, I'm currently using Window 7 Enterprise. Reporter: Patrick Dreyer Labels: tar Attachments: gnuSparseFile.patch Good news first: I already have the patch ready for that. I got several TAR files which I could not extract with any of the existing Java implementations, but I could extract all those TAR files successfully with GNU tar. It turned out that all the failing TAR files contained so called sparse files. Investigating the source code of all existing Java TAR implementations showed me that none of them even recognizes the existence of GNU sparse entries. Actually, I don't need to process one of the contained sparse files and I'm happy if I'm at least able to correctly untar all the non-sparsed files. Thus, it would be sufficient recognizing sparse files without the need to correctly un-sparse them while extracting. As long as all non-sparsed files get extracted correctly, I'm fine. The TAR files in question have all been VMware Diagnostic File bundles. See http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=653 to know how to get them. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (VFS-499) I am using common vfs jar with version 1.0. I have extended org.apache.commons.vfs.FileListener class.The fileCreated event is getting called more than once for the same fil
Ashwini Dixit created VFS-499: - Summary: I am using common vfs jar with version 1.0. I have extended org.apache.commons.vfs.FileListener class.The fileCreated event is getting called more than once for the same file. Key: VFS-499 URL: https://issues.apache.org/jira/browse/VFS-499 Project: Commons VFS Issue Type: Bug Affects Versions: 1.0 Reporter: Ashwini Dixit Priority: Critical I am using common vfs jar with version 1.0. I have extended org.apache.commons.vfs.FileListener class. The fileCreated event is getting called more than once for the same file in the folder.It should not happen once the fileCreated event has been triggered.Has something to do with using /var/tmp/vfs_cache as temporary files store. Please suggest,why this issue is getting caused and what is the resolution. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COMPRESS-238) Add RAR archive support
[ https://issues.apache.org/jira/browse/COMPRESS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808950#comment-13808950 ] Stefan Bodewig commented on COMPRESS-238: - AFAIU the format is proprietary but open source libraries exist that allow unarchiving - the license explicitly prohibits reverse-engineering of the compression algorithm. The ASF lists the license of the UNRAR lib as one that is acceptable for a binary depencency. Add RAR archive support --- Key: COMPRESS-238 URL: https://issues.apache.org/jira/browse/COMPRESS-238 Project: Commons Compress Issue Type: Wish Components: Archivers Reporter: Stefan Bodewig Creating a new ticket for RAR so I can close COMPRESS-54 There is an Unrar library with a license that has been deemed acceptable for use in Apache projects - I think TIKA already uses it. https://github.com/edmund-wagner/junrar -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COMPRESS-186) The example should be much easier to read
[ https://issues.apache.org/jira/browse/COMPRESS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808954#comment-13808954 ] Stefan Bodewig commented on COMPRESS-186: - all of them I guess. TBH we really only have a single example that we copy over for each algorithm we use. The example should be much easier to read - Key: COMPRESS-186 URL: https://issues.apache.org/jira/browse/COMPRESS-186 Project: Commons Compress Issue Type: Improvement Components: Documentation Reporter: Yang Hua Jie Labels: examples Original Estimate: 504h Remaining Estimate: 504h The example should be much easier to read。 I read it for a long time and copy the code to my favorite IDE. But no lucky, I can not make it work. There should have a quick start page, and the page should be very easy -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (DIGESTER-178) Constructor always gets passed null values
Michalis Adamidis created DIGESTER-178: -- Summary: Constructor always gets passed null values Key: DIGESTER-178 URL: https://issues.apache.org/jira/browse/DIGESTER-178 Project: Commons Digester Issue Type: Bug Affects Versions: 3.2 Environment: Win 8.1 64bit, Java 7u45 Reporter: Michalis Adamidis Fix For: 3.3 Using the ObjectCreateRules to pass parameter to the constructor I always get null values passed. I'm not quite sure if this is a usage problem or a bug but to minimize the chance of it beeing a user error I adapted the anotation example from the website and adapted it following the constructor guide also found on the website. The complete code including pom can be found in the following stackoverflow question http://stackoverflow.com/questions/19664073/digester3-always-passes-null-as-constructor-parameters As stated in the question the problem also occures with the current trunk code. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809009#comment-13809009 ] Sean Owen commented on MATH-1045: - Yes, this is a good point. It's safest to find the largest eigenvalue (by absolute value) with a loop I think. The final matrix in testUnsymmetric(), which is unsymmetric, shows this. The symmetric matrix in testSquareRootNonPositiveDefinite() also shows this -- the last eigenvalue is the most negative, but is the largest in absolute value. EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity --- Key: MATH-1045 URL: https://issues.apache.org/jira/browse/MATH-1045 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: eigenvalue, singular Fix For: 3.3 Attachments: MATH-1045.patch, MATH-1045.patch EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 for exact equality. Elsewhere in the class and in the code, of course, very small values are considered 0. This causes the solver to consider some singular matrices as non-singular. The patch here includes a test as well showing the behavior -- the matrix is clearly singular but isn't considered as such since one eigenvalue are ~1e-14 rather than exactly 0. (What I am not sure of is whether we should really be evaluating the *norm* of the imaginary eigenvalues rather than real/imag components separately. But the javadoc says the solver only supports real eigenvalues anyhow, so it's kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MATH-1050) Deprecate pow(int, long) and pow(long,long) in ArithmeticUtils
Gilles created MATH-1050: Summary: Deprecate pow(int, long) and pow(long,long) in ArithmeticUtils Key: MATH-1050 URL: https://issues.apache.org/jira/browse/MATH-1050 Project: Commons Math Issue Type: Task Affects Versions: 3.2 Reporter: Gilles Assignee: Gilles Priority: Trivial Fix For: 4.0, 3.3 Those two methods uses a long for the exponent, but overflow will occur when the exponent is larger than 31 (except for the trivial case where the base is 1). See also [this thread|http://markmail.org/message/nhnst5eryqyudxfy] on the dev ML. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COMPRESS-133) Mention Debian/Ubuntu packages in AR format documentation
[ https://issues.apache.org/jira/browse/COMPRESS-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809038#comment-13809038 ] Bear Giles commented on COMPRESS-133: - To give you two examples of how this can be used: 1. The deb format for the package 'foo' includes a file containing MD5 checksums for all of the files in the package, stored in /var/lib/dpkg/info/foo.md5sums. This can be used to verify the contents of the package, e.g., to detect modification. However a really paranoid site may not trust the contents of this file since it's well-known - a sophisticated attacker could modify the contents of this file. This would not be caught by the cryptographic signatures on the .deb files. A paranoid site may wish to periodically download the package and either compare the checksums in the control file or even recompute all values by opening the data.tar.gz file. It's worth noting that a few packages break the spec and don't include checksums for all of the included files. The standard Debian tools create this file automatically but it's not difficult for somebody to create a file manually. 2. A more sophisticated approach will check file ownership and permissions. AFAIK this information is not stored in the /var/lib/dpkg/info directory so the only way to do that is to scan data.tar.gz file yourself. (As an aside you can check for 'unknown' files by concatenating all of the /var/lib/dpkg/info/*.md5sums files and running 'md5sums' on the /usr, /bin and /sbin directories and diff'ing them. /lib may show differences in symlinks, and /etc has a lot of 'control' files. It won't catch rootkits but it will catch files that didn't come from a .deb package.) Bear Mention Debian/Ubuntu packages in AR format documentation - Key: COMPRESS-133 URL: https://issues.apache.org/jira/browse/COMPRESS-133 Project: Commons Compress Issue Type: Improvement Components: Documentation Reporter: Bear Giles Priority: Trivial The documentation for the AR format can/should mention that it is the basis for Debian/Ubuntu packages. A .deb file is actually an AR file with three elements: _debian-binary_: version number (2.0) _data.tar.gz_: compressed tarball containing the package's files _control.tar.gz_: compressed tarball containing the package's metadata (information, installation and removal scripts, etc.) People will normally want to use the Debian package management tools but it's nice to know that we can access the 'original' content if necessary. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809041#comment-13809041 ] Gilles commented on MATH-1045: -- Would you mind creating a patch? EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity --- Key: MATH-1045 URL: https://issues.apache.org/jira/browse/MATH-1045 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: eigenvalue, singular Fix For: 3.3 Attachments: MATH-1045.patch, MATH-1045.patch EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 for exact equality. Elsewhere in the class and in the code, of course, very small values are considered 0. This causes the solver to consider some singular matrices as non-singular. The patch here includes a test as well showing the behavior -- the matrix is clearly singular but isn't considered as such since one eigenvalue are ~1e-14 rather than exactly 0. (What I am not sure of is whether we should really be evaluating the *norm* of the imaginary eigenvalues rather than real/imag components separately. But the javadoc says the solver only supports real eigenvalues anyhow, so it's kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1045: Attachment: MATH-1045_2.patch Ah right, I should have said that these show out-of-order eigenvalues but that's not what we need to check. We need one that puts a very small eigenvalue first. That's easy to generate as something like [ d 0 ] [ 1 1 ] for tiny d. Patch attached. EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity --- Key: MATH-1045 URL: https://issues.apache.org/jira/browse/MATH-1045 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: eigenvalue, singular Fix For: 3.3 Attachments: MATH-1045_2.patch, MATH-1045.patch, MATH-1045.patch EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 for exact equality. Elsewhere in the class and in the code, of course, very small values are considered 0. This causes the solver to consider some singular matrices as non-singular. The patch here includes a test as well showing the behavior -- the matrix is clearly singular but isn't considered as such since one eigenvalue are ~1e-14 rather than exactly 0. (What I am not sure of is whether we should really be evaluating the *norm* of the imaginary eigenvalues rather than real/imag components separately. But the javadoc says the solver only supports real eigenvalues anyhow, so it's kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809126#comment-13809126 ] Gilles commented on MATH-1045: -- Thank you. Committed in revision 1537099. EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity --- Key: MATH-1045 URL: https://issues.apache.org/jira/browse/MATH-1045 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: eigenvalue, singular Fix For: 3.3 Attachments: MATH-1045_2.patch, MATH-1045.patch, MATH-1045.patch EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 for exact equality. Elsewhere in the class and in the code, of course, very small values are considered 0. This causes the solver to consider some singular matrices as non-singular. The patch here includes a test as well showing the behavior -- the matrix is clearly singular but isn't considered as such since one eigenvalue are ~1e-14 rather than exactly 0. (What I am not sure of is whether we should really be evaluating the *norm* of the imaginary eigenvalues rather than real/imag components separately. But the javadoc says the solver only supports real eigenvalues anyhow, so it's kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DBCP-402) Add a way to set an instance of java.sql.Driver directly on org.apache.commons.dbcp2.BasicDataSource
[ https://issues.apache.org/jira/browse/DBCP-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809128#comment-13809128 ] Mark Thomas commented on DBCP-402: -- It isn't as clean a solution but you are already able to specify the class loader to use to load the Driver. Add a way to set an instance of java.sql.Driver directly on org.apache.commons.dbcp2.BasicDataSource Key: DBCP-402 URL: https://issues.apache.org/jira/browse/DBCP-402 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 2.0 Reporter: Ben Hale Currently when org.apache.commons.dbcp2.BasicDataSource is directly instantiated (e.g. in an IoC environment), the only way to set the type of java.sql.Driver that is should use is by passing in a String classname which is then passed to DriverManager. The downside to this is that it requires the DataSource and the Driver to be in the same classloader. In practice many times the Driver is in the application classloader while the DataSource is in the container classloader meaning that other than packaging a Tomcat JAR in your application you cannot use the DataSource directly. It'd be great to have a way to pass the actual instance of Driver to the DataSource and have it use that instead of going to DriverManager to find it. This would enable standard classloader inheritance to work properly and allow the non-adjacent packaging of the Driver and DataSource. An example of this style of configuration can be found in Spring's SimpleDriverDataSource[1]. [1]: http://docs.spring.io/spring/docs/3.2.x/javadoc-api/org/springframework/jdbc/datasource/SimpleDriverDataSource.html#setDriver(java.sql.Driver) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (DBCP-402) Add a way to set an instance of java.sql.Driver directly on org.apache.commons.dbcp2.BasicDataSource
[ https://issues.apache.org/jira/browse/DBCP-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DBCP-402. -- Resolution: Fixed Fix Version/s: 2.0 Add a way to set an instance of java.sql.Driver directly on org.apache.commons.dbcp2.BasicDataSource Key: DBCP-402 URL: https://issues.apache.org/jira/browse/DBCP-402 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 2.0 Reporter: Ben Hale Fix For: 2.0 Currently when org.apache.commons.dbcp2.BasicDataSource is directly instantiated (e.g. in an IoC environment), the only way to set the type of java.sql.Driver that is should use is by passing in a String classname which is then passed to DriverManager. The downside to this is that it requires the DataSource and the Driver to be in the same classloader. In practice many times the Driver is in the application classloader while the DataSource is in the container classloader meaning that other than packaging a Tomcat JAR in your application you cannot use the DataSource directly. It'd be great to have a way to pass the actual instance of Driver to the DataSource and have it use that instead of going to DriverManager to find it. This would enable standard classloader inheritance to work properly and allow the non-adjacent packaging of the Driver and DataSource. An example of this style of configuration can be found in Spring's SimpleDriverDataSource[1]. [1]: http://docs.spring.io/spring/docs/3.2.x/javadoc-api/org/springframework/jdbc/datasource/SimpleDriverDataSource.html#setDriver(java.sql.Driver) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (DBCP-385) Please update to support Java 7 and JDBC 4.1
[ https://issues.apache.org/jira/browse/DBCP-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DBCP-385. -- Resolution: Fixed Fix Version/s: 2.0 Please update to support Java 7 and JDBC 4.1 Key: DBCP-385 URL: https://issues.apache.org/jira/browse/DBCP-385 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Environment: Ubuntu 12.10/openjdk-7 Reporter: James Page Priority: Minor Fix For: 2.0 I'm currently working on the transition of all Java packages in Ubuntu from Java 6 to Java 7. This means we have to be able to build packages from source using openjdk-7. At the moment we carry a pretty heavy patch for commons-dbcp to no-op all of the new features in the JDBC 4.1 API. I know the Fedora Java team have done the same (they are the source of the patch). It would be great if commons-dbcp could be updated to meet these new API requirements. Thanks -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (DBCP-261) How can I use custom object pool?
[ https://issues.apache.org/jira/browse/DBCP-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DBCP-261. -- Resolution: Won't Fix The performance issues of Pool have been addressed as much as they can without API changes in Pool 1.x and 2.x is a complete re-write (with API changes). The refactoring necessary to allow any Pool implementation to be used in BasicDataSource is very invasive and unlikely to happen (the inactivity on this issue for over 5 years demonstrating that point). Since performance of Pool was the real issue here, I'd prefer to deal with that and I believe it has been dealt with in Pool 2. If further performance issues arise, we'll deal with them then. How can I use custom object pool? - Key: DBCP-261 URL: https://issues.apache.org/jira/browse/DBCP-261 Project: Commons Dbcp Issue Type: New Feature Reporter: Navis Fix For: 2.0 need some injection point of custom implementation replacing pathetically inefficient org.apache.commons.pool.impl.GenericObjectPool. thanks -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
Matthew Hall created BEANUTILS-450:
--
Summary: BeanUtilsBean.getInstance() pseudo-singleton causes
problems with Java 7 parallelized class loader
Key: BEANUTILS-450
URL: https://issues.apache.org/jira/browse/BEANUTILS-450
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils, ConvertUtils Converters
Affects Versions: 1.7.0
Reporter: Matthew Hall
Priority: Blocker
From an email I sent to the BeanUtils users mailing list:
We recently tracked a bug in our software that started showing up with Java 7
back to an incompatibility between BeanUtilsBean.getInstance() pseudo-singleton
instance model, Java 7’s parallelized class loader, and the fact that we were
registering Converters with ConvertUtils inside of a static class-level block.
As far as I’m able to tell, this wasn’t a problem in previous versions of Java
because the class loader was not parallelized, meaning that the class loader
that handled the registration of our converters was the same class loader that
was in use when ConvertUtilsBean.getInstance() was invoked. Now, with Java 7,
it seems that there is no guarantee that the class loader that executes the
static block containing the Converter registration is the same one in use when
ConvertUtilsBean.getInstance() is invoked, meaning that our custom Converters
are not necessarily available everywhere they used to be.
I’m writing to the list today to ask three things about this situation:
1. First off, is this the correct explanation for the reason that it seems
we’re not guaranteed to have our custom Converters loaded in Java 7.
2. In order to ensure that a different class loader thread is not in use when
the Converters are registered with ConvertUtils, we’ve moved this registration
from a static class-level block into a user interface setup method that is
executed before the Converters are used.
3. Given that Java 7 introduced parallelized class loading in the base
ClassLoader and that BeanUtilsBean builds instances on a per-classloader basis,
should this issue be raised to the BeanUtils developers?
Below you’ll find some pseudocode that illustrates our situation:
public class UtilitiesClass {
...
static {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = new MainGUIClass();
mainGui.setup();
mainGui.show();
}
public void setup() {
UIManager.setLookAndFeel(new LookAndFeelClass());
}
public void show() {
((OurLookAndFeelClass) UIManager.getLookAndFeel()).getColor();
}
...
}
public class LookAndFeelClass extends LookAndFeel {
...
public java.awt.Color getColor(String colorString) {
return (java.awt.Color) ConvertUtils.convert(someValidColorString,
java.awt.Color.class);
}
...
}
In the above example, the cast of the results of ConvertUtils.convert to Color
in LookAndFeelClass.getColor(String) sometimes results in a runtime exception
with the message “java.lang.String cannot be cast to java.awt.Color.”. This
appears to be due to the fact that ConvertUtils.convert() fails over to the
built-in String.class Converter if it cannot find a Converter for the specified
class. In production environments, it was completely unpredictable as to when
this would happen and what would make the problem go away.
The fix we implemented was to move the registration of
OurCustomColorConverter() from the static block inside of UtilitiesClass to the
first line of MainGUIClass.setup(), before the LookAndFeel is loaded. Will this
fix be sufficient, or does it still suffer from the thread issue, if that is
indeed the root cause of the problem?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew Hall updated BEANUTILS-450:
---
Environment: Java 7u25+, Windows 7 32-bit desktop environments
BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7
parallelized class loader
--
Key: BEANUTILS-450
URL: https://issues.apache.org/jira/browse/BEANUTILS-450
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils, ConvertUtils Converters
Affects Versions: 1.7.0
Environment: Java 7u25+, Windows 7 32-bit desktop environments
Reporter: Matthew Hall
Priority: Blocker
From an email I sent to the BeanUtils users mailing list:
We recently tracked a bug in our software that started showing up with Java 7
back to an incompatibility between BeanUtilsBean.getInstance()
pseudo-singleton instance model, Java 7’s parallelized class loader, and the
fact that we were registering Converters with ConvertUtils inside of a static
class-level block. As far as I’m able to tell, this wasn’t a problem in
previous versions of Java because the class loader was not parallelized,
meaning that the class loader that handled the registration of our converters
was the same class loader that was in use when ConvertUtilsBean.getInstance()
was invoked. Now, with Java 7, it seems that there is no guarantee that the
class loader that executes the static block containing the Converter
registration is the same one in use when ConvertUtilsBean.getInstance() is
invoked, meaning that our custom Converters are not necessarily available
everywhere they used to be.
I’m writing to the list today to ask three things about this situation:
1. First off, is this the correct explanation for the reason that it seems
we’re not guaranteed to have our custom Converters loaded in Java 7.
2. In order to ensure that a different class loader thread is not in use
when the Converters are registered with ConvertUtils, we’ve moved this
registration from a static class-level block into a user interface setup
method that is executed before the Converters are used.
3. Given that Java 7 introduced parallelized class loading in the base
ClassLoader and that BeanUtilsBean builds instances on a per-classloader
basis, should this issue be raised to the BeanUtils developers?
Below you’ll find some pseudocode that illustrates our situation:
public class UtilitiesClass {
...
static {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = new MainGUIClass();
mainGui.setup();
mainGui.show();
}
public void setup() {
UIManager.setLookAndFeel(new LookAndFeelClass());
}
public void show() {
((OurLookAndFeelClass) UIManager.getLookAndFeel()).getColor();
}
...
}
public class LookAndFeelClass extends LookAndFeel {
...
public java.awt.Color getColor(String colorString) {
return (java.awt.Color) ConvertUtils.convert(someValidColorString,
java.awt.Color.class);
}
...
}
In the above example, the cast of the results of ConvertUtils.convert to
Color in LookAndFeelClass.getColor(String) sometimes results in a runtime
exception with the message “java.lang.String cannot be cast to
java.awt.Color.”. This appears to be due to the fact that
ConvertUtils.convert() fails over to the built-in String.class Converter if
it cannot find a Converter for the specified class. In production
environments, it was completely unpredictable as to when this would happen
and what would make the problem go away.
The fix we implemented was to move the registration of
OurCustomColorConverter() from the static block inside of UtilitiesClass to
the first line of MainGUIClass.setup(), before the LookAndFeel is loaded.
Will this fix be sufficient, or does it still suffer from the thread issue,
if that is indeed the root cause of the problem?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew Hall updated BEANUTILS-450:
---
Description:
From an email I sent to the BeanUtils users mailing list:
We recently tracked a bug in our software that started showing up with Java 7
back to an incompatibility between BeanUtilsBean.getInstance() pseudo-singleton
instance model, Java 7’s parallelized class loader, and the fact that we were
registering Converters with ConvertUtils inside of a static class-level block.
As far as I’m able to tell, this wasn’t a problem in previous versions of Java
because the class loader was not parallelized, meaning that the class loader
that handled the registration of our converters was the same class loader that
was in use when ConvertUtilsBean.getInstance() was invoked. Now, with Java 7,
it seems that there is no guarantee that the class loader that executes the
static block containing the Converter registration is the same one in use when
ConvertUtilsBean.getInstance() is invoked, meaning that our custom Converters
are not necessarily available everywhere they used to be.
I’m writing to the list today to ask three things about this situation:
1. First off, is this the correct explanation for the reason that it seems
we’re not guaranteed to have our custom Converters loaded in Java 7.
2. In order to ensure that a different class loader thread is not in use when
the Converters are registered with ConvertUtils, we’ve moved this registration
from a static class-level block into a user interface setup method that is
executed before the Converters are used.
3. Given that Java 7 introduced parallelized class loading in the base
ClassLoader and that BeanUtilsBean builds instances on a per-classloader basis,
should this issue be raised to the BeanUtils developers?
Below you’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = new MainGUIClass();
mainGui.setup();
mainGui.show();
}
public void setup() {
UIManager.setLookAndFeel(new LookAndFeelClass());
}
public void show() {
((OurLookAndFeelClass) UIManager.getLookAndFeel()).getColor();
}
...
}
{code}
public class LookAndFeelClass extends LookAndFeel {
...
public java.awt.Color getColor(String colorString) {
return (java.awt.Color) ConvertUtils.convert(someValidColorString,
java.awt.Color.class);
}
...
}
In the above example, the cast of the results of ConvertUtils.convert to Color
in LookAndFeelClass.getColor(String) sometimes results in a runtime exception
with the message “java.lang.String cannot be cast to java.awt.Color.”. This
appears to be due to the fact that ConvertUtils.convert() fails over to the
built-in String.class Converter if it cannot find a Converter for the specified
class. In production environments, it was completely unpredictable as to when
this would happen and what would make the problem go away.
The fix we implemented was to move the registration of
OurCustomColorConverter() from the static block inside of UtilitiesClass to the
first line of MainGUIClass.setup(), before the LookAndFeel is loaded. Will this
fix be sufficient, or does it still suffer from the thread issue, if that is
indeed the root cause of the problem?
was:
From an email I sent to the BeanUtils users mailing list:
We recently tracked a bug in our software that started showing up with Java 7
back to an incompatibility between BeanUtilsBean.getInstance() pseudo-singleton
instance model, Java 7’s parallelized class loader, and the fact that we were
registering Converters with ConvertUtils inside of a static class-level block.
As far as I’m able to tell, this wasn’t a problem in previous versions of Java
because the class loader was not parallelized, meaning that the class loader
that handled the registration of our converters was the same class loader that
was in use when ConvertUtilsBean.getInstance() was invoked. Now, with Java 7,
it seems that there is no guarantee that the class loader that executes the
static block containing the Converter registration is the same one in use when
ConvertUtilsBean.getInstance() is invoked, meaning that our custom Converters
are not necessarily available everywhere they used to be.
I’m writing to the list today to ask three things about this situation:
1. First off, is this the correct explanation for the reason that it seems
we’re not guaranteed to have our custom Converters loaded in Java 7.
2. In order to ensure that a different class loader thread is not in use when
the Converters are registered with ConvertUtils, we’ve moved this
[jira] [Updated] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew Hall updated BEANUTILS-450:
---
Description:
From an email I sent to the BeanUtils users mailing list:
We recently tracked a bug in our software that started showing up with Java 7
back to an incompatibility between BeanUtilsBean.getInstance() pseudo-singleton
instance model, Java 7’s parallelized class loader, and the fact that we were
registering Converters with ConvertUtils inside of a static class-level block.
As far as I’m able to tell, this wasn’t a problem in previous versions of Java
because the class loader was not parallelized, meaning that the class loader
that handled the registration of our converters was the same class loader that
was in use when ConvertUtilsBean.getInstance() was invoked. Now, with Java 7,
it seems that there is no guarantee that the class loader that executes the
static block containing the Converter registration is the same one in use when
ConvertUtilsBean.getInstance() is invoked, meaning that our custom Converters
are not necessarily available everywhere they used to be.
I’m writing to the list today to ask three things about this situation:
1. First off, is this the correct explanation for the reason that it seems
we’re not guaranteed to have our custom Converters loaded in Java 7.
2. In order to ensure that a different class loader thread is not in use when
the Converters are registered with ConvertUtils, we’ve moved this registration
from a static class-level block into a user interface setup method that is
executed before the Converters are used.
3. Given that Java 7 introduced parallelized class loading in the base
ClassLoader and that BeanUtilsBean builds instances on a per-classloader basis,
should this issue be raised to the BeanUtils developers?
Below you’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = new MainGUIClass();
mainGui.setup();
mainGui.show();
}
public void setup() {
UIManager.setLookAndFeel(new LookAndFeelClass());
}
public void show() {
((OurLookAndFeelClass) UIManager.getLookAndFeel()).getColor();
}
...
}
public class LookAndFeelClass extends LookAndFeel {
...
public java.awt.Color getColor(String colorString) {
return (java.awt.Color) ConvertUtils.convert(someValidColorString,
java.awt.Color.class);
}
...
}
{code}
In the above example, the cast of the results of ConvertUtils.convert to Color
in LookAndFeelClass.getColor(String) sometimes results in a runtime exception
with the message “java.lang.String cannot be cast to java.awt.Color.”. This
appears to be due to the fact that ConvertUtils.convert() fails over to the
built-in String.class Converter if it cannot find a Converter for the specified
class. In production environments, it was completely unpredictable as to when
this would happen and what would make the problem go away.
The fix we implemented was to move the registration of
OurCustomColorConverter() from the static block inside of UtilitiesClass to the
first line of MainGUIClass.setup(), before the LookAndFeel is loaded. Will this
fix be sufficient, or does it still suffer from the thread issue, if that is
indeed the root cause of the problem?
was:
From an email I sent to the BeanUtils users mailing list:
We recently tracked a bug in our software that started showing up with Java 7
back to an incompatibility between BeanUtilsBean.getInstance() pseudo-singleton
instance model, Java 7’s parallelized class loader, and the fact that we were
registering Converters with ConvertUtils inside of a static class-level block.
As far as I’m able to tell, this wasn’t a problem in previous versions of Java
because the class loader was not parallelized, meaning that the class loader
that handled the registration of our converters was the same class loader that
was in use when ConvertUtilsBean.getInstance() was invoked. Now, with Java 7,
it seems that there is no guarantee that the class loader that executes the
static block containing the Converter registration is the same one in use when
ConvertUtilsBean.getInstance() is invoked, meaning that our custom Converters
are not necessarily available everywhere they used to be.
I’m writing to the list today to ask three things about this situation:
1. First off, is this the correct explanation for the reason that it seems
we’re not guaranteed to have our custom Converters loaded in Java 7.
2. In order to ensure that a different class loader thread is not in use when
the Converters are registered with ConvertUtils, we’ve moved this
[jira] [Commented] (IMAGING-121) Null Pointer exception while extracting metadata for CR2 image
[ https://issues.apache.org/jira/browse/IMAGING-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809529#comment-13809529 ] Damjan Jovanovic commented on IMAGING-121: -- Why would imageHeight be null? Is this a TIFF file or an JPEG EXIF thumbnail? Null Pointer exception while extracting metadata for CR2 image -- Key: IMAGING-121 URL: https://issues.apache.org/jira/browse/IMAGING-121 Project: Commons Imaging Issue Type: Bug Reporter: Piyush Kapoor Priority: Minor Attachments: Tiff.patch rowsPerStrip = imageHeight.getIntValue(); is getting a null pointer exception if imageHeight is null -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew Hall updated BEANUTILS-450:
---
Description:
From an email I sent to the BeanUtils users mailing list:
We recently tracked a bug in our software that started showing up with Java 7
back to an incompatibility between BeanUtilsBean.getInstance() pseudo-singleton
instance model, Java 7’s parallelized class loader, and the fact that we were
registering Converters with ConvertUtils inside of a static class-level block.
As far as I’m able to tell, this wasn’t a problem in previous versions of Java
because the class loader was not parallelized, meaning that the class loader
that handled the registration of our converters was the same class loader that
was in use when ConvertUtilsBean.getInstance() was invoked. Now, with Java 7,
it seems that there is no guarantee that the class loader that executes the
static block containing the Converter registration is the same one in use when
ConvertUtilsBean.getInstance() is invoked, meaning that our custom Converters
are not necessarily available everywhere they used to be.
I’m writing to the list today to ask three things about this situation:
1. First off, is this the correct explanation for the reason that it seems
we’re not guaranteed to have our custom Converters loaded in Java 7.
2. In order to ensure that a different class loader thread is not in use when
the Converters are registered with ConvertUtils, we’ve moved this registration
from a static class-level block into a user interface setup method that is
executed before the Converters are used.
3. Given that Java 7 introduced parallelized class loading in the base
ClassLoader and that BeanUtilsBean builds instances on a per-classloader basis,
should this issue be raised to the BeanUtils developers?
Below you’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
registerConverters();
}
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = new MainGUIClass();
mainGui.setup();
mainGui.show();
}
public void setup() {
UIManager.setLookAndFeel(new LookAndFeelClass());
}
public void show() {
((OurLookAndFeelClass) UIManager.getLookAndFeel()).getColor();
}
...
}
public class LookAndFeelClass extends LookAndFeel {
...
public java.awt.Color getColor(String colorString) {
return (java.awt.Color) ConvertUtils.convert(someValidColorString,
java.awt.Color.class);
}
...
}
{code}
In the above example, the cast of the results of ConvertUtils.convert to Color
in LookAndFeelClass.getColor(String) sometimes results in a runtime exception
with the message “java.lang.String cannot be cast to java.awt.Color.”. This
appears to be due to the fact that ConvertUtils.convert() fails over to the
built-in String.class Converter if it cannot find a Converter for the specified
class. In production environments, it was completely unpredictable as to when
this would happen and what would make the problem go away.
The fix we implemented was to move the registration of
OurCustomColorConverter() from the static block inside of UtilitiesClass to the
first line of MainGUIClass.setup(), before the LookAndFeel is loaded. Will this
fix be sufficient, or does it still suffer from the thread issue, if that is
indeed the root cause of the problem?
was:
From an email I sent to the BeanUtils users mailing list:
We recently tracked a bug in our software that started showing up with Java 7
back to an incompatibility between BeanUtilsBean.getInstance() pseudo-singleton
instance model, Java 7’s parallelized class loader, and the fact that we were
registering Converters with ConvertUtils inside of a static class-level block.
As far as I’m able to tell, this wasn’t a problem in previous versions of Java
because the class loader was not parallelized, meaning that the class loader
that handled the registration of our converters was the same class loader that
was in use when ConvertUtilsBean.getInstance() was invoked. Now, with Java 7,
it seems that there is no guarantee that the class loader that executes the
static block containing the Converter registration is the same one in use when
ConvertUtilsBean.getInstance() is invoked, meaning that our custom Converters
are not necessarily available everywhere they used to be.
I’m writing to the list today to ask three things about this situation:
1. First off, is this the correct explanation for the reason that it seems
we’re not guaranteed to have our custom Converters loaded in Java 7.
2. In order to ensure that a different class loader thread is not in use
[jira] [Commented] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809538#comment-13809538
]
Matthew Hall commented on BEANUTILS-450:
We originally suspected this issue to be caused by the fact that we were
calling our converter registration method from within a static block, so we
moved the registration into the MainGUIClass setup function, like so:
{code}
public class UtilitiesClass {
...
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = new MainGUIClass();
mainGui.setup();
mainGui.show();
}
public void setup() {
UtilitiesClass.registerConverters();
UIManager.setLookAndFeel(new LookAndFeelClass());
}
public void show() {
((OurLookAndFeelClass) UIManager.getLookAndFeel()).getColor();
}
...
}
public class LookAndFeelClass extends LookAndFeel {
...
public java.awt.Color getColor(String colorString) {
return (java.awt.Color) ConvertUtils.convert(someValidColorString,
java.awt.Color.class);
}
...
}
{code}
This change has not solved the issue. I've marked this ticket as a blocker
because we do have applications in production that cannot launch due to this
problem, when it appears. We're also concerned that other converters we use in
our system for date and time format conversions are potentially impacted by
this issue as well. We currently haven't made any changes to how those are
registered, though.
One other thing that might be important to note is that we've discovered that
enabling the Java console seems to mitigate the issue.
BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7
parallelized class loader
--
Key: BEANUTILS-450
URL: https://issues.apache.org/jira/browse/BEANUTILS-450
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils, ConvertUtils Converters
Affects Versions: 1.7.0
Environment: Java 7u25+, Windows 7 32-bit desktop environments
Reporter: Matthew Hall
Priority: Blocker
From an email I sent to the BeanUtils users mailing list:
We recently tracked a bug in our software that started showing up with Java 7
back to an incompatibility between BeanUtilsBean.getInstance()
pseudo-singleton instance model, Java 7’s parallelized class loader, and the
fact that we were registering Converters with ConvertUtils inside of a static
class-level block. As far as I’m able to tell, this wasn’t a problem in
previous versions of Java because the class loader was not parallelized,
meaning that the class loader that handled the registration of our converters
was the same class loader that was in use when ConvertUtilsBean.getInstance()
was invoked. Now, with Java 7, it seems that there is no guarantee that the
class loader that executes the static block containing the Converter
registration is the same one in use when ConvertUtilsBean.getInstance() is
invoked, meaning that our custom Converters are not necessarily available
everywhere they used to be.
I’m writing to the list today to ask three things about this situation:
1. First off, is this the correct explanation for the reason that it seems
we’re not guaranteed to have our custom Converters loaded in Java 7.
2. In order to ensure that a different class loader thread is not in use
when the Converters are registered with ConvertUtils, we’ve moved this
registration from a static class-level block into a user interface setup
method that is executed before the Converters are used.
3. Given that Java 7 introduced parallelized class loading in the base
ClassLoader and that BeanUtilsBean builds instances on a per-classloader
basis, should this issue be raised to the BeanUtils developers?
Below you’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
registerConverters();
}
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = new MainGUIClass();
mainGui.setup();
mainGui.show();
}
public void setup() {
UIManager.setLookAndFeel(new LookAndFeelClass());
}
public void show() {
((OurLookAndFeelClass) UIManager.getLookAndFeel()).getColor();
}
...
}
public class LookAndFeelClass extends LookAndFeel {
...
public java.awt.Color
[jira] [Commented] (MATH-1050) Deprecate pow(int, long) and pow(long,long) in ArithmeticUtils
[ https://issues.apache.org/jira/browse/MATH-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809572#comment-13809572 ] Gilles commented on MATH-1050: -- Deprecation introduced in revision 1537279. Methods to be removed before releasing the next major version. Deprecate pow(int, long) and pow(long,long) in ArithmeticUtils Key: MATH-1050 URL: https://issues.apache.org/jira/browse/MATH-1050 Project: Commons Math Issue Type: Task Affects Versions: 3.2 Reporter: Gilles Assignee: Gilles Priority: Trivial Labels: API, deprecation Fix For: 4.0, 3.3 Those two methods uses a long for the exponent, but overflow will occur when the exponent is larger than 31 (except for the trivial case where the base is 1). See also [this thread|http://markmail.org/message/nhnst5eryqyudxfy] on the dev ML. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (MATH-1047) No check for overflow in ArithmeticUtils.pow
[ https://issues.apache.org/jira/browse/MATH-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809685#comment-13809685 ] Gilles edited comment on MATH-1047 at 10/30/13 10:08 PM: - Method pow(long,int) modified in revision 1537324 (using mulAndCheck(long,long)). If a more efficient version is needed (possibly without safety check), it will need to be reimplemented with another name, and documentation that clearly indicates the purpose and caveat. was (Author: erans): Method pow(long,long) modified in revision 1537324 (using mulAndCheck(long,long)). If a more efficient version is needed (possibly without safety check), it will need to be reimplemented with another name, and documentation that clearly indicates the purpose and caveat. No check for overflow in ArithmeticUtils.pow -- Key: MATH-1047 URL: https://issues.apache.org/jira/browse/MATH-1047 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Gilles Labels: safety Fix For: 3.3 Attachments: MATH-1047.patch The pow methods in o.a.c.m.util.ArithmeticUtils do not check for overflow. They will happily return nonsensical results. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (IMAGING-120) Extract an interface from ImageFormat
[
https://issues.apache.org/jira/browse/IMAGING-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved IMAGING-120.
-
Resolution: Fixed
Assignee: Matt Benson
Committed revision 1537329.
Extract an interface from ImageFormat
-
Key: IMAGING-120
URL: https://issues.apache.org/jira/browse/IMAGING-120
Project: Commons Imaging
Issue Type: Improvement
Affects Versions: 0.97
Reporter: Matt Benson
Assignee: Matt Benson
Fix For: 1.0
Attachments: IMAGING-120.patch2.txt, IMAGING-120.patch.txt
As discussed on the dev@commons ML, this would allow users to create custom
image formats while permitting the known image formats to be represented by
the {{ImageFormat enum}}.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (FUNCTOR-29) Drop support to serialization
Bruno P. Kinoshita created FUNCTOR-29: - Summary: Drop support to serialization Key: FUNCTOR-29 URL: https://issues.apache.org/jira/browse/FUNCTOR-29 Project: Commons Functor Issue Type: Improvement Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Priority: Minor [functor]'s API right now has many classes implementing Serializable. Several other commons components have already dropped support to serialization, and it can be tricky to maintain compatibility and serialization. As proposed in [1], we could focus in the functional API details and drop serialization (i.e. remove Serializable interface and update tests and classes). [1] http://markmail.org/thread/lrt34dcpynzfxl7n -- This message was sent by Atlassian JIRA (v6.1#6144)
