[jira] [Commented] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162071#comment-13162071
]
Simone Tripodi commented on CHAIN-58:
-
Hi Elijah!
just to keep you updated how I am reviewing the patch: the main point IMHO is
that the signature {{interface CommandC extends Context?, ?}} circumvents
the benefit of having Generics in the {{Context}}, I think that as user we have
to get benefits inside the {{Command}} instances since we don't have to know
which key/value type while performing the {{execute()}} method.
So, I would like to move to a less type agnostic {{Command}} implementation:
what's your opinion about that?
Many thanks in advance!
Update Chain Context interface to use K,V generics
--
Key: CHAIN-58
URL: https://issues.apache.org/jira/browse/CHAIN-58
Project: Commons Chain
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Elijah Zupancic
Fix For: 2.0
Attachments: chain-58.diff
As discussed in the mailing list, I am suggesting that we change the
definition of Context from:
{noformat}
public interface Context extends MapString, Object {
{noformat}
to:
{noformat}
public interface ContextK, V extends MapK, V {
{noformat}
--
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-703) Splitting up the distribution hierarchy
[ https://issues.apache.org/jira/browse/MATH-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Winter resolved MATH-703. --- Resolution: Fixed Splitting up the distribution hierarchy --- Key: MATH-703 URL: https://issues.apache.org/jira/browse/MATH-703 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2 Reporter: Christian Winter Priority: Minor Fix For: 3.0 Attachments: MATH-703_patch.zip, MATH-703_patch2.zip As discussed on the mailing list (http://apache-commons.680414.n4.nabble.com/math-Distributions-over-sample-spaces-other-than-R-tp3931349p3931349.html), the distribution interfaces should be restructured. The most important point is to create one root interface for each domain. There should *not* be a common super-interace because different domains require different functionality. Additionally, a super-inferface would require to parametrize the domain which makes things more complicated (e.g., double would have to be replaced by Double). Currently, Commons Math supports distributions with real domain and distributions with integer domain. Thus there will be the interfaces RealDistribution and IntegerDistribution. Another point is to drop the special cases of distributions with real domain in order to simplify the structure. There won't be an interface for absolutely continuous distributions, and there won't be an interface for discrete distributions on the real domain. All the functionality required by the special cases can be defined in RealDistribution. -- 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-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[
https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162169#comment-13162169
]
Sébastien Brisard commented on MATH-699:
New implementation (+ unit tests) committed in {{r1209942}}.
{{getDomainLowerBound(double)}}, {{getDomainUpperBound(double)}} and
{{getInitialDomain(double p)}} have now become superfluous.
inverseCumulativeDistribution fails with cumulative distribution having a
plateau
-
Key: MATH-699
URL: https://issues.apache.org/jira/browse/MATH-699
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.2
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Priority: Minor
Fix For: 3.0
Attachments: AbstractContinuousDistributionTest.java,
inv-cum-new-impl.zip
This bug report follows MATH-692. The attached unit test fails. As required
by the definition in MATH-692, the lower-bound of the interval on which the
cdf is constant should be returned. This is not so at the moment.
--
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] (SANSELAN-53) Bug in Sanselan.getImageInfo(File) with certain JPEGs causing java.lang.OutOfMemoryError or java.lang.NegativeArraySizeException
[ https://issues.apache.org/jira/browse/SANSELAN-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damjan Jovanovic resolved SANSELAN-53. -- Resolution: Fixed I've worked around even NegativeArraySizeException in commit 1209945. Resolving fixed. Bug in Sanselan.getImageInfo(File) with certain JPEGs causing java.lang.OutOfMemoryError or java.lang.NegativeArraySizeException Key: SANSELAN-53 URL: https://issues.apache.org/jira/browse/SANSELAN-53 Project: Commons Sanselan Issue Type: Bug Affects Versions: 0.94-incubator Environment: Windows, Unix Sun Java JVM (multiple versions) Reporter: Dominic Early Attachments: NegativeArraySizeException.jpg, OutOfMemoryError.jpg, SanselanTest.java, SanselanTest.java In order to extract JPEG image dimensions, Apache Commons Sanselan (0.97) was used as follows: File imgfile = new File(./test.jpg); org.apache.sanselan.Sanselan.getImageInfo(imgfile); For most JPEG images, this code works as expected. However with specific JPEG files, the call to getImageInfo() causes a repeatable java.lang.OutOfMemoryError or java.lang.NegativeArraySizeException - depending upon the input JPEG file. The same files can be processed with javax.imageio.ImageReader without such issues. The OutOfMemoryError is especially serious as it may cause JVM to fail. -- 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] (COMPRESS-163) Unable to extract a file larger than 8GB from a Posix-format tar archive
Unable to extract a file larger than 8GB from a Posix-format tar archive Key: COMPRESS-163 URL: https://issues.apache.org/jira/browse/COMPRESS-163 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.3 Environment: The tar archive used for testing was created by GNU tar, but the problem will occur with any Posix-formatted tar file containing files over 8GB in size. Reporter: John Kodis Priority: Minor Fix For: 1.3 An attempt to read a posix-format tar archive containing a file in excess of 8^11 bytes in size will fail with a Size out of range illegal argument exception. -- 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-163) Unable to extract a file larger than 8GB from a Posix-format tar archive
[ https://issues.apache.org/jira/browse/COMPRESS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Kodis updated COMPRESS-163: Attachment: 0003-Allow-reading-large-files-from-Posix-tar-archives.patch An attempt to read a posix-format tar archive containing a file in excess of 8^11 bytes in size will fail with a Size out of range illegal argument exception. We correct this by dropping the test for a too-large value in the TarArchiveEntry.setSize method, and making the corresponding modifications to the testMaxFileSize() junit test. Finally, in the getNextTarEntry method, we set the entrySize instance variable an additional time to pick up any larger size that may have been obtained as a result of processing any Posix Pax headers. Unable to extract a file larger than 8GB from a Posix-format tar archive Key: COMPRESS-163 URL: https://issues.apache.org/jira/browse/COMPRESS-163 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.3 Environment: The tar archive used for testing was created by GNU tar, but the problem will occur with any Posix-formatted tar file containing files over 8GB in size. Reporter: John Kodis Priority: Minor Fix For: 1.3 Attachments: 0003-Allow-reading-large-files-from-Posix-tar-archives.patch Original Estimate: 24h Remaining Estimate: 24h An attempt to read a posix-format tar archive containing a file in excess of 8^11 bytes in size will fail with a Size out of range illegal argument exception. -- 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] (DIGESTER-153) Add Constructor support to ObjectCreateRule
[ https://issues.apache.org/jira/browse/DIGESTER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved DIGESTER-153. -- Resolution: Fixed Committed revision 1209953. Add Constructor support to ObjectCreateRule --- Key: DIGESTER-153 URL: https://issues.apache.org/jira/browse/DIGESTER-153 Project: Commons Digester Issue Type: Improvement Affects Versions: 3.2 Reporter: Simone Tripodi Assignee: Simone Tripodi Fix For: 3.2 As shown in the past, the stack method of Digester has some [limitations |http://markmail.org/message/wick27gw6n5weqk2] for fully support the Constructors - it basically cannot use elements in the body as constructor arguments - but it could support arguments extracted from attributes. -- 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] [Issue Comment Edited] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[
https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162169#comment-13162169
]
Sébastien Brisard edited comment on MATH-699 at 12/3/11 6:25 PM:
-
New implementation (+ unit tests) committed in {{r1209942}}.
{{getDomainLowerBound(double)}}, {{getDomainUpperBound(double)}} and
{{getInitialDomain(double p)}} have now become superfluous: removed in
{{r1209963}}.
The same kind of approach might probably be adopted for
{{IntegerDistribution}}. I suggest we look into it before we resolve this issue.
was (Author: celestin):
New implementation (+ unit tests) committed in {{r1209942}}.
{{getDomainLowerBound(double)}}, {{getDomainUpperBound(double)}} and
{{getInitialDomain(double p)}} have now become superfluous.
inverseCumulativeDistribution fails with cumulative distribution having a
plateau
-
Key: MATH-699
URL: https://issues.apache.org/jira/browse/MATH-699
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.2
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Priority: Minor
Fix For: 3.0
Attachments: AbstractContinuousDistributionTest.java,
inv-cum-new-impl.zip
This bug report follows MATH-692. The attached unit test fails. As required
by the definition in MATH-692, the lower-bound of the interval on which the
cdf is constant should be returned. This is not so at the moment.
--
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] (DIGESTER-153) Add Constructor support to ObjectCreateRule
[ https://issues.apache.org/jira/browse/DIGESTER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162196#comment-13162196 ] Simone Tripodi commented on DIGESTER-153: - what a pleasant surprise, thanks a lot Matt! you made my weekend! :) Add Constructor support to ObjectCreateRule --- Key: DIGESTER-153 URL: https://issues.apache.org/jira/browse/DIGESTER-153 Project: Commons Digester Issue Type: Improvement Affects Versions: 3.2 Reporter: Simone Tripodi Assignee: Simone Tripodi Fix For: 3.2 As shown in the past, the stack method of Digester has some [limitations |http://markmail.org/message/wick27gw6n5weqk2] for fully support the Constructors - it basically cannot use elements in the body as constructor arguments - but it could support arguments extracted from attributes. -- 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] (DIGESTER-153) Add Constructor support to ObjectCreateRule
[
https://issues.apache.org/jira/browse/DIGESTER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi reopened DIGESTER-153:
-
sorry for bugging again on this, unfortunately there still is a case where the
lazy loader fails ;(
When classes have not the default empty constructor, CGLIB complains
{code}
java.lang.IllegalArgumentException: Superclass has no null constructors but no
arguments were given
at net.sf.cglib.proxy.Enhancer.emitConstructors(Enhancer.java:721)
at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:499)
at
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:285)
at
org.apache.commons.digester3.ObjectCreateRule.createLazyProxy(ObjectCreateRule.java:283)
at
org.apache.commons.digester3.ObjectCreateRule.begin(ObjectCreateRule.java:262)
at
org.apache.commons.digester3.Digester.startElement(Digester.java:1350)
{code}
you can test it simply by removing the empty constructor in
{{org.apache.commons.digester3.TestBean}}
Thanks a lot for your help in advance!
Add Constructor support to ObjectCreateRule
---
Key: DIGESTER-153
URL: https://issues.apache.org/jira/browse/DIGESTER-153
Project: Commons Digester
Issue Type: Improvement
Affects Versions: 3.2
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 3.2
As shown in the past, the stack method of Digester has some [limitations
|http://markmail.org/message/wick27gw6n5weqk2] for fully support the
Constructors - it basically cannot use elements in the body as constructor
arguments - but it could support arguments extracted from attributes.
--
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] (DIGESTER-153) Add Constructor support to ObjectCreateRule
[ https://issues.apache.org/jira/browse/DIGESTER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1316#comment-1316 ] Matt Benson commented on DIGESTER-153: -- Rather I would say that the no-arg constructor is a requirement when this functionality is desired. Otherwise [digester]'s internal design would have to change quite a bit! Add Constructor support to ObjectCreateRule --- Key: DIGESTER-153 URL: https://issues.apache.org/jira/browse/DIGESTER-153 Project: Commons Digester Issue Type: Improvement Affects Versions: 3.2 Reporter: Simone Tripodi Assignee: Simone Tripodi Fix For: 3.2 As shown in the past, the stack method of Digester has some [limitations |http://markmail.org/message/wick27gw6n5weqk2] for fully support the Constructors - it basically cannot use elements in the body as constructor arguments - but it could support arguments extracted from attributes. -- 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] (DIGESTER-153) Add Constructor support to ObjectCreateRule
[ https://issues.apache.org/jira/browse/DIGESTER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162226#comment-13162226 ] Matt Benson commented on DIGESTER-153: -- Well, that's not exactly true. We *could* attempt to call the constructor we know about with null/0/false args, but there's no guarantee such a constructor wouldn't throw an exception. I will work on this next. Add Constructor support to ObjectCreateRule --- Key: DIGESTER-153 URL: https://issues.apache.org/jira/browse/DIGESTER-153 Project: Commons Digester Issue Type: Improvement Affects Versions: 3.2 Reporter: Simone Tripodi Assignee: Simone Tripodi Fix For: 3.2 As shown in the past, the stack method of Digester has some [limitations |http://markmail.org/message/wick27gw6n5weqk2] for fully support the Constructors - it basically cannot use elements in the body as constructor arguments - but it could support arguments extracted from attributes. -- 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] (DIGESTER-153) Add Constructor support to ObjectCreateRule
[ https://issues.apache.org/jira/browse/DIGESTER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162227#comment-13162227 ] Simone Tripodi commented on DIGESTER-153: - thanks a lot Matt, you are actually my hero, I really appreciate your help! :) Add Constructor support to ObjectCreateRule --- Key: DIGESTER-153 URL: https://issues.apache.org/jira/browse/DIGESTER-153 Project: Commons Digester Issue Type: Improvement Affects Versions: 3.2 Reporter: Simone Tripodi Assignee: Simone Tripodi Fix For: 3.2 As shown in the past, the stack method of Digester has some [limitations |http://markmail.org/message/wick27gw6n5weqk2] for fully support the Constructors - it basically cannot use elements in the body as constructor arguments - but it could support arguments extracted from attributes. -- 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] (DIGESTER-159) */object-param-rule is not managed in the XML rules
*/object-param-rule is not managed in the XML rules
---
Key: DIGESTER-159
URL: https://issues.apache.org/jira/browse/DIGESTER-159
Project: Commons Digester
Issue Type: Bug
Affects Versions: 3.2
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Priority: Critical
XML metaparser never matches {{*/object-param-rule}} rules in xmlrules
descriptors, neither the related {{ObjectCreateRule}} is managed.
What is weird is that tests have never failed before... :/
--
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] (DIGESTER-159) */object-param-rule is not managed in the XML rules
[
https://issues.apache.org/jira/browse/DIGESTER-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved DIGESTER-159.
-
Resolution: Fixed
Fix Version/s: 3.2
fixed on trunk, see
[r1210032|https://svn.apache.org/viewvc?view=revisionrevision=1210032]
*/object-param-rule is not managed in the XML rules
---
Key: DIGESTER-159
URL: https://issues.apache.org/jira/browse/DIGESTER-159
Project: Commons Digester
Issue Type: Bug
Affects Versions: 3.2
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Priority: Critical
Fix For: 3.2
XML metaparser never matches {{*/object-param-rule}} rules in xmlrules
descriptors, neither the related {{ObjectCreateRule}} is managed.
What is weird is that tests have never failed before... :/
--
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-718) inverseCumulativeProbability of BinomialDistribution returns wrong value for large trials.
inverseCumulativeProbability of BinomialDistribution returns wrong value for
large trials.
--
Key: MATH-718
URL: https://issues.apache.org/jira/browse/MATH-718
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.2, 3.0
Reporter: Yuji Uchiyama
The inverseCumulativeProbability method of the BinomialDistributionImpl class
returns wrong value for large trials. Following code will be reproduce the
problem.
{{System.out.println(new BinomialDistributionImpl(100,
0.5).inverseCumulativeProbability(0.5));}}
This returns 499525, though it should be 49.
I'm not sure how it should be fixed, but the cause is that the
cumulativeProbability method returns Infinity, not NaN. As the result the
checkedCumulativeProbability method doesn't work as expected.
--
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] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162250#comment-13162250
]
Elijah Zupancic commented on CHAIN-58:
--
What type signature are you suggesting? Originally, that is what I wanted to do
as well. Could you post an example on how you would like to do this?
Update Chain Context interface to use K,V generics
--
Key: CHAIN-58
URL: https://issues.apache.org/jira/browse/CHAIN-58
Project: Commons Chain
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Elijah Zupancic
Fix For: 2.0
Attachments: chain-58.diff
As discussed in the mailing list, I am suggesting that we change the
definition of Context from:
{noformat}
public interface Context extends MapString, Object {
{noformat}
to:
{noformat}
public interface ContextK, V extends MapK, V {
{noformat}
--
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] (SANSELAN-13) Problem loading JPEG metada
[ https://issues.apache.org/jira/browse/SANSELAN-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damjan Jovanovic resolved SANSELAN-13. -- Resolution: Fixed My tests with the latest SVN show that getting metadata works - provided you explicitly disable fetching the thumbnail (which is corrupt in those images): Map params = new HashMap(); params.put(Sanselan.PARAM_KEY_READ_THUMBNAILS, Boolean.FALSE); IImageMetadata metadata = Sanselan.getMetadata(file, params); Resolving fixed. Problem loading JPEG metada --- Key: SANSELAN-13 URL: https://issues.apache.org/jira/browse/SANSELAN-13 Project: Commons Sanselan Issue Type: Question Reporter: Bruno Abreu Priority: Minor Attachments: 10200023566.jpg, 10200023936.jpg I'm trying to load the metadata from image files generated by a JAI-PULNIX camera, model TS-1327EN. I am specifically interested in getting the following tag values: ExifTagConstants.EXIF_TAG_IMAGE_DESCRIPTION, ExifTagConstants.EXIF_TAG_DATE_TIME_ORIGINAL and ExifTagConstants.EXIF_TAG_SUB_SEC_TIME_ORIGINAL. But, when the following line of code is executed: IImageMetadata metadata = Sanselan.getMetadata(file); I get one of two errors: java.io.IOException: Invalid Segment: insufficient data at org.apache.sanselan.common.BinaryFileFunctions.readByteArray(BinaryFileFunctions.java:497) at org.apache.sanselan.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:88) at org.apache.sanselan.formats.jpeg.JpegImageParser.readSegments(JpegImageParser.java:175) at org.apache.sanselan.formats.jpeg.JpegImageParser.readSegments(JpegImageParser.java:273) at org.apache.sanselan.formats.jpeg.JpegImageParser.getExifRawData(JpegImageParser.java:383) at org.apache.sanselan.formats.jpeg.JpegImageParser.getExifMetadata(JpegImageParser.java:363) at org.apache.sanselan.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:314) at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:871) at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:864) at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:839) at MetadataExample.metadataExample(MetadataExample.java:21) or java.io.IOException: Could not read block (block start: 1020, block length: 1447680, data length: 900). at org.apache.sanselan.common.byteSources.ByteSourceArray.getBlock(ByteSourceArray.java:47) at org.apache.sanselan.formats.tiff.TiffReader.getTiffRawImageData(TiffReader.java:409) at org.apache.sanselan.formats.tiff.TiffReader.readDirectory(TiffReader.java:197) at org.apache.sanselan.formats.tiff.TiffReader.readDirectory(TiffReader.java:100) at org.apache.sanselan.formats.tiff.TiffReader.readDirectories(TiffReader.java:92) at org.apache.sanselan.formats.tiff.TiffReader.read(TiffReader.java:399) at org.apache.sanselan.formats.tiff.TiffReader.readContents(TiffReader.java:390) at org.apache.sanselan.formats.tiff.TiffImageParser.getMetadata(TiffImageParser.java:125) at org.apache.sanselan.ImageParser.getMetadata(ImageParser.java:76) at org.apache.sanselan.formats.jpeg.JpegImageParser.getExifMetadata(JpegImageParser.java:376) at org.apache.sanselan.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:314) at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:871) at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:864) at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:839) at MetadataExample.metadataExample(MetadataExample.java:21) Is there something wrong with the encoding of these images? If that is the case I could contact JAI-PULNIX and ask them to fix it, but I'm not sure what the problem is. -- 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
