[jira] [Commented] (VFS-637) Zip files with legacy encoding and special characters let VFS crash
[
https://issues.apache.org/jira/browse/VFS-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16058831#comment-16058831
]
Guido Schnepp commented on VFS-637:
---
Not much, because both encodings differ from IBM437 in bigger parts:
java.nio.charset.StandardCharsets.US-ASCII is a 7 bit charset only, so all
characters 0x80 and above are missing. That's the most interesting part of
codepage 437 for non-US people, where you also find the german umlauts for
example.
ASCII (any) and ANSI (most) are 8 bit charsets which base on US-ASCII but have
codepoints 0x80-0xFF defined - differently! On a sample with german umlaut Ä
(Latin capital letter A with diaeresis) and ä (Latin small letter a with
diaeresis):
IBM437:Ä on 0x8E, ä on 0x84 (
https://de.wikipedia.org/wiki/Codepage_437 )
ISO-8859-1: Ä on 0xC4, ä on 0xE4 ( https://de.wikipedia.org/wiki/ISO_8859-1 )
UNICODE:Ä on U+00C4, ä on U+00E4 ( https://de.wikipedia.org/wiki/Umlaut )
US-ASCII: Ä non existent, ä non existent
PKWare is only a vendor of ZIP aware products, but with pkzip one of the first,
far before zip support has been added to operating systems or Java runtime
natively. I by myself trust their expertise here. BUT: I've also read on other
pages, that on development of the ZIP format, encoding was +not defined+ (or
not in mind) in any way. The language encoding bit has been added later. So
some functionality is required long-term to set the desired encoding as user
like, because you can also find ZIP files with native russian characters inside
potentially - which are even not supported by IBM437.
Another interesting source is the new Oracle Java Zip package javadoc:
https://docs.oracle.com/javase/7/docs/api/java/util/zip/package-summary.html .
The, in turn, refer to PKWare Appendix D already mentioned on Ticket above.
> Zip files with legacy encoding and special characters let VFS crash
> ---
>
> Key: VFS-637
> URL: https://issues.apache.org/jira/browse/VFS-637
> Project: Commons VFS
> Issue Type: Bug
> Environment: Windows 10 64 Bit, Java 8
>Reporter: Guido Schnepp
> Labels: easyfix
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Oracle has reworked the ZipFile object with Java 7. Since then the default
> constructor used by commons-vfs2 2.1 is more restrictive than with Java 6.
> The ZipFile constructor has got a second parameter (Charset) now for
> specification of the legacy charset to be used explicitly if the ZipFile
> doesn't state its UTF-8 compliance internally. This affects all ZIP files
> using a legacy charset for filename encoding but not using UTF-8 is it is
> common today. This could be a ZIP file with files containing german umlauts
> or russian characters in archived file's filenames, for example.
> To support this new parameter with (more or less) default values, the class
> org.apache.commons.vfs2.provider.zip.ZipFileSystem has to be extended by a
> default charset parameter, getter or setter (as you like) to forward this
> setting to the java.util.zip.ZipFile constructor.
> Quick workaround for me was to create a new OwnZipFileProvider referring to
> the even new OwnZipFileSystem (extending ZipFileSystem) with the following
> modified function. Change has been highlighted:
> {{protected ZipFile createZipFile(final File file) throws
> FileSystemException {
> try {
> return new ZipFile(file{color:red}*,
> Charset.forName("IBM437")*{color});
> } catch (final IOException ioe) {
> throw new
> FileSystemException("vfs.provider.zip/open-zip-file.error", file, ioe);
> }
> }
> }}
> Presetting to charset 437 as legacy default charset seems to be a a good
> workaround as stated in appendix D here:
> https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT :
> "D.1 The ZIP format has historically supported only the original IBM PC
> character encoding set, commonly referred to as IBM Code Page 437. This
> limits storing file name characters to only those within the original MS-DOS
> range of values and does not properly support file names in other character
> encodings, or languages. [...]"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (MATH-1421) WilsonConfidenceInterval returning negative values
[ https://issues.apache.org/jira/browse/MATH-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-1421. -- Resolution: Fixed Fix Version/s: 4.0 Thanks for the report. As of commit 612a04d6b0ff8fa3060d5e943f4f72968ea71700 the reported failure does not happen anymore. Please have a look, and reopen this issue if you have other case that still produce a negative value. > WilsonConfidenceInterval returning negative values > -- > > Key: MATH-1421 > URL: https://issues.apache.org/jira/browse/MATH-1421 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Mathijs Vogelzang > Fix For: 4.0 > > > Wilson confidence intervals sometimes return negative values as the lower > bound, e.g. > IntervalUtils.getWilsonScoreInterval(19436, 0, 0.95).getLowerBound() returns > -1.3549849074815073E-20 > This is causing assertion fails in our code, which we have fixed it now by > wrapping the confidence score bounds in Math.max(0, Math.min(1, bound)) until > the method doesn't return wrong results anymore. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-93) RandomStringGenerator accepts a list of valid characters
[
https://issues.apache.org/jira/browse/TEXT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16058503#comment-16058503
]
Gilles commented on TEXT-93:
We could have
* {{selectFromList(char[])}}
* {{selectFromList(List)}}
> RandomStringGenerator accepts a list of valid characters
>
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
> Issue Type: Wish
>Reporter: Wilson MacGyver
>
> implement a "selectFrom" feature:
> RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-79) Investigate adding string search algorithms
[ https://issues.apache.org/jira/browse/TEXT-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16058489#comment-16058489 ] Bruno P. Kinoshita commented on TEXT-79: I also believe it could be useful. Doing a search in other ASF projects first, and then other projects like lingpipe, google libraries, aws libraries, etc, can identify possible use cases as well. That way it would be easier to add the code to [text] [~ameyjadiye] :-) Thanks! B > Investigate adding string search algorithms > --- > > Key: TEXT-79 > URL: https://issues.apache.org/jira/browse/TEXT-79 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: algorithm, help-wanted, text > Fix For: 1.x > > > There are a few [string searching > algorithms|https://en.wikipedia.org/wiki/String_searching_algorithm] (e.g. > Rabin Karp) that do not have an implementation in commons yet. > Would be interesting to check if any other ASF projects use any of these or > others (e.g. Lucene, Solr, Tika, etc) and see if they could be implemented in > [text]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JEXL-227) JexlScriptEngineFactory.getEngineVersion() should return actual version, ie 3.1 as of reporting
[
https://issues.apache.org/jira/browse/JEXL-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16058477#comment-16058477
]
Bruno P. Kinoshita commented on JEXL-227:
-
Yup. Besides fixing the version in either or both methods, I'd like to add some
lines in the Javadocs, and then maybe a note somewhere in the project
documentation (wiki?) for when someone releases a new version s/he can remember
to check if this version needs to be updated too.
> JexlScriptEngineFactory.getEngineVersion() should return actual version, ie
> 3.1 as of reporting
> ---
>
> Key: JEXL-227
> URL: https://issues.apache.org/jira/browse/JEXL-227
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> JexlScriptEngineFactory.getEngineVersion() reports "3.0" as a script engine
> version in 3.1
> {code}
> public String getEngineVersion() {
> return "3.0"; // ensure this is updated if function changes are made
> to this class
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-227) JexlScriptEngineFactory.getEngineVersion() should return actual version, ie 3.1 as of reporting
[
https://issues.apache.org/jira/browse/JEXL-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16058471#comment-16058471
]
Sebb commented on JEXL-227:
---
Surely if the language syntax changes (as mentioned above), then the language
version needs updating?
It's not as clear to me what the engine version is supposed to represent.
Maybe worth checking the JSR
> JexlScriptEngineFactory.getEngineVersion() should return actual version, ie
> 3.1 as of reporting
> ---
>
> Key: JEXL-227
> URL: https://issues.apache.org/jira/browse/JEXL-227
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> JexlScriptEngineFactory.getEngineVersion() reports "3.0" as a script engine
> version in 3.1
> {code}
> public String getEngineVersion() {
> return "3.0"; // ensure this is updated if function changes are made
> to this class
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-77) Add code to check if a given string is a palindrome
[ https://issues.apache.org/jira/browse/TEXT-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16058379#comment-16058379 ] Bruno P. Kinoshita commented on TEXT-77: +1 for closing for now. We can revisit it later if we have better use cases :-) At Apache, I believe the only place with anything related right now would be [OODT streaming module|https://github.com/apache/oodt/blob/1ae92425ec3e7e0d0f026cbcc142ab17988cd071/streaming/resource/src/main/java/org/apache/oodt/cas/resource/examples/PalindromeUtils.java], and it is used just as part of an example. > Add code to check if a given string is a palindrome > --- > > Key: TEXT-77 > URL: https://issues.apache.org/jira/browse/TEXT-77 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: easy, help-wanted, text > Fix For: 1.x > > > I had a look at > [lang|https://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html] > and > [text|https://commons.apache.org/proper/commons-text/javadocs/api-release/index.html] > API's, but could not locate a class/method for > [palindromes|https://en.wikipedia.org/wiki/Palindrome]. > Ideally, it would support words or sentences such as "racecar" and "step on > no pets". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TEXT-77) Add code to check if a given string is a palindrome
[ https://issues.apache.org/jira/browse/TEXT-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Honton closed TEXT-77. -- Resolution: Won't Do This is a great academic / interview question with little practical use. What is the scope of requirements? What is the expected big O performance? Which of the following palindromes will it detect? Madam, I'm Adam Able was I ere I saw Elba A man, a plan, a canal - Panama! かるいきびんなこねこなんびきいるか 上海自来水来自海上 Dábale arroz a la zorra el abad. Adán no cede con nada. > Add code to check if a given string is a palindrome > --- > > Key: TEXT-77 > URL: https://issues.apache.org/jira/browse/TEXT-77 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: easy, help-wanted, text > Fix For: 1.x > > > I had a look at > [lang|https://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html] > and > [text|https://commons.apache.org/proper/commons-text/javadocs/api-release/index.html] > API's, but could not locate a class/method for > [palindromes|https://en.wikipedia.org/wiki/Palindrome]. > Ideally, it would support words or sentences such as "racecar" and "step on > no pets". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JEXL-227) JexlScriptEngineFactory.getEngineVersion() should return actual version, ie 3.1 as of reporting
[
https://issues.apache.org/jira/browse/JEXL-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16058343#comment-16058343
]
Bruno P. Kinoshita commented on JEXL-227:
-
(y) thanks for the explanation Henri!
>From the Javadocs of the parent
{code:java}
/**
* Returns the version of the scripting language supported by this
* ScriptEngine.
* @return The version of the supported language.
*/
public String getLanguageVersion();
/**
* Returns the version of the ScriptEngine.
* @return The ScriptEngine implementation version.
*/
public String getEngineVersion();
{code}
So I think #getEngineVersionmust match the version in pom.xml, and
#getLanguageVersion should be 3.0, until we introduce version to the language
that deserve a version bump. Does that sound right?
> JexlScriptEngineFactory.getEngineVersion() should return actual version, ie
> 3.1 as of reporting
> ---
>
> Key: JEXL-227
> URL: https://issues.apache.org/jira/browse/JEXL-227
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> JexlScriptEngineFactory.getEngineVersion() reports "3.0" as a script engine
> version in 3.1
> {code}
> public String getEngineVersion() {
> return "3.0"; // ensure this is updated if function changes are made
> to this class
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TEXT-93) RandomStringGenerator accepts a list of valid characters
Wilson MacGyver created TEXT-93: --- Summary: RandomStringGenerator accepts a list of valid characters Key: TEXT-93 URL: https://issues.apache.org/jira/browse/TEXT-93 Project: Commons Text Issue Type: Wish Reporter: Wilson MacGyver implement a "selectFrom" feature: RandomStringGenerator gen = new RandomStringGenerator.Builder() .selectFrom(charArray) .build(); so we can pass a list of valid characters -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DAEMON-364) Latest RHEL kernel update crashes jsvc
Peter Walsh created DAEMON-364:
--
Summary: Latest RHEL kernel update crashes jsvc
Key: DAEMON-364
URL: https://issues.apache.org/jira/browse/DAEMON-364
Project: Commons Daemon
Issue Type: Bug
Components: Jsvc
Affects Versions: 1.0.15
Reporter: Peter Walsh
After applying the latest RHEL kernel updates (CVE-2017-1000364), all jsvc
instance crash on start up with the following:
{quote}#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGBUS (0x7) at pc=0x7f0fcea07bdc, pid=28581, tid=0x7f0fdfc0c700
#
# JRE version: (8.0_121-b13) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# j java.lang.Object.()V+0
#
# Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# //hs_err_pid28581.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp{quote}
Manually starting the service does not exhibit the problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-79) Investigate adding string search algorithms
[ https://issues.apache.org/jira/browse/TEXT-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16058078#comment-16058078 ] Amey Jadiye commented on TEXT-79: - Hi [~kinow] Lucene don't use the string search algorithms, how it works explained in below stackoverflow question. https://stackoverflow.com/questions/2208649/string-matching-algorithms-used-by-lucene I personally feel that we should have string search API in Commons Text, I will be glad to provide the PR. > Investigate adding string search algorithms > --- > > Key: TEXT-79 > URL: https://issues.apache.org/jira/browse/TEXT-79 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: algorithm, help-wanted, text > Fix For: 1.x > > > There are a few [string searching > algorithms|https://en.wikipedia.org/wiki/String_searching_algorithm] (e.g. > Rabin Karp) that do not have an implementation in commons yet. > Would be interesting to check if any other ASF projects use any of these or > others (e.g. Lucene, Solr, Tika, etc) and see if they could be implemented in > [text]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (VFS-637) Zip files with legacy encoding and special characters let VFS crash
[
https://issues.apache.org/jira/browse/VFS-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16057955#comment-16057955
]
Bernd Eckenfels commented on VFS-637:
-
What do you think about StandardCharSet.ASCII or LATIN1 as default or would you
use absent (which throws for non UTF8 marked archives?)
> Zip files with legacy encoding and special characters let VFS crash
> ---
>
> Key: VFS-637
> URL: https://issues.apache.org/jira/browse/VFS-637
> Project: Commons VFS
> Issue Type: Bug
> Environment: Windows 10 64 Bit, Java 8
>Reporter: Guido Schnepp
> Labels: easyfix
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Oracle has reworked the ZipFile object with Java 7. Since then the default
> constructor used by commons-vfs2 2.1 is more restrictive than with Java 6.
> The ZipFile constructor has got a second parameter (Charset) now for
> specification of the legacy charset to be used explicitly if the ZipFile
> doesn't state its UTF-8 compliance internally. This affects all ZIP files
> using a legacy charset for filename encoding but not using UTF-8 is it is
> common today. This could be a ZIP file with files containing german umlauts
> or russian characters in archived file's filenames, for example.
> To support this new parameter with (more or less) default values, the class
> org.apache.commons.vfs2.provider.zip.ZipFileSystem has to be extended by a
> default charset parameter, getter or setter (as you like) to forward this
> setting to the java.util.zip.ZipFile constructor.
> Quick workaround for me was to create a new OwnZipFileProvider referring to
> the even new OwnZipFileSystem (extending ZipFileSystem) with the following
> modified function. Change has been highlighted:
> {{protected ZipFile createZipFile(final File file) throws
> FileSystemException {
> try {
> return new ZipFile(file{color:red}*,
> Charset.forName("IBM437")*{color});
> } catch (final IOException ioe) {
> throw new
> FileSystemException("vfs.provider.zip/open-zip-file.error", file, ioe);
> }
> }
> }}
> Presetting to charset 437 as legacy default charset seems to be a a good
> workaround as stated in appendix D here:
> https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT :
> "D.1 The ZIP format has historically supported only the original IBM PC
> character encoding set, commonly referred to as IBM Code Page 437. This
> limits storing file name characters to only those within the original MS-DOS
> range of values and does not properly support file names in other character
> encodings, or languages. [...]"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (POOL-327) GKOP: returnObject does not unblock threads waiting in borrowObject if maxIdle=0
[ https://issues.apache.org/jira/browse/POOL-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1605#comment-1605 ] Phil Steitz edited comment on POOL-327 at 6/21/17 5:27 PM: --- Its nice to have test cases and patches to look at. Nice work, Paul! The first patch should resolve the issue as presented and I don't see anything wrong with it, though its been a while since I worked on that code. The second is a more general solution that is probably also OK. I have two comments though. 1. Going back to POOL-240, my gut is we are playing whack-a-mole here to avoid addressing the core problem of just notifying the waiting threads when something happens that should enable them to progress. This is a vague statement and it could be the ensureMinIdle approach is just fine. I just think it is worth revisiting. 2. An WONT_FIX argument could be made here. maxIdle = 0 smells like a questionable use case for GOP. And the ensureMinidle workaround kind of abuses the fuzzy accounting that allows you to in fact push a new but "idle" instance through the pool to give to a waiting thread. was (Author: psteitz): Its nice to have test cases and patches to look at. Nice work, Paul! The first patch should resolve the issue as presented and I don't see anything wrong with it, though its been a while since I worked on that code. The second is a more general solution that is probably also OK. I have two comments though. 1. Going back to POOL-240, my gut is we are playing whack-a-mole here to avoid addressing the core problem of just notifying the waiting threads when something happens that should enable them to progress. This is a vague statement and it could be the ensureMinIdle approach is just fine. I just think it is worth revisiting. 2. An WONT_FIX argument could be made here. minIdle = 0 smells like a questionable use case for GOP. And the ensureMinidle workaround kind of abuses the fuzzy accounting that allows you to in fact push a new but "idle" instance through the pool to give to a waiting thread. > GKOP: returnObject does not unblock threads waiting in borrowObject if > maxIdle=0 > > > Key: POOL-327 > URL: https://issues.apache.org/jira/browse/POOL-327 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.4.2 >Reporter: Paul Pazderski >Priority: Minor > Attachments: 327-maxIdle0-alternativ.patch, 327-maxIdle0.patch, > 327-maxIdle0-test.patch > > > If idle objects are disabled by maxIdle=0 a thread blocked in borrowObject is > not notified if another thread returns an object. > Attached is a unit test (327-maxIdle0-test.patch) that demonstrates the > issue. I tried a similar test on GenericKeyedObjectPool as well which not > seems to be affected by this issue. > I also attached two possible solutions for this issue. > The first (327-maxIdle0.patch) just notifies a potentially waiting thread in > the affected returnObject code branch. (similar to POOL-240) > The second (327-maxIdle0-alternativ.patch) checks for waiting threads every > time an object get destroyed. But this may introduce undesired behavior in > other functions. (like clear or evict) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JEXL-227) JexlScriptEngineFactory.getEngineVersion() should return actual version, ie 3.1 as of reporting
[
https://issues.apache.org/jira/browse/JEXL-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16057653#comment-16057653
]
Henri Biestro commented on JEXL-227:
Since we've introduced new syntactic elements in 3.1 (side effect operators),
I'd bump the language version to 3.1. However, releasing a new version will
change the version number so #getEngineVersion should return 3.1.1 (probably).
Need to fix a few other bugs/enh before attempting release though.
> JexlScriptEngineFactory.getEngineVersion() should return actual version, ie
> 3.1 as of reporting
> ---
>
> Key: JEXL-227
> URL: https://issues.apache.org/jira/browse/JEXL-227
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> JexlScriptEngineFactory.getEngineVersion() reports "3.0" as a script engine
> version in 3.1
> {code}
> public String getEngineVersion() {
> return "3.0"; // ensure this is updated if function changes are made
> to this class
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (VFS-637) Zip files with legacy encoding and special characters let VFS crash
Guido Schnepp created VFS-637:
-
Summary: Zip files with legacy encoding and special characters let
VFS crash
Key: VFS-637
URL: https://issues.apache.org/jira/browse/VFS-637
Project: Commons VFS
Issue Type: Bug
Environment: Windows 10 64 Bit, Java 8
Reporter: Guido Schnepp
Oracle has reworked the ZipFile object with Java 7. Since then the default
constructor used by commons-vfs2 2.1 is more restrictive than with Java 6. The
ZipFile constructor has got a second parameter (Charset) now for specification
of the legacy charset to be used explicitly if the ZipFile doesn't state its
UTF-8 compliance internally. This affects all ZIP files using a legacy charset
for filename encoding but not using UTF-8 is it is common today. This could be
a ZIP file with files containing german umlauts or russian characters in
archived file's filenames, for example.
To support this new parameter with (more or less) default values, the class
org.apache.commons.vfs2.provider.zip.ZipFileSystem has to be extended by a
default charset parameter, getter or setter (as you like) to forward this
setting to the java.util.zip.ZipFile constructor.
Quick workaround for me was to create a new OwnZipFileProvider referring to the
even new OwnZipFileSystem (extending ZipFileSystem) with the following modified
function. Change has been highlighted:
{{ protected ZipFile createZipFile(final File file) throws
FileSystemException {
try {
return new ZipFile(file{color:red}*,
Charset.forName("IBM437")*{color});
} catch (final IOException ioe) {
throw new
FileSystemException("vfs.provider.zip/open-zip-file.error", file, ioe);
}
}
}}
Presetting to charset 437 as legacy default charset seems to be a a good
workaround as stated in appendix D here:
https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT :
"D.1 The ZIP format has historically supported only the original IBM PC
character encoding set, commonly referred to as IBM Code Page 437. This limits
storing file name characters to only those within the original MS-DOS range of
values and does not properly support file names in other character encodings,
or languages. [...]"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DAEMON-363) JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel 2.6.32-696.3.2.el6.x86_64
[
https://issues.apache.org/jira/browse/DAEMON-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Schenk updated DAEMON-363:
Attachment: hs_err_pid4035.log
Attaching the crash log.
> JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel
> 2.6.32-696.3.2.el6.x86_64
>
>
> Key: DAEMON-363
> URL: https://issues.apache.org/jira/browse/DAEMON-363
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.0.15
> Environment: CentOS 6.9
> Kernel: 2.6.32-696.3.2.el6.x86_64
> Updated for CVE: CVE-2017-1000364
> JSVC compiled from latest source.
>Reporter: Derek Schenk
>Priority: Critical
> Attachments: hs_err_pid4035.log
>
>
> After applying the update for CVE-2017-1000364 to CentOS 6.9 (kernel
> 2.6.32-696.3.2.el6.x86_64) JSVC no longer launches the JVM.
> The process starts, and when it attempts to launch the JVM it fails with a
> SIGBUS (0x7).
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0x7) at pc=0x7f4785109bfc, pid=21204, tid=0x7f4796bbd700
> #
> # JRE version: (8.0_121-b13) (build )
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13 mixed mode
> linux-amd64 compressed oops)
> # Problematic frame:
> # j java.lang.Object.()V+0
> {code}
> The following reproduces the problem. Note that the target class is not
> relevant as it never reaches that point.
> ./jsvc -debug -verbose -home /opt/java/1.8.0_121/ com.does.not.Matter
> Tracing the code it reaches this point and then fails:
> {code}
> java.c
> bool java_init(arg_data *args, home_data *data)
> ret = (*symb) (&jvm, &env, &arg);
> {code}
> The following is the output:
> {code}
> # ./jsvc -debug -verbose -home /opt/java/1.8.0_121/ com.does.not.Matter
> +-- DUMPING PARSED COMMAND LINE ARGUMENTS --
> | Detach: True
> | Show Version:No
> | Show Help: No
> | Check Only: Disabled
> | Stop:False
> | Wait:0
> | Run as service: No
> | Install service: No
> | Remove service: No
> | JVM Name:"null"
> | Java Home: "/opt/java/1.8.0_121/"
> | PID File:"/var/run/jsvc.pid"
> | User Name: "null"
> | Extra Options: 1
> | "-verbose"
> | Class Invoked: "com.does.not.Matter"
> | Class Arguments: 0
> +---
> Attempting to locate Java Home in /opt/java/1.8.0_121/
> Attempting to locate VM configuration file
> /opt/java/1.8.0_121//jre/lib/jvm.cfg
> Attempting to locate VM configuration file /opt/java/1.8.0_121//lib/jvm.cfg
> Attempting to locate VM configuration file
> /opt/java/1.8.0_121//jre/lib/amd64/jvm.cfg
> Attempting to locate VM configuration file
> /opt/java/1.8.0_121//lib/amd64/jvm.cfg
> Found VM configuration file at /opt/java/1.8.0_121//lib/amd64/jvm.cfg
> Found VM server definition in configuration
> Checking library /opt/java/1.8.0_121//jre/lib/amd64/server/libjvm.so
> Checking library /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
> Found VM client definition in configuration
> Checking library /opt/java/1.8.0_121//jre/lib/amd64/client/libjvm.so
> Checking library /opt/java/1.8.0_121//lib/amd64/client/libjvm.so
> Cannot locate library for VM client (skipping)
> Java Home located in /opt/java/1.8.0_121/
> +-- DUMPING JAVA HOME STRUCTURE
> | Java Home: "/opt/java/1.8.0_121/"
> | Java VM Config.: "/opt/java/1.8.0_121//lib/amd64/jvm.cfg"
> | Found JVMs: 1
> | JVM Name:"server"
> | "/opt/java/1.8.0_121//lib/amd64/server/libjvm.so"
> +---
> Using default JVM in /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
> Invoking w/
> LD_LIBRARY_PATH=/opt/java/1.8.0_121//lib/amd64/server:/opt/java/1.8.0_121//lib/amd64
> +-- DUMPING PARSED COMMAND LINE ARGUMENTS --
> | Detach: True
> | Show Version:No
> | Show Help: No
> | Check Only: Disabled
> | Stop:False
> | Wait:0
> | Run as service: No
> | Install service: No
> | Remove service: No
> | JVM Name:"null"
> | Java Home: "/opt/java/1.8.0_121/"
> | PID File:"/var/run/jsvc.pid"
> | User Name: "null"
> | Extra Options: 1
> | "-verbose"
> | Class Invoked: "com.does.not.Matter"
> | Class Arguments: 0
> +---
> Attempting to locate Java Home in /opt/java/1.8.0_121/
> Attempting to locate VM configuration file
> /opt/java/1.8.0_121//jre/lib/jvm.cfg
> Attempting to locate VM configuration file /opt/java/1.8.0_121//lib/jvm.cfg
> Attempting to locate VM configuration file
> /opt/java/1.8.0_121//jre/lib/amd64/jvm.cfg
> Attempting to locate VM configuration file
> /opt/java/1.8
[jira] [Created] (DAEMON-363) JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel 2.6.32-696.3.2.el6.x86_64
Derek Schenk created DAEMON-363:
---
Summary: JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel
2.6.32-696.3.2.el6.x86_64
Key: DAEMON-363
URL: https://issues.apache.org/jira/browse/DAEMON-363
Project: Commons Daemon
Issue Type: Bug
Components: Jsvc
Affects Versions: 1.0.15
Environment: CentOS 6.9
Kernel: 2.6.32-696.3.2.el6.x86_64
Updated for CVE: CVE-2017-1000364
JSVC compiled from latest source.
Reporter: Derek Schenk
Priority: Critical
After applying the update for CVE-2017-1000364 to CentOS 6.9 (kernel
2.6.32-696.3.2.el6.x86_64) JSVC no longer launches the JVM.
The process starts, and when it attempts to launch the JVM it fails with a
SIGBUS (0x7).
{code}
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGBUS (0x7) at pc=0x7f4785109bfc, pid=21204, tid=0x7f4796bbd700
#
# JRE version: (8.0_121-b13) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# j java.lang.Object.()V+0
{code}
The following reproduces the problem. Note that the target class is not
relevant as it never reaches that point.
./jsvc -debug -verbose -home /opt/java/1.8.0_121/ com.does.not.Matter
Tracing the code it reaches this point and then fails:
{code}
java.c
bool java_init(arg_data *args, home_data *data)
ret = (*symb) (&jvm, &env, &arg);
{code}
The following is the output:
{code}
# ./jsvc -debug -verbose -home /opt/java/1.8.0_121/ com.does.not.Matter
+-- DUMPING PARSED COMMAND LINE ARGUMENTS --
| Detach: True
| Show Version:No
| Show Help: No
| Check Only: Disabled
| Stop:False
| Wait:0
| Run as service: No
| Install service: No
| Remove service: No
| JVM Name:"null"
| Java Home: "/opt/java/1.8.0_121/"
| PID File:"/var/run/jsvc.pid"
| User Name: "null"
| Extra Options: 1
| "-verbose"
| Class Invoked: "com.does.not.Matter"
| Class Arguments: 0
+---
Attempting to locate Java Home in /opt/java/1.8.0_121/
Attempting to locate VM configuration file /opt/java/1.8.0_121//jre/lib/jvm.cfg
Attempting to locate VM configuration file /opt/java/1.8.0_121//lib/jvm.cfg
Attempting to locate VM configuration file
/opt/java/1.8.0_121//jre/lib/amd64/jvm.cfg
Attempting to locate VM configuration file
/opt/java/1.8.0_121//lib/amd64/jvm.cfg
Found VM configuration file at /opt/java/1.8.0_121//lib/amd64/jvm.cfg
Found VM server definition in configuration
Checking library /opt/java/1.8.0_121//jre/lib/amd64/server/libjvm.so
Checking library /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
Found VM client definition in configuration
Checking library /opt/java/1.8.0_121//jre/lib/amd64/client/libjvm.so
Checking library /opt/java/1.8.0_121//lib/amd64/client/libjvm.so
Cannot locate library for VM client (skipping)
Java Home located in /opt/java/1.8.0_121/
+-- DUMPING JAVA HOME STRUCTURE
| Java Home: "/opt/java/1.8.0_121/"
| Java VM Config.: "/opt/java/1.8.0_121//lib/amd64/jvm.cfg"
| Found JVMs: 1
| JVM Name:"server"
| "/opt/java/1.8.0_121//lib/amd64/server/libjvm.so"
+---
Using default JVM in /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
Invoking w/
LD_LIBRARY_PATH=/opt/java/1.8.0_121//lib/amd64/server:/opt/java/1.8.0_121//lib/amd64
+-- DUMPING PARSED COMMAND LINE ARGUMENTS --
| Detach: True
| Show Version:No
| Show Help: No
| Check Only: Disabled
| Stop:False
| Wait:0
| Run as service: No
| Install service: No
| Remove service: No
| JVM Name:"null"
| Java Home: "/opt/java/1.8.0_121/"
| PID File:"/var/run/jsvc.pid"
| User Name: "null"
| Extra Options: 1
| "-verbose"
| Class Invoked: "com.does.not.Matter"
| Class Arguments: 0
+---
Attempting to locate Java Home in /opt/java/1.8.0_121/
Attempting to locate VM configuration file /opt/java/1.8.0_121//jre/lib/jvm.cfg
Attempting to locate VM configuration file /opt/java/1.8.0_121//lib/jvm.cfg
Attempting to locate VM configuration file
/opt/java/1.8.0_121//jre/lib/amd64/jvm.cfg
Attempting to locate VM configuration file
/opt/java/1.8.0_121//lib/amd64/jvm.cfg
Found VM configuration file at /opt/java/1.8.0_121//lib/amd64/jvm.cfg
Found VM server definition in configuration
Checking library /opt/java/1.8.0_121//jre/lib/amd64/server/libjvm.so
Checking library /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
Found VM client definition in configuration
Checking library /opt/java/1.8.0_121//jre/lib/amd64/client/libjvm.so
Checking library /opt/java/1.8.0_121//lib/amd64/client/libjvm.so
Cannot locate library for VM client (skipping)
Java Home
[jira] [Resolved] (JCS-178) client using RemoteCache are not working
[ https://issues.apache.org/jira/browse/JCS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-178. Resolution: Fixed Fixed in SVN > client using RemoteCache are not working > > > Key: JCS-178 > URL: https://issues.apache.org/jira/browse/JCS-178 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Thomas Vandahl > Fix For: jcs-2.2 > > > RemoteCacheNoWaitFacade is not usable cause of its constructor loop > (concurrent modification) leading to the remote cache not being usable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (JEXL-227) JexlScriptEngineFactory.getEngineVersion() should return actual version, ie 3.1 as of reporting
[
https://issues.apache.org/jira/browse/JEXL-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16057388#comment-16057388
]
Bruno P. Kinoshita edited comment on JEXL-227 at 6/21/17 12:16 PM:
---
Felt tempted to quickly fix and commit. But then realized there are two methods
with 3.0: #getEngineVersion and #getLanguageVersion.
Not sure if we should update both, or one and not the other, or update only
with major releases... Will wait to see if someone else knows (maybe [~henrib]
or [~ebourg]?) more about these methods, and then maybe we could override the
javadoc (or complement, and use that inheritDoc tag too if necessary) saying
what to do / why.
Cheers
Bruno
was (Author: kinow):
Felt tempted to quickly fix and commit. But then realized there are two methods
with 3.0: #getEngineVersion and #getLanguageVersion.
Not sure if we should update both, or one and not the other, or update only
with major releases... Will wait to see if someone else knows (maybe [~henrib]
?) more about these methods, and then maybe we could override the javadoc (or
complement, and use that inheritDoc tag too if necessary) saying what to do /
why.
Cheers
Bruno
> JexlScriptEngineFactory.getEngineVersion() should return actual version, ie
> 3.1 as of reporting
> ---
>
> Key: JEXL-227
> URL: https://issues.apache.org/jira/browse/JEXL-227
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> JexlScriptEngineFactory.getEngineVersion() reports "3.0" as a script engine
> version in 3.1
> {code}
> public String getEngineVersion() {
> return "3.0"; // ensure this is updated if function changes are made
> to this class
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-227) JexlScriptEngineFactory.getEngineVersion() should return actual version, ie 3.1 as of reporting
[
https://issues.apache.org/jira/browse/JEXL-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16057388#comment-16057388
]
Bruno P. Kinoshita commented on JEXL-227:
-
Felt tempted to quickly fix and commit. But then realized there are two methods
with 3.0: #getEngineVersion and #getLanguageVersion.
Not sure if we should update both, or one and not the other, or update only
with major releases... Will wait to see if someone else knows (maybe [~henrib]
?) more about these methods, and then maybe we could override the javadoc (or
complement, and use that inheritDoc tag too if necessary) saying what to do /
why.
Cheers
Bruno
> JexlScriptEngineFactory.getEngineVersion() should return actual version, ie
> 3.1 as of reporting
> ---
>
> Key: JEXL-227
> URL: https://issues.apache.org/jira/browse/JEXL-227
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> JexlScriptEngineFactory.getEngineVersion() reports "3.0" as a script engine
> version in 3.1
> {code}
> public String getEngineVersion() {
> return "3.0"; // ensure this is updated if function changes are made
> to this class
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (DAEMON-362) CLONE - Windows service fails to stop with error code 1053 (using Windows 7 service manager)
[ https://issues.apache.org/jira/browse/DAEMON-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-362. Resolution: Invalid WinRun4J is not associated with Commons Daemon. You should use the appropriate support mechanism for that software. > CLONE - Windows service fails to stop with error code 1053 (using Windows 7 > service manager) > > > Key: DAEMON-362 > URL: https://issues.apache.org/jira/browse/DAEMON-362 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Any windows OS 64 bit > JRE 1.8 > WinRun4J for making tomcat as a windows service > Tomcat 8.5.8 version >Reporter: Raghavaraju Kudari >Assignee: Guillaume Chauvet > Labels: prunsrv, stop, windows > > Using Windows services manager (services.msc) to start/stop service. > Service installed with the following start/stop settings. > #service parameters > service.class=com.myserver.launcher.tomcat.Tomcat8Service > service.id=myappservice > service.startup=auto > service.name=myappservice > service.description=my app service > Service starts OK. > When I use services manager to stop the service, the application stops > running but the my service is not getting terminates (myappserver.exe) > process does not terminate. > Eventually the services manager reports that: > "Windows could not stop the service on Local Computer. Error > 1053: The service did not respond to the start or control request in a timely > fashion." > The service then stays at status "stopping" & cannot be stopped > Looking at the application logs I can see that the application's stop() > method gets called - > com.myserver.launcher.tomcat.Tomcat8Service.java extends the WinRun4j --> > AbstractService.java > We have our own tomcat-launcher which internally invokes the > org.apache.catalina.startup.Bootstrap.stop() method to stop the tomcat. > However it is not able to kill the myappserver.exe process. . > Any pointer would really helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DAEMON-362) CLONE - Windows service fails to stop with error code 1053 (using Windows 7 service manager)
[ https://issues.apache.org/jira/browse/DAEMON-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raghavaraju Kudari updated DAEMON-362: -- Description: Using Windows services manager (services.msc) to start/stop service. Service installed with the following start/stop settings. #service parameters service.class=com.myserver.launcher.tomcat.Tomcat8Service service.id=myappservice service.startup=auto service.name=myappservice service.description=my app service Service starts OK. When I use services manager to stop the service, the application stops running but the my service is not getting terminates (myappserver.exe) process does not terminate. Eventually the services manager reports that: "Windows could not stop the service on Local Computer. Error 1053: The service did not respond to the start or control request in a timely fashion." The service then stays at status "stopping" & cannot be stopped Looking at the application logs I can see that the application's stop() method gets called - com.myserver.launcher.tomcat.Tomcat8Service.java extends the WinRun4j --> AbstractService.java We have our own tomcat-launcher which internally invokes the org.apache.catalina.startup.Bootstrap.stop() method to stop the tomcat. However it is not able to kill the myappserver.exe process. . Any pointer would really helpful. was: Using Windows services manager (services.msc) to start/stop service. Service installed with the following start/stop settings. #service parameters service.class=com.myserver.launcher.tomcat.Tomcat8Service service.id=myappservice service.startup=auto service.name=myappservice service.description=my app service Service starts OK. When I use services manager to stop the service, the application stops running but the my service is not getting terminates (myappserver.exe) process does not terminate. Eventually the services manager reports that: "Windows could not stop the service on Local Computer. Error 1053: The service did not respond to the start or control request in a timely fashion." The service then stays at status "stopping" & cannot be stopped Looking at the application logs I can see that the application's stop() method gets called - com.myserver.launcher.tomcat.Tomcat8Service.java extends the WinRun4j --> AbstractService.java We have our own tomcat-launcher which internally invokes the org.apache.catalina.startup.Bootstrap.stop() method to stop the tomcat. However it is not able to kill the myappserver.exe process. . > CLONE - Windows service fails to stop with error code 1053 (using Windows 7 > service manager) > > > Key: DAEMON-362 > URL: https://issues.apache.org/jira/browse/DAEMON-362 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Any windows OS 64 bit > JRE 1.8 > WinRun4J for making tomcat as a windows service > Tomcat 8.5.8 version >Reporter: Raghavaraju Kudari >Assignee: Guillaume Chauvet > Labels: prunsrv, stop, windows > > Using Windows services manager (services.msc) to start/stop service. > Service installed with the following start/stop settings. > #service parameters > service.class=com.myserver.launcher.tomcat.Tomcat8Service > service.id=myappservice > service.startup=auto > service.name=myappservice > service.description=my app service > Service starts OK. > When I use services manager to stop the service, the application stops > running but the my service is not getting terminates (myappserver.exe) > process does not terminate. > Eventually the services manager reports that: > "Windows could not stop the service on Local Computer. Error > 1053: The service did not respond to the start or control request in a timely > fashion." > The service then stays at status "stopping" & cannot be stopped > Looking at the application logs I can see that the application's stop() > method gets called - > com.myserver.launcher.tomcat.Tomcat8Service.java extends the WinRun4j --> > AbstractService.java > We have our own tomcat-launcher which internally invokes the > org.apache.catalina.startup.Bootstrap.stop() method to stop the tomcat. > However it is not able to kill the myappserver.exe process. . > Any pointer would really helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DAEMON-362) CLONE - Windows service fails to stop with error code 1053 (using Windows 7 service manager)
[ https://issues.apache.org/jira/browse/DAEMON-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raghavaraju Kudari updated DAEMON-362: -- Environment: Any windows OS 64 bit JRE 1.8 WinRun4J for making tomcat as a windows service Tomcat 8.5.8 version was: Any windows OS 64 bit - JRE 1.8 WinRun4J for making tocmat as a windows service Tomcat 8.5.8 > CLONE - Windows service fails to stop with error code 1053 (using Windows 7 > service manager) > > > Key: DAEMON-362 > URL: https://issues.apache.org/jira/browse/DAEMON-362 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Any windows OS 64 bit > JRE 1.8 > WinRun4J for making tomcat as a windows service > Tomcat 8.5.8 version >Reporter: Raghavaraju Kudari >Assignee: Guillaume Chauvet > Labels: prunsrv, stop, windows > > Using Windows services manager (services.msc) to start/stop service. > Service installed with the following start/stop settings. > #service parameters > service.class=com.myserver.launcher.tomcat.Tomcat8Service > service.id=myappservice > service.startup=auto > service.name=myappservice > service.description=my app service > Service starts OK. > When I use services manager to stop the service, the application stops > running but the my service is not getting terminates (myappserver.exe) > process does not terminate. > Eventually the services manager reports that: > "Windows could not stop the service on Local Computer. Error > 1053: The service did not respond to the start or control request in a timely > fashion." > The service then stays at status "stopping" & cannot be stopped > Looking at the application logs I can see that the application's stop() > method gets called - > com.myserver.launcher.tomcat.Tomcat8Service.java extends the WinRun4j --> > AbstractService.java > We have our own tomcat-launcher which internally invokes the > org.apache.catalina.startup.Bootstrap.stop() method to stop the tomcat. > However it is not able to kill the myappserver.exe process. . -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DAEMON-362) CLONE - Windows service fails to stop with error code 1053 (using Windows 7 service manager)
[ https://issues.apache.org/jira/browse/DAEMON-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raghavaraju Kudari updated DAEMON-362: -- Description: Using Windows services manager (services.msc) to start/stop service. Service installed with the following start/stop settings. #service parameters service.class=com.myserver.launcher.tomcat.Tomcat8Service service.id=myappservice service.startup=auto service.name=myappservice service.description=my app service Service starts OK. When I use services manager to stop the service, the application stops running but the my service is not getting terminates (myappserver.exe) process does not terminate. Eventually the services manager reports that: "Windows could not stop the service on Local Computer. Error 1053: The service did not respond to the start or control request in a timely fashion." The service then stays at status "stopping" & cannot be stopped Looking at the application logs I can see that the application's stop() method gets called - com.myserver.launcher.tomcat.Tomcat8Service.java extends the WinRun4j --> AbstractService.java We have our own tomcat-launcher which internally invokes the org.apache.catalina.startup.Bootstrap.stop() method to stop the tomcat. However it is not able to kill the myappserver.exe process. . was: Using Windows services manager (services.msc) to start/stop service. Service installed with the following start/stop settings. --StartMode=jvm --StartClass=com.myorg.MyClass --StartMethod=start --StopMode=jvm --StopClass=com.myorg.MyClass --StopMethod=stop Service starts OK. When I use services manager to stop the service, the application stops running but the my service is not getting terminates (myappserver.exe) process does not terminate. Eventually the services manager reports that: "Windows could not stop the service on Local Computer. Error 1053: The service did not respond to the start or control request in a timely fashion." The service then stays at status "stopping" & cannot be stopped Looking at the application logs I can see that the application's stop() method gets called - the final line in this method is a logging call which is executing OK. > CLONE - Windows service fails to stop with error code 1053 (using Windows 7 > service manager) > > > Key: DAEMON-362 > URL: https://issues.apache.org/jira/browse/DAEMON-362 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Any windows OS 64 bit - > JRE 1.8 > WinRun4J for making tocmat as a windows service > Tomcat 8.5.8 >Reporter: Raghavaraju Kudari >Assignee: Guillaume Chauvet > Labels: prunsrv, stop, windows > > Using Windows services manager (services.msc) to start/stop service. > Service installed with the following start/stop settings. > #service parameters > service.class=com.myserver.launcher.tomcat.Tomcat8Service > service.id=myappservice > service.startup=auto > service.name=myappservice > service.description=my app service > Service starts OK. > When I use services manager to stop the service, the application stops > running but the my service is not getting terminates (myappserver.exe) > process does not terminate. > Eventually the services manager reports that: > "Windows could not stop the service on Local Computer. Error > 1053: The service did not respond to the start or control request in a timely > fashion." > The service then stays at status "stopping" & cannot be stopped > Looking at the application logs I can see that the application's stop() > method gets called - > com.myserver.launcher.tomcat.Tomcat8Service.java extends the WinRun4j --> > AbstractService.java > We have our own tomcat-launcher which internally invokes the > org.apache.catalina.startup.Bootstrap.stop() method to stop the tomcat. > However it is not able to kill the myappserver.exe process. . -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DAEMON-362) CLONE - Windows service fails to stop with error code 1053 (using Windows 7 service manager)
[ https://issues.apache.org/jira/browse/DAEMON-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raghavaraju Kudari updated DAEMON-362: -- Description: Using Windows services manager (services.msc) to start/stop service. Service installed with the following start/stop settings. --StartMode=jvm --StartClass=com.myorg.MyClass --StartMethod=start --StopMode=jvm --StopClass=com.myorg.MyClass --StopMethod=stop Service starts OK. When I use services manager to stop the service, the application stops running but the my service is not getting terminates (myappserver.exe) process does not terminate. Eventually the services manager reports that: "Windows could not stop the service on Local Computer. Error 1053: The service did not respond to the start or control request in a timely fashion." The service then stays at status "stopping" & cannot be stopped Looking at the application logs I can see that the application's stop() method gets called - the final line in this method is a logging call which is executing OK. was: Using Windows services manager (services.msc) to start/stop service. Service installed with the following start/stop settings. --StartMode=jvm --StartClass=com.myorg.MyClass --StartMethod=start --StopMode=jvm --StopClass=com.myorg.MyClass --StopMethod=stop Service starts OK. When I use services manager to stop the service, the application stops running but the prunsrv.exe process does not terminate. Eventually the services manager reports that: "Windows could not stop the service on Local Computer. Error 1053: The service did not respond to the start or control request in a timely fashion." The service then stays at status "stopping" & cannot be restarted without first killing the prunsrv.exe process. Looking at the application logs I can see that the application's stop() method gets called - the final line in this method is a logging call which is executing OK. The commons-daemon-.log file has the following entries: [2013-05-09 17:18:02] [info] [10944] Commons Daemon procrun (1.0.15.0 32-bit) started [2013-05-09 17:18:02] [info] [10944] Running '' Service... [2013-05-09 17:18:02] [info] [ 9224] Starting service... [2013-05-09 17:18:11] [info] [ 9224] Service started in 9202 ms. [2013-05-09 17:18:23] [info] [10780] Stopping service... [2013-05-09 17:18:24] [info] [10780] Service stop thread completed. This problem does not occur in daemon versions 11->14. I have only seen it in daemon-1.0.15 > CLONE - Windows service fails to stop with error code 1053 (using Windows 7 > service manager) > > > Key: DAEMON-362 > URL: https://issues.apache.org/jira/browse/DAEMON-362 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Any windows OS 64 bit - > JRE 1.8 > WinRun4J for making tocmat as a windows service > Tomcat 8.5.8 >Reporter: Raghavaraju Kudari >Assignee: Guillaume Chauvet > Labels: prunsrv, stop, windows > > Using Windows services manager (services.msc) to start/stop service. > Service installed with the following start/stop settings. > --StartMode=jvm --StartClass=com.myorg.MyClass --StartMethod=start > --StopMode=jvm --StopClass=com.myorg.MyClass --StopMethod=stop > Service starts OK. > When I use services manager to stop the service, the application stops > running but the my service is not getting terminates (myappserver.exe) > process does not terminate. > Eventually the services manager reports that: > "Windows could not stop the service on Local Computer. Error > 1053: The service did not respond to the start or control request in a timely > fashion." > The service then stays at status "stopping" & cannot be stopped > Looking at the application logs I can see that the application's stop() > method gets called - the final line in this method is a logging call which is > executing OK. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DAEMON-362) CLONE - Windows service fails to stop with error code 1053 (using Windows 7 service manager)
[ https://issues.apache.org/jira/browse/DAEMON-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raghavaraju Kudari updated DAEMON-362: -- Environment: Any windows OS 64 bit - JRE 1.8 WinRun4J for making tocmat as a windows service Tomcat 8.5.8 was: Windows 7 64bit - using 32-bit prunsrv.exe in jvm mode Using 32-bit Java JRE 1.7.0_17 > CLONE - Windows service fails to stop with error code 1053 (using Windows 7 > service manager) > > > Key: DAEMON-362 > URL: https://issues.apache.org/jira/browse/DAEMON-362 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Any windows OS 64 bit - > JRE 1.8 > WinRun4J for making tocmat as a windows service > Tomcat 8.5.8 >Reporter: Raghavaraju Kudari >Assignee: Guillaume Chauvet > Labels: prunsrv, stop, windows > > Using Windows services manager (services.msc) to start/stop service. > Service installed with the following start/stop settings. > --StartMode=jvm --StartClass=com.myorg.MyClass --StartMethod=start > --StopMode=jvm --StopClass=com.myorg.MyClass --StopMethod=stop > Service starts OK. > When I use services manager to stop the service, the application stops > running but the prunsrv.exe process does not terminate. > Eventually the services manager reports that: > "Windows could not stop the service on Local Computer. Error > 1053: The service did not respond to the start or control request in a timely > fashion." > The service then stays at status "stopping" & cannot be restarted without > first killing the prunsrv.exe process. > Looking at the application logs I can see that the application's stop() > method gets called - the final line in this method is a logging call which is > executing OK. > The commons-daemon-.log file has the following entries: > [2013-05-09 17:18:02] [info] [10944] Commons Daemon procrun (1.0.15.0 > 32-bit) started > [2013-05-09 17:18:02] [info] [10944] Running '' Service... > [2013-05-09 17:18:02] [info] [ 9224] Starting service... > [2013-05-09 17:18:11] [info] [ 9224] Service started in 9202 ms. > [2013-05-09 17:18:23] [info] [10780] Stopping service... > [2013-05-09 17:18:24] [info] [10780] Service stop thread completed. > This problem does not occur in daemon versions 11->14. > I have only seen it in daemon-1.0.15 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DAEMON-298) Windows service fails to stop with error code 1053 (using Windows 7 service manager)
[ https://issues.apache.org/jira/browse/DAEMON-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16057128#comment-16057128 ] Raghavaraju Kudari commented on DAEMON-298: --- Hi All, I am seeing same issue. I am able to start the service but when I am stopping service. It is not getting killed. I am trying with Tomcat 8.5.8 and JRE 1.8 with combination of WindRun4J. Any pointer would really helpful. > Windows service fails to stop with error code 1053 (using Windows 7 service > manager) > > > Key: DAEMON-298 > URL: https://issues.apache.org/jira/browse/DAEMON-298 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Windows 7 64bit - using 32-bit prunsrv.exe in jvm mode > Using 32-bit Java JRE 1.7.0_17 >Reporter: Andrew May >Assignee: Guillaume Chauvet > Labels: prunsrv, stop, windows > > Using Windows services manager (services.msc) to start/stop service. > Service installed with the following start/stop settings. > --StartMode=jvm --StartClass=com.myorg.MyClass --StartMethod=start > --StopMode=jvm --StopClass=com.myorg.MyClass --StopMethod=stop > Service starts OK. > When I use services manager to stop the service, the application stops > running but the prunsrv.exe process does not terminate. > Eventually the services manager reports that: > "Windows could not stop the service on Local Computer. Error > 1053: The service did not respond to the start or control request in a timely > fashion." > The service then stays at status "stopping" & cannot be restarted without > first killing the prunsrv.exe process. > Looking at the application logs I can see that the application's stop() > method gets called - the final line in this method is a logging call which is > executing OK. > The commons-daemon-.log file has the following entries: > [2013-05-09 17:18:02] [info] [10944] Commons Daemon procrun (1.0.15.0 > 32-bit) started > [2013-05-09 17:18:02] [info] [10944] Running '' Service... > [2013-05-09 17:18:02] [info] [ 9224] Starting service... > [2013-05-09 17:18:11] [info] [ 9224] Service started in 9202 ms. > [2013-05-09 17:18:23] [info] [10780] Stopping service... > [2013-05-09 17:18:24] [info] [10780] Service stop thread completed. > This problem does not occur in daemon versions 11->14. > I have only seen it in daemon-1.0.15 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DAEMON-362) CLONE - Windows service fails to stop with error code 1053 (using Windows 7 service manager)
Raghavaraju Kudari created DAEMON-362: - Summary: CLONE - Windows service fails to stop with error code 1053 (using Windows 7 service manager) Key: DAEMON-362 URL: https://issues.apache.org/jira/browse/DAEMON-362 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.15 Environment: Windows 7 64bit - using 32-bit prunsrv.exe in jvm mode Using 32-bit Java JRE 1.7.0_17 Reporter: Raghavaraju Kudari Assignee: Guillaume Chauvet Using Windows services manager (services.msc) to start/stop service. Service installed with the following start/stop settings. --StartMode=jvm --StartClass=com.myorg.MyClass --StartMethod=start --StopMode=jvm --StopClass=com.myorg.MyClass --StopMethod=stop Service starts OK. When I use services manager to stop the service, the application stops running but the prunsrv.exe process does not terminate. Eventually the services manager reports that: "Windows could not stop the service on Local Computer. Error 1053: The service did not respond to the start or control request in a timely fashion." The service then stays at status "stopping" & cannot be restarted without first killing the prunsrv.exe process. Looking at the application logs I can see that the application's stop() method gets called - the final line in this method is a logging call which is executing OK. The commons-daemon-.log file has the following entries: [2013-05-09 17:18:02] [info] [10944] Commons Daemon procrun (1.0.15.0 32-bit) started [2013-05-09 17:18:02] [info] [10944] Running '' Service... [2013-05-09 17:18:02] [info] [ 9224] Starting service... [2013-05-09 17:18:11] [info] [ 9224] Service started in 9202 ms. [2013-05-09 17:18:23] [info] [10780] Stopping service... [2013-05-09 17:18:24] [info] [10780] Service stop thread completed. This problem does not occur in daemon versions 11->14. I have only seen it in daemon-1.0.15 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MATH-1421) WilsonConfidenceInterval returning negative values
Mathijs Vogelzang created MATH-1421: --- Summary: WilsonConfidenceInterval returning negative values Key: MATH-1421 URL: https://issues.apache.org/jira/browse/MATH-1421 Project: Commons Math Issue Type: Bug Affects Versions: 3.6.1 Reporter: Mathijs Vogelzang Wilson confidence intervals sometimes return negative values as the lower bound, e.g. IntervalUtils.getWilsonScoreInterval(19436, 0, 0.95).getLowerBound() returns -1.3549849074815073E-20 This is causing assertion fails in our code, which we have fixed it now by wrapping the confidence score bounds in Math.max(0, Math.min(1, bound)) until the method doesn't return wrong results anymore. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
