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

[Joakim Knudsen (JIRA)]

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

Joakim Knudsen commented on IMAGING-205:


Well, I could certainly give it a try! I haven't tried compiling for Android 
because I read online that Android does not support java.awt (which is required 
for Imaging.

However, the Android release of Sanselan was apparently made by removing the 
parts of the code which relied on awt -- perhaps this can also be done for 
Imaging? 
https://stackoverflow.com/a/24147677/2736813


> 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
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Attachments: 20171030_21481_COPY.jpg, 
> Gaboxjellyfish-changedexifmetadata.jpg, Gaboxjellyfish.jpg, after.html, 
> before.html
>
>
> 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] [Closed] (IO-555) Add org.apache.commons.io.FilenameUtils.WINDOWS_ILLEGAL_FILE_NAME_CHARS

[Gary Gregory (JIRA)]

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

Gary Gregory closed IO-555.
---
   Resolution: Fixed
Fix Version/s: 2.7

In git master.

> Add org.apache.commons.io.FilenameUtils.WINDOWS_ILLEGAL_FILE_NAME_CHARS
> ---
>
> Key: IO-555
> URL: https://issues.apache.org/jira/browse/IO-555
> Project: Commons IO
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> Add {{org.apache.commons.io.FilenameUtils.WINDOWS_ILLEGAL_FILE_NAME_CHARS}}.
> {code:java}
> /**
>  * The characters that are illegal in Windows file names.
>  * 
>  * 
>  * < (less than
>  * > (greater than
>  * : (colon
>  * " (double quote
>  * / (forward slash
>  * \ (backslash
>  * | (vertical bar or pipe
>  * ? (question mark
>  * * (asterisk
>  * ASCII NUL (0)
>  * Integer characters 1 through 31
>  * 
>  * 
>  * @since 2.7
>  * @see  href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx">Naming
>  Files,
>  *  Paths, and Namespaces
>  */
> public static final char[] WINDOWS_ILLEGAL_FILE_NAME_CHARS = {
> // @formatter:off
> // ASCII NULL
> 0,  
> // 1-31 may be allowed in file streams
> 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 
> 19, 20, 21, 22, 23, 24, 25, 26, 27, 28,
> 29, 30, 31, 
> '<', '>', ':', '"', '/', '\\', '|', '?', '*'
> // @formatter:on
> };
> {code}



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

[jira] [Updated] (IO-555) Add org.apache.commons.io.FilenameUtils.WINDOWS_ILLEGAL_FILE_NAME_CHARS

[Gary Gregory (JIRA)]

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

Gary Gregory updated IO-555:

Description: 
Add {{org.apache.commons.io.FilenameUtils.WINDOWS_ILLEGAL_FILE_NAME_CHARS}}.

{code:java}
/**
 * The characters that are illegal in Windows file names.
 * 
 * 
 * < (less than
 * > (greater than
 * : (colon
 * " (double quote
 * / (forward slash
 * \ (backslash
 * | (vertical bar or pipe
 * ? (question mark
 * * (asterisk
 * ASCII NUL (0)
 * Integer characters 1 through 31
 * 
 * 
 * @since 2.7
 * @see https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx">Naming
 Files,
 *  Paths, and Namespaces
 */
public static final char[] WINDOWS_ILLEGAL_FILE_NAME_CHARS = {
// @formatter:off
// ASCII NULL
0,  
// 1-31 may be allowed in file streams
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 
20, 21, 22, 23, 24, 25, 26, 27, 28,
29, 30, 31, 
'<', '>', ':', '"', '/', '\\', '|', '?', '*'
// @formatter:on
};
{code}

  was:Add 
{{org.apache.commons.io.FilenameUtils.WINDOWS_ILLEGAL_FILE_NAME_CHARS}}.


> Add org.apache.commons.io.FilenameUtils.WINDOWS_ILLEGAL_FILE_NAME_CHARS
> ---
>
> Key: IO-555
> URL: https://issues.apache.org/jira/browse/IO-555
> Project: Commons IO
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> Add {{org.apache.commons.io.FilenameUtils.WINDOWS_ILLEGAL_FILE_NAME_CHARS}}.
> {code:java}
> /**
>  * The characters that are illegal in Windows file names.
>  * 
>  * 
>  * < (less than
>  * > (greater than
>  * : (colon
>  * " (double quote
>  * / (forward slash
>  * \ (backslash
>  * | (vertical bar or pipe
>  * ? (question mark
>  * * (asterisk
>  * ASCII NUL (0)
>  * Integer characters 1 through 31
>  * 
>  * 
>  * @since 2.7
>  * @see  href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx">Naming
>  Files,
>  *  Paths, and Namespaces
>  */
> public static final char[] WINDOWS_ILLEGAL_FILE_NAME_CHARS = {
> // @formatter:off
> // ASCII NULL
> 0,  
> // 1-31 may be allowed in file streams
> 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 
> 19, 20, 21, 22, 23, 24, 25, 26, 27, 28,
> 29, 30, 31, 
> '<', '>', ':', '"', '/', '\\', '|', '?', '*'
> // @formatter:on
> };
> {code}



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

[jira] [Created] (IO-555) Add org.apache.commons.io.FilenameUtils.WINDOWS_ILLEGAL_FILE_NAME_CHARS

[Gary Gregory (JIRA)]

Gary Gregory created IO-555:
---

 Summary: Add 
org.apache.commons.io.FilenameUtils.WINDOWS_ILLEGAL_FILE_NAME_CHARS
 Key: IO-555
 URL: https://issues.apache.org/jira/browse/IO-555
 Project: Commons IO
  Issue Type: Improvement
Reporter: Gary Gregory
Assignee: Gary Gregory


Add {{org.apache.commons.io.FilenameUtils.WINDOWS_ILLEGAL_FILE_NAME_CHARS}}.



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

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

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita commented on IMAGING-205:


No confusion at all. I've started to learn the code base and get myself used to 
the library recently. If I recall correctly, the development on Sanselan 
stopped, and it was since then moved to Apache Commons Imaging.

Not sure what are the requirements for Commons Imaging to be available for 
Android. Perhaps building the current sources into a jar would work?

There are a few blockers for a 1.0 release. But we could still try to release 
alpha/beta versions before that. In case having the JAR in a Maven repository 
is a requirement for you, and an -alpha or -beta works for you too. Even easier 
if you could use a -SNAPSHOT version.

> 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
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Attachments: 20171030_21481_COPY.jpg, 
> Gaboxjellyfish-changedexifmetadata.jpg, Gaboxjellyfish.jpg, after.html, 
> before.html
>
>
> 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] [Commented] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

[Joakim Knudsen (JIRA)]

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

Joakim Knudsen commented on IMAGING-205:


I'm using Sanselan 0.97 for my project, since this is an Android app. The 
details in this bug report, and the discussion at the Exiftool forum, all 
relate to Sanselan. The main concern with the generated image (as attached in 
this report) is that it corrupts the Maker Notes, and that it completely 
restructures the metadata (compared to the original image). The odd offsets are 
also a problem, but a relatively minor one. 

I have also tested with Commons Imaging (in a separate, small test project) and 
although the image still contains the odd offsets, it does look a lot better 
than the one produced by Sanselan. 

However, since I am dependant on an Android compatible library, I am hoping 
this bug might be fixed in the Sanselan library. If that is not possible, I'd 
like to know the status of making Commons Imaging available for Android? 

Thanks again, and sorry for the confusion!

> 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
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Attachments: 20171030_21481_COPY.jpg, 
> Gaboxjellyfish-changedexifmetadata.jpg, Gaboxjellyfish.jpg, after.html, 
> before.html
>
>
> 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] [Commented] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita commented on IMAGING-205:


Are you using the latest snapshot of Apache Commons Imaging? Or of Apache 
Sanselan? I tested the latest code from Git for Apache Commons Imaging, and the 
odd offsets were present in the generated image.

> 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
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Attachments: 20171030_21481_COPY.jpg, 
> Gaboxjellyfish-changedexifmetadata.jpg, Gaboxjellyfish.jpg, after.html, 
> before.html
>
>
> 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] [Commented] (LANG-1366) Add Feature for No ClassName and MultiLine StringStyle

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251960#comment-16251960
 ] 

ASF GitHub Bot commented on LANG-1366:
--

Github user coveralls commented on the issue:

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

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

Coverage decreased (-0.003%) to 95.165% when pulling 
**d716403dc4c3cbe30e596fcb6ceea82138c61af4 on pckeyan:master** into 
**721f3ef4aaa1f5cea764b3e9b1d639878b2a0a3b on apache:master**.



> Add Feature for No ClassName and MultiLine StringStyle
> --
>
> Key: LANG-1366
> URL: https://issues.apache.org/jira/browse/LANG-1366
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Reporter: Karthikeyan Palanivelu
>  Labels: features
>
> Add feature to print String with No Class Name and MultiLine. This would be 
> of helpful for more like metrics related use cases which needs to print like 
> properties with No Class Name and each property in new line.



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

[GitHub] commons-lang issue #308: LANG-1366 : Add Feature for No ClassName and MultiL...

[coveralls]

Github user coveralls commented on the issue:

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

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

Coverage decreased (-0.003%) to 95.165% when pulling 
**d716403dc4c3cbe30e596fcb6ceea82138c61af4 on pckeyan:master** into 
**721f3ef4aaa1f5cea764b3e9b1d639878b2a0a3b on apache:master**.



---

[jira] [Commented] (LANG-1366) Add Feature for No ClassName and MultiLine StringStyle

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251948#comment-16251948
 ] 

ASF GitHub Bot commented on LANG-1366:
--

GitHub user pckeyan opened a pull request:

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

LANG-1366 : Add Feature for No ClassName and MultiLine StringStyle

Added sub class to print with No Class Name in Multiline.
Added Junit.

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

$ git pull https://github.com/pckeyan/commons-lang master

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

https://github.com/apache/commons-lang/pull/308.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 #308


commit 2e806d5f576cfeb7fd151de197af3c54b9106e30
Author: Karthikeyan Palanivelu 
Date:   2017-11-06T15:28:50Z

LANG-1366 - Add Feature for No ClassName and MultiLine StringStyle

- Added the feature as a Inner Class to ToStringStyle
- Added JUnit

commit d716403dc4c3cbe30e596fcb6ceea82138c61af4
Author: Karthikeyan Palanivelu 
Date:   2017-11-06T15:33:53Z

Updated the Format




> Add Feature for No ClassName and MultiLine StringStyle
> --
>
> Key: LANG-1366
> URL: https://issues.apache.org/jira/browse/LANG-1366
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Reporter: Karthikeyan Palanivelu
>  Labels: features
>
> Add feature to print String with No Class Name and MultiLine. This would be 
> of helpful for more like metrics related use cases which needs to print like 
> properties with No Class Name and each property in new line.



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

[GitHub] commons-lang pull request #308: LANG-1366 : Add Feature for No ClassName and...

[pckeyan]

GitHub user pckeyan opened a pull request:

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

LANG-1366 : Add Feature for No ClassName and MultiLine StringStyle

Added sub class to print with No Class Name in Multiline.
Added Junit.

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

$ git pull https://github.com/pckeyan/commons-lang master

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

https://github.com/apache/commons-lang/pull/308.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 #308


commit 2e806d5f576cfeb7fd151de197af3c54b9106e30
Author: Karthikeyan Palanivelu 
Date:   2017-11-06T15:28:50Z

LANG-1366 - Add Feature for No ClassName and MultiLine StringStyle

- Added the feature as a Inner Class to ToStringStyle
- Added JUnit

commit d716403dc4c3cbe30e596fcb6ceea82138c61af4
Author: Karthikeyan Palanivelu 
Date:   2017-11-06T15:33:53Z

Updated the Format




---

[jira] [Commented] (LANG-1282) StringUtils#normalizeSpace normalizeSpace should not replace non-breaking spaces with normal whitespace

[Dirk Henselin (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251808#comment-16251808
 ] 

Dirk Henselin commented on LANG-1282:
-

IMO StringUtils#normalizeSpace should be idempotent, i.e.
{code:java}
String s = "a\u00A0 b";
assertEquals(StringUtils.normalizeSpace(s), 
StringUtils.normalizeSpace(StringUtils.normalizeSpace(s)));
{code}
Hence non-breaking spaces should not be replaced by normal spaces. Simply 
remove the replacement in the following line
{code:java}
newChars[count++] = (actualChar == 160 ? 32 : actualChar);
{code}



> StringUtils#normalizeSpace normalizeSpace should not replace non-breaking 
> spaces with normal whitespace
> ---
>
> Key: LANG-1282
> URL: https://issues.apache.org/jira/browse/LANG-1282
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Pascal Schumacher
>
> As of 3.4 StringUtils#normalizeSpace does not normalize non-breaking 
> whitespace anymore. Therefore it shouldn't replace a non-breaking whitespace 
> white breaking whitespace, but both assertions succeed:
> {code}
> assertEquals("a b", StringUtils.normalizeSpace("a\u00A0b"));
> assertEquals("a  b", StringUtils.normalizeSpace("a\u00A0 b"));
> {code}
> source: https://github.com/apache/commons-lang/pull/184



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

[jira] [Commented] (COMMONSRDF-49) Make AbstractRDFParser serializable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMMONSRDF-49:
--

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
So the question is whether what is here now is a step forward.

I think it is, and I would want to do what is here whether or not we go 
onto a builder factoring. I intentionally did not add the marker interface to 
the type, and I think it's okay for the moment (especially as this is in the 
`experimental` package). I can and will do a builder refactoring, but I don't 
want to slow anyone down waiting for that.


> Make AbstractRDFParser serializable
> ---
>
> Key: COMMONSRDF-49
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-49
> Project: Apache Commons RDF
>  Issue Type: New Feature
>  Components: simple
>Affects Versions: 0.3.0
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>  Labels: parser
> Fix For: 0.6.0
>
>
> Raised by [~p_ansell] in [pull request 
> 25|(https://github.com/apache/incubator-commonsrdf/pull/25#discussion_r85436754]
> {quote}
> The use of optional here as a field type makes it impossible to serialise. 
> Need to have the raw values stored in fields if you want to support 
> serialisation in the future, which should otherwise be possible.
> {quote}
> The suggestion is to avoid {{Optional}} in the private fields of 
> {{AbstractRDFParser}} so it can be serialized - it can still be {{Optional}} 
> in the accessor methods.



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

[jira] [Closed] (DAEMON-89) JVM detection should use run-time check

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-89.
-
Resolution: Won't Fix

> JVM detection should use run-time check
> ---
>
> Key: DAEMON-89
> URL: https://issues.apache.org/jira/browse/DAEMON-89
> Project: Commons Daemon
>  Issue Type: New Feature
>  Components: Jsvc
>Affects Versions: Nightly Builds
> Environment: Linux
>Reporter: Marcus Better
>Priority: Minor
>
> The checks for JVMs such as Kaffe or SableVM should be carried out at 
> run-time. Currently the support for these VMs is configured at compile time, 
> and support is conditioned on macros HAVE_KAFFEVM and HAVE_SABLEVM (see 
> location.c and java.c). This is useless for operating systems such as Debian, 
> which support several JVMs.
> Instead, jsvc should scan for all supported VMs on the platform at run-time.
> This should be a matter of simply removing the #ifdefs for the above macros, 
> but I haven't tested yet.



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

[jira] [Reopened] (DAEMON-89) JVM detection should use run-time check

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-89:
---

> JVM detection should use run-time check
> ---
>
> Key: DAEMON-89
> URL: https://issues.apache.org/jira/browse/DAEMON-89
> Project: Commons Daemon
>  Issue Type: New Feature
>  Components: Jsvc
>Affects Versions: Nightly Builds
> Environment: Linux
>Reporter: Marcus Better
>Priority: Minor
>
> The checks for JVMs such as Kaffe or SableVM should be carried out at 
> run-time. Currently the support for these VMs is configured at compile time, 
> and support is conditioned on macros HAVE_KAFFEVM and HAVE_SABLEVM (see 
> location.c and java.c). This is useless for operating systems such as Debian, 
> which support several JVMs.
> Instead, jsvc should scan for all supported VMs on the platform at run-time.
> This should be a matter of simply removing the #ifdefs for the above macros, 
> but I haven't tested yet.



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

[jira] [Closed] (DAEMON-107) JSVC does not support a reconfiguration call

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-107.
--
   Resolution: Fixed
Fix Version/s: 1.0.6

> JSVC does not support a reconfiguration call
> 
>
> Key: DAEMON-107
> URL: https://issues.apache.org/jira/browse/DAEMON-107
> Project: Commons Daemon
>  Issue Type: Improvement
>  Components: Jsvc
>Affects Versions: 1.0.1
> Environment: Linux Enterprise 10
>Reporter: Thomas Kiesslich
>Priority: Minor
> Fix For: 1.0.6
>
>
> The JSVC interface does not support any reconfiguration calls.
> It would be nice to send the application some kind of reinitialization, 
> reconfiguration triggers.
> I could imagine to have another parameter for JSVC saying  -reconfigure with 
> parameters which calls the interface method reconfigure(Properties) in the 
> Daemon interface implementing class.



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

[jira] [Closed] (DAEMON-225) Remove leftovers of Kaffe VM and Sable VM

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-225.
--
   Resolution: Fixed
Fix Version/s: 1.0.8

> Remove leftovers of Kaffe VM and Sable VM
> -
>
> Key: DAEMON-225
> URL: https://issues.apache.org/jira/browse/DAEMON-225
> Project: Commons Daemon
>  Issue Type: Sub-task
>  Components: Jsvc
>Affects Versions: Nightly Builds
>Reporter: Michael Osipov
> Fix For: 1.0.8
>
>
> Though compile support has been removed some stuff is still in the source 
> code:
> {noformat}
> mosipov@hardy-heron:~/Projekte/daemon/src/native/unix$ fgrep -Rn 
> --exclude=*\.svn* "SABLEVM" *
> native/java.c:331:#if defined(HAVE_SABLEVM)
> mosipov@hardy-heron:~/Projekte/daemon/src/native/unix$ fgrep -Rn 
> --exclude=*\.svn* "KAFFEVM" *
> native/jsvc-unix.c:735:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/arguments.c:330:#ifdef HAVE_KAFFEVM
> native/java.c:169:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/java.c:214:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/java.c:243:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/java.c:245:#if defined(HAVE_KAFFEVM)
> native/java.c:311:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> {noformat}



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

[jira] [Reopened] (DAEMON-107) JSVC does not support a reconfiguration call

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-107:


> JSVC does not support a reconfiguration call
> 
>
> Key: DAEMON-107
> URL: https://issues.apache.org/jira/browse/DAEMON-107
> Project: Commons Daemon
>  Issue Type: Improvement
>  Components: Jsvc
>Affects Versions: 1.0.1
> Environment: Linux Enterprise 10
>Reporter: Thomas Kiesslich
>Priority: Minor
>
> The JSVC interface does not support any reconfiguration calls.
> It would be nice to send the application some kind of reinitialization, 
> reconfiguration triggers.
> I could imagine to have another parameter for JSVC saying  -reconfigure with 
> parameters which calls the interface method reconfigure(Properties) in the 
> Daemon interface implementing class.



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

[jira] [Reopened] (DAEMON-225) Remove leftovers of Kaffe VM and Sable VM

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-225:


> Remove leftovers of Kaffe VM and Sable VM
> -
>
> Key: DAEMON-225
> URL: https://issues.apache.org/jira/browse/DAEMON-225
> Project: Commons Daemon
>  Issue Type: Sub-task
>  Components: Jsvc
>Affects Versions: Nightly Builds
>Reporter: Michael Osipov
>
> Though compile support has been removed some stuff is still in the source 
> code:
> {noformat}
> mosipov@hardy-heron:~/Projekte/daemon/src/native/unix$ fgrep -Rn 
> --exclude=*\.svn* "SABLEVM" *
> native/java.c:331:#if defined(HAVE_SABLEVM)
> mosipov@hardy-heron:~/Projekte/daemon/src/native/unix$ fgrep -Rn 
> --exclude=*\.svn* "KAFFEVM" *
> native/jsvc-unix.c:735:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/arguments.c:330:#ifdef HAVE_KAFFEVM
> native/java.c:169:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/java.c:214:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/java.c:243:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/java.c:245:#if defined(HAVE_KAFFEVM)
> native/java.c:311:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> {noformat}



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

[jira] [Closed] (DAEMON-285) jsvc seams not to be supported on netbsd

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-285.
--
Resolution: Duplicate

> jsvc seams not to be supported on netbsd
> 
>
> Key: DAEMON-285
> URL: https://issues.apache.org/jira/browse/DAEMON-285
> Project: Commons Daemon
>  Issue Type: Improvement
>  Components: Jsvc
>Affects Versions: 1.0.13
> Environment: netbsd 5.2-RELEASE amd64
>Reporter: Alfred Reibenschuh
>Priority: Trivial
>  Labels: jsvc, netbsd, port
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> configure --with-host=x86_64-unknown-freebsd 
> lets jsvc build on x86_64-unknown-netbsd5.2 flawlessly without error.



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

[jira] [Reopened] (DAEMON-285) jsvc seams not to be supported on netbsd

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-285:

  Assignee: (was: Guillaume Chauvet)

> jsvc seams not to be supported on netbsd
> 
>
> Key: DAEMON-285
> URL: https://issues.apache.org/jira/browse/DAEMON-285
> Project: Commons Daemon
>  Issue Type: Improvement
>  Components: Jsvc
>Affects Versions: 1.0.13
> Environment: netbsd 5.2-RELEASE amd64
>Reporter: Alfred Reibenschuh
>Priority: Trivial
>  Labels: jsvc, netbsd, port
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> configure --with-host=x86_64-unknown-freebsd 
> lets jsvc build on x86_64-unknown-netbsd5.2 flawlessly without error.



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

[jira] [Closed] (DAEMON-64) [daemon] Procrun 2 reserves semicolon; PATH spec fails on XP

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-64.
-
   Resolution: Fixed
Fix Version/s: 1.0.2

> [daemon] Procrun 2 reserves semicolon; PATH spec fails on XP
> 
>
> Key: DAEMON-64
> URL: https://issues.apache.org/jira/browse/DAEMON-64
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: Operating System: Windows XP
> Platform: PC
>Reporter: Ken Gartner
> Fix For: 1.0.2
>
>
> I am using the NT service setup that ships with Tomcat 5.5.4. It is using 
> ProcRun 2.0 (as far as the log messages indicate). I am trying to set an 
> environment variable using --Environment syntax. However, I am thwarted when 
> my environment variable has an embedded semicolon -- specifically I *really* 
> need to set the PATH environment variable on Windows. Since semicolon is the 
> path separator only the first element on my PATH setting is honored (the 
> settings made in the registry show that). Tomcat crashes hard in this case 
> since SYSTEM32 has been dropped from the PATH.
> What I need is a near term workaround/suggestion, perhaps as:
> (1) Is there a way to specify an alternate field separator than semicolon?
> (2) Is there a way that I can augment the PATH environment one folder at a 
> time such that I can prepend to existing PATH?
> (3) Is there as escape sequence that lets me bypass special processing for 
> semicolon and hashmark (the other separator character).
> Note I observe the same problem when I try to set the --Jvm option for -
> Djava.library.path with a semicolon-separated list. Bottom line: semicolon is 
> not a suitable reserved character in a windows environment.
> Although I did not raise the severity of this bug, it is *blocking* for me 
> now 
> since some of my nested DLLs need to be resolved in tomcat and I cannot 
> change 
> the PATH variable for the entire machine.
> Thanks for any workaround suggestions. I appreciate the service wrapper, but 
> this one glitch has been unfortunate.
> Ken Gartner



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

[jira] [Reopened] (DAEMON-64) [daemon] Procrun 2 reserves semicolon; PATH spec fails on XP

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-64:
---

> [daemon] Procrun 2 reserves semicolon; PATH spec fails on XP
> 
>
> Key: DAEMON-64
> URL: https://issues.apache.org/jira/browse/DAEMON-64
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: Operating System: Windows XP
> Platform: PC
>Reporter: Ken Gartner
>
> I am using the NT service setup that ships with Tomcat 5.5.4. It is using 
> ProcRun 2.0 (as far as the log messages indicate). I am trying to set an 
> environment variable using --Environment syntax. However, I am thwarted when 
> my environment variable has an embedded semicolon -- specifically I *really* 
> need to set the PATH environment variable on Windows. Since semicolon is the 
> path separator only the first element on my PATH setting is honored (the 
> settings made in the registry show that). Tomcat crashes hard in this case 
> since SYSTEM32 has been dropped from the PATH.
> What I need is a near term workaround/suggestion, perhaps as:
> (1) Is there a way to specify an alternate field separator than semicolon?
> (2) Is there a way that I can augment the PATH environment one folder at a 
> time such that I can prepend to existing PATH?
> (3) Is there as escape sequence that lets me bypass special processing for 
> semicolon and hashmark (the other separator character).
> Note I observe the same problem when I try to set the --Jvm option for -
> Djava.library.path with a semicolon-separated list. Bottom line: semicolon is 
> not a suitable reserved character in a windows environment.
> Although I did not raise the severity of this bug, it is *blocking* for me 
> now 
> since some of my nested DLLs need to be resolved in tomcat and I cannot 
> change 
> the PATH variable for the entire machine.
> Thanks for any workaround suggestions. I appreciate the service wrapper, but 
> this one glitch has been unfortunate.
> Ken Gartner



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

[jira] [Reopened] (DAEMON-70) [daemon] Making jsvc multiple instances enabled

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-70:
---

> [daemon] Making jsvc multiple instances enabled
> ---
>
> Key: DAEMON-70
> URL: https://issues.apache.org/jira/browse/DAEMON-70
> Project: Commons Daemon
>  Issue Type: Improvement
> Environment: Operating System: All
> Platform: All
>Reporter: Wolfgang Hackl
>Priority: Minor
> Fix For: 1.0.2
>
>
> This bug is closely related to 33580. The Tomcat5.sh script bundled with jsvc 
> is
> not capable of handling multiple instances. According to
> http://miti.sourceforge.net this script should be adapted in the following 
> ways:
> 1) Introduce a variable $INSTANCE_NAME which is unique
> 2) Introduce a variable $CATALINA_BASE_DIRS which represents a directory where
> all the instances will be located (e.g. /usr/local/tomcat/instances)
> 3) Set $CATALINA_BASE in the script (or require the shell variable to be
> non-zero) to  $CATALINA_BASE/$INSTANCE_NAME
> 4) Introduce a parameter TMP_DIR=$CATALINA_BASE/$INSTANCE_NAME/temp
> 5) Adapt the parameter in the jsvc call: "-Djava.io.tmpdir=$TMP_DIR \" 
> 6) Introduce a parameter PIDFILE=/var/run/jsvc-$INSTANCE_NAME.pid
> 7) Add a line with "-pidfile $PIDFILE \" to the parameters for the jsvc call 
> in
> the start section
> 8) Change the stop case to
> stop)
> #
> # Stop Tomcat
> #
> PID=`cat $PIDFILE`
> if [ -n $PID ]
> then
>kill $PID
>rm $PIDFILE
> fi
> ;;
> If the installation is for a single instance, $CATALINA_BASE will be empty and
> therefore can be set to $CATALINA_HOME.
> Point 8) might even be better addressed by the jsvc executable.



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

[jira] [Closed] (DAEMON-70) [daemon] Making jsvc multiple instances enabled

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-70.
-
   Resolution: Fixed
Fix Version/s: 1.0.2

> [daemon] Making jsvc multiple instances enabled
> ---
>
> Key: DAEMON-70
> URL: https://issues.apache.org/jira/browse/DAEMON-70
> Project: Commons Daemon
>  Issue Type: Improvement
> Environment: Operating System: All
> Platform: All
>Reporter: Wolfgang Hackl
>Priority: Minor
> Fix For: 1.0.2
>
>
> This bug is closely related to 33580. The Tomcat5.sh script bundled with jsvc 
> is
> not capable of handling multiple instances. According to
> http://miti.sourceforge.net this script should be adapted in the following 
> ways:
> 1) Introduce a variable $INSTANCE_NAME which is unique
> 2) Introduce a variable $CATALINA_BASE_DIRS which represents a directory where
> all the instances will be located (e.g. /usr/local/tomcat/instances)
> 3) Set $CATALINA_BASE in the script (or require the shell variable to be
> non-zero) to  $CATALINA_BASE/$INSTANCE_NAME
> 4) Introduce a parameter TMP_DIR=$CATALINA_BASE/$INSTANCE_NAME/temp
> 5) Adapt the parameter in the jsvc call: "-Djava.io.tmpdir=$TMP_DIR \" 
> 6) Introduce a parameter PIDFILE=/var/run/jsvc-$INSTANCE_NAME.pid
> 7) Add a line with "-pidfile $PIDFILE \" to the parameters for the jsvc call 
> in
> the start section
> 8) Change the stop case to
> stop)
> #
> # Stop Tomcat
> #
> PID=`cat $PIDFILE`
> if [ -n $PID ]
> then
>kill $PID
>rm $PIDFILE
> fi
> ;;
> If the installation is for a single instance, $CATALINA_BASE will be empty and
> therefore can be set to $CATALINA_HOME.
> Point 8) might even be better addressed by the jsvc executable.



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

[jira] [Closed] (DAEMON-65) [daemon] runs as multiple instances, does not use PID file logic

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-65.
-
   Resolution: Fixed
Fix Version/s: 1.0.2

> [daemon] runs as multiple instances, does not use PID file logic
> 
>
> Key: DAEMON-65
> URL: https://issues.apache.org/jira/browse/DAEMON-65
> Project: Commons Daemon
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: Operating System: Linux
> Platform: PC
>Reporter: bernard
>Priority: Critical
> Fix For: 1.0.2
>
>
> jsvc writes its own pid file but it appears that it does not have a logic that
> secures its own integrity.
> Multiple duplicate processes can be created simply by issuing the same jsvc
> command multiple times. The created processes cannot be killed using the pppid
> file for obvious reasons.
> 1) jsvc should terminate prematurely if it finds its own pid file.
> 2) jsvc should delete its own pid file when killed.
> If 1) and 2) are not acceptable because (hypothetically, because I don't know
> the specifications) the specifications require that the caller incorporates 
> this
> logic, then jsvc should not write a pid file.
> Why do i think so?
> Depending on implementation, the risk of malfunctioning is much higher if the
> pid file is managed across different execution environments.
> One major reason is that these environments are not usually maintained by the
> same person.
> I guess one might try to get a file system lock on the pid file before 
> launching
> the java program.
> Please excuse my ignorance if I am misinterpreting the daemon functionality in
> any way. I have tried to get responses from 3 relevant mailing lists,
> commons-user, commons-dev and tomcat-user, but nobody replied.
> I am not a Linux programmer and I would not be surprised if this kind of
> programming problem (uniqueness of id'd processes on one machine) has a 
> standard
> solution under Linux.
> Because



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

[jira] [Reopened] (DAEMON-65) [daemon] runs as multiple instances, does not use PID file logic

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-65:
---

> [daemon] runs as multiple instances, does not use PID file logic
> 
>
> Key: DAEMON-65
> URL: https://issues.apache.org/jira/browse/DAEMON-65
> Project: Commons Daemon
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: Operating System: Linux
> Platform: PC
>Reporter: bernard
>Priority: Critical
>
> jsvc writes its own pid file but it appears that it does not have a logic that
> secures its own integrity.
> Multiple duplicate processes can be created simply by issuing the same jsvc
> command multiple times. The created processes cannot be killed using the pppid
> file for obvious reasons.
> 1) jsvc should terminate prematurely if it finds its own pid file.
> 2) jsvc should delete its own pid file when killed.
> If 1) and 2) are not acceptable because (hypothetically, because I don't know
> the specifications) the specifications require that the caller incorporates 
> this
> logic, then jsvc should not write a pid file.
> Why do i think so?
> Depending on implementation, the risk of malfunctioning is much higher if the
> pid file is managed across different execution environments.
> One major reason is that these environments are not usually maintained by the
> same person.
> I guess one might try to get a file system lock on the pid file before 
> launching
> the java program.
> Please excuse my ignorance if I am misinterpreting the daemon functionality in
> any way. I have tried to get responses from 3 relevant mailing lists,
> commons-user, commons-dev and tomcat-user, but nobody replied.
> I am not a Linux programmer and I would not be surprised if this kind of
> programming problem (uniqueness of id'd processes on one machine) has a 
> standard
> solution under Linux.
> Because



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

[jira] [Closed] (DAEMON-67) signal handling on Solaris 5.8

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-67.
-
   Resolution: Fixed
Fix Version/s: 1.0.2

> signal handling on Solaris 5.8
> --
>
> Key: DAEMON-67
> URL: https://issues.apache.org/jira/browse/DAEMON-67
> Project: Commons Daemon
>  Issue Type: Bug
>Affects Versions: 1.0 Alpha
> Environment: Operating System: Solaris
> Platform: Sun
>Reporter: Peter Poloha
> Fix For: 1.0.2
>
> Attachments: ASF.LICENSE.NOT.GRANTED--jsvc-unix.diff
>
>
> in the handler() function (jsvc-unix.c) is after catching the relevant signal
> the flag stopping set and the handler tries to call itself once again (over 
> the
> func.pointer handler_xxx). In this case, the stop/restart daemon doesn't work
> correctly on Solaris, and ends with a status 143 (129) instead of 0 (123),
> without calling a java_stop()/java_destroy(). 
> If those duplicate calls from handler are removed, the daemon stop/restart 
> works
> fine and correct.



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

[jira] [Reopened] (DAEMON-67) signal handling on Solaris 5.8

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-67:
---

> signal handling on Solaris 5.8
> --
>
> Key: DAEMON-67
> URL: https://issues.apache.org/jira/browse/DAEMON-67
> Project: Commons Daemon
>  Issue Type: Bug
>Affects Versions: 1.0 Alpha
> Environment: Operating System: Solaris
> Platform: Sun
>Reporter: Peter Poloha
> Fix For: 1.0.2
>
> Attachments: ASF.LICENSE.NOT.GRANTED--jsvc-unix.diff
>
>
> in the handler() function (jsvc-unix.c) is after catching the relevant signal
> the flag stopping set and the handler tries to call itself once again (over 
> the
> func.pointer handler_xxx). In this case, the stop/restart daemon doesn't work
> correctly on Solaris, and ends with a status 143 (129) instead of 0 (123),
> without calling a java_stop()/java_destroy(). 
> If those duplicate calls from handler are removed, the daemon stop/restart 
> works
> fine and correct.



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

[jira] [Reopened] (DAEMON-86) [daemon] procrun --User and --Password options do not work

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-86:
---

> [daemon] procrun --User and --Password options do not work
> --
>
> Key: DAEMON-86
> URL: https://issues.apache.org/jira/browse/DAEMON-86
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: Windows 2000, 2003, XP
>Reporter: Gael Marziou
> Fix For: 1.0.2
>
>
> Using procrun as tomcat5.exe from Tomcat 5.5.17 distribution, I am unable to 
> set the user and password using --User and  --Password options, I searched in 
> the mailing list archive, it seems that several users have experienced this 
> bug but no solution was provided.
> I tried the following:
> tomcat5.exe //US// --User tomcat_usr --Password 1qaZ2wsX
> tomcat5.exe //US// --User "tomcat_usr" --Password "1qaZ2wsX"
> tomcat5.exe //US// --User .\tomcat_usr --Password 1qaZ2wsX
> tomcat5.exe //US// --User ".\tomcat_usr" --Password 1qaZ2wsX
> tomcat5.exe //US// --User ".\tomcat_usr" --Password "1qaZ2wsX"
> I tested both on Windows 2000, 2003 and XP, no luck.
> I also tried using environment variables PR_USER and PR_PASSWORD: also not 
> working.
> Finally, I ended up by using the "sc" command but it does not exist in 
> Windows 2000.
> sc config tomcat5 obj= .\tomcat_usr password= "1qaZ2wsX"
> So having these options working would help automatic deployment 



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

[jira] [Closed] (DAEMON-86) [daemon] procrun --User and --Password options do not work

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-86.
-
   Resolution: Fixed
Fix Version/s: 1.0.2

> [daemon] procrun --User and --Password options do not work
> --
>
> Key: DAEMON-86
> URL: https://issues.apache.org/jira/browse/DAEMON-86
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: Windows 2000, 2003, XP
>Reporter: Gael Marziou
> Fix For: 1.0.2
>
>
> Using procrun as tomcat5.exe from Tomcat 5.5.17 distribution, I am unable to 
> set the user and password using --User and  --Password options, I searched in 
> the mailing list archive, it seems that several users have experienced this 
> bug but no solution was provided.
> I tried the following:
> tomcat5.exe //US// --User tomcat_usr --Password 1qaZ2wsX
> tomcat5.exe //US// --User "tomcat_usr" --Password "1qaZ2wsX"
> tomcat5.exe //US// --User .\tomcat_usr --Password 1qaZ2wsX
> tomcat5.exe //US// --User ".\tomcat_usr" --Password 1qaZ2wsX
> tomcat5.exe //US// --User ".\tomcat_usr" --Password "1qaZ2wsX"
> I tested both on Windows 2000, 2003 and XP, no luck.
> I also tried using environment variables PR_USER and PR_PASSWORD: also not 
> working.
> Finally, I ended up by using the "sc" command but it does not exist in 
> Windows 2000.
> sc config tomcat5 obj= .\tomcat_usr password= "1qaZ2wsX"
> So having these options working would help automatic deployment 



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

[jira] [Reopened] (DAEMON-87) procrun as tomcat5.exe from Tomcat 5.5.17 does not start, when installed into the file path containing non-ascii character

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-87:
---

> procrun as tomcat5.exe from Tomcat 5.5.17 does not start, when installed into 
> the file path containing non-ascii character
> --
>
> Key: DAEMON-87
> URL: https://issues.apache.org/jira/browse/DAEMON-87
> Project: Commons Daemon
>  Issue Type: Bug
>Reporter: Yury Litvinov
> Fix For: 1.0.2
>
> Attachments: apxwin.h, prunsrv.c, utils.c
>
>
> Tomcat Service can not be started if Tomcat was installed into the path, 
> containing non-ASCII (e.g. Japanese or Chinese) symbols.
> The problem is apparently due to the improper treatment of non-ascii 
> characters in the "Java classpath" section of the Service settings.
> In tomcat5w.exe GUI or windows registry I could see proper PATH, namely
> C:\[ONE CHINESE HIEROGLIPH]\Tomcat 5.5\bin\bootstrap.jar
> Unfortunately, service doesn't get started with the following log:
> [2006-09-15 18:29:17] [457  javajni.c] [error] FindClass 
> org/apache/catalina/startup/Bootstrap failed
> [2006-09-15 18:29:17] [935  prunsrv.c] [error] Failed loading main 
> org/apache/catalina/startup/Bootstrap class C:\ss\Tomcat 5.5\bin\bootstrap.jar
> [2006-09-15 18:29:17] [1179 prunsrv.c] [error] ServiceStart returned 3
> where the non-ascii symbol gets replaced with improper ascii 'ss' sequence.
> Moreover, I tried to define environmental variables PR_CLASSPATH and 
> PR_STARTPATH instead of using corresponding service params. The result is 
> exactly the same.
> Please, suggest me the workaround to make Tomcat service run.
> P.S. The problem is stable either under JRE 1.5.0_02 or 1.4.2_10 (within 
> tomcat compatibility package). The problem exist apparently under all OS (in 
> particular, it was detected on Windows 2000 and Windows XP Pro 2002 SP2 
> either 
> Chinese version or standard English with Chinese System locale installed.



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

[jira] [Closed] (DAEMON-87) procrun as tomcat5.exe from Tomcat 5.5.17 does not start, when installed into the file path containing non-ascii character

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-87.
-
   Resolution: Fixed
Fix Version/s: 1.0.2

> procrun as tomcat5.exe from Tomcat 5.5.17 does not start, when installed into 
> the file path containing non-ascii character
> --
>
> Key: DAEMON-87
> URL: https://issues.apache.org/jira/browse/DAEMON-87
> Project: Commons Daemon
>  Issue Type: Bug
>Reporter: Yury Litvinov
> Fix For: 1.0.2
>
> Attachments: apxwin.h, prunsrv.c, utils.c
>
>
> Tomcat Service can not be started if Tomcat was installed into the path, 
> containing non-ASCII (e.g. Japanese or Chinese) symbols.
> The problem is apparently due to the improper treatment of non-ascii 
> characters in the "Java classpath" section of the Service settings.
> In tomcat5w.exe GUI or windows registry I could see proper PATH, namely
> C:\[ONE CHINESE HIEROGLIPH]\Tomcat 5.5\bin\bootstrap.jar
> Unfortunately, service doesn't get started with the following log:
> [2006-09-15 18:29:17] [457  javajni.c] [error] FindClass 
> org/apache/catalina/startup/Bootstrap failed
> [2006-09-15 18:29:17] [935  prunsrv.c] [error] Failed loading main 
> org/apache/catalina/startup/Bootstrap class C:\ss\Tomcat 5.5\bin\bootstrap.jar
> [2006-09-15 18:29:17] [1179 prunsrv.c] [error] ServiceStart returned 3
> where the non-ascii symbol gets replaced with improper ascii 'ss' sequence.
> Moreover, I tried to define environmental variables PR_CLASSPATH and 
> PR_STARTPATH instead of using corresponding service params. The result is 
> exactly the same.
> Please, suggest me the workaround to make Tomcat service run.
> P.S. The problem is stable either under JRE 1.5.0_02 or 1.4.2_10 (within 
> tomcat compatibility package). The problem exist apparently under all OS (in 
> particular, it was detected on Windows 2000 and Windows XP Pro 2002 SP2 
> either 
> Chinese version or standard English with Chinese System locale installed.



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

[jira] [Closed] (DAEMON-88) JMX java options can cause silent service failure

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-88.
-
Resolution: Won't Fix

> JMX java options can cause silent service failure
> -
>
> Key: DAEMON-88
> URL: https://issues.apache.org/jira/browse/DAEMON-88
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Reporter: Mark Thomas
>
> See http://issues.apache.org/bugzilla/show_bug.cgi?id=35635 for the full 
> history.
> Short version is:
> * Install 5.5.20
> * add -Dcom.sun.management.jmxremote.port= and 
> -Dcom.sun.management.jmxremote.password.file=C:\jmxremote.password to Java 
> Options
> * Try to start the service
> The service fails to start and creates only zero byte log files



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

[jira] [Reopened] (DAEMON-88) JMX java options can cause silent service failure

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-88:
---

> JMX java options can cause silent service failure
> -
>
> Key: DAEMON-88
> URL: https://issues.apache.org/jira/browse/DAEMON-88
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Reporter: Mark Thomas
>
> See http://issues.apache.org/bugzilla/show_bug.cgi?id=35635 for the full 
> history.
> Short version is:
> * Install 5.5.20
> * add -Dcom.sun.management.jmxremote.port= and 
> -Dcom.sun.management.jmxremote.password.file=C:\jmxremote.password to Java 
> Options
> * Try to start the service
> The service fails to start and creates only zero byte log files



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

[jira] [Closed] (DAEMON-131) Win64 build: //DS// fails to delete registry keys

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-131.
--
   Resolution: Fixed
Fix Version/s: 1.0.2

> Win64 build:   //DS// fails to delete registry keys
> ---
>
> Key: DAEMON-131
> URL: https://issues.apache.org/jira/browse/DAEMON-131
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: Win64; I've only seen it on AMD64, but presumably it 
> would also happen on ia64.
>Reporter: Jesse Morris
>Priority: Minor
> Fix For: 1.0.2
>
> Attachments: procrun-win64-registry-cleanup.patch
>
>
> When creating and accessing the configuration registry keys, the tool uses 
> CreateRegKeyEx with the KEY_WOW64_32KEY flag, telling windows "Use the 32-bit 
> hive instead of the 64-bit one".  Maybe this was done so that 64-bit daemons 
> could use the configuration from 32-bit ones?  
> Anyway when it's time to go and delete the configuration from the registry it 
> uses the ancient SHDeleteKey call, which tries to delete the key from the 
> 64-bit hive, which fails, so the key is left behind.



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

[jira] [Reopened] (DAEMON-131) Win64 build: //DS// fails to delete registry keys

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-131:

  Assignee: (was: Mladen Turk)

> Win64 build:   //DS// fails to delete registry keys
> ---
>
> Key: DAEMON-131
> URL: https://issues.apache.org/jira/browse/DAEMON-131
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: Win64; I've only seen it on AMD64, but presumably it 
> would also happen on ia64.
>Reporter: Jesse Morris
>Priority: Minor
> Fix For: 1.0.2
>
> Attachments: procrun-win64-registry-cleanup.patch
>
>
> When creating and accessing the configuration registry keys, the tool uses 
> CreateRegKeyEx with the KEY_WOW64_32KEY flag, telling windows "Use the 32-bit 
> hive instead of the 64-bit one".  Maybe this was done so that 64-bit daemons 
> could use the configuration from 32-bit ones?  
> Anyway when it's time to go and delete the configuration from the registry it 
> uses the ancient SHDeleteKey call, which tries to delete the key from the 
> 64-bit hive, which fails, so the key is left behind.



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

[jira] [Reopened] (DAEMON-229) Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-229:


> Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
> ---
>
> Key: DAEMON-229
> URL: https://issues.apache.org/jira/browse/DAEMON-229
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Affects Versions: 1.0.7
> Environment: Windows 2003 server 64bit
> Sun JDK1.6.0_29 64bit
>Reporter: Apache Fan
> Fix For: 1.0.9
>
>
> I tried to install Commons Daemon on 64 bit Windows 2003 Server with JDK 
> 1.6.0_29 64 bit.
> During starting a service (Cassandra) I receive the error log below.
> As a workaround I installed 32 bit JVM, and configured the 
> \jre6\bin\client\jvm.dll as JVM with the prunmgr //ES//servicename
> (Hint found at 
> http://www.mkyong.com/tomcat/tomcat-error-prunsrvc-failed-creating-java-jvmdll/
>   )
> Compatibility with 64 bit JVM should be established.
> {noformat}
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1519) Commons Daemon procrun log 
> initialized
> [2011-11-25 02:50:51] [info]  (  :0   ) Commons Daemon procrun 
> (1.0.7.0 32-bit) started
> [2011-11-25 02:50:51] [info]  (  :0   ) Running 'cassandra' Service...
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1259) Inside ServiceMain...
> [2011-11-25 02:50:51] [info]  (  :0   ) Starting service...
> [2011-11-25 02:50:51] [debug] ( javajni.c:206 ) loading jvm 
> 'D:\apps\jre6\bin\server\jvm.dll'
> [2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to 
> 'D:\apps\jre6\bin\server'
> [2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to 
> 'D:\apps\jre6\bin'
> [2011-11-25 02:50:52] [error] ( javajni.c:264 ) %1 is not a valid Win32 
> application.
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1045) Failed creating java 
> D:\apps\jre6\bin\server\jvm.dll
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1045) %1 is not a valid Win32 
> application.
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1402) ServiceStart returned 1
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1402) %1 is not a valid Win32 
> application.
> [2011-11-25 02:50:52] [info]  (  :0   ) Run service finished.
> [2011-11-25 02:50:52] [info]  (  :0   ) Commons Daemon procrun 
> finished
> {noformat}



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

[jira] [Closed] (DAEMON-229) Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-229.
--
   Resolution: Fixed
Fix Version/s: 1.0.9

> Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
> ---
>
> Key: DAEMON-229
> URL: https://issues.apache.org/jira/browse/DAEMON-229
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Affects Versions: 1.0.7
> Environment: Windows 2003 server 64bit
> Sun JDK1.6.0_29 64bit
>Reporter: Apache Fan
> Fix For: 1.0.9
>
>
> I tried to install Commons Daemon on 64 bit Windows 2003 Server with JDK 
> 1.6.0_29 64 bit.
> During starting a service (Cassandra) I receive the error log below.
> As a workaround I installed 32 bit JVM, and configured the 
> \jre6\bin\client\jvm.dll as JVM with the prunmgr //ES//servicename
> (Hint found at 
> http://www.mkyong.com/tomcat/tomcat-error-prunsrvc-failed-creating-java-jvmdll/
>   )
> Compatibility with 64 bit JVM should be established.
> {noformat}
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1519) Commons Daemon procrun log 
> initialized
> [2011-11-25 02:50:51] [info]  (  :0   ) Commons Daemon procrun 
> (1.0.7.0 32-bit) started
> [2011-11-25 02:50:51] [info]  (  :0   ) Running 'cassandra' Service...
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1259) Inside ServiceMain...
> [2011-11-25 02:50:51] [info]  (  :0   ) Starting service...
> [2011-11-25 02:50:51] [debug] ( javajni.c:206 ) loading jvm 
> 'D:\apps\jre6\bin\server\jvm.dll'
> [2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to 
> 'D:\apps\jre6\bin\server'
> [2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to 
> 'D:\apps\jre6\bin'
> [2011-11-25 02:50:52] [error] ( javajni.c:264 ) %1 is not a valid Win32 
> application.
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1045) Failed creating java 
> D:\apps\jre6\bin\server\jvm.dll
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1045) %1 is not a valid Win32 
> application.
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1402) ServiceStart returned 1
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1402) %1 is not a valid Win32 
> application.
> [2011-11-25 02:50:52] [info]  (  :0   ) Run service finished.
> [2011-11-25 02:50:52] [info]  (  :0   ) Commons Daemon procrun 
> finished
> {noformat}



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

[jira] [Reopened] (DAEMON-230) Procrun Documentation

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-230:


> Procrun Documentation
> -
>
> Key: DAEMON-230
> URL: https://issues.apache.org/jira/browse/DAEMON-230
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Reporter: David Haveman
>Priority: Minor
> Fix For: 1.0.9
>
>
> the page http://commons.apache.org/daemon/procrun.html refrences the switch 
> to add JVM options as "--JvmOptions", but the examples show it as "JvmOption":
> If a parameter is repeated, then normally the last value takes precedence. 
> However some parameters can take multiple values - for example StartParams 
> and JvmOption. If these parameters are prefixed with ++, then the value will 
> be appended to the existing value. For example:
> --Startup=manual --Startup=auto --JvmOption=-Done=1 ++JvmOption=-Dtwo=2



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

[jira] [Closed] (DAEMON-230) Procrun Documentation

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-230.
--
   Resolution: Fixed
Fix Version/s: 1.0.9

> Procrun Documentation
> -
>
> Key: DAEMON-230
> URL: https://issues.apache.org/jira/browse/DAEMON-230
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Reporter: David Haveman
>Priority: Minor
> Fix For: 1.0.9
>
>
> the page http://commons.apache.org/daemon/procrun.html refrences the switch 
> to add JVM options as "--JvmOptions", but the examples show it as "JvmOption":
> If a parameter is repeated, then normally the last value takes precedence. 
> However some parameters can take multiple values - for example StartParams 
> and JvmOption. If these parameters are prefixed with ++, then the value will 
> be appended to the existing value. For example:
> --Startup=manual --Startup=auto --JvmOption=-Done=1 ++JvmOption=-Dtwo=2



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

[jira] [Closed] (DAEMON-348) Clearing the "Thread Stack Size" field leaves service unstartable

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-348.
--
Resolution: Cannot Reproduce

> Clearing the "Thread Stack Size" field leaves service unstartable
> -
>
> Key: DAEMON-348
> URL: https://issues.apache.org/jira/browse/DAEMON-348
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Affects Versions: 1.0.15
> Environment: Windows7 x86
>Reporter: Rod Widdowson
>
> Just diagnosed an issue with a customer in which the java [process was 
> unrunnable).  This was because 
> {{HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 
> 2.0\shibd_idp\Parameters\Java\JvmSs}} was zero, (where {{shibd_idp}} is the 
> service.
> I managed to reproduce this behavior by
> * starting shibd_idpw (a.k.a prunmgr.exe)
> * modifying Thread Stack Size to be something
> * (verify with regedit)
> * clear the Thread Stack Size field
> * JvmSs is now zero



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

[jira] [Reopened] (DAEMON-348) Clearing the "Thread Stack Size" field leaves service unstartable

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-348:


> Clearing the "Thread Stack Size" field leaves service unstartable
> -
>
> Key: DAEMON-348
> URL: https://issues.apache.org/jira/browse/DAEMON-348
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Affects Versions: 1.0.15
> Environment: Windows7 x86
>Reporter: Rod Widdowson
>
> Just diagnosed an issue with a customer in which the java [process was 
> unrunnable).  This was because 
> {{HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 
> 2.0\shibd_idp\Parameters\Java\JvmSs}} was zero, (where {{shibd_idp}} is the 
> service.
> I managed to reproduce this behavior by
> * starting shibd_idpw (a.k.a prunmgr.exe)
> * modifying Thread Stack Size to be something
> * (verify with regedit)
> * clear the Thread Stack Size field
> * JvmSs is now zero



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

[jira] [Closed] (DAEMON-361) Windows service fails to stop with error code 1053 (using Windows service manager)

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-361.
--
Resolution: Not A Problem

> Windows service fails to stop with error code 1053 (using Windows service 
> manager)
> --
>
> Key: DAEMON-361
> URL: https://issues.apache.org/jira/browse/DAEMON-361
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: windows 7/8/10
>Reporter: Raghavaraju Kudari
> Attachments: errormessage_winservices.png
>
>
> We are using windows service to start and stop our application.
> It is starting but not stopping and giving "{color:red}Error 1053 : "The 
> service did not respond to start or control request in a timely 
> fashion{color}" 
> To create windows service entry we used WinRun4J API and using catalina.jar 
> startup classes
> (org.apache.catalina.startup.Bootstrap) to perform this operation.
> It was worked earlier when we used tomcat 7 and started facing the issue 
> after we upgraded to tomcat 8.5



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

[jira] [Reopened] (DAEMON-361) Windows service fails to stop with error code 1053 (using Windows service manager)

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-361:

  Assignee: (was: Bernd Eckenfels)

> Windows service fails to stop with error code 1053 (using Windows service 
> manager)
> --
>
> Key: DAEMON-361
> URL: https://issues.apache.org/jira/browse/DAEMON-361
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: windows 7/8/10
>Reporter: Raghavaraju Kudari
> Attachments: errormessage_winservices.png
>
>
> We are using windows service to start and stop our application.
> It is starting but not stopping and giving "{color:red}Error 1053 : "The 
> service did not respond to start or control request in a timely 
> fashion{color}" 
> To create windows service entry we used WinRun4J API and using catalina.jar 
> startup classes
> (org.apache.catalina.startup.Bootstrap) to perform this operation.
> It was worked earlier when we used tomcat 7 and started facing the issue 
> after we upgraded to tomcat 8.5



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

[jira] [Reopened] (DAEMON-367) Windows service fails to start after Windows 10 Creators Update

[Mark Thomas (JIRA)]

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

Mark Thomas reopened DAEMON-367:


> Windows service fails to start after Windows 10 Creators Update
> ---
>
> Key: DAEMON-367
> URL: https://issues.apache.org/jira/browse/DAEMON-367
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Affects Versions: 1.0.15
> Environment: Windows 10 Home and Pro after Creators Update. Windows 
> version 10.0.15063 Build 15063
>Reporter: Dave Bennett
>  Labels: prunsrv, windows10
>
> I have been running windows services via prunsrv for quite a long time 
> without any problem. Since updating my PC (Windows 10 Home) recently with the 
> Creators Update version of Windows 10 any new service that I install will not 
> start. Similar services that were installed prior to the update work ok as 
> before. When I try to start a new service, the system event log contains the 
> message "The BSS2SRVB2 service terminated with the following service-specific 
> error: Incorrect function". The service was initially configured with 
> PR_LOGLEVEL set to "Error" and no log files were created. When I set the 
> level to "Debug", the following log files were created,
> - stderrb2.txt contains,
> 2017-06-29 08:45:34 Commons Daemon procrun stderr initialized
> - stdoutb2.txt contains,
> 2017-06-29 08:45:34 Commons Daemon procrun stdout initialized
> - commons-daemon.2017-06-29.log contains,
> [2017-06-29 08:45:34] [debug] ( prunsrv.c:1679) [20104] Commons Daemon 
> procrun log initialized
> [2017-06-29 08:45:34] [info]  ( prunsrv.c:1683) [20104] Commons Daemon 
> procrun (1.0.15.0 32-bit) started
> [2017-06-29 08:45:34] [info]  ( prunsrv.c:1596) [20104] Running 'BSS2SRVB2' 
> Service...
> [2017-06-29 08:45:34] [debug] ( prunsrv.c:1374) [19220] Inside ServiceMain...
> [2017-06-29 08:45:34] [debug] ( prunsrv.c:844 ) [19220] reportServiceStatusE: 
> 2, 0, 3000, 0
> [2017-06-29 08:45:34] [info]  ( prunsrv.c:1127) [19220] Starting service...
> [2017-06-29 08:45:34] [error] ( prunsrv.c:1190) [19220] Missing service 
> ImageFile
> [2017-06-29 08:45:34] [error] ( prunsrv.c:1536) [19220] ServiceStart returned 
> 1
> [2017-06-29 08:45:34] [debug] ( prunsrv.c:844 ) [19220] reportServiceStatusE: 
> 1, 1066, 0, 1
> [2017-06-29 08:45:34] [info]  ( prunsrv.c:1598) [20104] Run service finished.
> [2017-06-29 08:45:34] [info]  ( prunsrv.c:1764) [20104] Commons Daemon 
> procrun finished
> The service processes have been written by myself in Java. 
> I have also seen the same problem on another PC (Windows 10 Pro) so this 
> suggests that it is not specific to my PC.



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

[jira] [Closed] (DAEMON-367) Windows service fails to start after Windows 10 Creators Update

[Mark Thomas (JIRA)]

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

Mark Thomas closed DAEMON-367.
--
Resolution: Not A Problem

> Windows service fails to start after Windows 10 Creators Update
> ---
>
> Key: DAEMON-367
> URL: https://issues.apache.org/jira/browse/DAEMON-367
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Affects Versions: 1.0.15
> Environment: Windows 10 Home and Pro after Creators Update. Windows 
> version 10.0.15063 Build 15063
>Reporter: Dave Bennett
>  Labels: prunsrv, windows10
>
> I have been running windows services via prunsrv for quite a long time 
> without any problem. Since updating my PC (Windows 10 Home) recently with the 
> Creators Update version of Windows 10 any new service that I install will not 
> start. Similar services that were installed prior to the update work ok as 
> before. When I try to start a new service, the system event log contains the 
> message "The BSS2SRVB2 service terminated with the following service-specific 
> error: Incorrect function". The service was initially configured with 
> PR_LOGLEVEL set to "Error" and no log files were created. When I set the 
> level to "Debug", the following log files were created,
> - stderrb2.txt contains,
> 2017-06-29 08:45:34 Commons Daemon procrun stderr initialized
> - stdoutb2.txt contains,
> 2017-06-29 08:45:34 Commons Daemon procrun stdout initialized
> - commons-daemon.2017-06-29.log contains,
> [2017-06-29 08:45:34] [debug] ( prunsrv.c:1679) [20104] Commons Daemon 
> procrun log initialized
> [2017-06-29 08:45:34] [info]  ( prunsrv.c:1683) [20104] Commons Daemon 
> procrun (1.0.15.0 32-bit) started
> [2017-06-29 08:45:34] [info]  ( prunsrv.c:1596) [20104] Running 'BSS2SRVB2' 
> Service...
> [2017-06-29 08:45:34] [debug] ( prunsrv.c:1374) [19220] Inside ServiceMain...
> [2017-06-29 08:45:34] [debug] ( prunsrv.c:844 ) [19220] reportServiceStatusE: 
> 2, 0, 3000, 0
> [2017-06-29 08:45:34] [info]  ( prunsrv.c:1127) [19220] Starting service...
> [2017-06-29 08:45:34] [error] ( prunsrv.c:1190) [19220] Missing service 
> ImageFile
> [2017-06-29 08:45:34] [error] ( prunsrv.c:1536) [19220] ServiceStart returned 
> 1
> [2017-06-29 08:45:34] [debug] ( prunsrv.c:844 ) [19220] reportServiceStatusE: 
> 1, 1066, 0, 1
> [2017-06-29 08:45:34] [info]  ( prunsrv.c:1598) [20104] Run service finished.
> [2017-06-29 08:45:34] [info]  ( prunsrv.c:1764) [20104] Commons Daemon 
> procrun finished
> The service processes have been written by myself in Java. 
> I have also seen the same problem on another PC (Windows 10 Pro) so this 
> suggests that it is not specific to my PC.



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

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

[Joakim Knudsen (JIRA)]

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

Joakim Knudsen commented on IMAGING-205:


Thanks for looking into this! I have checked the current snapshot of Commons 
Imaging, and the bug does not seem to be present there. As Damjan Jovanovic 
pointed out to me, this has been fixed somewhere along the way. However, I need 
a version which will run on Android, and, as far as I can tell (though I 
haven't tried), the current version of the library won't/can't run on Android.

> 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
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Attachments: 20171030_21481_COPY.jpg, 
> Gaboxjellyfish-changedexifmetadata.jpg, Gaboxjellyfish.jpg, after.html, 
> before.html
>
>
> 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] [Commented] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita commented on IMAGING-205:


Had a bit more of time. So removed the code in the example that changes the the 
metadata (aperture, GPS). The changed code simply retrieved the TIFF metadata, 
and then called a code as below:

{code:java}
new ExifRewriter().updateExifMetadataLossless(jpegImageFile, os,
outputSet);
{code}

And the output still presents the issue. So looks like we can focus on the 
ExifRewriter method call and onwards.

> 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
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Attachments: 20171030_21481_COPY.jpg, 
> Gaboxjellyfish-changedexifmetadata.jpg, Gaboxjellyfish.jpg, after.html, 
> before.html
>
>
> 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

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita updated IMAGING-205:
---
Assignee: Bruno P. Kinoshita

> 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
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Attachments: 20171030_21481_COPY.jpg, 
> Gaboxjellyfish-changedexifmetadata.jpg, Gaboxjellyfish.jpg, after.html, 
> before.html
>
>
> 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] [Commented] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita commented on IMAGING-205:


Here's the code to reproduce the issue:

{code:java}
public static void main(String[] args) throws Exception {
WriteExifMetadataExample example = new WriteExifMetadataExample();
// This is broken
example.changeExifMetadata(new 
File("/home/kinow/Downloads/Gaboxjellyfish.jpg"),
new 
File("/home/kinow/Downloads/Gaboxjellyfish-changedexifmetadata.jpg"));
}
}
{code}

The `WriteExifMetadataExample` class is in the test src folder.

Not sure if its implementation is correct. Could be that it simply needs 
updating to latest changes. Or may be a real bug.

> 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, 
> Gaboxjellyfish-changedexifmetadata.jpg, Gaboxjellyfish.jpg, after.html, 
> before.html
>
>
> 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

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita updated IMAGING-205:
---
Attachment: after.html
before.html
Gaboxjellyfish.jpg
Gaboxjellyfish-changedexifmetadata.jpg

Attaching original file from 
https://en.wikipedia.org/wiki/Talk%3ABox_jellyfish#/media/File:Gaboxjellyfish.jpg.

First HTML dump generated with `exiftool -validate -error -warning -a -G1 
-htmldump Gaboxjellyfish.jpg > before.html`. Second file generated with 
`exiftool -validate -error -warning -a -G1 -htmldump 
Gaboxjellyfish-changedexifmetadata.jpg > after.html`.

> 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, 
> Gaboxjellyfish-changedexifmetadata.jpg, Gaboxjellyfish.jpg, after.html, 
> before.html
>
>
> 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] [Commented] (IMAGING-205) Imaging (Apache Sanselan) produces "odd offsets" in (EXIF) metadata

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita commented on IMAGING-205:


Hi [~joakimk],

Thanks for the detailed report, and the link to the forum discussion. Comparing 
the output of the exiftool's htmldump, from a normal JPEG and another image 
created with WriteExifMetadataExample.changeExifMetadata (not quite the one you 
used, but from Commons Imaging tests), I can confirm there are odd offsets and 
also markers that were changed.

Going to add a sample before, and another after. Plus the code, and the output 
HTML files for posterity and for working on this issue.

> 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)