[jira] [Commented] (LANG-1360) Add methods to ObjectUtils to get various forms of class names in a null-safe manner
[ https://issues.apache.org/jira/browse/LANG-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213324#comment-16213324 ] Bruno P. Kinoshita commented on LANG-1360: -- Looks good to me. Unit tests included. +1 > Add methods to ObjectUtils to get various forms of class names in a null-safe > manner > > > Key: LANG-1360 > URL: https://issues.apache.org/jira/browse/LANG-1360 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 3.7 > > > Add methods to ObjectUtils to get various forms of class names in a null-safe > manner: > - getClassName(Object) > - getClassSimpleName(Object) > - getClassCanonicalName(Object) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-100) StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly
[ https://issues.apache.org/jira/browse/TEXT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213293#comment-16213293 ] ASF GitHub Bot commented on TEXT-100: - Github user kinow commented on the issue: https://github.com/apache/commons-text/pull/72 Merged, and ticket updated. Thanks for the pull request @drajakumar ! > StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly > --- > > Key: TEXT-100 > URL: https://issues.apache.org/jira/browse/TEXT-100 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Michael Hausegger >Assignee: Bruno P. Kinoshita > Fix For: 1.2 > > > As shown in > org.apache.commons.text.StringEscapeUtils#testUnescapeJsonFoundBug JSON > escape signs do not get treated correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-100) StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly
[ https://issues.apache.org/jira/browse/TEXT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213291#comment-16213291 ] Bruno P. Kinoshita commented on TEXT-100: - GitHub merged. The unescape JSON now does almost the same as Java, except for the escape signs. The previously ignored test is now passing. Looked at site reports, all good. Added changes.xml entry. Thanks for reporting the issue, and thanks to Don Jeba for the pull request. > StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly > --- > > Key: TEXT-100 > URL: https://issues.apache.org/jira/browse/TEXT-100 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Michael Hausegger > Fix For: 1.2 > > > As shown in > org.apache.commons.text.StringEscapeUtils#testUnescapeJsonFoundBug JSON > escape signs do not get treated correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TEXT-100) StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly
[ https://issues.apache.org/jira/browse/TEXT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated TEXT-100: Assignee: Bruno P. Kinoshita > StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly > --- > > Key: TEXT-100 > URL: https://issues.apache.org/jira/browse/TEXT-100 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Michael Hausegger >Assignee: Bruno P. Kinoshita > Fix For: 1.2 > > > As shown in > org.apache.commons.text.StringEscapeUtils#testUnescapeJsonFoundBug JSON > escape signs do not get treated correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TEXT-100) StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly
[ https://issues.apache.org/jira/browse/TEXT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved TEXT-100. - Resolution: Fixed > StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly > --- > > Key: TEXT-100 > URL: https://issues.apache.org/jira/browse/TEXT-100 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Michael Hausegger >Assignee: Bruno P. Kinoshita > Fix For: 1.2 > > > As shown in > org.apache.commons.text.StringEscapeUtils#testUnescapeJsonFoundBug JSON > escape signs do not get treated correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TEXT-100) StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly
[ https://issues.apache.org/jira/browse/TEXT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated TEXT-100: Fix Version/s: 1.2 > StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly > --- > > Key: TEXT-100 > URL: https://issues.apache.org/jira/browse/TEXT-100 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Michael Hausegger > Fix For: 1.2 > > > As shown in > org.apache.commons.text.StringEscapeUtils#testUnescapeJsonFoundBug JSON > escape signs do not get treated correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-100) StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly
[ https://issues.apache.org/jira/browse/TEXT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213289#comment-16213289 ] ASF GitHub Bot commented on TEXT-100: - Github user asfgit closed the pull request at: https://github.com/apache/commons-text/pull/72 > StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly > --- > > Key: TEXT-100 > URL: https://issues.apache.org/jira/browse/TEXT-100 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Michael Hausegger > > As shown in > org.apache.commons.text.StringEscapeUtils#testUnescapeJsonFoundBug JSON > escape signs do not get treated correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (DAEMON-375) Contradictory prunsrv --StartMethod documentation
[
https://issues.apache.org/jira/browse/DAEMON-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-375.
Resolution: Duplicate
Fix Version/s: 1.1
> Contradictory prunsrv --StartMethod documentation
> -
>
> Key: DAEMON-375
> URL: https://issues.apache.org/jira/browse/DAEMON-375
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Reporter: Aidan Pitt-Brooke
> Labels: consistency, documentation, prunsrv
> Fix For: 1.1
>
>
> The Procrun documentation at
> http://commons.apache.org/proper/commons-daemon/procrun.html contradicts
> itself in describing {{Prunsrv}}'s {{--StartMethod}} parameter. In the table
> of parameters, there is a note that the start method shouldn't return until
> the stop method is called, but the
> [section|http://commons.apache.org/proper/commons-daemon/procrun.html#Using_Procrun_in_jvm_mode]
> headed "Using Procrun in jvm mode" contains the following sentence:
> {quote}Note that the method handling service start should create and start a
> separate thread to carry out the processing, and then return.{quote}
> I don't see how it could be both at once, so which is correct?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (DAEMON-372) create shutdown event for shutdown process
[ https://issues.apache.org/jira/browse/DAEMON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-372. Resolution: Fixed Fix Version/s: 1.1 Thanks for the patch. > create shutdown event for shutdown process > -- > > Key: DAEMON-372 > URL: https://issues.apache.org/jira/browse/DAEMON-372 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Windows >Reporter: Sérgio Ozaki >Priority: Minor > Fix For: 1.1 > > > On Windows, when using Java or exe modes, if the service process ends before > the stop process, prunsrv starts clean up. > When the stop process finishes, the handles might be freed and all sorts of > illegal access errors may happen. > The solution is to make the service execution to wait on the shutdown event. > https://github.com/apache/commons-daemon/pull/4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (LANG-1360) Add methods to ObjectUtils to get various forms of class names in a null-safe manner
[ https://issues.apache.org/jira/browse/LANG-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved LANG-1360. Resolution: Fixed Fix Version/s: 3.7 In git master. Looking for a code review. > Add methods to ObjectUtils to get various forms of class names in a null-safe > manner > > > Key: LANG-1360 > URL: https://issues.apache.org/jira/browse/LANG-1360 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 3.7 > > > Add methods to ObjectUtils to get various forms of class names in a null-safe > manner: > - getClassName(Object) > - getClassSimpleName(Object) > - getClassCanonicalName(Object) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (LANG-1360) Add methods to ObjectUtils to get various forms of class names in a null-safe manner
[ https://issues.apache.org/jira/browse/LANG-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LANG-1360: --- Description: Add methods to ObjectUtils to get various forms of class names in a null-safe manner: - getClassName(Object) - getClassSimpleName(Object) - getClassCanonicalName(Object) was: Add methods to ObjectUtils to get various forms of class names in a null-safe manner: - getClassName(Object) - getClassSimpleName(Object) - getClassCannonicalName(Object) > Add methods to ObjectUtils to get various forms of class names in a null-safe > manner > > > Key: LANG-1360 > URL: https://issues.apache.org/jira/browse/LANG-1360 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Reporter: Gary Gregory >Assignee: Gary Gregory > > Add methods to ObjectUtils to get various forms of class names in a null-safe > manner: > - getClassName(Object) > - getClassSimpleName(Object) > - getClassCanonicalName(Object) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (DAEMON-354) DMESG reports: warning: `jsvc' uses 32-bit capabilities (legacy support in use)
[
https://issues.apache.org/jira/browse/DAEMON-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-354.
Resolution: Not A Problem
This is something you'll need to take up with the provider of your linux
distribution.
> DMESG reports: warning: `jsvc' uses 32-bit capabilities (legacy support in
> use)
> ---
>
> Key: DAEMON-354
> URL: https://issues.apache.org/jira/browse/DAEMON-354
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.0.15
> Environment: {code}
> Server version: Apache Tomcat/8.0.36
> Server built: Jun 9 2016 13:55:50 UTC
> Server number: 8.0.36.0
> OS Name:Linux
> OS Version: 3.10.0-327.28.3.el7.x86_64
> Architecture: amd64
> JVM Version:1.8.0_102-b14
> JVM Vendor: Oracle Corporation
> {code}
>Reporter: bidorbuy
>Priority: Minor
>
> Dmesg on CentOS7 displays the following warning:
> {code}
> [ 22.742524] warning: `jsvc' uses 32-bit capabilities (legacy support in
> use)
> {code}
> To reproduce we run the following on CentOS 7:
> 1) Install Tomcat 8.0.36
> {code}
> wget -O /tmp/tomcat8.tgz
> http://apache.saix.net/tomcat/tomcat-8/v8.0.36/bin/apache-tomcat-8.0.36.tar.gz
>
> cd /tmp
> tar -zxvf /tmp/tomcat8.tgz
> mkdir /usr/share/tomcat8
> mv /tmp/apache-tomcat-8.0.36/* /usr/share/tomcat8
> {code}
> 2) Compile native library
> {code}
> yum install apr-devel gcc make zlib-devel
>
> tar -xvzf /usr/share/tomcat8/bin/tomcat-native.tar.gz -C /tmp
> cd /tmp/tomcat-native-1.2.7-src/native/
> ./configure --with-apr=/usr/bin/apr-1-config
> --with-java-home=/usr/java/default/ --with-ssl=no --prefix=/usr/share/tomcat8
> make
> make install
> {code}
> 3) Compile jsvc
> {code}
> ## Extract and compile from source:
> tar -xvf /usr/share/tomcat8/bin/commons-daemon-native.tar.gz -C /tmp/
> cd /tmp/commons-daemon-*-native-src/unix
> ./configure --with-java=/usr/java/latest
> make
>
> ## Adjust permissions/ownership and move the executable into place
> chmod a+x jsvc
> mv jsvc /usr/share/tomcat8/bin/
>
>
> ## Test that the compiled version works
> /usr/share/tomcat8/bin/jsvc --help
> {code}
> Tomcat 8.0.36 ships with DAEMON 1.0.15. I am not sure if the above compile
> settings are wrong or we are missing something?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (LANG-1360) Add methods to ObjectUtils to get various forms of class names in a null-safe manner
Gary Gregory created LANG-1360: -- Summary: Add methods to ObjectUtils to get various forms of class names in a null-safe manner Key: LANG-1360 URL: https://issues.apache.org/jira/browse/LANG-1360 Project: Commons Lang Issue Type: Bug Components: lang.* Reporter: Gary Gregory Assignee: Gary Gregory Add methods to ObjectUtils to get various forms of class names in a null-safe manner: - getClassName(Object) - getClassSimpleName(Object) - getClassCannonicalName(Object) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (DAEMON-309) Documentation for start method in JVM mode is conflicting
[
https://issues.apache.org/jira/browse/DAEMON-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-309.
Resolution: Fixed
Fix Version/s: 1.1
Thanks for the report.
> Documentation for start method in JVM mode is conflicting
> -
>
> Key: DAEMON-309
> URL: https://issues.apache.org/jira/browse/DAEMON-309
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Reporter: Joachim Sauer
>Priority: Minor
> Labels: doc, documentaion
> Fix For: 1.1
>
>
> The documentation for how the start method should act in JVM mode is
> conflicting (http://commons.apache.org/proper/commons-daemon/procrun.html).
> 1. In the documentation of the StartMethod parameter there's this text:
> {quote}
> Note: in jvm mode, the start method should not return until the stop method
> has been called.
> {quote}
> 2. The second-to-last sentence in the section "Using Procrun in jvm mode"
> reads:
> {quote}
> Note that the method handling service start should create and start a
> separate thread to carry out the processing, and then return.
> {quote}
> According to my reading those two sentences say pretty much the opposite of
> each other and observation shows that #1 is the correct one (i.e. the service
> is assumed to have stopped when the start method returns).
> Generally speaking, JVM mode is pretty under-documented (in my opinion). That
> can easily be verified by the fact that very popular documentation exists
> outside the procrun/commons daemon project, as a blog post:
> http://joerglenhard.wordpress.com/2012/05/29/build-windows-service-from-java-application-with-procrun/
> A simple end-to-end example showing a similar setup as that blog post would
> be good.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (WEAVER-18) Update Apache Commons IO from 2.5 to 2.6
[ https://issues.apache.org/jira/browse/WEAVER-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed WEAVER-18. -- Resolution: Fixed In SVN trunk. > Update Apache Commons IO from 2.5 to 2.6 > > > Key: WEAVER-18 > URL: https://issues.apache.org/jira/browse/WEAVER-18 > Project: Commons Weaver > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Gary Gregory > Fix For: 1.4 > > > Update Apache Commons IO from 2.5 to 2.6. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (WEAVER-18) Update Apache Commons IO from 2.5 to 2.6
Gary Gregory created WEAVER-18: -- Summary: Update Apache Commons IO from 2.5 to 2.6 Key: WEAVER-18 URL: https://issues.apache.org/jira/browse/WEAVER-18 Project: Commons Weaver Issue Type: Improvement Affects Versions: 1.3 Reporter: Gary Gregory Fix For: 1.4 Update Apache Commons IO from 2.5 to 2.6. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COLLECTIONS-662) Build failures when building with Java 9
[
https://issues.apache.org/jira/browse/COLLECTIONS-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16212851#comment-16212851
]
Pascal Schumacher commented on COLLECTIONS-662:
---
Yes. Thanks for resolving the issue and adding the changes.xml entry. I forgot
to do that. :( Sorry.
> Build failures when building with Java 9
>
>
> Key: COLLECTIONS-662
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-662
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Vamsi
>Assignee: Pascal Schumacher
>
> *mvn clean test* fails with following errors when using with java-9
> {code:java}
> Tests in error:
> MapUtilsTest.testgetByteValue:1051 » ServiceConfiguration
> sun.util.locale.prov...
> MapUtilsTest.testgetDoubleValue:956 » ServiceConfiguration
> sun.util.locale.pro...
> MapUtilsTest.testgetFloatValue:974 » ServiceConfiguration
> sun.util.locale.prov...
> MapUtilsTest.testgetIntValue:1012 » ServiceConfiguration
> sun.util.locale.provi...
> MapUtilsTest.testgetLongValue:992 » ServiceConfiguration
> sun.util.locale.provi...
> MapUtilsTest.testgetShortValue:1031 » ServiceConfiguration
> sun.util.locale.pro...
> ListIteratorWrapperTest.testRemove:116 » ServiceConfiguration
> sun.util.locale
> Tests run: 16088, Failures: 0, Errors: 7, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-103) Add provision to change the cost for insert, delete and replace operation in levenshtein distance
[ https://issues.apache.org/jira/browse/TEXT-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16212824#comment-16212824 ] Pascal Schumacher commented on TEXT-103: [~arohit] Consider this issue assigned to you anyway. Looking forward to the pull request/patch. Thanks in advance! (Sadly it is not possible to assign issues to people who are not part of the commons developer group in jira, so it has to stay unassigned in jira.) > Add provision to change the cost for insert, delete and replace operation in > levenshtein distance > - > > Key: TEXT-103 > URL: https://issues.apache.org/jira/browse/TEXT-103 > Project: Commons Text > Issue Type: Improvement >Reporter: Rohit Agarwal >Priority: Minor > Labels: newbie, patch > Original Estimate: 48h > Remaining Estimate: 48h > > There are two implementation of levenshtein distance, unlimitedCompare and > limitedCompare. > I propose to generalise the levenshtein distance by adding an option to > change the value of > 1) Addition of Character. > 2) Deletion of Character. > 3) Substitution of Character. > Currently they are all set to 1. For backward compatibility this will be the > default case. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TEXT-105) Typo in LongestCommonSubsequence#logestCommonSubsequence
[
https://issues.apache.org/jira/browse/TEXT-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher resolved TEXT-105.
Resolution: Fixed
Fix Version/s: 1.2
> Typo in LongestCommonSubsequence#logestCommonSubsequence
>
>
> Key: TEXT-105
> URL: https://issues.apache.org/jira/browse/TEXT-105
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 1.2
>
>
> Reported by Abrasha in https://github.com/apache/commons-text/pull/69
> {quote}Also I found a typo in public signature in
> org.apache.commons.text.similarity.LongestCommonSubsequence#logestCommonSubsequence{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-105) Typo in LongestCommonSubsequence#logestCommonSubsequence
[
https://issues.apache.org/jira/browse/TEXT-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16212798#comment-16212798
]
ASF GitHub Bot commented on TEXT-105:
-
Github user PascalSchumacher commented on the issue:
https://github.com/apache/commons-text/pull/69
created https://issues.apache.org/jira/browse/TEXT-105 for the typo in
`LongestCommonSubsequence#logestCommonSubsequence`.
> Typo in LongestCommonSubsequence#logestCommonSubsequence
>
>
> Key: TEXT-105
> URL: https://issues.apache.org/jira/browse/TEXT-105
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
>Priority: Minor
>
> Reported by Abrasha in https://github.com/apache/commons-text/pull/69
> {quote}Also I found a typo in public signature in
> org.apache.commons.text.similarity.LongestCommonSubsequence#logestCommonSubsequence{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TEXT-105) Typo in LongestCommonSubsequence#logestCommonSubsequence
Pascal Schumacher created TEXT-105:
--
Summary: Typo in LongestCommonSubsequence#logestCommonSubsequence
Key: TEXT-105
URL: https://issues.apache.org/jira/browse/TEXT-105
Project: Commons Text
Issue Type: Bug
Affects Versions: 1.1
Reporter: Pascal Schumacher
Assignee: Pascal Schumacher
Priority: Minor
Reported by Abrasha in https://github.com/apache/commons-text/pull/69
{quote}Also I found a typo in public signature in
org.apache.commons.text.similarity.LongestCommonSubsequence#logestCommonSubsequence{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (DAEMON-318) children (controller) process doesnt use correct umask value
[
https://issues.apache.org/jira/browse/DAEMON-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-318.
Resolution: Fixed
Fix Version/s: 1.1
Thanks for the steps to reproduce and the patch.
> children (controller) process doesnt use correct umask value
>
>
> Key: DAEMON-318
> URL: https://issues.apache.org/jira/browse/DAEMON-318
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.0.15
> Environment: Centos 6.5:
> Linux staging 2.6.32-431.17.1.el6.x86_64 #1 SMP Wed May 7 23:32:49 UTC 2014
> x86_64 x86_64 x86_64 GNU/Linux
> Java 7:
> java version "1.7.0_55"
> OpenJDK Runtime Environment (rhel-2.4.7.1.el6_5-x86_64 u55-b13)
> OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
> selinux enabled
> tomcat 7.0.54
> jsvc compiled from tar.gz in /bin
> build tools from distribution
> starting tomcat via daemon.sh start
> setenv.sh:
> {noformat}
> #!/bin/sh
> JSVC_OPTS="-umask 002"
> CATALINA_OPTS="$CATALINA_OPTS -server -Xms512m -Xmx1024m -XX:MaxPermSize=512m
> -Djava.awt.headless=true"
> export CATALINA_OPTS
> export JSVC_OPTS
> {noformat}
>Reporter: Tiago Oliveira
>Priority: Minor
> Fix For: 1.1
>
> Attachments: UmaskBugReproducer.java, umask.patch
>
>
> Expected behavior:
> after issuing -umask 002 to JSVC (with -tomcat-user != root, e.g. "tomcat"),
> child process (controller) have umask = 2
> Actual behavior:
> root process have umask = 2
> child process have umask = 18
> After runing daemon start:
> {noformat}
> NOTICE: jsvc umask of 002 allows write permission to group and/or other
> {noformat}
> Running instances:
> {noformat}
> # ps aux | grep jsvc
> root 11410 0.0 0.0 10436 480 ?Ss 09:30 0:00 jsvc.exec
> -umask 002 -java-home /usr/lib/jvm/java-1.7.0 -user tomcat -pidfile
> /opt/apache/tomcat7/logs/catalina-daemon.pid -wait 10 -outfile
> /opt/apache/tomcat7/logs/catalina-daemon.out -errfile &1 -classpath
> /opt/apache/tomcat7/bin/bootstrap.jar:/opt/apache/tomcat7/bin/commons-daemon.jar:/opt/apache/tomcat7/bin/tomcat-juli.jar
> -Djava.util.logging.config.file=/opt/apache/tomcat7/conf/logging.properties
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -server
> -Xms512m -Xmx1024m -XX:MaxPermSize=512m -Djava.awt.headless=true
> -Djava.endorsed.dirs= -Dcatalina.base=/opt/apache/tomcat7
> -Dcatalina.home=/opt/apache/tomcat7 -Djava.io.tmpdir=/opt/apache/tomcat7/temp
> org.apache.catalina.startup.Bootstrap
> tomcat 11411 89.9 26.7 3919288 1048692 ? Sl 09:30 1:24 jsvc.exec
> -umask 002 -java-home /usr/lib/jvm/java-1.7.0 -user tomcat -pidfile
> /opt/apache/tomcat7/logs/catalina-daemon.pid -wait 10 -outfile
> /opt/apache/tomcat7/logs/catalina-daemon.out -errfile &1 -classpath
> /opt/apache/tomcat7/bin/bootstrap.jar:/opt/apache/tomcat7/bin/commons-daemon.jar:/opt/apache/tomcat7/bin/tomcat-juli.jar
> -Djava.util.logging.config.file=/opt/apache/tomcat7/conf/logging.properties
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -server
> -Xms512m -Xmx1024m -XX:MaxPermSize=512m -Djava.awt.headless=true
> -Djava.endorsed.dirs= -Dcatalina.base=/opt/apache/tomcat7
> -Dcatalina.home=/opt/apache/tomcat7 -Djava.io.tmpdir=/opt/apache/tomcat7/temp
> org.apache.catalina.startup.Bootstrap
> {noformat}
> GDB output:
> {noformat}
> # gdb --pid=11410
> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
>
[jira] [Resolved] (COLLECTIONS-662) Build failures when building with Java 9
[
https://issues.apache.org/jira/browse/COLLECTIONS-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins resolved COLLECTIONS-662.
--
Resolution: Fixed
Assignee: Pascal Schumacher
Pascal merged this, I think.
> Build failures when building with Java 9
>
>
> Key: COLLECTIONS-662
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-662
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Vamsi
>Assignee: Pascal Schumacher
>
> *mvn clean test* fails with following errors when using with java-9
> {code:java}
> Tests in error:
> MapUtilsTest.testgetByteValue:1051 » ServiceConfiguration
> sun.util.locale.prov...
> MapUtilsTest.testgetDoubleValue:956 » ServiceConfiguration
> sun.util.locale.pro...
> MapUtilsTest.testgetFloatValue:974 » ServiceConfiguration
> sun.util.locale.prov...
> MapUtilsTest.testgetIntValue:1012 » ServiceConfiguration
> sun.util.locale.provi...
> MapUtilsTest.testgetLongValue:992 » ServiceConfiguration
> sun.util.locale.provi...
> MapUtilsTest.testgetShortValue:1031 » ServiceConfiguration
> sun.util.locale.pro...
> ListIteratorWrapperTest.testRemove:116 » ServiceConfiguration
> sun.util.locale
> Tests run: 16088, Failures: 0, Errors: 7, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (DAEMON-339) Patch for commons-daemon 1.0.15 to avoid shutdown failures
[ https://issues.apache.org/jira/browse/DAEMON-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-339. Resolution: Fixed Fix Version/s: 1.1 Many thanks for the patch and the steps to recreate the issue. > Patch for commons-daemon 1.0.15 to avoid shutdown failures > -- > > Key: DAEMON-339 > URL: https://issues.apache.org/jira/browse/DAEMON-339 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.0.15 > Environment: Multiple UNIX platforms ... E.g.: > Red Hat ES 6 > Solaris 10 x64 >Reporter: John Wehle >Priority: Minor > Fix For: 1.1 > > Attachments: jsvc-shutdown.txt > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > We've seen situations on UNIX where JSVC will fail to shutdown when > requested ... in at least one case this caused the machine to hang > during shutdown. > On UNIX JSVC automatically restarts the JVM if it crashes. Currently > this means that if the JVM crashes after receiving a shutdown request > (i.e. a SIGINT), then it's restarted by the controller which is not > what's desired. > The enclosed patch propagates the termination request from the JVM to > the controller so that the controller knows not to schedule a restart > thus allowing JSVC to actually terminate. > Granted this doesn't fix the underlying problem of the JVM crashing > during shutdown, however that's a separate (potentially application > specific) issue. > Tested by using a dummy JAVA service containing an endless loop in > the shutdown code. Test sequence was: > jsvc ... -verbose -debug hello.MyDaemon > kill -INT `cat pidfile` > # notice that output showed shutdown running > kill -BUS `cat pidfile` > # notice that prior to patch output showed restart being scheduled > -- John Wehle -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (DAEMON-327) New -cwd default needlessly breaks backwards compatibility
[ https://issues.apache.org/jira/browse/DAEMON-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-327. Resolution: Won't Fix See DAEMON-264 for the reasoning as to why this was implemented the way it was. I don't see a way to keep everyone happy on this. On balance, I agree with the reasoning in DAEMON-264 so I am resolving this as WONTFIX. Note that the next release is expected to be 1.1 > New -cwd default needlessly breaks backwards compatibility > -- > > Key: DAEMON-327 > URL: https://issues.apache.org/jira/browse/DAEMON-327 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.0.15 > Environment: debian/amd64 >Reporter: Frank Gevaerts >Priority: Minor > > Before 1.0.15, jsvc did not change working directory in any way, so the way > to set the cwd for an application was just to cd to the proper directory > before calling jsvc. > Starting with 1.0.15, the -cwd option was added, which is indeed a useful > addition. > However, 1.0.15 now *always* changes directory, with / as the default. This > means that -cwd now basically has to be used if a specific cwd is needed. Of > course, -cwd is an invalid option with > +versions before 1.0.15, so now it's impossible to make an init script that > works with both older and newer jsvc setups. > It's not clear to me why leaving the cwd as is if -cwd isn't used wasn't kept. > As an extra annoyance, -version doesn't work without also setting seemingly > unrelated options, so adding code to set -cwd based on jsvc version is harder > than it should be. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (DAEMON-324) [home.c:130]: (error) Resource leak: cfgf
[
https://issues.apache.org/jira/browse/DAEMON-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-324.
Resolution: Fixed
Fix Version/s: 1.1
Fixed. Thanks for the report.
> [home.c:130]: (error) Resource leak: cfgf
> -
>
> Key: DAEMON-324
> URL: https://issues.apache.org/jira/browse/DAEMON-324
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.0.15
>Reporter: David Binderman
>Priority: Minor
> Fix For: 1.1
>
>
> $ fgrep cfgf ../BUILD/commons-daemon-1.0.15-src/src/native/unix/native/home.c
> FILE *cfgf = fopen(data->cfgf, "r");
> if (cfgf == NULL) {
> log_debug("Can't open %s\n", data->cfgf);
> while ((ret = fgets(buf, 1024, cfgf)) != NULL) {
> char *cfgf = NULL;
> Suggest add call to fclose.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (DAEMON-373) Daemon does not start with JDK9
[ https://issues.apache.org/jira/browse/DAEMON-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-373. Resolution: Fixed Fix Version/s: 1.1 Fixed for OSX and Linux. Additional fixes may be required for other platforms. To fix them we'll need to know: - the platform - path(s) to libjvm.so under JAVA_HOME > Daemon does not start with JDK9 > --- > > Key: DAEMON-373 > URL: https://issues.apache.org/jira/browse/DAEMON-373 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.0.15 >Reporter: Evgenij Ryazanov > Fix For: 1.1 > > > Jsvc cannot find Java VM if JDK9 is installed and logs the following message: > Cannot find any VM in Java Home /path/to/jdk9 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (DAEMON-325) missing location in location.c location_jvm_configure for Darwin
[
https://issues.apache.org/jira/browse/DAEMON-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-325.
Resolution: Duplicate
Fix Version/s: 1.1
This was fixed in 1.0.x and forward ported to 1.1.x several months ago.
I'm currently working on getting a 1.1 release out that supports Java 9 -
hopefully in the next couple of weeks.
> missing location in location.c location_jvm_configure for Darwin
>
>
> Key: DAEMON-325
> URL: https://issues.apache.org/jira/browse/DAEMON-325
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.0.15
> Environment: Mac OS X and JDK 7
>Reporter: philippe le berre
>Priority: Blocker
> Fix For: 1.1
>
> Attachments: java.c.diff, location.c.diff
>
>
> On OS_DARWIN the native/location.c is missing a location and java.c is
> missing a check/location for libverify.dylib
> --- location.c.old2014-11-01 18:53:45.0 +0100
> +++ location.c2014-11-01 18:54:15.0 +0100
> @@ -144,6 +144,7 @@ char *location_jvm_default[] = {
> char *location_jvm_configured[] = {
> #if defined(OS_DARWIN)
> "$JAVA_HOME/../Libraries/lib$VM_NAME.dylib",
> +"$JAVA_HOME/jre/lib/$VM_NAME/libjvm.dylib",
> #elif defined(OS_CYGWIN)
> "$JAVA_HOME/jre/bin/$VM_NAME/jvm.dll", /* Sun JDK 1.3 */
> #elif defined(OS_LINUX) || defined(OS_SOLARIS) || defined(OS_BSD) ||
> defined(OS_FREEBSD) || defined(OS_TRU64)
> --- /Users/rplb/java.c.orig 2014-11-02 12:00:16.0 +0100
> +++ /Users/rplb/java.c2014-11-02 12:16:25.0 +0100
> @@ -135,8 +135,15 @@
> {
> #ifdef OS_DARWIN
> dso_handle apph = NULL;
> -char appf[1024];
> +char repl[1024];
> struct stat sb;
> +char *jvm_libs[] = {
> +"$JAVA_HOME/../Libraries/libjvm_compat.dylib",
> +"$JAVA_HOME/../Libraries/libappshell.dylib",
> +"$JAVA_HOME/jre/lib/libverify.dylib",
> +NULL,
> +};
> +
> #endif /* ifdef OS_DARWIN */
> jvm_create_t symb = NULL;
> JNINativeMethod nativemethods[2];
> @@ -184,30 +191,33 @@
> JVM 1.4.1 through 1.5.* The library name is libjvm_compat.dylib
> starting with JVM 1.6 on OS X 10.6 the library name is
> libverify.dylib.
> */
> -if (replace(appf, 1024, "$JAVA_HOME/../Libraries/libappshell.dylib",
> -"$JAVA_HOME", data->path) != 0) {
> -log_error("Cannot replace values in loader library");
> -return false;
> -}
> -if (stat(appf, )) {
> -if (replace(appf, 1024,
> "$JAVA_HOME/../Libraries/libjvm_compat.dylib",
> -"$JAVA_HOME", data->path) != 0) {
> +x = 0;
> +char *appf = NULL;
> +while (jvm_libs[x] != NULL) {
> +char *orig = jvm_libs[x];
> +int k = 0;
> +
> +k = replace(repl, 1024, orig, "$JAVA_HOME", data->path);
> +if (k != 0) {
> log_error("Cannot replace values in loader library");
> return false;
> }
> -}
> -if (stat(appf, )) {
> -if (replace(appf, 1024, "$JAVA_HOME/../Libraries/libverify.dylib",
> -"$JAVA_HOME", data->path) != 0) {
> -log_error("Cannot replace values in loader library");
> -return false;
> +
> +if (stat(repl, )) {
> +log_debug("Cannot load the shell library %s", repl);
> +x++;
> +} else {
> +appf = repl;
> +break;
> }
> }
> -apph = dso_link(appf);
> -if (apph == NULL) {
> -log_error("Cannot load required shell library %s", appf);
> +
> +if (appf == NULL) {
> +log_error("Cannot load none of the required shell library");
> return false;
> }
> +
> +apph = dso_link(appf);
> log_debug("Shell library %s loaded", appf);
> #endif /* ifdef OS_DARWIN */
> #if defined(OSD_POSIX)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
