[jira] [Comment Edited] (JEXL-243) Allow restricting available features in Script/Expressions
[ https://issues.apache.org/jira/browse/JEXL-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/JEXL-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
[ https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
[ https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
[ 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
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
[ 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
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
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
[ https://issues.apache.org/jira/browse/IMAGING-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 (eve
[jira] [Updated] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata
[ 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 th
[jira] [Commented] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata
[ https://issues.apache.org/jira/browse/IMAGING-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
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
[ https://issues.apache.org/jira/browse/IMAGING-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IMAGING-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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)