date:20171030

[jira] [Comment Edited] (JEXL-243) Allow restricting available features in Script/Expressions

2017-10-30 Thread Dmitri Blinov (JIRA)


[ 
https://issues.apache.org/jira/browse/JEXL-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226276#comment-16226276
 ] 

Dmitri Blinov edited comment on JEXL-243 at 10/31/17 5:56 AM:
--

Well, this basically works, the only thing is what if I have in one framework 
two different types of scripts, say scripts with side effects and scripts 
without side effects (or better to name them getters and setters). Those types 
of scripts are supposed to use a single Jexl engine instance. It would be more 
practical to be able to specify desired features right to 
JexlEngine.createScript() method. Maybe JexlEngine.createExpression() should 
get such an overload too, but maybe it's even better, not to speak of backward 
compatibility now, to have the only one JexlEngine.createScript() which could 
create both "scripts" and "expressions" by simply specifying "right" feature 
sets in each case.


was (Author: dmitri_blinov):
Well, this is basically works, the only thing is what if I have in one 
framework two different types of scripts, say scripts with side effects and 
scripts without side effects (or better to name them getters and setters). 
Those types of scripts are supposed to use a single Jexl engine instance. It 
would be more practical to be able to specify desired features right to 
JexlEngine.createScript() method. Maybe JexlEngine.createExpression() should 
get such an overload too, but maybe it's even better, not to speak of backward 
compatibility now, to have the only one JexlEngine.createScript() which could 
create both "scripts" and "expressions" by simply specifying "right" feature 
sets in each case.

> Allow restricting available features in Script/Expressions
> --
>
> Key: JEXL-243
> URL: https://issues.apache.org/jira/browse/JEXL-243
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
> Fix For: 3.2
>
>
> Restrict features related to potential dangers/difficulties one may encounter 
> whilst scripting;
> Reserved Names: a set of reserved variable names that can not be used as 
> local variable (or parameter) names
> Registers: boolean property allowing parsing of register syntax (#number)
> Global Side Effect : boolean property controlling assigning/modifying values 
> on global variables
> Side Effect: boolean property controlling side effects assigning/modifying 
> values on any variable
> New Instance: boolean property controlling creating new instances through 
> new(...) or using class as functor
> Loops: boolean property controlling usage of loop constructs (while(true), 
> for(...))
> Lambda: boolean property controlling usage of script function declarations
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JEXL-243) Allow restricting available features in Script/Expressions

2017-10-30 Thread Dmitri Blinov (JIRA)


[ 
https://issues.apache.org/jira/browse/JEXL-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226276#comment-16226276
 ] 

Dmitri Blinov commented on JEXL-243:


Well, this is basically works, the only thing is what if I have in one 
framework two different types of scripts, say scripts with side effects and 
scripts without side effects (or better to name them getters and setters). 
Those types of scripts are supposed to use a single Jexl engine instance. It 
would be more practical to be able to specify desired features right to 
JexlEngine.createScript() method. Maybe JexlEngine.createExpression() should 
get such an overload too, but maybe it's even better, not to speak of backward 
compatibility now, to have the only one JexlEngine.createScript() which could 
create both "scripts" and "expressions" by simply specifying "right" feature 
sets in each case.

> Allow restricting available features in Script/Expressions
> --
>
> Key: JEXL-243
> URL: https://issues.apache.org/jira/browse/JEXL-243
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
> Fix For: 3.2
>
>
> Restrict features related to potential dangers/difficulties one may encounter 
> whilst scripting;
> Reserved Names: a set of reserved variable names that can not be used as 
> local variable (or parameter) names
> Registers: boolean property allowing parsing of register syntax (#number)
> Global Side Effect : boolean property controlling assigning/modifying values 
> on global variables
> Side Effect: boolean property controlling side effects assigning/modifying 
> values on any variable
> New Instance: boolean property controlling creating new instances through 
> new(...) or using class as functor
> Loops: boolean property controlling usage of loop constructs (while(true), 
> for(...))
> Lambda: boolean property controlling usage of script function declarations
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang issue #299: Add module-info for Java 9

2017-10-30 Thread coveralls

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/299
  

[![Coverage 
Status](https://coveralls.io/builds/13963478/badge)](https://coveralls.io/builds/13963478)

Coverage decreased (-0.02%) to 95.163% when pulling 
**313723da37a87a683683ff5edab139cf10612573 on jodastephen:module-info** into 
**1f0dfc31b51a445eb2cfbee5321800cf51e10b67 on apache:master**.



---

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

2017-10-30 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226172#comment-16226172
 ] 

ASF GitHub Bot commented on COMMONSRDF-66:
--

Github user wikier commented on a diff in the pull request:

https://github.com/apache/commons-rdf/pull/42#discussion_r147886874
  
--- Diff: 
jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java ---
@@ -149,7 +149,7 @@ public long size() {
 @Override
 public String toString() {
 final StringWriter sw = new StringWriter();
-RDFDataMgr.write(sw, graph, Lang.NT);
--- End diff --

Attribute already renamed in `master` (see 151a8ea). 

So, please, rebase this PR to the current `HEAD` so we can ship this patch 
in the imminent `0.5.0` release. 


> JenaDatasetImpl.toString() throws RIOT exception
> 
>
> Key: COMMONSRDF-66
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-66
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: jena
>Affects Versions: 0.3.0
>Reporter: Christopher Johnson
>Assignee: Sergio Fernández
> Fix For: 0.5.0
>
>
> Occurs from this method 
> [https://github.com/apache/commons-rdf/blob/master/jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java#L152]
>  on instantiation:
> The exception message is "No dataset writer for N-Triples/utf-8".
> The source is RDFWriterRegistry that builds a registryDataset HashMap of 17 
> +Dataset+ RDFFormats that does not include this serialization.  The 
> registryGraph HashMap has 25 RDFFormats that does include "N-Triples/utf-8".
> No exception is thrown if Lang.NQUADS is set in the toString() method.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

2017-10-30 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergio Fernández updated COMMONSRDF-66:
---
Assignee: Sergio Fernández

> JenaDatasetImpl.toString() throws RIOT exception
> 
>
> Key: COMMONSRDF-66
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-66
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: jena
>Affects Versions: 0.3.0
>Reporter: Christopher Johnson
>Assignee: Sergio Fernández
> Fix For: 0.5.0
>
>
> Occurs from this method 
> [https://github.com/apache/commons-rdf/blob/master/jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java#L152]
>  on instantiation:
> The exception message is "No dataset writer for N-Triples/utf-8".
> The source is RDFWriterRegistry that builds a registryDataset HashMap of 17 
> +Dataset+ RDFFormats that does not include this serialization.  The 
> registryGraph HashMap has 25 RDFFormats that does include "N-Triples/utf-8".
> No exception is thrown if Lang.NQUADS is set in the toString() method.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

2017-10-30 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergio Fernández updated COMMONSRDF-66:
---
Fix Version/s: 0.4.0

> JenaDatasetImpl.toString() throws RIOT exception
> 
>
> Key: COMMONSRDF-66
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-66
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: jena
>Affects Versions: 0.3.0
>Reporter: Christopher Johnson
> Fix For: 0.4.0
>
>
> Occurs from this method 
> [https://github.com/apache/commons-rdf/blob/master/jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java#L152]
>  on instantiation:
> The exception message is "No dataset writer for N-Triples/utf-8".
> The source is RDFWriterRegistry that builds a registryDataset HashMap of 17 
> +Dataset+ RDFFormats that does not include this serialization.  The 
> registryGraph HashMap has 25 RDFFormats that does include "N-Triples/utf-8".
> No exception is thrown if Lang.NQUADS is set in the toString() method.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

2017-10-30 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226140#comment-16226140
 ] 

ASF GitHub Bot commented on COMMONSRDF-66:
--

Github user wikier commented on a diff in the pull request:

https://github.com/apache/commons-rdf/pull/42#discussion_r147883486
  
--- Diff: 
jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java ---
@@ -149,7 +149,7 @@ public long size() {
 @Override
 public String toString() {
 final StringWriter sw = new StringWriter();
-RDFDataMgr.write(sw, graph, Lang.NT);
--- End diff --

I'd keep both, parameter and attribute, as `datasetGraph`.


> JenaDatasetImpl.toString() throws RIOT exception
> 
>
> Key: COMMONSRDF-66
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-66
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: jena
>Affects Versions: 0.3.0
>Reporter: Christopher Johnson
>
> Occurs from this method 
> [https://github.com/apache/commons-rdf/blob/master/jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java#L152]
>  on instantiation:
> The exception message is "No dataset writer for N-Triples/utf-8".
> The source is RDFWriterRegistry that builds a registryDataset HashMap of 17 
> +Dataset+ RDFFormats that does not include this serialization.  The 
> registryGraph HashMap has 25 RDFFormats that does include "N-Triples/utf-8".
> No exception is thrown if Lang.NQUADS is set in the toString() method.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

2017-10-30 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226145#comment-16226145
 ] 

ASF GitHub Bot commented on COMMONSRDF-66:
--

Github user wikier commented on the issue:

https://github.com/apache/commons-rdf/pull/42
  
Please, rebase this PR on top of the current `HEAD` of `master`.


> JenaDatasetImpl.toString() throws RIOT exception
> 
>
> Key: COMMONSRDF-66
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-66
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: jena
>Affects Versions: 0.3.0
>Reporter: Christopher Johnson
>
> Occurs from this method 
> [https://github.com/apache/commons-rdf/blob/master/jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java#L152]
>  on instantiation:
> The exception message is "No dataset writer for N-Triples/utf-8".
> The source is RDFWriterRegistry that builds a registryDataset HashMap of 17 
> +Dataset+ RDFFormats that does not include this serialization.  The 
> registryGraph HashMap has 25 RDFFormats that does include "N-Triples/utf-8".
> No exception is thrown if Lang.NQUADS is set in the toString() method.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

2017-10-30 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226137#comment-16226137
 ] 

ASF GitHub Bot commented on COMMONSRDF-66:
--

Github user wikier commented on a diff in the pull request:

https://github.com/apache/commons-rdf/pull/42#discussion_r147883290
  
--- Diff: 
jena/src/test/java/org/apache/commons/rdf/jena/DatasetJenaTest.java ---
@@ -7,7 +7,7 @@
  * "License"); you may not use this file except in compliance
  * with the License.  You may obtain a copy of the License at
  *
- * http://www.apache.org/licenses/LICENSE-2.0
--- End diff --

Please, remove this changeset from the PR.


> JenaDatasetImpl.toString() throws RIOT exception
> 
>
> Key: COMMONSRDF-66
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-66
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: jena
>Affects Versions: 0.3.0
>Reporter: Christopher Johnson
>
> Occurs from this method 
> [https://github.com/apache/commons-rdf/blob/master/jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java#L152]
>  on instantiation:
> The exception message is "No dataset writer for N-Triples/utf-8".
> The source is RDFWriterRegistry that builds a registryDataset HashMap of 17 
> +Dataset+ RDFFormats that does not include this serialization.  The 
> registryGraph HashMap has 25 RDFFormats that does include "N-Triples/utf-8".
> No exception is thrown if Lang.NQUADS is set in the toString() method.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang issue #299: Add module-info for Java 9

2017-10-30 Thread namannigam

Github user namannigam commented on the issue:

https://github.com/apache/commons-lang/pull/299
  
@jodastephen What's the error that you get with site? Any links to the 
build?


---

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

2017-10-30 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226090#comment-16226090
 ] 

ASF GitHub Bot commented on COMMONSRDF-66:
--

Github user christopher-johnson commented on a diff in the pull request:

https://github.com/apache/commons-rdf/pull/42#discussion_r147875892
  
--- Diff: 
jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java ---
@@ -149,7 +149,7 @@ public long size() {
 @Override
 public String toString() {
 final StringWriter sw = new StringWriter();
-RDFDataMgr.write(sw, graph, Lang.NT);
--- End diff --

right.  would something like this be ok?  
```java
private final DatasetGraph dg;

JenaDatasetImpl(final DatasetGraph datasetGraph, final UUID salt) {
this.dg = datasetGraph;
this.salt = salt;
this.factory = new JenaRDF(salt);
}
```
so `dg` is the private variable, and `datasetGraph` is only used in the 
constructor to match InternalJenaFactory.


> JenaDatasetImpl.toString() throws RIOT exception
> 
>
> Key: COMMONSRDF-66
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-66
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: jena
>Affects Versions: 0.3.0
>Reporter: Christopher Johnson
>
> Occurs from this method 
> [https://github.com/apache/commons-rdf/blob/master/jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java#L152]
>  on instantiation:
> The exception message is "No dataset writer for N-Triples/utf-8".
> The source is RDFWriterRegistry that builds a registryDataset HashMap of 17 
> +Dataset+ RDFFormats that does not include this serialization.  The 
> registryGraph HashMap has 25 RDFFormats that does include "N-Triples/utf-8".
> No exception is thrown if Lang.NQUADS is set in the toString() method.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang issue #299: Add module-info for Java 9

2017-10-30 Thread jodastephen

Github user jodastephen commented on the issue:

https://github.com/apache/commons-lang/pull/299
  
`mvn install` works fine on each JDK version AFAICT. `mvn site` still 
breaks on cobertura on Java 9 and I'm not sure I can work around it without 
removing it from the parent pom.


---

[jira] [Closed] (POOL-330) Drop Ant build

2017-10-30 Thread Gary Gregory (JIRA)


 [ 
https://issues.apache.org/jira/browse/POOL-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed POOL-330.
-
   Resolution: Fixed
Fix Version/s: 2.5

In git master,

> Drop Ant build
> --
>
> Key: POOL-330
> URL: https://issues.apache.org/jira/browse/POOL-330
> Project: Commons Pool
>  Issue Type: Task
>Reporter: Gary Gregory
> Fix For: 2.5
>
>
> Drop the Ant build, it is no longer maintained.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #299: Add module-info for Java 9

2017-10-30 Thread jodastephen

Github user jodastephen commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/299#discussion_r147859782
  
--- Diff: .travis.yml ---
@@ -21,8 +21,19 @@ jdk:
   - oraclejdk8
   - oraclejdk9
 
+cache:
+  directories:
+- "$HOME/.m2/repository"
+
+before_cache:
+  - rm -rf $HOME/.m2/repository/org/apache/commons/commons-lang3
+
+install:
+  - mvn --version
+
 script:
-  - mvn
+  - mvn -e -B
 
 after_success:
-  - mvn clean cobertura:cobertura coveralls:report -Ptravis-cobertura
+  - if [ $TRAVIS_JDK_VERSION == "openjdk7" ] || [ $TRAVIS_JDK_VERSION == 
"oraclejdk8" ]; then mvn -e -B clean cobertura:cobertura coveralls:report 
-Ptravis-cobertura; fi
+  - if [ $TRAVIS_JDK_VERSION == "oraclejdk9" ]; then mvn -e -B clean 
cobertura:cobertura -Ptravis-cobertura; fi
--- End diff --

The right answer will be to move from Cobertura to JaCoCo (as JaCoCo is the 
more alive project). But right now, Coveralls also doesn't work with JaCoCo.


---

[jira] [Closed] (POOL-331) Update from Java 6 to 7

2017-10-30 Thread Gary Gregory (JIRA)


 [ 
https://issues.apache.org/jira/browse/POOL-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed POOL-331.
-
   Resolution: Fixed
Fix Version/s: 2.5

In git master.

> Update from Java 6 to 7
> ---
>
> Key: POOL-331
> URL: https://issues.apache.org/jira/browse/POOL-331
> Project: Commons Pool
>  Issue Type: Task
>Reporter: Gary Gregory
> Fix For: 2.5
>
>
> Update from Java 6 to 7.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (POOL-331) Update from Java 6 to 7

2017-10-30 Thread Gary Gregory (JIRA)

Gary Gregory created POOL-331:
-

 Summary: Update from Java 6 to 7
 Key: POOL-331
 URL: https://issues.apache.org/jira/browse/POOL-331
 Project: Commons Pool
  Issue Type: Task
Reporter: Gary Gregory


Update from Java 6 to 7.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (POOL-330) Drop Ant build

2017-10-30 Thread Gary Gregory (JIRA)

Gary Gregory created POOL-330:
-

 Summary: Drop Ant build
 Key: POOL-330
 URL: https://issues.apache.org/jira/browse/POOL-330
 Project: Commons Pool
  Issue Type: Task
Reporter: Gary Gregory


Drop the Ant build, it is no longer maintained.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

2017-10-30 Thread Joakim Knudsen (JIRA)


[ 
https://issues.apache.org/jira/browse/IMAGING-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16225827#comment-16225827
 ] 

Joakim Knudsen commented on IMAGING-205:


Also, see the [following 
discussion|http://u88.n24.queensu.ca/exiftool/forum/index.php/topic,8642.msg44434.html#msg44434],
 from the ExifTool forum.

> Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata
> ---
>
> Key: IMAGING-205
> URL: https://issues.apache.org/jira/browse/IMAGING-205
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: imaging.*
>Reporter: Joakim Knudsen
>Priority: Critical
> Attachments: 20171030_21481_COPY.jpg
>
>
> I'm using the "last stable version" of Apache Sanselan 0.97 in an Android 
> project (app). I have not upgraded to Commons Imaging yet, since the website 
> says there is no stable release yet. Meanwhile, there are bugs in Sanselan. 
> If I run the [sample code method 
> WriteExifMetadataExample.changeExifMetadata|http://svn.apache.org/repos/asf/commons/proper/sanselan/trunk/src/test/java/org/apache/sanselan/sampleUsage/WriteExifMetadataExample.java?p=820841]
>  on an image, which updates the Apterture and GPS tags, the resulting image 
> fails to validate (through Phil Harvey's [ExifTool 
> software|https://sno.phy.queensu.ca/~phil/exiftool/]):
> {noformat}
> > exiftool.exe -validate -error -warning -a "..\20171030_21481_COPY.jpg"
> Validate: 19 Warnings (17 minor)
> Warning : [minor] Odd offset for IFD0 tag 0x010f
> Warning : [minor] Odd offset for IFD0 tag 0x011a
> Warning : [minor] Odd offset for IFD0 tag 0x011b
> Warning : [minor] Odd offset for IFD0 tag 0x0131
> Warning : [minor] Odd offset for IFD0 tag 0x0132
> Warning : [minor] Odd offset for ExifIFD tag 0x829a
> Warning : [minor] Odd offset for ExifIFD tag 0x829d
> Warning : [minor] Odd offset for ExifIFD tag 0x9003
> Warning : [minor] Odd offset for ExifIFD tag 0x9004
> Warning : [minor] Odd offset for ExifIFD tag 0x9202
> Warning : [minor] Odd offset for ExifIFD tag 0x9205
> Warning : [minor] Odd offset for ExifIFD tag 0x920a
> Warning : [minor] Odd offset for ExifIFD tag 0x9286
> Warning : Non-standard count (1) for GPS tag 0x0001 
> GPSLatitudeRef
> Warning : [minor] Odd offset for GPS tag 0x0002
> Warning : Non-standard count (1) for GPS tag 0x0003 
> GPSLongitudeRef
> Warning : [minor] Odd offset for GPS tag 0x0004
> Warning : [minor] Odd offset for IFD1 tag 0x011a
> Warning : [minor] Odd offset for IFD1 tag 0x011b
> {noformat}
> I need some advice on how to proceed here. Since Sanselan does not appear to 
> do what it should (even on very basic metadata editing), am I correct to 
> assume that the current version of Commons Imaging does a better job? :-)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

2017-10-30 Thread Joakim Knudsen (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joakim Knudsen updated IMAGING-205:
---
Description: 
I'm using the "last stable version" of Apache Sanselan 0.97 in an Android 
project (app). I have not upgraded to Commons Imaging yet, since the website 
says there is no stable release yet. Meanwhile, there are bugs in Sanselan. 

If I run the [sample code method 
WriteExifMetadataExample.changeExifMetadata|http://svn.apache.org/repos/asf/commons/proper/sanselan/trunk/src/test/java/org/apache/sanselan/sampleUsage/WriteExifMetadataExample.java?p=820841]
 on an image, which updates the Apterture and GPS tags, the resulting image 
fails to validate (through Phil Harvey's [ExifTool 
software|https://sno.phy.queensu.ca/~phil/exiftool/]):


{noformat}
> exiftool.exe -validate -error -warning -a "..\20171030_21481_COPY.jpg"
Validate: 19 Warnings (17 minor)
Warning : [minor] Odd offset for IFD0 tag 0x010f
Warning : [minor] Odd offset for IFD0 tag 0x011a
Warning : [minor] Odd offset for IFD0 tag 0x011b
Warning : [minor] Odd offset for IFD0 tag 0x0131
Warning : [minor] Odd offset for IFD0 tag 0x0132
Warning : [minor] Odd offset for ExifIFD tag 0x829a
Warning : [minor] Odd offset for ExifIFD tag 0x829d
Warning : [minor] Odd offset for ExifIFD tag 0x9003
Warning : [minor] Odd offset for ExifIFD tag 0x9004
Warning : [minor] Odd offset for ExifIFD tag 0x9202
Warning : [minor] Odd offset for ExifIFD tag 0x9205
Warning : [minor] Odd offset for ExifIFD tag 0x920a
Warning : [minor] Odd offset for ExifIFD tag 0x9286
Warning : Non-standard count (1) for GPS tag 0x0001 
GPSLatitudeRef
Warning : [minor] Odd offset for GPS tag 0x0002
Warning : Non-standard count (1) for GPS tag 0x0003 
GPSLongitudeRef
Warning : [minor] Odd offset for GPS tag 0x0004
Warning : [minor] Odd offset for IFD1 tag 0x011a
Warning : [minor] Odd offset for IFD1 tag 0x011b
{noformat}


I need some advice on how to proceed here. Since Sanselan does not appear to do 
what it should (even on very basic metadata editing), am I correct to assume 
that the current version of Commons Imaging does a better job? :-)



  was:
I'm using the "last stable version" of Apache Sanselan 0.97 in an Android 
project (app). I have not upgraded to Commons Imaging yet, since the website 
says there is no stable release yet. Meanwhile, there are bugs in Sanselan. 

If I run the [sample code method 
WriteExifMetadataExample.changeExifMetadata|http://svn.apache.org/repos/asf/commons/proper/sanselan/trunk/src/test/java/org/apache/sanselan/sampleUsage/WriteExifMetadataExample.java?p=820841]
 on an image, which updates the Apterture and GPS tags, the resulting image 
fails to validate (through Phil Harvey's ExifTool software):


{noformat}
> exiftool.exe -validate -error -warning -a "..\20171030_21481_COPY.jpg"
Validate: 19 Warnings (17 minor)
Warning : [minor] Odd offset for IFD0 tag 0x010f
Warning : [minor] Odd offset for IFD0 tag 0x011a
Warning : [minor] Odd offset for IFD0 tag 0x011b
Warning : [minor] Odd offset for IFD0 tag 0x0131
Warning : [minor] Odd offset for IFD0 tag 0x0132
Warning : [minor] Odd offset for ExifIFD tag 0x829a
Warning : [minor] Odd offset for ExifIFD tag 0x829d
Warning : [minor] Odd offset for ExifIFD tag 0x9003
Warning : [minor] Odd offset for ExifIFD tag 0x9004
Warning : [minor] Odd offset for ExifIFD tag 0x9202
Warning : [minor] Odd offset for ExifIFD tag 0x9205
Warning : [minor] Odd offset for ExifIFD tag 0x920a
Warning : [minor] Odd offset for ExifIFD tag 0x9286
Warning : Non-standard count (1) for GPS tag 0x0001 
GPSLatitudeRef
Warning : [minor] Odd offset for GPS tag 0x0002
Warning : Non-standard count (1) for GPS tag 0x0003 
GPSLongitudeRef
Warning : [minor] Odd offset for GPS tag 0x0004
Warning : [minor] Odd offset for IFD1 tag 0x011a
Warning : [minor] Odd offset for IFD1 tag 0x011b
{noformat}


I need some advice on how to proceed here. Since Sanselan does not appear to do 
what it should

[jira] [Updated] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

2017-10-30 Thread Joakim Knudsen (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joakim Knudsen updated IMAGING-205:
---
Description: 
I'm using the "last stable version" of Apache Sanselan 0.97 in an Android 
project (app). I have not upgraded to Commons Imaging yet, since the website 
says there is no stable release yet. Meanwhile, there are bugs in Sanselan. 

If I run the [sample code method 
WriteExifMetadataExample.changeExifMetadata|http://svn.apache.org/repos/asf/commons/proper/sanselan/trunk/src/test/java/org/apache/sanselan/sampleUsage/WriteExifMetadataExample.java?p=820841]
 on an image, which updates the Apterture and GPS tags, the resulting image 
fails to validate (through Phil Harvey's ExifTool software):


{noformat}
> exiftool.exe -validate -error -warning -a "..\20171030_21481_COPY.jpg"
Validate: 19 Warnings (17 minor)
Warning : [minor] Odd offset for IFD0 tag 0x010f
Warning : [minor] Odd offset for IFD0 tag 0x011a
Warning : [minor] Odd offset for IFD0 tag 0x011b
Warning : [minor] Odd offset for IFD0 tag 0x0131
Warning : [minor] Odd offset for IFD0 tag 0x0132
Warning : [minor] Odd offset for ExifIFD tag 0x829a
Warning : [minor] Odd offset for ExifIFD tag 0x829d
Warning : [minor] Odd offset for ExifIFD tag 0x9003
Warning : [minor] Odd offset for ExifIFD tag 0x9004
Warning : [minor] Odd offset for ExifIFD tag 0x9202
Warning : [minor] Odd offset for ExifIFD tag 0x9205
Warning : [minor] Odd offset for ExifIFD tag 0x920a
Warning : [minor] Odd offset for ExifIFD tag 0x9286
Warning : Non-standard count (1) for GPS tag 0x0001 
GPSLatitudeRef
Warning : [minor] Odd offset for GPS tag 0x0002
Warning : Non-standard count (1) for GPS tag 0x0003 
GPSLongitudeRef
Warning : [minor] Odd offset for GPS tag 0x0004
Warning : [minor] Odd offset for IFD1 tag 0x011a
Warning : [minor] Odd offset for IFD1 tag 0x011b
{noformat}


I need some advice on how to proceed here. Since Sanselan does not appear to do 
what it should (even on very basic metadata editing), am I correct to assume 
that the current version of Commons Imaging does a better job? :-)



  was:
I'm using the "last stable version" of Apache Sanselan 0.97 in an Android 
project (app). I have not upgraded to Commons Imaging yet, since the website 
says there is no stable release yet. Meanwhile, there are bugs in Sanselan. 

If I run the [sample code method 
WriteExifMetadataExample.changeExifMetadata|http://svn.apache.org/repos/asf/commons/proper/sanselan/trunk/src/test/java/org/apache/sanselan/sampleUsage/WriteExifMetadataExample.java?p=820841]
 on an image, which updates the Apterture and GPS tags, the resulting image 
fails to validate (through Phil Harvey's ExifTool software):

{{> exiftool.exe -validate -error -warning -a "..\20171030_21481_COPY.jpg"
Validate: 19 Warnings (17 minor)
Warning : [minor] Odd offset for IFD0 tag 0x010f
Warning : [minor] Odd offset for IFD0 tag 0x011a
Warning : [minor] Odd offset for IFD0 tag 0x011b
Warning : [minor] Odd offset for IFD0 tag 0x0131
Warning : [minor] Odd offset for IFD0 tag 0x0132
Warning : [minor] Odd offset for ExifIFD tag 0x829a
Warning : [minor] Odd offset for ExifIFD tag 0x829d
Warning : [minor] Odd offset for ExifIFD tag 0x9003
Warning : [minor] Odd offset for ExifIFD tag 0x9004
Warning : [minor] Odd offset for ExifIFD tag 0x9202
Warning : [minor] Odd offset for ExifIFD tag 0x9205
Warning : [minor] Odd offset for ExifIFD tag 0x920a
Warning : [minor] Odd offset for ExifIFD tag 0x9286
Warning : Non-standard count (1) for GPS tag 0x0001 
GPSLatitudeRef
Warning : [minor] Odd offset for GPS tag 0x0002
Warning : Non-standard count (1) for GPS tag 0x0003 
GPSLongitudeRef
Warning : [minor] Odd offset for GPS tag 0x0004
Warning : [minor] Odd offset for IFD1 tag 0x011a
Warning : [minor] Odd offset for IFD1 tag 0x011b}}

I need some advice on how to proceed here. Since Sanselan does not appear to do 
what it should (even on very basic metadata editing), am I correct to assume 
that

[jira] [Commented] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

2017-10-30 Thread Joakim Knudsen (JIRA)


[ 
https://issues.apache.org/jira/browse/IMAGING-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16225820#comment-16225820
 ] 

Joakim Knudsen commented on IMAGING-205:


I have attached the file producing the output from above.

> Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata
> ---
>
> Key: IMAGING-205
> URL: https://issues.apache.org/jira/browse/IMAGING-205
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: imaging.*
>Reporter: Joakim Knudsen
>Priority: Critical
> Attachments: 20171030_21481_COPY.jpg
>
>
> I'm using the "last stable version" of Apache Sanselan 0.97 in an Android 
> project (app). I have not upgraded to Commons Imaging yet, since the website 
> says there is no stable release yet. Meanwhile, there are bugs in Sanselan. 
> If I run the [sample code method 
> WriteExifMetadataExample.changeExifMetadata|http://svn.apache.org/repos/asf/commons/proper/sanselan/trunk/src/test/java/org/apache/sanselan/sampleUsage/WriteExifMetadataExample.java?p=820841]
>  on an image, which updates the Apterture and GPS tags, the resulting image 
> fails to validate (through Phil Harvey's ExifTool software):
> {{> exiftool.exe -validate -error -warning -a "..\20171030_21481_COPY.jpg"
> Validate: 19 Warnings (17 minor)
> Warning : [minor] Odd offset for IFD0 tag 0x010f
> Warning : [minor] Odd offset for IFD0 tag 0x011a
> Warning : [minor] Odd offset for IFD0 tag 0x011b
> Warning : [minor] Odd offset for IFD0 tag 0x0131
> Warning : [minor] Odd offset for IFD0 tag 0x0132
> Warning : [minor] Odd offset for ExifIFD tag 0x829a
> Warning : [minor] Odd offset for ExifIFD tag 0x829d
> Warning : [minor] Odd offset for ExifIFD tag 0x9003
> Warning : [minor] Odd offset for ExifIFD tag 0x9004
> Warning : [minor] Odd offset for ExifIFD tag 0x9202
> Warning : [minor] Odd offset for ExifIFD tag 0x9205
> Warning : [minor] Odd offset for ExifIFD tag 0x920a
> Warning : [minor] Odd offset for ExifIFD tag 0x9286
> Warning : Non-standard count (1) for GPS tag 0x0001 
> GPSLatitudeRef
> Warning : [minor] Odd offset for GPS tag 0x0002
> Warning : Non-standard count (1) for GPS tag 0x0003 
> GPSLongitudeRef
> Warning : [minor] Odd offset for GPS tag 0x0004
> Warning : [minor] Odd offset for IFD1 tag 0x011a
> Warning : [minor] Odd offset for IFD1 tag 0x011b}}
> I need some advice on how to proceed here. Since Sanselan does not appear to 
> do what it should (even on very basic metadata editing), am I correct to 
> assume that the current version of Commons Imaging does a better job? :-)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

2017-10-30 Thread Joakim Knudsen (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joakim Knudsen updated IMAGING-205:
---
Attachment: 20171030_21481_COPY.jpg

> Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata
> ---
>
> Key: IMAGING-205
> URL: https://issues.apache.org/jira/browse/IMAGING-205
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: imaging.*
>Reporter: Joakim Knudsen
>Priority: Critical
> Attachments: 20171030_21481_COPY.jpg
>
>
> I'm using the "last stable version" of Apache Sanselan 0.97 in an Android 
> project (app). I have not upgraded to Commons Imaging yet, since the website 
> says there is no stable release yet. Meanwhile, there are bugs in Sanselan. 
> If I run the [sample code method 
> WriteExifMetadataExample.changeExifMetadata|http://svn.apache.org/repos/asf/commons/proper/sanselan/trunk/src/test/java/org/apache/sanselan/sampleUsage/WriteExifMetadataExample.java?p=820841]
>  on an image, which updates the Apterture and GPS tags, the resulting image 
> fails to validate (through Phil Harvey's ExifTool software):
> {{> exiftool.exe -validate -error -warning -a "..\20171030_21481_COPY.jpg"
> Validate: 19 Warnings (17 minor)
> Warning : [minor] Odd offset for IFD0 tag 0x010f
> Warning : [minor] Odd offset for IFD0 tag 0x011a
> Warning : [minor] Odd offset for IFD0 tag 0x011b
> Warning : [minor] Odd offset for IFD0 tag 0x0131
> Warning : [minor] Odd offset for IFD0 tag 0x0132
> Warning : [minor] Odd offset for ExifIFD tag 0x829a
> Warning : [minor] Odd offset for ExifIFD tag 0x829d
> Warning : [minor] Odd offset for ExifIFD tag 0x9003
> Warning : [minor] Odd offset for ExifIFD tag 0x9004
> Warning : [minor] Odd offset for ExifIFD tag 0x9202
> Warning : [minor] Odd offset for ExifIFD tag 0x9205
> Warning : [minor] Odd offset for ExifIFD tag 0x920a
> Warning : [minor] Odd offset for ExifIFD tag 0x9286
> Warning : Non-standard count (1) for GPS tag 0x0001 
> GPSLatitudeRef
> Warning : [minor] Odd offset for GPS tag 0x0002
> Warning : Non-standard count (1) for GPS tag 0x0003 
> GPSLongitudeRef
> Warning : [minor] Odd offset for GPS tag 0x0004
> Warning : [minor] Odd offset for IFD1 tag 0x011a
> Warning : [minor] Odd offset for IFD1 tag 0x011b}}
> I need some advice on how to proceed here. Since Sanselan does not appear to 
> do what it should (even on very basic metadata editing), am I correct to 
> assume that the current version of Commons Imaging does a better job? :-)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

2017-10-30 Thread Joakim Knudsen (JIRA)

Joakim Knudsen created IMAGING-205:
--

 Summary: Imaging (Apache Sanselan) produces "odd offsets" in 
(EXIF) metadata
 Key: IMAGING-205
 URL: https://issues.apache.org/jira/browse/IMAGING-205
 Project: Commons Imaging
  Issue Type: Bug
  Components: imaging.*
Reporter: Joakim Knudsen
Priority: Critical


I'm using the "last stable version" of Apache Sanselan 0.97 in an Android 
project (app). I have not upgraded to Commons Imaging yet, since the website 
says there is no stable release yet. Meanwhile, there are bugs in Sanselan. 

If I run the [sample code method 
WriteExifMetadataExample.changeExifMetadata|http://svn.apache.org/repos/asf/commons/proper/sanselan/trunk/src/test/java/org/apache/sanselan/sampleUsage/WriteExifMetadataExample.java?p=820841]
 on an image, which updates the Apterture and GPS tags, the resulting image 
fails to validate (through Phil Harvey's ExifTool software):

{{> exiftool.exe -validate -error -warning -a "..\20171030_21481_COPY.jpg"
Validate: 19 Warnings (17 minor)
Warning : [minor] Odd offset for IFD0 tag 0x010f
Warning : [minor] Odd offset for IFD0 tag 0x011a
Warning : [minor] Odd offset for IFD0 tag 0x011b
Warning : [minor] Odd offset for IFD0 tag 0x0131
Warning : [minor] Odd offset for IFD0 tag 0x0132
Warning : [minor] Odd offset for ExifIFD tag 0x829a
Warning : [minor] Odd offset for ExifIFD tag 0x829d
Warning : [minor] Odd offset for ExifIFD tag 0x9003
Warning : [minor] Odd offset for ExifIFD tag 0x9004
Warning : [minor] Odd offset for ExifIFD tag 0x9202
Warning : [minor] Odd offset for ExifIFD tag 0x9205
Warning : [minor] Odd offset for ExifIFD tag 0x920a
Warning : [minor] Odd offset for ExifIFD tag 0x9286
Warning : Non-standard count (1) for GPS tag 0x0001 
GPSLatitudeRef
Warning : [minor] Odd offset for GPS tag 0x0002
Warning : Non-standard count (1) for GPS tag 0x0003 
GPSLongitudeRef
Warning : [minor] Odd offset for GPS tag 0x0004
Warning : [minor] Odd offset for IFD1 tag 0x011a
Warning : [minor] Odd offset for IFD1 tag 0x011b}}

I need some advice on how to proceed here. Since Sanselan does not appear to do 
what it should (even on very basic metadata editing), am I correct to assume 
that the current version of Commons Imaging does a better job? :-)





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IMAGING-194) Tiff with JPEG,Zip compression fails to decompress

2017-10-30 Thread Gary Lucas (JIRA)


[ 
https://issues.apache.org/jira/browse/IMAGING-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16225617#comment-16225617
 ] 

Gary Lucas edited comment on IMAGING-194 at 10/30/17 7:39 PM:
--

The compression code 7 is not even listed in TiffConstants.java.  TiffConstants 
does include TIFF_COMPRESSION_JPEG = 6, though neither format is decoded.
I've seen Code 7 used in many satellite images.

The documentation seems a bit sketchy on this issue, though I found some at 

ftp://ftp.sgi.com/graphics/tiff/TTN2.draft.txt


was (Author: gwlucas):
The compression code 7 is not even listed in TiffConstants.java.  TiffConstants 
does include TIFF_COMPRESSION_JPEG = 6, though neither format is decoded.
I've seen Code 7 used in many satellite images.

The documentation seems a bit sketchy on this issue, though I found some at 

[#ftp://ftp.sgi.com/graphics/tiff/TTN2.draft.txt]

> Tiff with JPEG,Zip compression fails to decompress
> --
>
> Key: IMAGING-194
> URL: https://issues.apache.org/jira/browse/IMAGING-194
> Project: Commons Imaging
>  Issue Type: Improvement
>  Components: Format: TIFF
>Affects Versions: 1.0
>Reporter: Satya Deep Maheshwari
>
> Tiff with JPEG, Zip compression  fails to decompress with the below exception:
> {code}
> org.apache.commons.imaging.ImageReadException: Tiff: unknown/unsupported 
> compression: 7
>   at 
> org.apache.commons.imaging.formats.tiff.datareaders.DataReader.decompress(DataReader.java:215)
>   at 
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.readImageData(DataReaderStrips.java:210)
>   at 
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:650)
>   at 
> org.apache.commons.imaging.formats.tiff.TiffDirectory.getTiffImage(TiffDirectory.java:157)
>   at 
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:463)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1407)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1370)
> {code}
> From the 
> [documentation|https://commons.apache.org/proper/commons-imaging/formatsupport.html]
>  , it seems this compression format is not supported. Excerpt from the 
> document below:
> {quote}
> Supported through version 6.0. TIFFs is a open-ended container format, so 
> it's not possible to support every possibly variation. Supports Bi-Level, 
> Palette/Indexed, RGB, CMYK, YCbCr, CIELab and LOGLUV images. Supports reading 
> and writing LZW, CCITT Modified Huffman/Group 3/Group 4, and Packbits/RLE 
> compression. Notably missing other forms of compression though, including 
> JPEG. Supports reading Tiled images.
> {quote}
> This ticket is logged to add JPEG/Zip compression format support.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IMAGING-194) Tiff with JPEG,Zip compression fails to decompress

2017-10-30 Thread Gary Lucas (JIRA)


[ 
https://issues.apache.org/jira/browse/IMAGING-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16225617#comment-16225617
 ] 

Gary Lucas commented on IMAGING-194:


The compression code 7 is not even listed in TiffConstants.java.  TiffConstants 
does include TIFF_COMPRESSION_JPEG = 6, though neither format is decoded.
I've seen Code 7 used in many satellite images.

The documentation seems a bit sketchy on this issue, though I found some at 

[#ftp://ftp.sgi.com/graphics/tiff/TTN2.draft.txt]

> Tiff with JPEG,Zip compression fails to decompress
> --
>
> Key: IMAGING-194
> URL: https://issues.apache.org/jira/browse/IMAGING-194
> Project: Commons Imaging
>  Issue Type: Improvement
>  Components: Format: TIFF
>Affects Versions: 1.0
>Reporter: Satya Deep Maheshwari
>
> Tiff with JPEG, Zip compression  fails to decompress with the below exception:
> {code}
> org.apache.commons.imaging.ImageReadException: Tiff: unknown/unsupported 
> compression: 7
>   at 
> org.apache.commons.imaging.formats.tiff.datareaders.DataReader.decompress(DataReader.java:215)
>   at 
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.readImageData(DataReaderStrips.java:210)
>   at 
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:650)
>   at 
> org.apache.commons.imaging.formats.tiff.TiffDirectory.getTiffImage(TiffDirectory.java:157)
>   at 
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:463)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1407)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1370)
> {code}
> From the 
> [documentation|https://commons.apache.org/proper/commons-imaging/formatsupport.html]
>  , it seems this compression format is not supported. Excerpt from the 
> document below:
> {quote}
> Supported through version 6.0. TIFFs is a open-ended container format, so 
> it's not possible to support every possibly variation. Supports Bi-Level, 
> Palette/Indexed, RGB, CMYK, YCbCr, CIELab and LOGLUV images. Supports reading 
> and writing LZW, CCITT Modified Huffman/Group 3/Group 4, and Packbits/RLE 
> compression. Notably missing other forms of compression though, including 
> JPEG. Supports reading Tiled images.
> {quote}
> This ticket is logged to add JPEG/Zip compression format support.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (DAEMON-359) Control characters messed up with SYSLOG output

2017-10-30 Thread Mark Thomas (JIRA)


 [ 
https://issues.apache.org/jira/browse/DAEMON-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas resolved DAEMON-359.

Resolution: Not A Problem

The escaping is happening in syslog and can be controlled via configuration. I 
suspect you are seeing the results of the logging framework buffering several 
messages and then flushing them.

> Control characters messed up with SYSLOG output
> ---
>
> Key: DAEMON-359
> URL: https://issues.apache.org/jira/browse/DAEMON-359
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Jsvc
>Affects Versions: 1.0.15
> Environment: CentOS 6.8 (virtual machine, all defaults)
> jsvc 1.0.15
>Reporter: Julien Nicoulaud
>
> Using the {{-outfile SYSLOG}} option, on CentOS 6 I get this kind of output 
> in {{/var/log/messages}}:
> {code}
> Feb  9 11:21:43 localhost mydaemon[16262]: [INFO ] mydaemon is 
> initialized.#012[INFO ] mydaemon is starting...
> {code}
> => Several log lines are concatenated.
> It looks like {{#012}} is the line return character. I also have {{#011}} 
> instead of tabs.
> My application uses SLF4J+Logback, with default console appender.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (DAEMON-341) prunsrv injects garbage into ImagePath

2017-10-30 Thread Mark Thomas (JIRA)


 [ 
https://issues.apache.org/jira/browse/DAEMON-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas resolved DAEMON-341.

   Resolution: Duplicate
Fix Version/s: 1.1.14

I was able to re-create this with prunsrv.exe from 1.0.13 on Windows 2016. 
Thanks for the test case and an additional thanks for providing an alternative 
OS (that I happened to have available) where the problem could be observed.

I then tested 1.0.15 and confirmed that the issue was resolved as suspected.

Looking at the change log, DAEMON-284 looks to be very likely the issue where 
this was fixed.

> prunsrv injects garbage into ImagePath
> --
>
> Key: DAEMON-341
> URL: https://issues.apache.org/jira/browse/DAEMON-341
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Affects Versions: 1.0.13
> Environment: Windows Server 2008 (not R2)
>Reporter: Mikhail Dobrinin
> Fix For: 1.1.14
>
>
> Here is a reproducible example that works every time:
> {noformat}
> prunsrv.exe //IS//abcd.branch2 --StartMode=jvm 
> --StartClass=abc.abcdefghih.abcd.abcdef.abcd.MyImportantClass 
> --StartMethod=startService ++StartParams=abcd.branch2
> {noformat}
> The ImagePath entry for the service ends up being:
> {noformat}
> C:\path\to\prunsrv.exe 12-08.loɥ//RS//abcd.branch2
> {noformat}
> As you see, there is garbage inserted in front of the {{//RS//}} string.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

2017-10-30 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16224964#comment-16224964
 ] 

ASF GitHub Bot commented on COMMONSRDF-66:
--

Github user afs commented on a diff in the pull request:

https://github.com/apache/commons-rdf/pull/42#discussion_r147701840
  
--- Diff: 
jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java ---
@@ -149,7 +149,7 @@ public long size() {
 @Override
 public String toString() {
 final StringWriter sw = new StringWriter();
-RDFDataMgr.write(sw, graph, Lang.NT);
--- End diff --

It would good to rename graph (throughout the class) as `datasetGraph` or 
some such. It's not a graph.


> JenaDatasetImpl.toString() throws RIOT exception
> 
>
> Key: COMMONSRDF-66
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-66
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: jena
>Affects Versions: 0.3.0
>Reporter: Christopher Johnson
>
> Occurs from this method 
> [https://github.com/apache/commons-rdf/blob/master/jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java#L152]
>  on instantiation:
> The exception message is "No dataset writer for N-Triples/utf-8".
> The source is RDFWriterRegistry that builds a registryDataset HashMap of 17 
> +Dataset+ RDFFormats that does not include this serialization.  The 
> registryGraph HashMap has 25 RDFFormats that does include "N-Triples/utf-8".
> No exception is thrown if Lang.NQUADS is set in the toString() method.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

2017-10-30 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16224963#comment-16224963
 ] 

ASF GitHub Bot commented on COMMONSRDF-66:
--

Github user afs commented on a diff in the pull request:

https://github.com/apache/commons-rdf/pull/42#discussion_r147701690
  
--- Diff: 
jena/src/test/java/org/apache/commons/rdf/jena/DatasetJenaTest.java ---
@@ -7,7 +7,7 @@
  * "License"); you may not use this file except in compliance
  * with the License.  You may obtain a copy of the License at
  *
- * http://www.apache.org/licenses/LICENSE-2.0
--- End diff --

Accidental reformat of the license.


> JenaDatasetImpl.toString() throws RIOT exception
> 
>
> Key: COMMONSRDF-66
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-66
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: jena
>Affects Versions: 0.3.0
>Reporter: Christopher Johnson
>
> Occurs from this method 
> [https://github.com/apache/commons-rdf/blob/master/jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java#L152]
>  on instantiation:
> The exception message is "No dataset writer for N-Triples/utf-8".
> The source is RDFWriterRegistry that builds a registryDataset HashMap of 17 
> +Dataset+ RDFFormats that does not include this serialization.  The 
> registryGraph HashMap has 25 RDFFormats that does include "N-Triples/utf-8".
> No exception is thrown if Lang.NQUADS is set in the toString() method.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (DAEMON-336) prunsrv crash on service stop

2017-10-30 Thread Mark Thomas (JIRA)


 [ 
https://issues.apache.org/jira/browse/DAEMON-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas resolved DAEMON-336.

Resolution: Duplicate

I can't recreate this with the provided information. I am assuming it is a 
duplicate of the now fixed DAEMON-372.

If this isn't the case then feel free to re-open and provide the steps to 
reproduce the issue.

> prunsrv crash on service stop
> -
>
> Key: DAEMON-336
> URL: https://issues.apache.org/jira/browse/DAEMON-336
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Affects Versions: 1.0.15
> Environment: Windows 8.1 with Java 8 64bit, Java mode
>Reporter: Volker Berlin
>
> If the service should be stop then it crash. In the event log you can see:
> Name der fehlerhaften Anwendung: foo-serverService.exe, Version: 1.0.15.0, 
> Zeitstempel: 0x51543b9d
> Name des fehlerhaften Moduls: ntdll.dll, Version: 6.3.9600.17736, 
> Zeitstempel: 0x550f4336
> Ausnahmecode: 0xc005
> Fehleroffset: 0x00035150
> ID des fehlerhaften Prozesses: 0x1578
> Startzeit der fehlerhaften Anwendung: 0x01d0be119603c23f
> Pfad der fehlerhaften Anwendung: C:\Program Files\foo 
> Server\foo-serverService.exe
> Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\ntdll.dll
> Berichtskennung: da5b2537-2a04-11e5-8063-7427ea3e8675
> Vollständiger Name des fehlerhaften Pakets: 
> Anwendungs-ID, die relativ zum fehlerhaften Paket ist: 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

2017-10-30 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16224892#comment-16224892
 ] 

ASF GitHub Bot commented on COMMONSRDF-66:
--

GitHub user christopher-johnson opened a pull request:

https://github.com/apache/commons-rdf/pull/42

COMMONSRDF-66:  fixes RIOT exception in JenaDatasetImpl 

 Lang.NT is not supported by registryDataset.  Opts for Lang.NQUADS as a 
default replacement.
adds test

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/pan-dora/commons-rdf commonsrdf-66

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-rdf/pull/42.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #42


commit e627ba43597a5f20a985bd9373d030d9797fc1e7
Author: Christopher Johnson 
Date:   2017-10-30T12:51:45Z

fixes RIOT exception thrown by JenaDatasetImpl.toString()
adds test




> JenaDatasetImpl.toString() throws RIOT exception
> 
>
> Key: COMMONSRDF-66
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-66
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: jena
>Affects Versions: 0.3.0
>Reporter: Christopher Johnson
>
> Occurs from this method 
> [https://github.com/apache/commons-rdf/blob/master/jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java#L152]
>  on instantiation:
> The exception message is "No dataset writer for N-Triples/utf-8".
> The source is RDFWriterRegistry that builds a registryDataset HashMap of 17 
> +Dataset+ RDFFormats that does not include this serialization.  The 
> registryGraph HashMap has 25 RDFFormats that does include "N-Triples/utf-8".
> No exception is thrown if Lang.NQUADS is set in the toString() method.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (DAEMON-322) Missing Windows 2012 R2 support

2017-10-30 Thread Mark Thomas (JIRA)


 [ 
https://issues.apache.org/jira/browse/DAEMON-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas resolved DAEMON-322.

Resolution: Not A Problem

Testing shows that this is a JVM issue, not a Commons Daemon or Tomcat issue.

I can repeat these results on Windows Server 2012 R2 with Java 7u65 and 7u80. I 
get the correct results if I switch to Java 8u144.

> Missing Windows 2012 R2 support
> ---
>
> Key: DAEMON-322
> URL: https://issues.apache.org/jira/browse/DAEMON-322
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Affects Versions: 1.0.15
> Environment: Windows 2012 R2
> Tomcat 7.0.55
> Java 7u67
>Reporter: Bernd Ernesti
>
> Tomcat uses Procrun to install a Windows service.
> I opened a bug at the tomcat tracker 
> (https://issues.apache.org/bugzilla/show_bug.cgi?id=56929) and was pointed 
> out to open it here. Windows 8.1 is probably also affected too.
> Here is the Tomcat bug:
> The server information while running as a Windows service on 2012 R2 is wrong.
> The system is identified as:
>  OS Name: Windows Server 2012
>  OS Version: 6.2
> It is correct when starting tomcat with startup.bat:
>  OS Name: Windows Server 2012 R2
>  OS Version: 6.3
> How to reproduce:
> 1. Install the Windows service from apache-tomcat-7.0.55\bin
>service.bat install Test
> 2. Activate the configuration for the /manager/ access in 
> conf\tomcat-users.xml
> 3. Start the service
> 4. Navigate to the /manager/status page
> 5. The "Server Information" contains the wrong OS Version
> 6. Stop the Windows service
> 7. Start the tomcat with the startup.bat script
> 8. Check the /manager/status page again which now contains the correct version
> The issue could be related due too the service binary which needs to be 
> recompiled for:
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724832%28v=vs.85%29.aspx
> and the link inside it for:
> http://msdn.microsoft.com/en-us/library/windows/desktop/dn481241%28v=vs.85%29.aspx



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (JEXL-243) Allow restricting available features in Script/Expressions

[jira] [Commented] (JEXL-243) Allow restricting available features in Script/Expressions

[GitHub] commons-lang issue #299: Add module-info for Java 9

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

[jira] [Updated] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

[jira] [Updated] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

[GitHub] commons-lang issue #299: Add module-info for Java 9

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

[GitHub] commons-lang issue #299: Add module-info for Java 9

[jira] [Closed] (POOL-330) Drop Ant build

[GitHub] commons-lang pull request #299: Add module-info for Java 9

[jira] [Closed] (POOL-331) Update from Java 6 to 7

[jira] [Created] (POOL-331) Update from Java 6 to 7

[jira] [Created] (POOL-330) Drop Ant build

[jira] [Commented] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

[jira] [Updated] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

[jira] [Updated] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

[jira] [Commented] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

[jira] [Updated] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

[jira] [Created] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

[jira] [Comment Edited] (IMAGING-194) Tiff with JPEG,Zip compression fails to decompress

[jira] [Commented] (IMAGING-194) Tiff with JPEG,Zip compression fails to decompress

[jira] [Resolved] (DAEMON-359) Control characters messed up with SYSLOG output

[jira] [Resolved] (DAEMON-341) prunsrv injects garbage into ImagePath

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

[jira] [Resolved] (DAEMON-336) prunsrv crash on service stop

[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception

[jira] [Resolved] (DAEMON-322) Missing Windows 2012 R2 support

32 matches

Site Navigation

Mail list logo

Footer information